[gmx-developers] Re: TNG format in Gromacs

[Shirts, Michael (mrs5pt)]

One other thing to note here is that HD5 is the basis for netCDF, at least
since 2009, which is also very widely used.  So presumably if any group is
using netCDF, they have a way to deal with HD5 portability as well.

http://en.wikipedia.org/wiki/NetCDF

netCDF usage:
http://www.unidata.ucar.edu/software/netcdf/docs/standards.html
http://www.unidata.ucar.edu/software/netcdf/usage.html

BTW, Should we be bringing netCDF into the discussion as well?  I don't know
enough about I/O standards to answer that question myself. . .

Best,
~~~~~~~~~~~~
Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu
(434)-243-1821


> From: Szilárd Páll <szilard.pall at cbr.su.se>
> Reply-To: Discussion list for GROMACS development <gmx-developers at gromacs.org>
> Date: Tue, 17 Apr 2012 23:35:50 +0200
> To: Roland Schulz <roland at utk.edu>
> Cc: Erik Lindahl <erik at kth.se>, Discussion list for GROMACS development
> <gmx-developers at gromacs.org>, Daniel Spångberg <daniels at mkem.uu.se>
> Subject: [gmx-developers] Re: TNG format in Gromacs
> 
> Perhaps it could be advantageous to ask developers of portable codes
> that use HDF5 about their experience.
> 
> There's a list of software using HDF5 on the website
> (http://goo.gl/pnhkG), but at the first glance I don't recognize any
> software that I know it is highly portable (maybe ITK?). Is it only me
> or the list itself is not that large?
> 
> --
> Szilárd
> 
> 
> On Tue, Apr 17, 2012 at 10:10 PM, Roland Schulz <roland at utk.edu> wrote:
>> 
>> 
>> On Tue, Apr 17, 2012 at 1:57 PM, Erik Lindahl <erik at kth.se> wrote:
>>> 
>>> Hi,
>>> 
>>> On Apr 17, 2012, at 6:58 PM, Roland Schulz wrote:
>>>> 
>>>> Why does this require a scaled-down version? Why is not option to e.g.
>>>> provide a custom Virtual File Layer? That would put the OS depending part
>>>> in
>>>> our hands.
>>> 
>>> This far we've heard three different sizes of HDF5 today, ranging from
>>> ~50MB source to ~1MB source - I simply don't know how much it will be in
>>> practice!
>>> Once it gets below 1MB uncompressed (preferrably a few hundred K, but
>>> that's no big deal) we're in the ballpark where it can be included in a
>>> library for other codes to use, but 50MB source isn't :-)
>>> 
>>> What is the total size of _all_ the HDF5 code that would have to be
>>> included in a stand-alone library that does not have to be linked with
>>> anything else? Is that 130k lines, and could it be reduced further to make
>>> it easier to support as part of the file format library?
>>> 
>>>> And even without. The OS depending part of HDF5 (otherwise it is also
>>>> ANSI C) are a small part and it is OpenSource. So it is very much possible
>>>> to fix ourselves. I doubt this is comparable to Charm++.
>>> 
>>> I think this is the core discussion item. Would somebody be willing to
>>> support this code - including porting to new platforms that are considered
>>> important for Gromacs even if they are not yet HDF5 platforms?  *Hopefully*
>>> that will never be any significant amount of work, but I simply don't know
>>> HDF5 well enough to say, and we don't know what will happen in the future.
>>> 
>>> However, we don't want a situation where developers add library
>>> dependencies because it is short-term convenient, and when that library
>>> later causes long-term portability problems nobody really feels responsible.
>>> 
>>> Rossen has already volunteered to check HDF5 on a fujitsu system similar
>>> to Kei - I think another first obvious step is for somebody to create the
>>> smallest possible stand-alone version corresponding to what we would
>>> include.
>>> 
>>> Rather than guessing I think we could have a much more informed discussion
>>> when we know that compiles file on stuff like:
>>> 
>> 
>> Getting started to test portability I list here the portability I was able
>> to find online:
>> 
>>> - Itanium
>> 
>> yes: http://www.hdfgroup.org/HDF5/release/platforms516.html
>>> 
>>> - Different x86 compilers (Open64, Portland, etc.)
>> 
>> PGI, Intel, GNU, Cray (according to those installed on Jaguar)
>>> 
>>> - Different windows versions & compilers
>> 
>> http://www.hdfgroup.org/HDF5/release/platforms516.html (XP, Vista; VS .Net,
>> VS 2005, Cygwin)
>>> 
>>> - Nativeclient
>>> - Fujitsu
>> 
>> 
>> I can test Open64, Portland, VS2008, VS2010, Win7. Who can test
>> Nativeclient?
>> 
>> Roland
>>> 
>>> 
>>> 
>>> Cheers,
>>> 
>>> Erik
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> --
>> 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.