Getting on Soapbox:
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.
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.
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.
To see why, take a good long look at the pile of weird FORTRAN IV legacy
code sitting in PMEMD right now that has significant performance and code
analysis consequences.
You may understand what you did to prmtop and you may even tell your
colleagues but given that we still have a bunch of FORTRAN IV
colloquialisms hanging around to extend people's stints in grad school and
as post-docs, IMO you should code this more defensively and assume whatever
you do will hang around for at least until your unborn children are in grad
school and cursing your name for writing this code the way you did.
Just my two cents...
Scott
On Tue, May 29, 2012 at 12:15 PM, Jason Swails <jason.swails.gmail.com>wrote:
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed May 30 2012 - 08:30:04 PDT
