[gmx-developers] Re: TNG format in Gromacs

[Szilárd Páll]

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