Dear All,
I am just following a pretty standard install protocol with a student on
his machine (Ubuntu 9.10) for AMBER11 and AMBERtools 1.5:
1) Extract AMBERTools 1.5:
cd ~
tar xfj AmberTools-1.5.tar.bz2
2) Set your environment variables and make them "stick"
cd amber11
echo "export AMBERHOME=$PWD" >> ~/.bashrc
echo "export PATH=$PATH:$AMBERHOME/bin" >> ~/.bashrc
source ~/.bashrc
3) Apply bug fixes:
wget
http://ambermd.org/bugfixes/AmberTools/1.5/bugfix.all
patch -p0 < bugfix.all
rm bugfix.all
4) Configure and build
cd $AMBERHOME/AmberTools/src
./configure gnu
make install
...Run tests...
5) Extract AMBER11:
cd $AMBERHOME
cd ..
tar xfj Amber11.tar.bz2
6) Apply bugfixes:
cd $AMBERHOME
wget
http://ambermd.org/bugfixes/11.0/bugfix.all
wget
http://ambermd.org/bugfixes/11.0/apply_bugfix.x
chmod +x ./apply_bugfix.x
./apply_bugfix.x bugfix.all
7) Apply AmberTools 1.5 specific patch:
./AT15_Amber11.py
8) Compile:
cd $AMBERHOME/src
make install
The problem I'm having is a patch warning at stage 6:
patching file test/cuda/4096wat_oct/mdout.pure_wat_oct_nvt_ntt3.GPU_SPDP
patching file AmberTools/src/configure
Reversed (or previously applied) patch detected! Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file
AmberTools/src/configure.rej
patching file src/pmemd/config_data/linux_em64t_cuda_DPDP.gfortran.mpi
It is not fatal, but it may throw someone that has not done this before;
does the AMBER11 bugfix.all need updating or will this break
compatibility with AT14? On another point, I've discovered that I need
to run AT15_Amber11.py every time I create a new config.h (via
configure) if I want to compile AMBER. This also is going to catch a few
people out.
Observing people attempting to install AMBER is a very interesting
experience and ideas for improvements can be gained from examining
common mistakes that are made.
Stepping back a bit, it is my opinion, that over the past few years the
entire installation process for AMBER has become more complex and as a
result, more error prone. I think a few aspects have contributed to
this: the splitting of the code base into AMBER and AMBERTools, some
bugfixes that are essentially feature additions and a diversification of
languages used within the package.
At this point, I want to make clear that it is not my intention to start
any form of flame war here; the above aspects are indicative of an
active and vibrant code base, which is great. New theory and method
developments, manifest in new code, are of great benefit to the entire
scientific community. What I want to do is reduce the difficulties
with the setup, so that user can focus on the science and not get bogged
down in installation technical issues. I appreciate that the main
purpose of the AMBER mailing list is to cater for this, but I am
wondering if there are any other things that could be done.
One low hanging solution I see, is the moving the remaining code in
AMBER into AMBERTools. A unification of the tree would make
installation easier since patch management post release would be
simpler, since it would not diverge. Also, the release rate could be
increased, allowing feature updates on a per version basis instead of
via large "bugfixes". I understand that this is probably a difficult and
complex area, but is there an overview of the current barriers to
migrating the rest of the code over? For example, are there university
and or author specific licensing complications with code in AMBER?
Regards,
Mark
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu May 19 2011 - 02:30:03 PDT
