[gmx-developers] Re: TNG format in Gromacs

[Christoph Junghans]

Am 17. April 2012 10:49 schrieb Roland Schulz <roland at utk.edu>:
>
>
> 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
Matlab support HDF5 as well.
> - 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)
- HDF5 has support for windows
- their current version uses the cmake buildsystem, which would allow
us to use cmake's ExternalProject_Add feature to
download/build/install HDF5 as an dependency if it is not available on
the system.

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



-- 
Christoph Junghans
Web: http://www.compphys.de