Dear professor Case,
thank you very much for your prompt answer. Thanks a lot also to Niel !
From your responses clearly follow that memory requirements (for N-R
minimisation and normal mode analysis) are strongly
dependent on quality of the previous conjug. grad. minimistation or more
precisely on the size of the "frms".
I apologize for my ignorance, but because I don't know the algorithms
which are on the "background" of the conformational
entropy calculation I simply assumed, that quality of the conjug. grad.
influence only accuracy of the entropy calculation,
not the memory requirements. If anybody knows some good article or www
regarding this topic please let me know.
Until now I worked just with mm_PBSA routine to carry out energy analysis
of my simulations which was performed
in explicit water. Since NAB seems to me more advanced it could be good
idea to use this new powerful and versatile tool or at least
use NAB for the normal mode analysis.
OK in mm_PBSA is possible to choose between PB and GB algorithms to
calculate desolvation energy. I always used PB
since I read somewhere that it is let say more realistic model but if I am
not wrong in NAB is available only GB
in this moment so what is the better choice (from the point of view of
more realistic results).
#1 - to use mm_PBSA for the enthalpic contribution with PB method to
calculate desolvation energy and
than to use NAB with gb=1 to calculate entropic contribution.
#2 - or it is not a good idea to mix PB and GB like this and more
resonable is to carry whole energy
analysis using NAB ?
Thank you again !
Marek
Dne Tue, 20 Jan 2009 21:53:48 +0100 David A. Case
<case.biomaps.rutgers.edu> napsal/-a:
> On Tue, Jan 20, 2009, Marek Mal? wrote:
>
>>
>> I am dealing with simulations of dendrimer/(RNA,DNA) complexes.
>> Of course that one of the main information of the interest is free
>> energy of binding including also the entropic contribution. But I
>> recently found out that the entropy calculation for the bigger
>> systems ( let say around 10000 atoms) is really very problematic task.
>
> Indeed. It usually takes heroic efforts (within a supercomputer center)
> to go beyond this.
>
>> "allocation failure in vector: nh = 2159739729"
>
> The NAB code is giving a more useful error message (rather than a
> segfault). Here you are asking for 2.1 billion vector elements, each 8
> bytes long, for a total of 17.3 Gbytes. How to get success in such a
> request is something that depends a lot on the local environemnt.
>
>>
>> Here is whole output from NAB:
>>
>> ################NAB OUTPUT##############NAB
>> OUTPUT####################################################
>> Reading parm file (g7C_DNAds.prmtop)
>> title:
>>
>> mm_options: cut=999.
>> mm_options: ntpr=1
>> mm_options: nsnb=99999
>> mm_options: diel=C
>> mm_options: gb=0
>> mm_options: dielc=1.0
>> iter Total bad vdW elect nonpolar genBorn
>> frms
>> ff: 0 672691.69 40992.92 8545.93 623152.83 0.00 0.00
>> 3.82e+01
>> ff: 1 672691.69 40992.92 8545.93 623152.83 0.00 0.00
>> 3.82e+01
>> ff: 2 672691.68 40992.92 8545.93 623152.83 0.00 0.00
>> 3.82e+01
>> mm_options: ntpr=1
>> allocation failure in vector: nh = 2159739729
>
> If/when you solve the memory problem, you will need to use xmin to
> minimize to a *much* lower "frms" (force rms) value, something like
> 10**-5 or lower (rather than the value of 38 listed above.) See the
> txmin.nab example in $AMBERHOME/test/nab, but set the value of
> xo.maxiter to a much larger value (try a few thousand to begin with).
>
> ...good luck...dac
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
> __________ Informace od NOD32 3781 (20090120) __________
>
> Tato zprava byla proverena antivirovym systemem NOD32.
> http://www.nod32.cz
>
>
--
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 Wed Jan 21 2009 - 01:27:06 PST
