On Fri, Apr 15, 2011 at 10:42 AM, David A Case <case.biomaps.rutgers.edu>wrote:
> On Fri, Apr 15, 2011, Ross Walker wrote:
>
> [Moving this over to the amber-developers mailing list.]
>
> >
> > With regards to the second problem I think the issue here is that you end
> up
> > with a bond that spans molecules.
>
> Things like this impact imaging and the barostat. As for imaging, my
> hope(?!?) is that people will move to a netcdf restart format, which should
> greatly reduce the need to set iwrap=1 during dynamics. (Alternatively,
> the
> iwrap code in sander/pmemd needs to become as sophisticated [and
> complicated]
> as what is in ptraj.)
>
I completely support moving to NetCDF restart files. This is going to be
especially useful for any kind of generalized replica exchange if we're
going to avoid exchanging coordinates at all costs. If all we do are
exchange restraint locations, temperatures, etc., then the restart files
needs to be able to track exactly *which* set of conditions it corresponds
to. NetCDF files are ideally suited for this (just add a variable/array
with the REMD 'dimension' location). This becomes infeasible with the
current ASCII restart file format. To that end, though, there needs to
actually be a real push in that direction.
I elect to at least aim to move entirely to NetCDF files for coordinate
processing. Which is to say, I think we should work on changing the default
ioutfm to be 1 (at least inside an #ifdef BINTRAJ), and after the binary
restart has been sufficiently validated, move to that as well (but that will
probably have to wait a couple of versions so we can actually support
backwards-compatibility easily for this).
However, this would need to be implemented in pmemd, obviously, for any kind
of widespread adoption.
> For the barostat:
> In the short- to medium time frame (e.g. for Amber12) I think we should
> really
> explore porting Dave Cerutti's(*) Monte Carlo barostat to pmemd. This
> avoids
> calculation of the virial (and hence simplifies things by removing all the
> code that relates to that) and doesn't require any knowledge of
> "molecules".
> The cost is an extra energy evaluation at each step where a trial volume
> change "move" is attempted. I *think* we will be able to do this only
> every
> 20-100 steps (especially for long simulations, where you would still get
> lots
> of moves), which implies a 1-5% overhead, comparable to what we currently
> pay
> for NPT vs NVT. Things like parallel scaling need to be addressed, but I
> think that we can just use our current parallel technology for this.
>
I agree completely (that we can use the current parallel technology for
this). In fact, Bob put in a switch for calculating the virials. If the
code behaves like I expect it to behave, we could implement this barostat
quite simply in pmemd by simply adding another subroutine for that
calculation and always turning off the virial switch. That should leave
current scaling completely intact, and as long as the barostat moves aren't
that extensive, we would probably not ever have to rebuild pairlists or
redistribute the workload for these extra force calls (which would be easy
to add). I'd be willing to work with Dave in implementing this in pmemd
(making sure we don't affect present performance). We'd probably have to
back-port this to sander (it's probably much easier to implement efficiently
in pmemd)...
All the best,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Apr 15 2011 - 11:30:03 PDT
