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.
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.
> > 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.
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.
> > 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.
[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]
All the best,
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 Fri Aug 31 2012 - 09:00:03 PDT
