[gmx-developers] Re: TNG format in Gromacs

[Roland Schulz]

On Tue, Apr 17, 2012 at 5:47 PM, Shirts, Michael (mrs5pt) <
mrs5pt at eservices.virginia.edu> wrote:

> One other thing to note here is that HD5 is the basis for netCDF, at least
> since 2009, which is also very widely used.

Yes NetCDF4 is based on HDF5.


> So presumably if any group is
> using netCDF, they have a way to deal with HD5 portability as well.
>
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.

>
> http://en.wikipedia.org/wiki/NetCDF
>
> netCDF usage:
> http://www.unidata.ucar.edu/software/netcdf/docs/standards.html
> http://www.unidata.ucar.edu/software/netcdf/usage.html
>
> BTW, Should we be bringing netCDF into the discussion as well?  I don't
> know
> enough about I/O standards to answer that question myself. . .
>

NetCDF-4 is just a front-end to HDF5. The same way as
http://www.hdfgroup.org/HDF5/doc/HL/ 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.

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.

Roland



>
> Best,
> ~~~~~~~~~~~~
> Michael Shirts
> Assistant Professor
> Department of Chemical Engineering
> University of Virginia
> michael.shirts at virginia.edu
> (434)-243-1821
>
>
> > From: Szilárd Páll <szilard.pall at cbr.su.se>
> > Reply-To: Discussion list for GROMACS development <
> gmx-developers at gromacs.org>
> > Date: Tue, 17 Apr 2012 23:35:50 +0200
> > To: Roland Schulz <roland at utk.edu>
> > Cc: Erik Lindahl <erik at kth.se>, Discussion list for GROMACS development
> > <gmx-developers at gromacs.org>, Daniel Spångberg <daniels at mkem.uu.se>
> > Subject: [gmx-developers] Re: TNG format in Gromacs
> >
> > Perhaps it could be advantageous to ask developers of portable codes
> > that use HDF5 about their experience.
> >
> > There's a list of software using HDF5 on the website
> > (http://goo.gl/pnhkG), but at the first glance I don't recognize any
> > software that I know it is highly portable (maybe ITK?). Is it only me
> > or the list itself is not that large?
> >
> > --
> > Szilárd
> >
> >
> > On Tue, Apr 17, 2012 at 10: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?
> >>
> >> Roland
> >>>
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Erik
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> >> 865-241-1537, ORNL PO BOX 2008 MS6309
> > --
> > gmx-developers mailing list
> > gmx-developers at gromacs.org
> > http://lists.gromacs.org/mailman/listinfo/gmx-developers
> > Please don't post (un)subscribe requests to the list. Use the
> > www interface or send it to gmx-developers-request at gromacs.org.
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
>
>
>
>


-- 
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/1460d8d0/attachment.html>