Hi Peter,
The easiest approach is probably to try it out in Leap and see what it
actually does. It would be useful to know. You could build a custom peptide
with the sequence command. E.g.
foo = sequence { ACE VAL LEU ILE ... }
saveamberparm foo prmtop inpcrd
Then run the prmtop through rdparm and select printdihedrals and see what
you actually get in the prmtop file. From this it should be possible to
reverse engineer what actually goes on. You could move the wildcards around
in the ildn frcmod file and see if it makes any difference. It would be
interesting to know though what the ILDN parameter actually should be and
see if these are what leap actually gives you. It is worth comparing tleap
and sleap as well to see if they agree.
It would be nice if Wei can chime in here with an exact definition of what
he coded in sleap.
In my opinion though the wildcards should still be removed (especially since
they can hide possible missing parameters) and someone should just make a
ILDN frcmod file that explicitly defines every dihedral and 'does the right
thing'(tm) matching what the original ILDN authors intended.
All the best
Ross
> -----Original Message-----
> From: Peter Eastman [mailto:peastman.stanford.edu]
> Sent: Tuesday, October 04, 2011 11:56 AM
> To: AMBER Mailing List
> Subject: Re: [AMBER] Ordering of torsion definitions
>
> I'm really just trying to understand what AMBER does. I'm adapting the
> AMBER force fields for use with OpenMM. My goal is to interpret the
> parameter files correctly, where "correctly" is defined as, "Giving
> identical results to AMBER."
>
> Peter
>
>
> On Oct 4, 2011, at 11:50 AM, Bill Ross wrote:
>
> >> So is this the correct set of rules to use?
> >>
> >> 1. Within a file, specifics should override wildcards (regardless of
> order).
> >> 2. Definitions in later files should override definitions in earlier
> files (regardless of whether they're specific or wildcards).
> >
> > 1 makes sense, not sure what the code does now.
> > I think 2. is debatable, it depends on what is desired, but your
> > suggestion would make for a simpler implementation.
> >
> > Bill
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 04 2011 - 12:30:02 PDT
