On Thu, May 19, 2011 at 7:19 AM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> 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.
>
I agree, but no care is taken to make sure that the interface b/w Amber and
AmberTools is static. For example, sqm 1.5 didn't even come close to
working for QM/MM with Amber11. Ideally, these would be static and
separating them would prove no issue. Unfortunately, AmberTools versions
are closely married to the Amber version that existed alongside them in the
tree, so this is difficult...
--Jason
>
> -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
>
--
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 - 05:00:02 PDT
