> On Feb 17, 2015, at 9:18 PM, Marek Maly <marek.maly.ujep.cz> wrote:
>
> OK,
>
> so first of all I already did the change in "mmpbsa_entropy.nab" which you
> suggested
> me and did some calculations with my small testing system to compare with
> older
> Python and Perl results and here they are:
>
> nmode_igb=1, nmode_istrng=0.0 ("IGB 1", "SALTCON 0.0" in Perl version)
>
>
> drms PYTHON_dsyevd | PYTHON_dsyev | PERL_dsyev
> ( ORIG diagon ) (perl diagon) (ORIG diagon)
>
> 0.04 --- -33.3570 -22.70
> 0.03 -33.8740 -27.9280 -27.03
> 0.02 -41.7830 -34.1221 -24.25
> 0.01 -42.0022 -41.7371 -21.02
> 0.005 -44.0156 -44.0597 -21.79
>
> "PYTHON_dsyev" column corresponds to the results with edited
> "mmpbsa_entropy.nab"
> function. I was assuming that the results after the changing
> diagonalization
> routine ( dsyevd -> dsyev ) will not change (just the memory and time
> requirements).
> Fortunately this is true at least for the small drms values :))
>
> It's a pity that "dsyevd" method is not able from some reason work with
> higher
> amounts of memory because along with higher speed we can see that this
> method is
> also a bit less sensitive to "drms" values than "dsyev”.
dsyev and dsyevd are two algorithms that should both give identical eigenvectors and eigenvalues for the same matrix. So this seems to *me* to mean that the matrices are not the same in the two runs you did (especially at the larger drms values like 0.03 and 0.04). This is probably causing a noticeable shuffling of the low-frequency eigenvalues (the high-frequency ones should hopefully all be very similar). Note that normal mode calculations can be VERY sensitive (since the noisiest modes contribute the most to the entropy).
> Anyway we have here still a little "mystery" I mean the clear difference
> between the PYTHON and PERL results. BTW just for the curiosity, would be
> possible to do the similar experiment which we did with PYTHON version
> (dsyevd -> dsyev) also with PERL version (here naturally in oposite manner
> dsyev -> dsyevd ) ?
Yes, you can change the 0 to a 1 (the reverse change you made for the nmode call in mmpbsa_entropy.nab). Just modify the mm_pbsa.pl nabnmode program instead.
> I am really very curious if it might have some
> influence
> on results (especially for small rmsds).
>
> Regarding DIELC value and IGB value in PERL implementation.
>
> I verified that DIELC value does not influence the results if the IGB is
> set to 1.
> Which is something I assumed. So in GB calculations is scaling DIELC
> parameter
> or ignored (but for this case should be in the code IF statement also with
> target elstat. formula without this scaling param) or simply automatically
> set to 1 (if I understood well in case of PYTHON version one has to be
> careful because setting gb=1 will not ensure automatic resetting of dielc
> to 1 if dielc!=1 is set in some input file in the given moment).
This might be. I’ll look into that and change it if necessary.
The discrepancy you are noting here is interesting, and it would be nice to know exactly what is causing it.
The key is probably in the nabnmode output files, which should list the normal mode frequencies as well as the minimization information for the frames. The high-frequency modes should be *very* close between the two scripts (hopefully), and the discrepancy between the two versions may be reflected in relatively large fluctuations of the low-frequency modes.
I’m hoping that we’ll be able to look into this sometime soon in more depth.
>> 1. You want to model aqueous solute entropies with gb=1, dielc=1
>> 2. You want to model gas phase entropies with gb=0, dielc=1
>>
>> Neither of those use-cases use anything except dielc=1. And gb=1 is
>> better than dielc=4 (or any other constant dielectric or distance-based
>> dielectric) for aqueous solute entropies IMO.
>
> You are right !
>
> Here was perhaps some misunderstanding because if I spoke about the
> default value
> for dielc constant I was thinking about the default value just in the
> framework of the
> distance-based dielectric calculations where perhaps value 4 is the most
> appropriate
> (that's why was and still is as the default for DIELC in mm_pbsa.pl).
Ah, I understand. DIELC=4 was probably a good compromise in the pre-GB days for normal mode analysis.
All the best,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Feb 17 2015 - 19:00:03 PST
