[gmx-developers] Re: TNG format in Gromacs

[Roland Schulz]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20120417/bbad7319/attachment.html>