On Fri, 2013-11-01 at 12:48 -0600, Daniel Roe wrote:
> On Fri, Nov 1, 2013 at 11:56 AM, Jason Swails <jason.swails.gmail.com> wrote:
> > Lachele put together a nice table that's in the
> > doc/AtomTypesTableWorkspace.lyx file. It is a long list that appears to
> > have taken a long time to put together. It includes most of the force
> > fields (except ff13, it appears). It was added to the repo Feb. 2, 2012
> > and last updated (by Lachele) Feb. 23, 2012. Those were 2 of the only 3
> > commits (together with James' addition of ff12SB atom types).
> >
> > This was an excellent start, but unfortunately probably suggests to me
> > that either the central database will not work, or the lyx table is the
> > wrong medium to be using given its lack of attention and notoriety. I'd
>
> Can't this doc just be converted to html and placed on the Amber website?
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.
>
> > This already exists to some extent in LEaP. Each atom knows about its
> > hybridization, number of bonded partners, and atomic number. Hopefully
> > this is enough to unambiguously assign GB parameters?
>
> Yes, but then we're again locked into having LEaP determine what an
> atom is from other parameters. If you assign an atom type an
> unambiguous type from the get-go I think that's better as far as
> future-proofing. These values then no longer need to be hard-coded in
> LEaP which in my opinion is the way to go. If there is an unambiguous
> atom type then there can be separate table files for each of the GB
> radii set. So using my previous atoms it would look something like:
>
> mbondi.dat
> #UnambigiousType GBradius description
> 0 1.7 <some text, reference, etc>
> 1 1.3 <some text, reference, etc>
>
> Using this format you could also have e.g. all the LCPO parameters in
> one place, so they don't need to be hard-coded into every program
> separately like we do now (which we've already seen is error-prone).
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.
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.
Just my 2c,
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 - 12:30:03 PDT
