Dave / Yong -
Thanks, guys for the updates on all this. The history is helpful, Dave,
as
well as the rundown on what is happening on *leap. As I have probably
already said, I got a little concerned about these sorts of issues due to
the potential for changes in the prmtop/inpcrd to mess code up severely,
and
the way I originally read Yong's mail, it sounded to me like he was
saying,
and proposing, that we could drop the excluded list from the prmtop. I
would be doing a lot of scrambling to recover from such a move, presuming
that you can indeed reconstruct the excluded list from all the bond,
angle,
and dihedral info. So that part was a misunderstanding; I think what Yong
was really concerned about was that if he added something to the excluded
list, would it be missed, when it shouldn't be, by the sander extra points
code. When Tom D. came back from the dev meeting, we talked a lot about
everything that is going on, including the introduction of new
forcefields.
Yong, when I say "forcefield", in my mind that conjours up an image of not
only all the parameters, but how they are to be used in force/energy
evaluations. So there is something implicit there - how you use the data.
The prmtop captures all the parameter and topology data for you; it is
made
more complete if you also identify the forcefield in the prmtop, because
that way you are not trying to guess how to use all the information in a
consistent manner based on the set of data that happens to be there. We
currently do that for 10-12's. Not a big deal; I have no idea how people
get 10-12's in anything these days, but if they are there I use them. So
dropping the misunderstanding issues, I have really two remaining concerns
1) the fact that various ff's are being added, and that if these are not
easily identifiable by pmemd, it may try to run using the prmtop when it
shouldn't, and 2) the fact that amoeba will be coming on line sometime in
the next little while, and it clearly will have very different
requirements
in the prmtop and inpcrd. I am just trying to insure we think about this
a
little bit in advance, figuring out ways that we clearly identify legal
combinations of prmtop, inpcrd, mdin, and program. What we do currently
is
very ad hoc; not unexpected given the number of folks working
simultaneously
in different directions; I'll give as exhibit A the issue brought up by
Dave
somewhere in this thread about LES and extra points not working together,
and we can do much better through addition of prmtop version + ff
identifiers in the prmtop and inpcrd, and extension of the extensible
format
of prmtops to the inpcrd. Yong, I am not advocating dropping any of the
ff
efforts so far; just making it explicit how the input files are to be
handled as things get more complicated. This is really all very much
outside my baliwick, and it is not my role or desire to take any sort of
lead on these issues, other than to point out that if we continue to do
this
stuff in an ad hoc manner, the combinatorics will eventually get us.
Whatever happens, just please keep me informed with enough lead time that
I
can keep pmemd functioning (pmemd now runs factor ix at ~11 nsec/day const
vol and ~10.5 nsec/day const pressure on the xt3, and I am still
introducing
major enhancements :-)).
Regards - Bob
----- Original Message -----
From: "David A. Case" <case.scripps.edu>
To: <amber-developers.scripps.edu>
Sent: Saturday, November 12, 2005 1:17 PM
Subject: Re: amber-developers: Excluded list ?
> On Fri, Nov 11, 2005, Robert Duke wrote:
>
>> I also think that changes to the prmtop should not be done
>> except when absolutely required.
>
> I think we've actually been pretty good about all this. There has been
> only
> one change in the prmtop format in more than 25 years, and prmtop files
> from
> the early 80's can still be used as inputs to sander. And the results
of
> "standard" calculations haven't changed since smooth PME was implemented
> somewhere around version 4.1.
>
> Users lived surprisingly well through the change in prmtop format
> introduced
> in Amber 7. Since this format is extensible, a number of new things
will
> be
> going in there in Amber 9, including better identification of the force
> fields, etc. All such "new" information *should* be invisible to
existing
> programs. But nothing "old" (already there) will be changed.
>
>> you should think long and hard about removing or changing anything that
>> is
>> already in the prmtop - you will break everything in sight.
>
>> and my immediate concern is that I don't want people blowing up
>> my code by trashing the existing prmtop/inpcrd formats without at least
>> telling me about it in advance of the release :-).
>
> I don't think anyone has proposed this. We *will* allow restart files
to
> have
> the same sort of format as prmtop files, since this is "absolutely
> required"
> (your term) for the Amoeba force field, and makes good sense in general.
> Of
> course, it will be good if pmemd (along with NAMD and NAB and other
> programs)
> can support this, but there will be enough backward compatibility so
that
> it
> will not be required.
>
>> Is there any status on the future of tleap/xleap? Seems to me what is
>> really needed is a graphical topology generator that can generate
>> prmtop/inpcrd based on a forcefield selection, and that the forcefield
>> information input should be table driven. That way, you could "load
up"
>> parameters for forcefields and extend them without touching the icky
>> graphical code...
>
> Wei Zhang is working on a replacement to LEaP, but that won't ready for
> this release. The problem with LEaP (in my view) is not in its
> "icky graphical code": the tleap version has full functionality, and
> many/most experienced Amber users rarely use xleap.
>
> Rather, the use of home-grown containers and a lot of data abstraction
> makes
> it hard to follow and modify much of the tleap code. Maybe this is a
good
> thing, since that has meant that the contents of the prmtop file have
> *not*
> been changed. The new "gleap" code should be much easier to understand,
> maintain and modify, and should allow a cleaner specification of what
> should
> be in the prmtop file and what should be hard-wired into the simulation
> programs. Of course, once Wei has the core functionality coded,
everyone
> will
> have to pitch in to make sure that its design and performance are really
> something we can all agree on.
>
> ...dac
>
>
Received on Wed Apr 05 2006 - 23:49:49 PDT
