[gmx-developers] Re: TNG format in Gromacs

[Szilárd Páll]

On Tue, Apr 17, 2012 at 7: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:
>
> - Itanium
> - Different x86 compilers (Open64, Portland, etc.)

Slightly offtopic, but it shows very well how non-trivial portability
is even with a quite strict ISO C adherence.

In fact, even the current GROMACS code is not as portable as one might
think/wish: 4.6 will most probably not work/partially work with
current versions of AMD Open64, PGI, EkoPath, and the Cray compiler --
at least until code generation and/or optimization bugs in these
compilers get fixed. Note that even 4.5 doesn't work with some of the
aforementioned compilers.

--
Szilárd


> - Different windows versions & compilers
> - Nativeclient
> - Fujitsu
>
>
> Cheers,
>
> Erik