On 08/31/2012 05:43 PM, Jason Swails wrote:
> On Fri, Aug 31, 2012 at 10:58 AM, Jan-Philip Gehrcke <
> jgehrcke.googlemail.com> 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, MMPBSA.py 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 MMPBSA.py. 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
/dev/null).
>
> 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 MMPBSA.py 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:
>>
>>> GLYCAM_06_G PARAMETERS (FOR AMBER 8.0, RESP 0.010), COPYRIGHT CCRC 2004
>>> 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.
>
Interesting.
>
>>> 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 :-)
Cheers!
>
> All the best,
> Jason
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Aug 31 2012 - 09:00:04 PDT
