On Sat, Feb 27, 2016 at 12:43 AM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
> > On Feb 26, 2016, at 9:40 PM, Jason Swails <jason.swails.gmail.com>
> wrote:
> >
> > On Sat, Feb 27, 2016 at 12:24 AM, Hai Nguyen <nhai.qn.gmail.com> wrote:
> >
> >> Never mind, I think you meant to reply to Gerald but actually quoted me.
> >>
> >
> > I was anticipating the argument that you would only have to store *one*
> > uncompressed ASCII trajectory at a time (since you'd compress before
> > writing another one), so you'd still get net savings in disk space. But
> > you pay for that disk space savings by sacrificing data (and in some
> cases,
> > trajectory integrity).
> >
> > Your point is certainly valid that Amber can't write compressed ASCII
> > trajectories directly (cpptraj can :)). All told, the benefits of
> ioutfm=1
> > *far* outweigh the benefits of ioutfm=0. ioutfm=1 is a much more
> sensible
> > default.
>
> Is there any real benefit we could gain from compressed netcdf
> trajectories?
Not gzip or bzip2. Maybe if we go with NetCDF-4 (which sits on top of
HDF5), but that would complicate the Amber build by introducing additional
dependencies.
> (and restarts)? in pmemd. I am guessing they don't compress much but it
> might help on performance on systems with slow disk access? - Also is there
> support for writing netcdf files in parallel? We could 'potentially' avoid
> a coordinate reduction if we could write out in parallel but still get a
> single coherent netcdf file.
>
That's only for CPU pmemd, right? My suspicion is that it won't even come
close to being worth the effort. What's the difference between ns/day with
ntwx=0 (no trajectory) and ntwx=500? >1%? I'd be surprised. That's a lot
of effort to go through to make something not even noticeably faster.
The reduction isn't the expensive part, anyway (really a gather, but who
cares). We do reductions every 20 steps or so, anyway, each time the
pairlist is rebuilt. The only thing that could make this slow is slow
filesystem access. In that case, pnetcdf might help. Or might not. I
doubt it'd help much, if at all. I really don't think trajectory writing
kills our scaling (or even touches it).
All the best,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Feb 26 2016 - 22:00:05 PST
