Custom Search
----
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).
----
Yes, the problem is in slightly different outputs from the minimization
phase (hence difference in inputs for the diagonalization routines).
Naturally this difference is decreasing with decreasing drms parameter.
Thank you Jason for your valuable advice !
Best wishes,
Marek
Dne Wed, 18 Feb 2015 03:58:18 +0100 Jason Swails <jason.swails.gmail.com>
napsal/-a:
>
>> 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
--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:
http://www.opera.com/mail/
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Feb 20 2015 - 07:30:03 PST