I should really stop getting roped into these discussions, but...
On Mon, May 28, 2012 at 8:30 AM, Scott Le Grand <varelse2005.gmail.com>wrote:
> It's relatively easy (though awkward) to fix OPLS support, but adding
> support for manual tweaking of off-diagonal entries will cost SM 1.3
> support for the entire program for a variety of reasons, and even then,
> there will be a performance cliff when shared memory is exhausted. My own
> opinion is that off-diagonal hacking is really ill-specified at this time
> and it would be better to clean that up into something more obiously
> specified in a machine-readable format before it goes any further.
>
For my part I tend to disagree. Off-diagonal modification could be enabled
in tleap in a straightforward way (just add a new tleap command for it).
It would generate exactly the same topology file that ParmEd produces --
the current prmtop format is already flexible enough to fully allow this
behavior.
Pmemd.cuda derived its behavior from the force field definition not the
> actual values in the cn1 and cn2 tables which seemed to be
> machine-generated (and IMO) ought to remain so.
>
I agree, yet claim that ParmEd-modified A/B-coefficient matrices are still
machine-generated. It is logically equivalent to NBFIX implemented in the
CHARMM force field, but implemented through the prmtop. (And chamber
prmtops are supported here, and technically NBFIX is part of the CHARMM FF,
or so I've been told.) Therefore, I claim this is fairly well-defined
behavior.
However, I think it should be treated like a new feature to pmemd.cuda --
add it if there is enough demand to warrant the effort. At this point,
there clearly is not, so we just add a check for it and wait.
Just my 2c,
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 Tue May 29 2012 - 12:30:03 PDT
