Re: [AMBER] MMPBSA.py: DELTA section missing in FINAL_DECOMP_MMPBSA.dat for dec_verbose=3

From: Jason Swails <jason.swails.gmail.com>
Date: Fri, 4 Nov 2011 17:28:40 -0400

On Fri, Nov 4, 2011 at 4:53 PM, Jan-Philip Gehrcke
<jgehrcke.googlemail.com>wrote:

> Thanks for the long comment, Jason!
>
> First, I have to add that maybe the subject of my mail was misleading. I
> did not question the check itself. The way I had set up the system,
> MMPBSA.py did not determine the receptor and ligand masks automatically
> and therefore the warning
>
> > "DELTAs can only be printed with the default mask assignments"
>
> should have been printed to the output file. Especially, it should have
> been printed independently of the dec_verbose setting, right?
>

Oh, I see what you mean. Yes, it should have been printed to the output
file.


> Second, what you've written sounds very reasonable. But, just in order
> to make sure I got you right:
>
> - in case MMPBSA.py determines the ligand and receptor masks from the
> topology files, these masks are "forwarded" to the "decomp parsing code"
>

Yes. In the form of a single integer (ligand_start). The ligand residues
must be sequential in the complex for MMPBSA.py to guess the mask. Thus,
all you need is the number of residues in the ligand and where in the
complex topology file the ligand starts. Once you have that, you have the
complete mapping.


>
> - in case the user defines ligand and receptor masks in the MMPBSA input
> file, these masks are considered to be not trustworthy enough to be
> "forwarded" to the "decomp parsing code"
>

It's more that you can't make sure that the above condition holds (that is,
a single number is *not* sufficient to define the full mapping completely
in the general case). So even if the masks were "trustworthy", the decomp
parsing information doesn't receive generalized mapping data (it just gets
3 numbers -- # res in complex, # res in ligand, first ligand residue in
complex prmtop).

The decomp parser has been *completely* reworked (which was necessary to
calculate the standard deviations properly for the DELTA section), so most
of these issues will disappear in a few months.


> Is that somehow correct?
>
> Third, a totally different thing on MMPBSA.py which I was wondering
> about for some time now but maybe it's not worth opening a new topic for
> that. The level of parallelization of MMPBSA happens on the level of
> different frames, i.e. several workers work on different frames, right?
> The analysis of a single frame is not worth to further split and
> parallalize. Hence, the serial version of ptraj is used for frame
> extraction and the serial version of sander is used for frame analysis.
> These processes need to be managed by Python in a parallel fashion. My
> point is: I do not quite get why MPI is used for that. I must be missing
> something, otherwise this process management could easily be done using
> Python's multiprocessing module. Must MMPBSA.py be able to work
> distributed over various nodes?
>

I had thought about this, and debated using the multiprocessing or
threading modules, but ultimately decided on an MPI module (which is open
source and easily obtained). With the exception of a couple (experimental)
programs, all parallelization in Amber is done via MPI. That, and MPI is
actually a very easy parallelization scheme to grasp, so MMPBSA.py is more
likely to be maintainable after I leave if it's parallelized using
something other Amber-ers will know (it doesn't necessarily require
in-depth knowledge of a module unique to Python). That and MPI trivially
parallelizes over distributed systems. The threading modules are
restricted to a single physical node.

All the best,
Jason


> Hopefully my mails don't annoy you :)
>
>
> Have a nice weekend!
>
> Jan-Philip
>
> On 04.11.2011 21:00, Jason Swails wrote:
> > You've touched on another issue that is actually solved with the upcoming
> > MMPBSA.py release (this is, IMO, one of the largest shortcomings of the
> > current version). The only way DELTA decomposition energies can be
> > calculated is if we know "residue mapping". That is, if we know where
> > every residue is *exactly* in both the complex and [receptor or ligand]
> > topology files. Only then can you subtract the two of them. The perl
> > version required 2 extra input variables: RECMAP and LIGMAP -- that is,
> you
> > have to directly tell mm_pbsa.pl where the complex residues "map" onto
> the
> > receptor and ligand residues. This is difficult to wrap your head
> around,
> > IMO, and very easily leads to user errors that very easily slip through
> the
> > mesh, so we decided not to take that approach.
> >
> > When MMPBSA.py determines the receptor and ligand masks, it maps out the
> > residue correspondence (mapping) in the process. The decomp parsing code
> > takes advantage of this to calculate the deltas appropriately. If users
> > supply their own masks for the receptor and ligand, this mapping doesn't
> > take place, so the decomp parser has no idea what differences to take for
> > each residue. Thus, that check is very much important.
> >
> > I've implemented a mask parser written in Python for the upcoming
> MMPBSA.py
> > release, however, which solves this problem. When it interprets the
> > receptor and ligand masks, it maps out which atoms belong to the receptor
> > and which belong to the ligand, which serves 2 purposes. First, we now
> > *always* have the mapping necessary to calculate decomp DELTAs, and
> second,
> > it's an additional layer of error checking to make sure that the masks
> > users input are not wrong.
> >
> > All the best,
> > Jason
> >
> > On Fri, Nov 4, 2011 at 12:47 PM, Jan-Philip Gehrcke<
> jgehrcke.googlemail.com
> >> wrote:
> >
> >> Huhu,
> >>
> >> once again me. Sorry :)
> >>
> >> I've performed two equivalent MMPBSA.py.MPI runs. One with
> >>
> >> dec_verbose=0
> >>
> >> and one with
> >>
> >> dec_verbose=3
> >>
> >> In both cases, the DELTA section was not written in
> >> FINAL_DECOMP_MMPBSA.dat. But only in the first case, this message is
> >> printed to FINAL_DECOMP_MMPBSA.dat:
> >>
> >> "DELTAs can only be printed with the default mask assignments"
> >>
> >> I am wondering if these lines:
> >>
> >> > if ligstart == -1 and verbose<= 2 and not stability:
> >> > output.write("DELTAs can only be printed with the default mask
> >> assignments\n\n")
> >> > verbose += 2
> >>
> >> in AmberTools/src/mmpbsa_py/MMPBSA_mods/amberoutputs.py really make
> >> sense (especially the condition `verbose<= 2`). Do they? :)
> >>
> >> Thanks,
> >>
> >> Jan-Philip
> >>
> >> _______________________________________________
> >> AMBER mailing list
> >> AMBER.ambermd.org
> >> http://lists.ambermd.org/mailman/listinfo/amber
> >>
> >
> >
> >
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>



-- 
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 Fri Nov 04 2011 - 14:30:03 PDT
Custom Search