Thanks, Jason for the quick response (as usual :-)). I am fine with
everything you've said.
Jan-Philip
On 04.10.2011 19:39, Jason Swails wrote:
> 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
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 04 2011 - 12:00:03 PDT
