[gmx-users] Strong egative energy drift (losing energy) in explicit water AMBER protein simulation

[Justin A. Lemkul]

On 6/13/12 11:49 AM, ms wrote:
> On 13/06/12 16:59, Justin A. Lemkul wrote:
>>
>>
>> On 6/13/12 10:48 AM, ms wrote:
>>> On 13/06/12 16:36, Justin A. Lemkul wrote:
>>>> Here, you're not preserving any of the previous state information.
>>>> You're picking up from 2 ns, but not passing a .cpt file to grompp - the
>>>> previous state is lost. Is that what you want? In conjunction with
>>>> "gen_vel = no" I suspect you could see some instabilities.
>>>
>>> This is interesting -I have to ask the guys who devised the group's
>>> standard
>>> procedure :)
>>>
>>>>> mpirun -np 8 mdrun_d -v -deffn 1AKI_production_GPU -s
>>>>> 1AKI_production_GPU.tpr
>>>>> -g 1AKI_production_GPU.log -c 1AKI_production_GPU.gro -o
>>>>> 1AKI_production_GPU.trr
>>>>> -g 1AKI_production_GPU.log -e 1AKI_production_GPU.edr
>>>>>
>>>>
>>>> As an aside, proper use of -deffnm (not -deffn) saves you all of this
>>>> typing :)
>>>>
>>>> mpirun -np 8 mdrun_d -v -deffnm 1AKI_production_GPU
>>>>
>>>> That's all you need.
>>>
>>> FFFFUUUU that's why -deffn it didn't work! silly me. Thanks!
>>>
>>>>> I am using Gromacs 4.5.5 compiled in double precision.
>>>>>
>>>>> I am very rusty with Gromacs, since I last dealt molecular dynamics
>>>>> more than 1
>>>>> year ago :) , so probably I am missing something obvious. Any hint on
>>>>> where
>>>>> should I look for to solve the problem? (Also, advice on if the .mdp
>>>>> is indeed
>>>>> correct for CUDA simulations are welcome)
>>>>>
>>>>
>>>> I see the same whenever I run on GPU, but my systems are always implicit
>>>> solvent. Do you get reasonable performance with an explicit solvent PME
>>>> system on GPU? I thought that was supposed to be really slow.
>>> >
>>>> Do you observe similar effects on CPU? My tests have always indicated
>>>> that equivalent systems on CPU are far more stable (energetically and
>>>> structurally) than on GPU. I have never had any real luck on GPU. I get
>>>> great performance, and then crashes ;)
>>>
>>> Sorry, perhaps I wasn't clear. This was on normal CPUs! I was trying
>>> to get the
>>> system working on CPU and to see how it behaved before diving in the
>>> GPU misty
>>> sea...
>>>
>>
>> Ah, sorry - with everything being named "GPU" it threw me off. I guess I
>> should have known based on the energy terms. When running on GPU, very
>> little information is printed (something I've complained about before) -
>> you only get Potential, Kinetic, Total, Temperature, and anything
>> related to constraints. I think it's due to limitations in OpenMM, not
>> Gromacs (something that should be improved in upcoming versions).
>>
>> A few things to look at based on the .mdp file:
>>
>> 1. No constraints? Even with a 1-fs timestep, you probably need to be
>> constraining all least the h-bonds.
>
> Ok. We usually don't constrain with 1-fs timestep, and since the gmx website
> said that most restrains were unsupported, I didn't feel like adding them. Will
> ask about this here.
>

Constraints and restraints are different.  Restraints are not supported. 
Constraints are, but not methods like LINCS.  OpenMM uses SHAKE/SETTLE/CCMA 
algorithms for constraints on GPU.

>> 2. nstlist set to 2 is not going to give wrong results, but it's
>> incredibly time-consuming to do neighbor searching that often. A value
>> of 5 or 10 is probably more appropriate.
>
> I have to ask why we use this value as default, and thanks for the tip -however
> this seems not relevant now :)
>
>> 3. COM removal of multiple groups can lead to bad energy conservation.
>
> OK, good to know.
>
>> 4. What happens when you use the Andersen thermostat? That's not
>> implemented yet for CPU calculations (though it was recently pushed into
>> the 4.6 development branch). Your comment regarding GPU is fine, but I
>> would think grompp would complain.
>
> I am unsure of what do you mean. On the gmx website it reads:
> "Temperature control: Supported only with the sd/sd1, bd, md/md-vv/md-vv-avek
> integrators. OpenMM implements only the Andersen thermostat. All values for
> tcoupl are thus accepted and equivalent to andersen. Multiple temperature
> coupling groups are not supported, only tc-grps=System will work."
>
> So it seems that *every* choice of mine means "andersen" in that context. Am I
> wrong?

Huh, I guess this option is accepted.  What was unclear to me was that grompp 
would accept "Andersen" as a valid setting for tcoupl.  All that's being 
referenced in the quote above is that, no matter what you set for the tcoupl 
parameter, mdrun is going to use an Andersen thermostat.

-Justin

>
>> 5. Why not use dispersion correction?
>
> True, why not? :)
> Will give it a shot.
>
>
> thanks!
> m.
>

-- 
========================================

Justin A. Lemkul, Ph.D.
Research Scientist
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin

========================================