<br><br><div class="gmail_quote">On Tue, Apr 17, 2012 at 5:47 PM, Shirts, Michael (mrs5pt) <span dir="ltr">&lt;<a href="mailto:mrs5pt@eservices.virginia.edu">mrs5pt@eservices.virginia.edu</a>&gt;</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&#39;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&#39;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>
&gt; From: Szilárd Páll &lt;<a href="mailto:szilard.pall@cbr.su.se">szilard.pall@cbr.su.se</a>&gt;<br>
&gt; Reply-To: Discussion list for GROMACS development &lt;<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>&gt;<br>
&gt; Date: Tue, 17 Apr 2012 23:35:50 +0200<br>
&gt; To: Roland Schulz &lt;<a href="mailto:roland@utk.edu">roland@utk.edu</a>&gt;<br>
&gt; Cc: Erik Lindahl &lt;<a href="mailto:erik@kth.se">erik@kth.se</a>&gt;, Discussion list for GROMACS development<br>
&gt; &lt;<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>&gt;, Daniel Spĺngberg &lt;<a href="mailto:daniels@mkem.uu.se">daniels@mkem.uu.se</a>&gt;<br>
&gt; Subject: [gmx-developers] Re: TNG format in Gromacs<br>
&gt;<br>
&gt; Perhaps it could be advantageous to ask developers of portable codes<br>
&gt; that use HDF5 about their experience.<br>
&gt;<br>
&gt; There&#39;s a list of software using HDF5 on the website<br>
&gt; (<a href="http://goo.gl/pnhkG" target="_blank">http://goo.gl/pnhkG</a>), but at the first glance I don&#39;t recognize any<br>
&gt; software that I know it is highly portable (maybe ITK?). Is it only me<br>
&gt; or the list itself is not that large?<br>
&gt;<br>
&gt; --<br>
&gt; Szilárd<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Apr 17, 2012 at 10:10 PM, Roland Schulz &lt;<a href="mailto:roland@utk.edu">roland@utk.edu</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Apr 17, 2012 at 1:57 PM, Erik Lindahl &lt;<a href="mailto:erik@kth.se">erik@kth.se</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Apr 17, 2012, at 6:58 PM, Roland Schulz wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Why does this require a scaled-down version? Why is not option to e.g.<br>
&gt;&gt;&gt;&gt; provide a custom Virtual File Layer? That would put the OS depending part<br>
&gt;&gt;&gt;&gt; in<br>
&gt;&gt;&gt;&gt; our hands.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This far we&#39;ve heard three different sizes of HDF5 today, ranging from<br>
&gt;&gt;&gt; ~50MB source to ~1MB source - I simply don&#39;t know how much it will be in<br>
&gt;&gt;&gt; practice!<br>
&gt;&gt;&gt; Once it gets below 1MB uncompressed (preferrably a few hundred K, but<br>
&gt;&gt;&gt; that&#39;s no big deal) we&#39;re in the ballpark where it can be included in a<br>
&gt;&gt;&gt; library for other codes to use, but 50MB source isn&#39;t :-)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What is the total size of _all_ the HDF5 code that would have to be<br>
&gt;&gt;&gt; included in a stand-alone library that does not have to be linked with<br>
&gt;&gt;&gt; anything else? Is that 130k lines, and could it be reduced further to make<br>
&gt;&gt;&gt; it easier to support as part of the file format library?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; And even without. The OS depending part of HDF5 (otherwise it is also<br>
&gt;&gt;&gt;&gt; ANSI C) are a small part and it is OpenSource. So it is very much possible<br>
&gt;&gt;&gt;&gt; to fix ourselves. I doubt this is comparable to Charm++.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I think this is the core discussion item. Would somebody be willing to<br>
&gt;&gt;&gt; support this code - including porting to new platforms that are considered<br>
&gt;&gt;&gt; important for Gromacs even if they are not yet HDF5 platforms?  *Hopefully*<br>
&gt;&gt;&gt; that will never be any significant amount of work, but I simply don&#39;t know<br>
&gt;&gt;&gt; HDF5 well enough to say, and we don&#39;t know what will happen in the future.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; However, we don&#39;t want a situation where developers add library<br>
&gt;&gt;&gt; dependencies because it is short-term convenient, and when that library<br>
&gt;&gt;&gt; later causes long-term portability problems nobody really feels responsible.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Rossen has already volunteered to check HDF5 on a fujitsu system similar<br>
&gt;&gt;&gt; to Kei - I think another first obvious step is for somebody to create the<br>
&gt;&gt;&gt; smallest possible stand-alone version corresponding to what we would<br>
&gt;&gt;&gt; include.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Rather than guessing I think we could have a much more informed discussion<br>
&gt;&gt;&gt; when we know that compiles file on stuff like:<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Getting started to test portability I list here the portability I was able<br>
&gt;&gt; to find online:<br>
&gt;&gt;<br>
&gt;&gt;&gt; - Itanium<br>
&gt;&gt;<br>
&gt;&gt; yes: <a href="http://www.hdfgroup.org/HDF5/release/platforms516.html" target="_blank">http://www.hdfgroup.org/HDF5/release/platforms516.html</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; - Different x86 compilers (Open64, Portland, etc.)<br>
&gt;&gt;<br>
&gt;&gt; PGI, Intel, GNU, Cray (according to those installed on Jaguar)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; - Different windows versions &amp; compilers<br>
&gt;&gt;<br>
&gt;&gt; <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>
&gt;&gt; VS 2005, Cygwin)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; - Nativeclient<br>
&gt;&gt;&gt; - Fujitsu<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I can test Open64, Portland, VS2008, VS2010, Win7. Who can test<br>
&gt;&gt; Nativeclient?<br>
&gt;&gt;<br>
&gt;&gt; Roland<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Cheers,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Erik<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>
&gt;&gt; <a href="tel:865-241-1537" value="+18652411537">865-241-1537</a>, ORNL PO BOX 2008 MS6309<br>
<span class="HOEnZb"><font color="#888888">&gt; --<br>
&gt; gmx-developers mailing list<br>
&gt; <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
&gt; <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
&gt; Please don&#39;t post (un)subscribe requests to the list. Use the<br>
&gt; 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&#39;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>