[gmx-developers] Re: TNG format in Gromacs

[Roland Schulz]

On Tue, Apr 17, 2012 at 12:55 PM, Erik Lindahl <erik at kth.se> wrote:

> Hi,
>
> On Apr 17, 2012, at 6:14 PM, Szilárd Páll wrote:
>
> > a) The need for a new format which will *immediately* replace XTC as
> > the default in Gromacs and seems to have requirements that pretty much
> > exclude any external library (that is not as widespread as libc :).
> >
> > b) It's not in line with the EU deliverable which requires a new
> > library with certain specs to be written. Could it be that this is the
> > classic case where the specification was created before the actual
> > requirement engineering?
>
> No, I don't think so, but the goals are different: I very much see the
> point for a file format that enables you to do fancy stuff, but if you want
> a file format that is supported by as many applications as possible you
> have to settle for the greatest common divisor.
>
> >
> > c) The apparent need for ultimate portability to extremely rare and
> > exotic architectures without accepting XTC as a fallback on these
> > platforms (with conversion for post-processing and analysis). I might
> > be wrong, but to me it seems that these extremely rare architectures
> > are often more showcase platforms rather than the iron on which 99% of
> > the science is carried out.
>
> Well, windows was exactly such a very exotic architecture until we started
> using Gromacs in Folding at Home. In hindsight, the decision to rely on XDR
> libraries for all our IO was a bad one.
>
> Just counting core-hours, I actually think windows is one of our most
> common Gromacs architectures today. Similarly, I think there is a clear
> possibility nativeclient could become a dominant platform quite soon if
> Google decides to push it for cloud services. It is very difficult to make
> predictions, in particular about the future.
>
> *Of course* does not mean a new default file format must be 100% portable
> without modifying the code.
>
> > Wouldn't it be beneficial to struck a balance
> > between portability and effort/time required by accepting a short-term
> > "compromise" (which isn't really a compromise if we don't consider
> > ultimate portability a strict requirement :). XTC will have to be
> > anyway maintained anyway so it could as well be kept as the
> > alternative for platforms where the new format is not supported in
> > early versions. So a file format that works on all reference platforms
> > (that we can and should simply list and track) with XTC  as a fallback
> > for the exotic iron should be an acceptable compromise, I'd say.
>
> I think that's a perfectly valid short- and long-term balance *as long as
> there is a way to gradually expand support to other platforms as we need
> it*.
>
> The problem isn't the unimportant platforms, but when a new platform gets
> important for us, while it might not yet be important for the external
> library. What do we do when 10MB of source code fails to work on one of our
> reference platforms?
>
I think the file size (10MB) is not a good metric. A lot is demo and test
code. As I said 130k lines is the total code and only 18 files with total
of 9300 lines have Windows #ifdef in them. Thus adding Windows support (if
it wouldn't be their) is something absolutely feasible for us (optional by
paid or HPC center support).

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/1bfb8c14/attachment.html>