Hello,
On Tue, Oct 4, 2011 at 1:00 PM, Jan-Philip Gehrcke
<jgehrcke.googlemail.com>wrote:
> Hey,
>
> I have three small questions/suggestions regarding the
> MMPBSA.py/MMPBSA.py.MPI code.
>
> 1) search path
> ==============
> I am running a setup consisting of AmberTools 1.5 and Amber 10 -- being
> in separate directory trees. MMPBSA.py/MMPBSA.py.MPI did not find
> sander, although it's in the $PATH:
>
> > Error: sander could not be found!
>
> I've changed line 587 in MMPBSA.py/MMPBSA.py.MPI to
>
> > sander = utils.which(prog, True)
>
> so that `utils.which` searches in $PATH and not only in $AMBERHOME/bin/.
> Is there any problem with this, so it should not be default for all
> users? I would consider it a special case if someone really does not
> want to use the sander which is in his $PATH (then one still could
> temporarily modify the environment).
>
This was a deliberate choice that was aimed at making sure that the "wanted"
version of sander was chosen (but I also wanted to make it easy to allow
users to search the PATH in case they had something like AT15 + Amber10,
like you have). However, sander is at this point only needed for QM/MMGBSA,
decomp, and igb=7,8. I only wanted PATH searching to be done if the user
really wanted it done, since this can mask certain issues.
The upcoming version of MMPBSA.py includes a search_path input variable in
the &general namelist to enable exactly this (so no code change is
necessary).
>
> 2) re-implementation of which?
> ==============================
> Isn't it more safe&clean to simply spawn a process with
> GNU which instead of trying to re-implement it in the second half of
> `utils.which`?
>
I like the Python implementation of "which" since it gives additional
flexibility. For instance, I can search AMBERHOME/bin without requiring
that AMBERHOME/bin already be in the PATH. (And I could do something in
terms of searching an AMBER10HOME path or something like that as well). I
don't think the Python implementation is particularly complex, and I like
the flexibility it provides over GNU which in terms of being able to add
functionality to it later if I want to. Also, the nature of the functions
and variables used in the Python which is such that it should be
platform-independent.
>
> 3) MMPBSA.py and MMPBSA.py.MPI
> ==============================
> I did not look at all the implementation details, but it looks it could
> be a good idea to somehow get rid of the large part of duplicate code
> these two files have. Maintaining two pretty equivalent files probably
> requires more effort than necessary :-)
>
Completely agreed. In the first incarnation of the code, the MPI version
was basically a cut-and-paste of the serial version while throwing in a
couple MPI hooks. This was more of a proof-of-principle approach, and
starting with AmberTools 1.4, the code was largely rewritten to do exactly
this. The actual file you should be looking at is MMPBSA.pypp (which is a
"pre-processed" python file). This includes a couple #ifdef MPI, #endif
constructs that operate very similarly to how other Amber and AmberTools
programs create both a serial and parallel version with the same code
files. Since cpp wouldn't work for this, though, we wrote our own (very
limited) preprocessor that only recognizes #ifdef and #ifndef to produce
MMPBSA.py and MMPBSA.py.MPI from this file (see setup.sh in
$AMBERHOME/AmberTools/src/mmpbsa_py). In fact, I would suggest that you
make the change you mentioned above to MMPBSA.pypp and re-install the serial
and parallel versions.
The next release of AmberTools with MMPBSA.py will be significantly
different (in the code base, not in the user-interface or anything), with
several of the issues you mentioned above already fixed (It will also give
the option of dumping energy vectors into spreadsheet-readable CSV files).
Thanks!
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 04 2011 - 11:00:06 PDT
