Re: amber-developers: Fw: How many atoms?

From: Robert Duke <rduke.email.unc.edu>
Date: Wed, 12 Dec 2007 14:35:14 -0500

Hi John,
I am not like violently opposed to implementing NetCDF restrts (and thus
inpcrds), but the reasons for doing this are substantially less compelling
than for the trajectory file. Basically, there really is not that much of a
performance impact to writing out formatted restrts, as the frequency is
typically pretty low (say compared to trajectory snapshots). PMEMD backs
the default frequency off as you add processors. So any real argument to my
mind would be in the realm of better retained precision, but the formatted
restrt already has substantially more precision than is really necessary.
While I like the binary stuff for it's improved performance and portability,
it does have two downsides: 1) harder to read, requiring an intermediate
tool, and 2) on some machines, the performance actually is worse - I am
thinking here about the lustre filesystem on the cray xt* machines - they
have an io buffering library that helps with formatted fortran i/o but not
the netcdf stuff (last time I checked anyway). And the bloody cray xt*
machines are still prone to extraordinary variations in performance due to
who knows what all factors, but at one time at least it included file i/o.
Anyway, this is an amber 11 discussion, and I at least am still hammered
trying to get stuff into 10 :-)
Regards - Bob

----- Original Message -----
From: "John Mongan" <jmongan.mccammon.ucsd.edu>
To: <amber-developers.scripps.edu>
Sent: Wednesday, December 12, 2007 2:14 PM
Subject: Re: amber-developers: Fw: How many atoms?


> I'm a little late to the discussion as I've been on the road, but that
> won't stop me from throwing in my (late) two cents.
>
> On the issue of a new inpcrd/restrt format that can support 1M+ atoms,
> what about using the NetCDF trajectory format? As I see it, some
> advantages are (some of these may not be benefits relative to amoeba
> format; I'm not familiar with its particulars):
>
> * we already have full support in ptraj and VMD
> * sander and pmemd would require some "plumbing" work, but most of the
> needed code is already there
> * *leap doesn't know how to speak NetCDF, but it's a pretty
> straight-forward API, probably easier than having to write to a new file
> spec
> * performance and filesize benefits
> * It's an extensible format so further down the road things like constant
> pH that currently require separate restart files might be folded in.
>
> Some thoughts on how the interface might work: To avoid adding yet another
> flag to mdin, we could detect the format of the inpcrd file and write
> restarts in the same format. If we default to using data from the last
> frame of NetCDF inpcrd files, then you could restart a run directly from
> the trajectory file of the previous run without having to process it
> through ptraj. In some cases this might even eliminate the user's need for
> a separate restart file.
>
> It appears that we have (wisely, I think) decided not to implement any of
> this in time for 10, so we have some time to work it out. What do you all
> think? If people like the idea, I'll volunteer to do the implementation in
> sander.
>
> John
>
Received on Sun Dec 16 2007 - 06:07:08 PST
Custom Search