<br><br><div class="gmail_quote">On Tue, Apr 17, 2012 at 5:47 PM, Shirts, Michael (mrs5pt) <span dir="ltr"><<a href="mailto:mrs5pt@eservices.virginia.edu">mrs5pt@eservices.virginia.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One other thing to note here is that HD5 is the basis for netCDF, at least<br>
since 2009, which is also very widely used. </blockquote><div>Yes NetCDF4 is based on HDF5. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So presumably if any group is<br>
using netCDF, they have a way to deal with HD5 portability as well.<br></blockquote><div>As far as I know NetCDF 3 is still quite widely used. Thus quite a few people don't run on top of HDF5 yet. But I think in the future this is true.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://en.wikipedia.org/wiki/NetCDF" target="_blank">http://en.wikipedia.org/wiki/NetCDF</a><br>
<br>
netCDF usage:<br>
<a href="http://www.unidata.ucar.edu/software/netcdf/docs/standards.html" target="_blank">http://www.unidata.ucar.edu/software/netcdf/docs/standards.html</a><br>
<a href="http://www.unidata.ucar.edu/software/netcdf/usage.html" target="_blank">http://www.unidata.ucar.edu/software/netcdf/usage.html</a><br>
<br>
BTW, Should we be bringing netCDF into the discussion as well? I don't know<br>
enough about I/O standards to answer that question myself. . .<br></blockquote><div><br></div><div>NetCDF-4 is just a front-end to HDF5. The same way as <a href="http://www.hdfgroup.org/HDF5/doc/HL/">http://www.hdfgroup.org/HDF5/doc/HL/</a> is. I think the question of whether we should be using either of these two high level APIs is a detail question which can be answered later. I think it has no important implication on the compatibility, source size, or available features.</div>
<div><br></div><div>NetCDF-3 would be an alternative. But given that it has some limitations and that the future is in NetCDF-4, I doubt it would be a good idea to base the design on that.</div><div><br></div><div>Roland </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
~~~~~~~~~~~~<br>
Michael Shirts<br>
Assistant Professor<br>
Department of Chemical Engineering<br>
University of Virginia<br>
<a href="mailto:michael.shirts@virginia.edu">michael.shirts@virginia.edu</a><br>
<a href="tel:%28434%29-243-1821" value="+14342431821">(434)-243-1821</a><br>
<br>
<br>
> From: Szilárd Páll <<a href="mailto:szilard.pall@cbr.su.se">szilard.pall@cbr.su.se</a>><br>
> Reply-To: Discussion list for GROMACS development <<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>><br>
> Date: Tue, 17 Apr 2012 23:35:50 +0200<br>
> To: Roland Schulz <<a href="mailto:roland@utk.edu">roland@utk.edu</a>><br>
> Cc: Erik Lindahl <<a href="mailto:erik@kth.se">erik@kth.se</a>>, Discussion list for GROMACS development<br>
> <<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>>, Daniel Spĺngberg <<a href="mailto:daniels@mkem.uu.se">daniels@mkem.uu.se</a>><br>
> Subject: [gmx-developers] Re: TNG format in Gromacs<br>
><br>
> Perhaps it could be advantageous to ask developers of portable codes<br>
> that use HDF5 about their experience.<br>
><br>
> There's a list of software using HDF5 on the website<br>
> (<a href="http://goo.gl/pnhkG" target="_blank">http://goo.gl/pnhkG</a>), but at the first glance I don't recognize any<br>
> software that I know it is highly portable (maybe ITK?). Is it only me<br>
> or the list itself is not that large?<br>
><br>
> --<br>
> Szilárd<br>
><br>
><br>
> On Tue, Apr 17, 2012 at 10:10 PM, Roland Schulz <<a href="mailto:roland@utk.edu">roland@utk.edu</a>> wrote:<br>
>><br>
>><br>
>> On Tue, Apr 17, 2012 at 1:57 PM, Erik Lindahl <<a href="mailto:erik@kth.se">erik@kth.se</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> On Apr 17, 2012, at 6:58 PM, Roland Schulz wrote:<br>
>>>><br>
>>>> Why does this require a scaled-down version? Why is not option to e.g.<br>
>>>> provide a custom Virtual File Layer? That would put the OS depending part<br>
>>>> in<br>
>>>> our hands.<br>
>>><br>
>>> This far we've heard three different sizes of HDF5 today, ranging from<br>
>>> ~50MB source to ~1MB source - I simply don't know how much it will be in<br>
>>> practice!<br>
>>> Once it gets below 1MB uncompressed (preferrably a few hundred K, but<br>
>>> that's no big deal) we're in the ballpark where it can be included in a<br>
>>> library for other codes to use, but 50MB source isn't :-)<br>
>>><br>
>>> What is the total size of _all_ the HDF5 code that would have to be<br>
>>> included in a stand-alone library that does not have to be linked with<br>
>>> anything else? Is that 130k lines, and could it be reduced further to make<br>
>>> it easier to support as part of the file format library?<br>
>>><br>
>>>> And even without. The OS depending part of HDF5 (otherwise it is also<br>
>>>> ANSI C) are a small part and it is OpenSource. So it is very much possible<br>
>>>> to fix ourselves. I doubt this is comparable to Charm++.<br>
>>><br>
>>> I think this is the core discussion item. Would somebody be willing to<br>
>>> support this code - including porting to new platforms that are considered<br>
>>> important for Gromacs even if they are not yet HDF5 platforms? *Hopefully*<br>
>>> that will never be any significant amount of work, but I simply don't know<br>
>>> HDF5 well enough to say, and we don't know what will happen in the future.<br>
>>><br>
>>> However, we don't want a situation where developers add library<br>
>>> dependencies because it is short-term convenient, and when that library<br>
>>> later causes long-term portability problems nobody really feels responsible.<br>
>>><br>
>>> Rossen has already volunteered to check HDF5 on a fujitsu system similar<br>
>>> to Kei - I think another first obvious step is for somebody to create the<br>
>>> smallest possible stand-alone version corresponding to what we would<br>
>>> include.<br>
>>><br>
>>> Rather than guessing I think we could have a much more informed discussion<br>
>>> when we know that compiles file on stuff like:<br>
>>><br>
>><br>
>> Getting started to test portability I list here the portability I was able<br>
>> to find online:<br>
>><br>
>>> - Itanium<br>
>><br>
>> yes: <a href="http://www.hdfgroup.org/HDF5/release/platforms516.html" target="_blank">http://www.hdfgroup.org/HDF5/release/platforms516.html</a><br>
>>><br>
>>> - Different x86 compilers (Open64, Portland, etc.)<br>
>><br>
>> PGI, Intel, GNU, Cray (according to those installed on Jaguar)<br>
>>><br>
>>> - Different windows versions & compilers<br>
>><br>
>> <a href="http://www.hdfgroup.org/HDF5/release/platforms516.html" target="_blank">http://www.hdfgroup.org/HDF5/release/platforms516.html</a> (XP, Vista; VS .Net,<br>
>> VS 2005, Cygwin)<br>
>>><br>
>>> - Nativeclient<br>
>>> - Fujitsu<br>
>><br>
>><br>
>> I can test Open64, Portland, VS2008, VS2010, Win7. Who can test<br>
>> Nativeclient?<br>
>><br>
>> Roland<br>
>>><br>
>>><br>
>>><br>
>>> Cheers,<br>
>>><br>
>>> Erik<br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>
>> <a href="tel:865-241-1537" value="+18652411537">865-241-1537</a>, ORNL PO BOX 2008 MS6309<br>
<span class="HOEnZb"><font color="#888888">> --<br>
> gmx-developers mailing list<br>
> <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
> Please don't post (un)subscribe requests to the list. Use the<br>
> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
<br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>