On Mon, Jan 21, 2013 at 3:55 PM, David A Case <case.biomaps.rutgers.edu>wrote:
> On Mon, Jan 21, 2013, dcerutti.rci.rutgers.edu wrote:
> >
> > LJEDIT
> > <Type 1> <Type 2> <R* pair> <Eps pair>
> > ...
> > END
> >
> > One might ask why put it in parm*.dat rather than a frcmod file, but I
> can
> > certainly check for the extension in frcmods as well.
>
> This section should be able to be in both parm.dat and frcmod files...the
> code
> for reading these two formats is essentially identical (I can help with the
> implementation) and there are cases where these terms indeed represent
> small
> changes from an existing ff, and hence "belong" in a frcmod file.
>
> [Aside: I'm not sure what the "END" command does above; all other sections
> of
> parm.dat files are terminated with a blank line, and, indeed, the NONB
> section
> is as well. I think(?) "END" means "end of the entire parameter set",
> allowing comments to be placed after that.]
>
> We might want to consider an extra flag (I think in the POINTERS section,
> but
> maybe not....) that is set if LJEDIT terms have been used. This would
> make it
> simpler for programs that don't support such extensions (e.g. the current
> GPU
> codes) to exit immediately upon finding such a flag.
>
Why not just look for those sections of the prmtop -- if they exist (or are
non-zero), bail if they're not supported? Modifying existing parts of the
prmtop, especially POINTERS, is a good way of breaking 3rd-party parsers
(like VMD and pymol).
>
> There *is* some overlap with ParmEd functionality, but I agree that it is
> better for the capability to be folded into LEaP.
>
The principle thrust of ParmEd was mostly for developers and tinkerers
(with a few conveniences thrown in for the end-user). The goal was to
allow very rapid (scripted) prototyping and experimentation to avoid
expending large amounts of time and programming effort only to find out
it's not worth doing in the first place.
Passing a prmtop through ParmEd as a standard part of using a force field
is an unattractive option, I'll fully agree there.
All the best,
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
Received on Mon Jan 21 2013 - 13:30:04 PST
