<div dir="ltr">Hi,<div><br></div><div>Yes, that&#39;s my point too :-)  First, I&#39;m all for just picking JSON right away, but there are a few additional things that are not rocket science, but that we also should settle on before hacking away to avoid each data file inventing its own standard. For instance:</div><div><br></div><div>* How do we handle units? Lists?  </div><div><br></div><div>* How do we specify any property that depends on the name/type of a particle, residue, or chain? How do we specify things that depend on pairwise combinations?</div><div><br></div><div>* How do we handle text fields/comments that we might want to be able to read into Gromacs? <br></div><div><br></div><div>* We should have some sort of metadata for all parameters that describe the source, and what program version or person who wrote it. How should references to scientific papers be specified so we don&#39;t have to parse them from free text format?</div><div><br></div><div>* It would be good to decide on some labels on the very highest level as we implement things. Initially we might only have &quot;ChemicalProperties&quot;, but that way it will be more straightforward to later add more labels so we get a nice hierarchical description - without having to decide all other labels now. If I undersand JSON correctly, it does not have functionality for including a file into another, but if each file contains a hierarchy description of the data it might be possible to just concatenate them?</div><div><br></div><div>* How should this type of (extensible) data be represented on class level in the code (so we avoid one implementation for each tool that needs external data)? This should be independent of the file storage format - if some of tools are IO-bound this will make it possible to later implement a binary alternative, possibly including automatic compilation from updated text files.</div><div><br></div><div><br></div><div>Anything else we should consider?</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 5:22 PM, Berk Hess <span dir="ltr">&lt;<a href="mailto:hess@kth.se" target="_blank">hess@kth.se</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi,</p>
<p dir="ltr">I think David question is not so much about our current data handled by pdb2gmx, but rather for new data he needs to handle. We should of course keep the whole picture in mind, but we should not end up in endless topology formatting discussions, when all we need right away is a more generic container type format organization.</p>
<p dir="ltr">Cheers,</p>
<p dir="ltr">Berk</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On May 12, 2016 6:06 PM, Erik Lindahl &lt;<a href="mailto:erik.lindahl@gmail.com" target="_blank">erik.lindahl@gmail.com</a>&gt; wrote:<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Rome wasn&#39;t built in a day, so no - I don&#39;t want the kitchen sink initially. However, it would be good if we could decide on some high-level principles and roughly how formats should later be implemented hierarchically. </div><div><br></div><div>Where should comments and metadata go? Can we get a format where it is trivial to combine multiple files if a new analysis tools suddenly needs multiple types of data already implemented for other programs (without writing a new parser)?  For instance, if we were to rewrite pdb2gmx, roughly how should all those files be organized?</div><div><br></div><div>With a bit of thought and a common parsing layer, it feels like it should be much easier for any developer to start adding/changing formats one-by-one instead of having a large discussion involving everybody each time somebody needs to add a file type!</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div><div><br></div></div><div><br><div>On Thu, May 12, 2016 at 4:54 PM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>&gt;</span> wrote:<br><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi,<br><br></div>What&#39;s the scope? If we want to write a wrapper layer around some JSON code so people can use it for parsing input files, while we have a way to replace the dependency with something else in the future, then that&#39;s pretty much fine by me.<br><br></div><div>What I&#39;m not keen on is the rabbit hole of converting all our existing parameter-like file formats to some JSON format. That amounts to re-writing lots of our setup tools. That would likely be a big improvement in code quality, but it&#39;s dozens of hours of input from quite a few people to agree on how it should look, and then a few coding months to write tests, re-implement the code, and get it reviewed. This create a bunch of friction for users, for no immediate gain. Who&#39;s got the resources for that, and what&#39;s the big payoff?<font color="#888888"><br></font></div><font color="#888888"></font><div><br></div>Mark<br></div><div><div><br><div><div dir="ltr">On Thu, May 12, 2016 at 5:25 PM David van der Spoel &lt;<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>&gt; wrote:<br></div><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/05/16 14:16, Erik Lindahl wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; While I’m all for JSON, the format per se isn’t critical. What is needed is for somebody (or a couple of people) to sit down and start working on a larger framework for writing and reading all sorts of data, and how to handle this in an abstract way. Then the actual file format is simply a module that can be replaced if we ever want to change it.  But, this will require volunteers!<br>
&gt;<br>
This is what we discussed in the gerrit patch, to have a module on top<br>
of it that would form the API for the rest of the code. For me this is<br>
the most important thing to decide in gmx development in the near future.<br>
<br>
&gt; Just picking a format and then having dozens of modules all fire away with creating their own data fields directly in that format doesn’t bring any more portability than using raw text files, IMHO :-)<br>
&gt;<br>
&gt; Cheers,<br>
&gt;<br>
&gt; Erik<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt; On 12 May 2016, at 12:40, David van der Spoel &lt;<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; with the developer meeting coming up next week I would like to once again bring up the issue of what file format to use for database files. We have discussed this for over ten years and not having a decision is stopping innovation.<br>
&gt;&gt;<br>
&gt;&gt; I propose we vote on it at the meeting next week if we can not reach concensus. Personally I am beyond caring which of the two as long as we make a decision - now we have nothing.<br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt; --<br>
&gt;&gt; David van der Spoel, Ph.D., Professor of Biology<br>
&gt;&gt; Dept. of Cell &amp; Molec. Biol., Uppsala University.<br>
&gt;&gt; Box 596, 75124 Uppsala, Sweden. Phone:       <a href="tel:%2B46184714205" target="_blank">+46184714205</a>.<br>
&gt;&gt; <a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>    <a href="http://folding.bmc.uu.se" target="_blank">http://folding.bmc.uu.se</a><br>
&gt;&gt; --<br>
&gt;&gt; Gromacs Developers mailing list<br>
&gt;&gt;<br>
&gt;&gt; * Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
&gt;&gt;<br>
&gt;&gt; * Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
&gt;&gt;<br>
&gt;&gt; * For (un)subscribe requests visit<br>
&gt;&gt; <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
&gt;<br>
<br>
<br>
--<br>
David van der Spoel, Ph.D., Professor of Biology<br>
Dept. of Cell &amp; Molec. Biol., Uppsala University.<br>
Box 596, 75124 Uppsala, Sweden. Phone:  <a href="tel:%2B46184714205" target="_blank">+46184714205</a>.<br>
<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>    <a href="http://folding.bmc.uu.se" target="_blank">http://folding.bmc.uu.se</a><br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>
</div></div><br>--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr">--<div>Erik Lindahl &lt;<a href="mailto:erik.lindahl@gmail.com" target="_blank">erik.lindahl@gmail.com</a>&gt;</div><div>Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div>
</div>
</blockquote></div></div></div><br>--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">--<div>Erik Lindahl &lt;<a href="mailto:erik.lindahl@gmail.com" target="_blank">erik.lindahl@gmail.com</a>&gt;</div><div>Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div>
</div>