On this note about file sizes and such, what about simply extending the
restart file format to permit the printing of larger numbers in ASCII?
Having to wrap coordinates in some trajectories can be detrimental to
analysis, and while the NetCDF format permits much longer simulations
without wrapping, the restart file format is still constrictive.
Extending the numbers to something like %15.7f rather than the current
%12.7f would, I think, be reasonable.
Dave
On Wed, 12 Dec 2007, Robert Duke wrote:
> 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:09 PST
