Previous Thread
Next Thread
Print Thread
heating using CHARMM/OpenMM implementation
#37706 11/19/19 05:14 AM
Joined: Dec 2018
Posts: 8
J
Forum Member
OP Offline
Forum Member
J
Joined: Dec 2018
Posts: 8
Dear all,
I am having trouble to set up heating using charmm/openmm implementation and need some help. For a fixed temperature, I can run NVE/NVT/NPT with charmm/openmm implementation without any problem. However, when temperature changes (for heating process), the temperature control seems not working and it dies in the first several steps (with error Energy is NaN). Below you can find my script. I would be very thankful if anyone can instruct me what I did wrong or share with me a working script for heating using charmm/openmm.

Thank you very much.
James

Code:
* stream
*

set t1    8.0
set t2  298.0
set mdstep  8000

dynamics leap start -
         nstep @mdstep timestep 0.002 -
         iunrea -34  iunwri 33   iuncrd 32  kunit -1 -
                     isvfrq 1000 nsavc 1000 nprint 1000 -
         ntrfrq 1000 iprfrq 2000 ixtfrq 1000 ilbfrq 1000 -
         firstt @t1 finalt @t2 tstruc @t1 -
         teminc 5.00 ihtfrq  100 ieqfrq 100 iasor 0 iasvel 1 iscvel 0 -
         ichecw 1 twindh 5.0 twindl -5.0 -
         omm -
         ECHECK 1000000000.0
return

Re: heating using CHARMM/OpenMM implementation
jamesmao #37709 11/19/19 05:00 PM
Joined: Sep 2003
Posts: 8,447
rmv Online Content
Forum Member
Online Content
Forum Member
Joined: Sep 2003
Posts: 8,447
You may need to use the standard MD code for the heating and early equilibration, before changing to the OpenMM code.


Rick Venable
computational chemist

Re: heating using CHARMM/OpenMM implementation
jamesmao #37710 11/19/19 05:55 PM
Joined: Sep 2003
Posts: 4,771
Likes: 2
Forum Member
Online Content
Forum Member
Joined: Sep 2003
Posts: 4,771
Likes: 2
I always heat without using the GPU.
For production runs using OpenMM
ECHECK -1.0 turns off the energy check.
You should probably use the langevin thermostat with OpenMM, and the mixed precision floating point option. I/O is fairly expensive so don't print or output anything more often than you write frames to the trajectory file; set ilbfrq to 0!
It is quite pointless to save the restart file during the trajectory. You should not run longer pieces than you can afford to loose.

This is what I use for production runs (with OPENMM_PRECISION=mixed):

dynamics restart timestep 0.002 nstep 125000000 -
firstt 100 finalt @T - ! firstt is not actually used here
ewald pme kappa 0.34 order 6 fftx @fx ffty @fy fftz @fz -
vswitch cutnb 12.0 cutim 12.0 ctofnb 9.0 ctonnb 8.0
echeck -1.0 imgfrq -1 inbfrq -1 nprint 50000 iprfrq 50000 - ntrfrq 250000 -
iunread 101 iunwrite 201 iuncrd 202 nsavc 50000 ilbfrq 0 -
omm langevin gamma 5

Another performance issue are the NBFIXES - they are expensive, so if you know what you are doing and don't really need them you can remove them from the parameter file; this in particular applies to water-ion nbfixes at low ion concentrations.


Lennart Nilsson
Karolinska Institutet
Stockholm, Sweden
Re: heating using CHARMM/OpenMM implementation
jamesmao #37711 11/20/19 06:27 AM
Joined: Dec 2018
Posts: 8
J
Forum Member
OP Offline
Forum Member
J
Joined: Dec 2018
Posts: 8
thank you all very much. very helpful.


Moderated by  John Legato, lennart, rmv 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 5.6.33-0+deb8u1 Page Time: 0.007s Queries: 22 (0.003s) Memory: 0.9122 MB (Peak: 0.9937 MB) Data Comp: Off Server Time: 2020-05-31 07:28:57 UTC
Valid HTML 5 and Valid CSS