From: 王茜茜 (wangqq430_at_gmail.com)
Date: Tue Sep 05 2017 - 05:23:02 CDT
Dear NAMD developer,
Sorry for troubling you. As proposed the problem above (ERROR:
Constraint failure in RATTLE algorithm for atom 107!), I have not solved it
to date although I have tried many methods.
Now, I found it might be the problem of my installed NAMD2.9 source
software. Because five different systems I used fail to work with NAMD2.9
source, but actually they all work well with
NAMD_2.11_Linux-x86_64-multicore-CUDA.
The plumed official website said plumed was matched to NAMD2.9 source, but
is there more updated NAMD version able to match plumed? How to make them
matched? This problem troubles me for a long time, and I want to try a new
NAMD version. Hope someone help me. Thank you very much.
Qianqian
2017-08-28 9:19 GMT+08:00 王茜茜 <wangqq430_at_gmail.com>:
> Dear Richard,
> Thanks for your kindly attention for my problem.
> I will also go on testing, and I hope I can solve it. Thank you very
> much. Happy Chinese Valentine's Day!
>
>
>
>
> Qianqian
>
>
> 2017-08-28 8:35 GMT+08:00 Richard Overstreet <roverst_at_g.clemson.edu>:
>
>> I would test each one. Start with the minimization since you wouldn't
>> have to start over from the initial minimization.
>>
>> On 08/27/2017 01:33 AM, 王茜茜 wrote:
>>
>> Dear Richard,
>> Sorry for my late reply.The problem may be also related to my
>> exchanged binary velocity files between versions. For the power failture
>> caused by typhoon now, I will try it later.
>> Actually, atoms given by contraints failture are many, and changable
>> everytime when I tried. Most of them including atom 107 is belonging to
>> protein. From your view, this problem is still attributed to the
>> minimization for my system, right?
>>
>>
>>
>>
>> Qianqian
>>
>> 2017-08-26 14:02 GMT+08:00 Richard <roverst_at_g.clemson.edu>:
>>
>>> Qianqian,
>>> To clarify. You wouldn't be exchanging binary velocity files between
>>> versions during an equilibration? Someone may correct me but I think that
>>> could cause read errors if a binary velocity file was written with namd2.11
>>> and read with namd2.9 in between MD phases. Especially if the two versions
>>> where built with different compilers. Also, could you tell me what is atoms
>>> 107 protein/ligand/solvent? One other idea would be to add a minization
>>> just before the md of the free equlibration. So the conf file you sent
>>> would look like.
>>> ...
>>> minimize 10000
>>> run 25000
>>>
>>> -Richard
>>>
>>> On Aug 26, 2017 1:19 AM, 王茜茜 <wangqq430_at_gmail.com> wrote:
>>>
>>> Dear Richard,
>>> Thanks very much for your reply.
>>> Previously,I attributed this behavior to my system. But, as said in
>>> my e-mail, I have did minimization, heating and equilibration (restraint
>>> and free) as you and google suggested. It failed. So, now I am confused
>>> that why it works with NAMD_2.11_Linux-x86_64-multicore-CUDA or other
>>> machine with NAMD2.9 source code.
>>>
>>>
>>> 🤔
>>> Qianqian
>>>
>>>
>>>
>>> 2017-08-26 12:03 GMT+08:00 Richard <roverst_at_g.clemson.edu>:
>>>
>>> If you are using explicit solvent it is usually a good idea to fix or
>>> restrain the protein/ligand atoms and let the solvent atoms equlibrate
>>> after heating the system. Once the solvent is equlibrated you can then run
>>> a second phase with the protein unconstrained. I wouldn't attribute this
>>> behavior to the software just yet.
>>>
>>> -Richard
>>>
>>> On Aug 25, 2017 11:47 PM, 王茜茜 <wangqq430_at_gmail.com> wrote:
>>>
>>> Dear developer,
>>> Recently, I need to use NAMD2.9 source code (because I want to learn
>>> Plumed2.1.2). After installing both two softwares, I tested the given
>>> examples in the manual and both worked well.
>>> Then, I tested my system that worked well previously with
>>> NAMD_2.11_Linux-x86_64-multicore-CUDA. However, when using NAMD2.9
>>> source code, it always gave the error:
>>> ERROR: Constraint failure in RATTLE algorithm for atom 107!
>>> ERROR: Constraint failure; simulation has become unstable.
>>> The following is my conf:
>>> amber yes
>>> parmfile com_sol.prmtop
>>> ambercoor com_sol.inpcrd
>>> set temperature 310
>>> set outputname ../output/md
>>>
>>> # Continuing a job from the restart files
>>> if {1} {
>>> set inputname eq3
>>> binCoordinates ../output/$inputname.restart.coor
>>> binVelocities ../output/$inputname.restart.vel ;# remove the
>>> "temperature" entry if you use this!
>>> extendedSystem ../output/$inputname.restart.xsc
>>> }
>>> exclude scaled1-4
>>> 1-4scaling 0.833333
>>> cutoff 12.0
>>> switching off
>>> switchdist 10.0
>>> pairlistdist 13.5
>>>
>>> # Integrator Parameters
>>> timestep 2.0 ;# 2fs/step
>>> rigidBonds all ;# needed for 2fs steps
>>> nonbondedFreq 1
>>> fullElectFrequency 2
>>> stepspercycle 20
>>> rigidTolerance 0.00001
>>>
>>> # Constant Temperature Control
>>> langevin on ;# do langevin dynamics
>>> langevinDamping 1 ;# damping coefficient (gamma) of 5/ps
>>> langevinTemp $temperature
>>> langevinHydrogen off ;# don't couple langevin bath to hydrogens
>>>
>>> # Periodic Boundary Conditions
>>> wrapAll on
>>>
>>> # PME (for full-system periodic electrostatics)
>>> PME yes
>>> PMEGridSizeX 72
>>> PMEGridSizeY 72
>>> PMEGridSizeZ 80
>>>
>>> # Constant Pressure Control (variable volume)
>>> if {1} {
>>> useGroupPressure yes ;# needed for 2fs steps
>>> useFlexibleCell no ;# no for water box, yes for membrane
>>> useConstantArea no ;# no for water box, yes for membrane
>>>
>>> langevinPiston on
>>> langevinPistonTarget 1.01325 ;# in bar -> 1 atm
>>> langevinPistonPeriod 200.0
>>> langevinPistonDecay 100.0
>>> langevinPistonTemp $temperature
>>> }
>>>
>>> # Output
>>> outputName $outputname
>>>
>>> restartfreq 1000 ;# 500steps = every 1ps
>>> dcdfreq 1000
>>> xstFreq 1000
>>>
>>> run 25000
>>> I have minimized the system for many times and tried other systems,
>>> and obtained same error. Actually, my system worked well in other machines
>>> with NAMD2.9 source code. So, I donot know why. It confused me for two
>>> weeks. so, dear developer, may you give me a help?
>>>
>>>
>>> Qianqian
>>> Macao university
>>>
>>>
>>>
>>>
>>>
>>
>>
>
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2018 - 23:20:34 CST