On Fri, Nov 1, 2013 at 5:54 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> OK, after chatting with Tom about this a bit I think we've hit upon a
> potentially useful solution. The basic idea is to have a new parameter
> file type - a "TypeMod" file - that can be read in (like frcmod files)
> to modify atom type parameters beyond mass and polarizability. For
> example, it could look something like this (almost like the VDW
> section in parm files):
>
> #Type gbradius description
> CT 1.7 "mbondi"
> c3 1.7 "mbondi"
> When you change parameter sets in LEaP via "set default pbradii
> mbondi" or something it can automatically source the right file
> (something like $AMBERHOME/dat/leap/parm/typemod.mbondi) to keep
> backwards compatibility. We could also potentially support wildcards,
> but I think it would be best if every atom type got assigned a
> specific GB radius.
>
I could get on board with this idea. I think an important first step is
still to modify the assignment routine and make them smarter (by using
existing information, like hybridization and coordinate number). This would
be easy to implement and require minimal changes. From there, we can add
support for typemod files akin to frcmods -- it allows you to override
radii of specific atom types from the default assignment. This facilitates
an improvement plan that can be implemented in two (relatively easy) steps.
This could even be an extensible format that would allow you to modify
> other things like mass and vdw params on a single line, but wouldn't
> require modifying the existing parm format. You could define what is
> being modified by what the columns are named in the file header, and
> denote specific entries that shouldn't be modified with '-':
>
> #Type gbradius vdw_r description
> CT 1.7 0.0860 "mbondi, modified vdw R"
> c3 1.7 - "mbondi, do not modify vdw R"
>
I'm a bit more wary of this. We already have a way of modifying everything
except the GB parameters (LCPO, screen, and intrinsic radius). They can
all be specified in the parm.dat file and overridden by an frcmod. I don't
think we should provide multiple avenues to accomplishing the same task
using tleap...
Don't get me wrong: I like the idea (and the motivation) for the proposed
'grand unifying parameter database' and a generalized parameter assignment
library shared throughout all of Amber. I just don't think we have the
resources to do it properly. I certainly won't spend time on it, and your
work with cpptraj (and sander and pmemd) is far more useful than a trial
implementation of this centralized parameter idea. I think we could find
someone to implement a smarter assignment routine in tleap fairly quickly
that would be easily ported to ParmEd. While it's not as attractive from a
software engineering perspective as your proposal, it's better than nothing
(and doesn't preclude future steps for improving GB parameter
customizability for users).
This may be a conversation better left until January (I look forward to
seeing people there!)
Happy weekend!
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 Nov 01 2013 - 21:00:02 PDT
