Re: [AMBER] Amber 12: CalcError in mmpbsa_py_energy and sander

From: Jan-Philip Gehrcke <>
Date: Fri, 31 Aug 2012 17:56:49 +0200

On 08/31/2012 05:43 PM, Jason Swails wrote:
> On Fri, Aug 31, 2012 at 10:58 AM, Jan-Philip Gehrcke <
>> wrote:
>>> OK. My intent was to capture printed stderr within Python and redirect
>> it
>>> back to the system standard error stream.
>> Good intent :-) Unfortunately, the error was written to stdout.
> Well, captures stderr and prints it to stderr. The problem was
> that the error message wasn't printed to stderr in the first place, which
> does not originate with I'm actually not sure where the error
> is printed to or where it's going. I will look into it.

What I meant with "Unfortunately, the error was written to stdout.":
mmpbsa_py_energy writes this error to stdout (I checked it by running it
two times, once redirecting stderr to /dev/null and once stdout to

> Can you send me your topology files and a single frame so I can test it
> (any format -- even PDB will be fine)? I don't have ready access to any
> systems with atoms not recognized by PBSA.

You should have an from me email off-list by now.

>>> I've always liked the idea of sending error messages to stderr, although
>> it
>>> may be helpful to send it to both streams so users know *where* in
>> program
>>> execution the error occurred (although this should be obvious or
>>> unnecessary from the error message itself).
>> You're right. However, I think Amber software is a special case. Due to
>> the importance of the mdout files, also all error messages should end up
>> there.
> I think it depends on the particular Amber program. For MMPBSA, I think
> printing it to stderr is sufficient. The goal is that will say
> "Error with this calculation: <error message>", and will just insert the
> error message from the program it calls (of course this only works if the
> external program prints to stderr).
> The external programs will probably benefit by printing error messages to
> both streams, but that's a separate issue.

I agree :)

> This atom type is from Glycam 06 G. From Glycam_06g-1.dat:
>>> CG 12.01 ! sp3 C aliphatic
>> The prmtop file has actually been created using leap from AmberTools 1.5
>> with FF99SB + custom libs using types from GLYCAM_06_G.
>> PBSA from Amber 11 / AmberTools 1.5 does not complain about the prmtop
>> file. How comes that it finds the parameter that PBSA from Amber 12 misses?
> PBSA from AmberTools 1.5 automatically took radii from the prmtop file, I
> think. Now it doesn't. Hence the difference.


>>> The solution would be to add this atom type explicitly to the PBSA source
>>> code so it assigns the correct radius. The relevant subroutine is
>>> pb_aaradi in $AMBERHOME/AmberTools/src/pbsa/sa_driver.F90.
>> Hm, does this mean that for MMPBSA in Amber 12 all parameters for atoms
>> from third party force fields need to be hardcoded in that file? I am
>> sure you don't mean that, right? :)
> The solution is either that -or- use the radii from the topology file
> instead (i.e., set radiopt=0). The hard-coded radii are the optimized
> radii (cited in the AmberTools manual). The manual actually claims that
> unrecognized atoms take radii from the topology, but that doesn't seem to
> be the case... I can't speak definitively much more on this due to limited
> experience/knowledge with PBSA.

Would you consider this a bug now?

> [Note, a particularly hacktastic way of doing this is to actually change
> the atom type name for the offending atoms to the equivalent type that PBSA
> understands -- parmed can be used for this]

Ha, okay, noted :-)


> All the best,
> Jason

AMBER mailing list
Received on Fri Aug 31 2012 - 09:00:04 PDT
Custom Search