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.
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"
Anyway, just an idea.
-Dan
On Fri, Nov 1, 2013 at 1:41 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> Hi,
>
> On Fri, Nov 1, 2013 at 1:15 PM, Jason Swails <jason.swails.gmail.com> wrote:
>> It could, but then it's not easily edited. As easy as some people claim
>> the website is to edit, it is significantly more challenging than
>> editing a simple Wiki (it's easy to break monolithic HTML files in ways
>> not easy to detect, and going through the whole git process is harder
>> than editing a Wiki). I just don't trust an HTML table to stay updated
>> any more than the LyX table was.
>
> I still think we need something like this. Having one definitive "this
> is what Amber atom types there are" from ambermd.org will remove
> future uncertainty about what types can be used. Just going forward
> with the status quo is I think inviting more things like the
> ChiOL3/ILDN clash.
>
>> The problem I see with this approach is that UnambiguousType is
>> ill-defined. In general these tables will be specific to whatever
>> parameter they're used to define. So you can have an UnambiguousGBType,
>> for instance, in which case you'll still need to edit the parameter
>> files to assign this GB type to each individual atom type in the same
>> type of way that (sometimes degenerate) LJ parameters are assigned to
>> every atom type.
>
> But the point is that Unambiguous type *will* be well-defined, in the
> same way that current Amber atom types are well-defined; it will just
> not be specific to any given parameter set. It will only depend on the
> chemical environment the atom finds itself in. In this way it serves
> as a base for parameter assignment, no matter what those parameters
> are, whether they be for GB or some other method.
>
>> This approach involves a lot of work, significant changes, and will
>> require very careful validation. If the GB parameters can be uniquely
>> defined as a function of information tleap already has available about
>> every atom (e.g., number of connected atoms, hybridization, charge,
>> etc.), then implementing a robust radius assignment can be done with
>> small, isolated changes to a single source file rather than sweeping
>> changes to multiple source code files and parameter files.
>
> Maybe as a short-term fix the aforementioned changes can be made to
> tleap, but I really think we should consider if another solution might
> be more sustainable over the long term. Hard-coding these parameters
> is not a good long-term solution as we have seen; not only is it hard
> to understand how existing parameters are assigned, but it can also be
> difficult to add new parameter sets. For example, if we wanted to add
> or make changes to any GB radii set for some reason, currently both
> tleap and parmed need to be updated. If there is a central data base
> for such parameters that depend on a parameter-set-independent
> unambiguous atom type assignment, an update there propagates
> everywhere. I agree that the approach involves a lot of work, but that
> doesn't mean it's not worth doing, especially if it will make things
> easier down the road.
>
> -Dan
>
> --
> -------------------------
> Daniel R. Roe, PhD
> Department of Medicinal Chemistry
> University of Utah
> 30 South 2000 East, Room 201
> Salt Lake City, UT 84112-5820
> http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-6208 (Fax)
--
-------------------------
Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 201
Salt Lake City, UT 84112-5820
http://home.chpc.utah.edu/~cheatham/
(801) 587-9652
(801) 585-6208 (Fax)
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Nov 01 2013 - 15:00:02 PDT
