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
