On Thu, Mar 22, 2012 at 2:17 PM, B. Lachele Foley <lfoley.uga.edu> wrote:
>
> multitmd.o: multitmd.F90
> $(FC) $(FPPFLAGS) -c $(FOPTFLAGS) $(FFLAGS) $(AMBERFFLAGS)
> $(RISMSANDER) -o $. multitmd.F90
>
> to
> multitmd.o: multitmd.F90
> $(FC) $(FPPFLAGS) -c $(FFLAGS) $(FFLAGS) $(AMBERFFLAGS)
> $(RISMSANDER) -o $. multitmd.F90
>
In my experience, this indicates an uninitialized variable. If it occurs
in serial, a quick valgrind may help catch it (maybe even compiler warnings
will...)
> But 3 had actual large differences. The content of
> FINAL_RESULTS_MMPBSA_1.dat.dif is
>
> 17c17
> < Vibrational 70.6419 10.6543
> 4.7647
> > Vibrational 68.1106 4.6216
> 2.0668
> 18c18
> < Total 95.7422 11.1286
> 4.9769
> > Total 93.2564 5.0712
> 2.2679
> 38c38
> < Vibrational 12.7828 10.6560
> 4.7655
> > Vibrational 10.2511 4.6255
> 2.0686
> 39c39
> < Total -8.7066 11.1313
> 4.9781
> > Total -11.1926 5.0770
> 2.2705
> ### Maximum absolute error in matching lines = 6.06e+00 at line 18 field 3
> ### Maximum relative error in matching lines = 1.31e+00 at line 17 field 3
>
The real explanation has become very lengthy, so I've moved it into an
appendix of sorts below, and provide here the hand-wavy argument that "the
system is small and silly, so these diffs are not surprising". Because
this test tests ALL of the functionality, using anything but a tiny system
would take ages. I have found it very useful in the past for debugging,
but since users will probably never want to do _everything_ in one script,
this particular test should probably be removed from the full test suite.
All the best,
Jason
And for the lengthy explanation for those that want one:
I'll still argue this is not a real failure. At its core, MMPBSA.py (and
mm_pbsa.pl) are glorified parsers in interpreted languages, making them
incredibly stable across platforms (since the whole "compiler" thing is
irrelevant here). I've verified by hand that the values MMPBSA.py prints
to the final output files are the actual averages and standard deviations
from the output files. Therefore, the differences stem from results
reported by the "nmode" call in NAB (since all failures are normal mode
related) -- and these results differ based on the math library used moreso
than any other factor, if I recall correctly.
Also, the system itself is silly (70 kcal/mol is, after all, a _very_ low
value for total vibrational entropy) -- it's a tripeptide 'binding' to a
tripeptide. The complex has between 5 and 10 eigenvalues that report no
entropy contributions (because the frequencies are either too low or
imaginary), so there are a lot of eigenvalues that contribute sensitive
values (sensitive to the math library, that is) -- keeping in mind there is
a minimization step that occurs before this, whose convergence and final
coordinates may slightly vary from lib to lib. This gives rise to a noisy
value for the entropy.
I'll also point out that ASCII coordinates have only 3 decimals for each
coordinate. Even final GB binding results are sensitive to what mask is
used to perform an RMSD fit to prior to evaluating the energy because the
precision of the coordinates is so low. The differences that are tagged
here only occur in the vibrational part of the entropy. For the 5
snapshots, here are the vibrational entropy contributions:
ifort/MKL macAccelerate,GNU
68.2465 65.438
76.268 81.7492
64.4967 64.4955
65.6842 65.6869
67.8485 65.9478
Snapshot 2 is the biggest difference here. In snapshot 2, the Mac side has
an entropic contribution from the 8th eigenvector, frequency 0.081 (17.576
cal/mol-K), whereas that same mode has frequency 0.000 and is omitted with
the MKL. The only appreciable differences in the two outputs are in the
super-super low (to negative) frequency modes, and it is these that count
the most toward the entropy. As soon as you start looking at larger
eigenvalues (e.g. the ~15th eigenvalue goes from 0.450 to 14.518), then the
differences become far more modest (14.518 vs. 14.514). This translates to
an entropy difference of 0.001 cal/mol-K, which is a diff of 0.0002 when
transformed to kcal/mol. However, the contributions from the 4 or 5
eigenvectors above gives rise to the difference we observe in the output
file. This, I claim, is neither MMPBSA.py's fault nor is it something we
should be concerned about.
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Mar 22 2012 - 15:00:02 PDT
