On Tue, Oct 18, 2011 at 1:03 PM, Jan-Philip Gehrcke <jgehrcke.googlemail.com
> wrote:
> 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
>
Which lines were these on (specifically, which terms were blowing up)? My
suggestion here is to visualize the trajectories _MMPBSA_ligand.mdcrd(.x)
with your ligand topology file to make sure that these are created properly.
>
> $ 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'll preface this by saying that decomposition uses gbsa=2 and all other GB
calculations use gbsa=1 (LCPO).
Are you using decomposition? If so, the gbsa=2 code has known issues (at
least 1 bug). If you run a 1-step minimization using imin=1 (so it's just
an energy extraction) using gbsa==2, the ESURF energy printed out in the
first step differs from the ESURF energy printed out in the summary, which
is indicative of an issue. All other energies are identical, as you would
expect. This was raised in a thread within the last year or so, but I'm too
lazy to go after it now... I'm not exactly sure what causes this issue, but
I'm not keen on hunting through the (sander) code looking for it.
> 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"?
>
Extracted frames for the complex, receptor, and ligand, yes. By "look OK" I
mean they don't look completely warped and ridiculous (caused by the fact
that the atoms in the trajectory don't correspond to the atoms in the
associated topology file).
>
>
> 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!
>
Try using NetCDF trajectories as intermediates (this won't work for Alanine
scanning, but it will for everything else). You can do this via the
"netcdf=1" variable in the MM/PBSA input file. Are your original
trajectories NetCDF?
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 Tue Oct 18 2011 - 11:30:06 PDT
