[gmx-developers] Re: TNG format in Gromacs

[Roland Schulz]

On Tue, Apr 17, 2012 at 12:29 PM, Peter Kasson <kasson at stanford.edu> wrote:

> Hmm--maybe we need to think about our goals here.
>
> I would assert that parallel I/O capabilities are the exotic
> requirement rather than portability to a wide range of
> hardware/software platforms.  The great majority of hardware platforms
> and simulations (even on big Cray machines) will not require parallel
> I/O.  So if parallel capability is driving a Gromacs standard, I think
> that may be a mis-weighted priority.
>

Since this is a very long thread, let me copy my earlier preliminary list
of HDF5 reasons:

====
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):

- User can use HDF5 tools to look at files
- User can write easy scripts (simple binding to scripting languages) to
analyze data
- No large extra code base for container format in Gromacs
(maintainability)
- Less developer time (we can focus on MD specific code and not how to
implement a container format)
- 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)
- Trajectory easy to index and seek (e.g. for parallel analysis)

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.
====


> That question aside, there's the issue of what we want in a trajectory
> standard.  My personal preference would be to go with a standard
> header/wrapper format *if* we can get a lightweight portable version
> that could be shipped with Gromacs e.g. xdr libraries.  But I'm not
> strongly wedded to this vs. a simple home-build format, but it's a
> preference.  My suggestion would be that if a developer feels strongly
> about HDF5, he or she might prepare a lightweight version.
>

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))
with a few extra disadvantages (extra code for HDF5 compatibility, less
design choices).

Roland


>
> Best,
> --Peter
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
>
>
>
>


-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20120417/a791b502/attachment.html>