On Thu, May 19, 2011 at 5:29 AM, Mark Williamson <mjw.mjw.name> wrote:
> 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
>
Yes, this was something I had observed awhile ago, yet there is no getting
around it. The configure script had to be modified for various changes in
the pmemd.cuda stuff, so all configure patches fail harmlessly. I was
hoping that it would fly by so fast that people wouldn't even notice, and
those that did could be consoled on the mailing list.
There's really no *good* way to fix this given our current situation.
> 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.
>
True. Unfortunately the configure script was changed between amber11 and
AmberTools 1.5, so the easiest way to install the 2 alongside each other is
to modify the config.h file each time in such a way that allows it to work
for both AmberTools 1.5 and Amber11. This is what AT15_Amber11.py was
designed to do, and for this particular AT15+Amber11 marriage, I think
that's about as good as can be hoped. I agree there should be a better way
to do this. Maybe "cmake" is the answer (as suggested by Tyler).
>
>
>
>
>
> 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
>
Installation would certainly be easier here, but then we're releasing free
code alongside non-free code. Of course we could make it *all* free, but
I'm not about to suggest cutting out core developer amber $$ :). Another
option would be to sell *only* pmemd, as that program is entirely
self-contained (one could argue except for NetCDF libs, but that's unchanged
from any Amber that has it, and systems can install it separately), and
hopefully well-worth buying for $400, anyway, since it's faster (and in the
future more feature-rich hopefully) than NAMD anyway ;). It's also the only
GPU-enabled code in Amber, and probably the most mature GPU MD code out
there right now (or at least one of them).
My 2c,
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 Thu May 19 2011 - 04:30:02 PDT
