Hi everyone:
At the developers' meeting in Sanibel, we agreed to package up the "free"
parts of Amber into a coherent(!?!) distribution. The current name for
this is "amber-tools", hoping that the amber brand will make things more
visible, and that we can provide a more uniform interface to these codes.
Currently, amber-tools consists of antechamber, ptraj, gleap, tleap and nab.
The saqm (stand-alone quantum mechanics) program will be added soon, perhaps
with a better name. Other components could be added, depending on the
developers' wishes and interest. The dividing point will be that these will
all be released under the GPL license, as is already the case for the current
crop of programs.
I spent quite some time trying to figure out how to create a CVS tree that
would incorporate amber-tools, yet still keep everything in sync with Amber
itself, having only one copy of common files. I'm now pretty convinced that
the best course is to fold everything into the amber10 tree, and to create
various "mkrelease" scripts to build tarballs of just the things needed for
a particular project. Hence, there will be a mkrelease_amber script for Amber
itself, and mkrelease_at for amber-tools. If we decide that we still need to
release even smaller pieces, we could have mkrelease_ptraj, and so on.
If I can get agreement on this, we can abandon the current separate trees
(which currently are ptraj, antechamber, and nab) and fold them into the
amber10 tree. This will eliminate a lot of duplication, and no longer require
lots of (potentially confusing) soft-links inside the various cvsroot
subdirectories. I have made a start at this: if you type "cvs update -d" in
amber10, you will see lots of new directories, plus some files like
configure_at and Makefile_at. The "_at" part means that this is designed for
amber-tools. If you type (in $AMBERHOME/src):
./configure_at [options, use -help to see what they are]
make -f Makefile_at install
you will see that amber-tools gets built, instead of Amber itself. WARNING:
although the compile step should work, the resulting programs are not yet
fully functional, mainly because some environment variables and library
locations are still messed up
One advantage I see in the new scheme is that a single environment variable,
AMBERHOME, can be used to root everything, and can take the place of NABHOME,
ACHOME, etc. I'm also starting to go through all the files, and use $BINDIR,
$LIBDIR and $INCDIR variables (created in config.h) to define the location
of executables, libraries, and include files. This can replace having these
hard-wired in many dozens of Makefiles. Once this is all working, we can
upgrade amber-tools at whatever frequency we want: users will just un-tar the
the new material on top of the old, in a directory tree that will also include
sander, pmemd and other Amber codes.
There is still a fair amount of work to do here, especially in getting
consistent documentation, removing some duplication, and getting all the
libraries and data files into rational locations. Files with the "_at" ending
should be removed as we go forward. I don't think I broke anything for the
standard Amber build, but let me know if something seems amiss.
A few further notes:
1. I would like to eventually move all the documentation from troff to
LyX/latex. This allows anyone to modify things, since LyX is a simple front
end, like Word or OpenOffice, with a zero learning curve for simple stuff.
It also makes indexing trivial, allows nice code listings, and good ways to
intersperse "science" (including equations) with the documentation itself.
I have almost completed converting the nab documentation, but it was harder
than I had expected, so I'm not eager to tackle the Amber Users' Manual just
yet. However, since nab, tleap and gleap all now have latex docs, I don't
think it will be hard to add ptraj and antechamber to that list, so
amber-tools should be able to have a modern and consistent way of doing
things.
2. It would be nice if amber-tools could depend only on C/C++. This probably
is not possible for saqm, but my plan is to convert the handful of fortran
routines used by ptraj to C (either by hand, or with f2c). This reduces the
number of compiler combinations the configuration program has to worry about,
and makes installation simpler, since users' won't have to install a Fortran
compiler.
3. If Junmei or Tom have plans to release soon a new version of antechamber
or ptraj, please let me know: maybe we can use that as a first example of this
new approach.
As always, comments and suggestions are welcome. Remember that amber-tools
is not "there" yet, but we are much closer than before.
...thx....dac
Received on Wed Jun 20 2007 - 06:07:11 PDT
