Hi,
Mark, I think you have several valid points here; the install process
has definitely gotten a lot more complicated. While I agree that
unifying the code tree again would simplify things, it gets away from
the original reason that AmberTools was split off from the main tree
in the first place: to make most of the useful stuff in Amber free to
the scientific community while still retaining some control over the
main MD engines. Personally, I think that we should go in the opposite
direction and split AmberTools completely from Sander/Pmemd, meaning
that both AmberTools and Sander/Pmemd should each have their own
directory and configure scripts. Sander/Pmemd could still rely on the
presence of AmberTools (for netcdf/sqm/rism/whatever other libs) via
AMBERHOME (since sander/pmemd dont need AMBERHOME set anyway). I feel
that separating them physically would ultimately simplify things like
updates, and also would make the code separation make more sense to
the user. Anyway, just my opinion.
-Dan
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
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu May 19 2011 - 04:30:05 PDT
