Sorry for the late reply. I have some more details regarding this issue:
1) weird: parsing error depends on MPI process count
====================================================
An MMPBSA.py.MPI run using `mpirun -np 8` on 101 frames succeeds
(executed locally on my 8 core machine). An MMPBSA.py.MPI run using
`mpirun -np 2` using the *same files* with the *same input
configuration* on the same machine fails with the parsing error
indicated in the opening mail (due to "*********" tokens in the
_MMPBSA_ligand_gb.mdout).
Let me provide more detail on the differences between the two
_MMPBSA_ligand_gb.mdout files created by these two independent runs:
- The "crashtest1/_MMPBSA_ligand_gb.mdout" corresponds to the -np 2 run.
- The file "crashtest3/_MMPBSA_ligand_gb.mdout" corresponds to the -np 8
run.
First of all, I checked the number of lines containing "***" in both files:
$ cat crashtest1/_MMPBSA_ligand_gb.mdout | grep "\*\*\*" | wc -l
297
$ cat crashtest3/_MMPBSA_ligand_gb.mdout | grep "\*\*\*" | wc -l
0
Then, I took "crashtest1/_MMPBSA_ligand_gb.mdout" (from the -np 2 run)
as reference. In this file, I grepped all lines starting with either
VDWAALS, 1-4, BOND, or ESURF. For each grepped line, I checked in the
"crashtest3/_MMPBSA_ligand_gb.mdout" (the -np 8 run) if an equivalent
line is existing. If it exists, it is a match and counted:
$ cat crashtest1/_MMPBSA_ligand_gb.mdout | grep VDWAALS | while read
LINE; do grep "${LINE}" crashtest3/_MMPBSA_ligand_gb.mdout; done | wc -l
101
$ cat crashtest1/_MMPBSA_ligand_gb.mdout | grep 1-4 | while read LINE;
do grep "${LINE}" crashtest3/_MMPBSA_ligand_gb.mdout; done | wc -l
101
$ cat crashtest1/_MMPBSA_ligand_gb.mdout | grep BOND | while read LINE;
do grep "${LINE}" crashtest3/_MMPBSA_ligand_gb.mdout; done | wc -l
101
$ cat crashtest1/_MMPBSA_ligand_gb.mdout | grep ESURF | while read
LINE; do grep "${LINE}" crashtest3/_MMPBSA_ligand_gb.mdout; done | wc -l
80
I believe that the runs should not differ in their results so that each
grepped line from the reference file should find a matching line in the
comparison file. As 101 frames have been analyzed by MMPBSA, the 101
should be the desired output, right?
However, the matching above shows that the ESURF results differ
significantly in 21 of 101 cases only due to a change from -np 2 to -np
8. How can this be explained?
I performed both tests three times and reproduced the result.
2) The initial trajectory
=========================
The initial trajectory (from which the frames are extracted) looks fine
in VMD. Also, the RMSD of the whole complex compared to the initial
structure over time is quite stable.
Jason, you wrote "Try visualizing the created trajectories with VMD or
something to make sure that they look OK". So you mean I should also
visualize the extracted frames, yes? Can't we rely on ptraj that the
extraction went well? How would I check if "they look OK"?
3) Various other frame count / -np X combinations
=================================================
I've performed some more tests under constant conditions. All MMPBSA
runs are based on the same trajectory file. Let me list the test results
in dependence on the X in `-np X` and on the `interval` variable in the
`&general` block of the MMPBSA input file:
- 11 Frames / np 2: success
- 101 Frames / np 2: parsing error
- 11 Frames / np 8: success
- 101 Frames / np 8: success
- 10001 Frames / np 8: parsing error
Hence, just using "-np 8" is not a solution. I/we have to understand
what is going on here. What can I do now? Thanks for your help!
Jan-Philip
On 10/11/2011 03:54 PM, Jason Swails wrote:
> On Tue, Oct 11, 2011 at 9:20 AM, Jan-Philip Gehrcke <jgehrcke.googlemail.com
>> wrote:
>
>> Hey,
>>
>> everything went fine during a run of MMPBSA.py.MPI analyzing ~100 MD
>> frames. Then, I decreased the frame interval by a factor of 10, leading
>> to ~1000 frames to analyze. Nothing else changed. I've re-run MMPBSA
>> with the -O option and then encountered the following Python traceback
>> (at the end of this second MMPBSA.py.MPI run):
>>
>> Beginning GB calculations with sander...
>> calculating complex contribution...
>> calculating receptor contribution...
>> calculating ligand contribution...
>> Traceback (most recent call last):
>> File
>> "/home/bioinfp/jang/apps/amber11/AmberTools/src/mmpbsa_py/MMPBSA.py.MPI",
>> line
>> 1684, in <module>
>> lig_prm, ligstart, INPUT['surften'], '', '_MMPBSA_')
>> File
>>
>> "/home/bioinfp/jang/apps/amber11/AmberTools/src/mmpbsa_py/MMPBSA_mods/amberoutputs.py",
>> line 124, in PrintDecompResults
>> return
>>
>> _decoutput12(outfile,debug,verbose,frames,comres,recres,ligres,ligstart,type,idecomp,surften,stability,prefix)
>> File
>>
>> "/home/bioinfp/jang/apps/amber11/AmberTools/src/mmpbsa_py/MMPBSA_mods/amberoutputs.py",
>> line 263, in _decoutput12
>> eint = float(line[11:20])
>> ValueError: invalid literal for float(): *********
>>
>
> Try looking at the energies. It appears that some of the energies are
> overflowing the fixed format. Are the energies for the same frames
> identical for both simulations? Try visualizing the created trajectories
> with VMD or something to make sure that they look OK.
>
> HTH,
> Jason
>
>
>> Looks like an issue during parsing of _MMPBSA_complex_gb.mdout. For
>> diagnosis, I've uploaded a gzipped version of this file here (25 MB):
>>
>> http://vs241092.vserver.de/_MMPBSA_complex_gb.mdout.gz
>>
>> Do you need more information?
>>
>> Thanks,
>>
>> Jan-Philip
>>
>> --
>> Jan-Philip Gehrcke
>> PhD student
>> Structural Bioinformatics Group
>>
>> Technische Universität Dresden
>> Biotechnology Center
>> Tatzberg 47/49
>> 01307 Dresden, Germany
>>
>>
>>
>> _______________________________________________
>> 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
Received on Tue Oct 18 2011 - 10:30:02 PDT
