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".
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 ) ? 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).
> 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). I had
no reason to think about some "global" dielc default value, the properly
chosen default
with respect to combinations with gb values, as I simply assumed that for
gb=1 is
dielc ignored or automatically set to 1 which is true in PERL version as I
already mentioned above.
Thats all :))
Anyway thanks for your comments !
Best wishes,
Marek
Dne Wed, 18 Feb 2015 01:15:37 +0100 Jason Swails <jason.swails.gmail.com>
napsal/-a:
>
>> On Feb 17, 2015, at 4:42 PM, Marek Maly <marek.maly.ujep.cz> wrote:
>>
>> Here
>>
>> ----
>>> dielc should be 1, the perl version is wrong here
>> ----
>>
>> you are probably wrong. As far as I remember, from the very start of my
>> work with
>> Amber (2008) there was "DIELC 4" as the default in the mm_pbsa.in
>> example files for NON-GB calculation.
>
> I admit that I misread your previous email. The dielc=4 case was
> specifically when the GB model was set to 0. If dielc=4 when igb=1,
> then that *is* clearly wrong.
>
>> I can demonstrate that value 4 is more reasonable than 1 directly on my
>> test calculation:
>>
>> python version (nmode_igb=0)
>> DELTA S total= -100.1086 0.0000
>> 0.0000
>>
>> perl version ("IGB 0","DIELC 4" )
>> TSTOT -32.26 0.00
>
> I don’t agree with the premise of your demonstration (i.e., that your
> desired target here is the GB entropy), but this is more philosophical
> than not.
>
>> perl version is here much closer to the results which uses GB (cca -40
>> python, cca -20 perl).
>>
>> Also if dielc is multiplicative scaling parameter seems to me not so
>> useful to have this constant equal 1 by default.
>
> I don’t follow. Just because a scaling parameter exists doesn’t mean it
> should be used...?
>
>> So my opinion is opposite here i.e. I would say that dielc should be 4
>> by
>> default so that value in
>> python version (1) is wrong and should be changed to 4.
>
> I disagree here, and the Python default almost certainly won't change.
> There are two use cases I see:
>
> 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.
>
>> ------------
>> (this should never be !=1 for GB). From the NAB user’s manual
>> describing
>> the “dielc” variable:
>> -------------
>>
>> But sorry if GB is used dielc parameter is not used in calculation (so
>> should be ignored/skipped in the code) so it's actual value in case of
>> calc. with nmode_igb=IGB=1 is irrelevant or am I wrong ?
>
> dielc is not ignored by nab if gb=1. But based on rereading your
> previous email, it seems like dielc is *not* set to 4 when gb=1 in
> mm_pbsa.pl (this was my mistake -- I thought that it was).
>
> HTH,
> 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 Tue Feb 17 2015 - 19:00:02 PST
