[gmx-developers] Re: TNG format in Gromacs

[Roland Schulz]

On Tue, Apr 17, 2012 at 4: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?
>

Open64, Portland, and VS2010 on Win7 work too.

Roland


> Roland
>
>>
>>
>> Cheers,
>>
>> Erik
>>
>>
>>
>>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
>



-- 
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/20120418/e0319335/attachment.html>