On Wed, May 30, 2012, Scott Le Grand wrote:
>
> I'm in the ugly middle of adding NMR support to pmemd.cuda. Adrian and I
> have observed the pastalicious mess that the FORTRAN code for this is right
> now.
Agreed. You and Adrian can figure which parts you want to support,
and ignore the rest. Much of the "varying conditions" stuff is hardly
used. For the restraints themselves, the code gets a lot of use, so is
probably worth putting in, but you could consider not supporting (or only
supporting) the interface from Matt Seetin.
>
> The prmtop is indeed flexible enough to support what you wish to do, but it
> also locks in the method of implementing the VDW parameters. This is a bad
> thing.
I guess I'm lost here. We do need an input routine to check if the
off-diagonal terms match the model that is being used, and to exit with a
error message if it is not. Longer term, we need to avoid dependence on
mixing rules, which leave too little flexibility the physics of things. We
had not before hit the memory problem you are experiencing on GPU's. [Are
you storing A and C coefficients by atom type (as in the prmtop file), or in
some other way that grows with the size of the system?]
>
> In fact it's a very bad thing. GPU and CPU architectures change over time
> and with over 20 years of commercial software development under my belt
> (and lots of battle scars from dysfunctional practices therein) I really
> think you don't want to do this.
What is "it" and "this" here (that we don't want to do)? Are you talking
about mixing rules, about "weird FORTRAN IV legacy code", or about something
else? To me, these seem like very different things.
....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed May 30 2012 - 11:00:04 PDT
