<br><br><div class="gmail_quote">On Tue, Apr 17, 2012 at 12:29 PM, Peter Kasson <span dir="ltr"><<a href="mailto:kasson@stanford.edu">kasson@stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hmm--maybe we need to think about our goals here.<br>
<br>
I would assert that parallel I/O capabilities are the exotic<br>
requirement rather than portability to a wide range of<br>
hardware/software platforms. The great majority of hardware platforms<br>
and simulations (even on big Cray machines) will not require parallel<br>
I/O. So if parallel capability is driving a Gromacs standard, I think<br>
that may be a mis-weighted priority.<br></blockquote><div><br></div><div>Since this is a very long thread, let me copy my earlier preliminary list of HDF5 reasons:</div><div><br></div><div>====</div><div><div style>Parallel IO is not something which would benefit from HDF5 [it might make it even more complicate]. The advantages I see (as I said a preliminary list because we are in the middle of looking into it):</div>
<div style><br></div><div style>- User can use HDF5 tools to look at files</div><div style>- User can write easy scripts (simple binding to scripting languages) to analyze data</div><div style>- No large extra code base for container format in Gromacs (maintainability) </div>
<div style>- Less developer time (we can focus on MD specific code and not how to implement a container format)</div><div style>- Easy to implement convenience features (like adding structure and topology to trajectory; combining trajectory, energies, and extra output (e.g. pull) and thus having (optionally) only one output file; having build in history; making files user extendable)</div>
<div style>- Trajectory easy to index and seek (e.g. for parallel analysis)</div><div style><br></div><div style>Obviously one could either keep the own container format very simple, and thus would miss most convince features, tools, and language bindings, or one could make it very complex, and thus require a lot of developer time and have the maintainability issues. But without an external library one cannot have both.</div>
</div><div>====</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That question aside, there's the issue of what we want in a trajectory<br>
standard. My personal preference would be to go with a standard<br>
header/wrapper format *if* we can get a lightweight portable version<br>
that could be shipped with Gromacs e.g. xdr libraries. But I'm not<br>
strongly wedded to this vs. a simple home-build format, but it's a<br>
preference. My suggestion would be that if a developer feels strongly<br>
about HDF5, he or she might prepare a lightweight version.<br></blockquote><div><br></div><div>I think including a lightweight version is the worst option. It combines the main disadvantage of an own format (a large code base to maintain without many optional features (because lightweight)) </div>
<div>with a few extra disadvantages (extra code for HDF5 compatibility, less design choices). </div><div><br></div><div>Roland</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
--Peter<br>
<div class="HOEnZb"><div class="h5">--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>