[gmx-users] Energy minimization Error
Mark Abraham
Mark.Abraham at anu.edu.au
Sat Feb 11 01:08:39 CET 2012
On 11/02/2012 2:48 AM, francesca vitalini wrote:
> In fact in the reverse transformation I'm feeding the CG structure
> information.
Yes, but you need a source of atomistic intra-residue knowledge about
protein structure in order to convert a CG structure to something that
is vaguely plausible at FG.
> Once I look through VMD to the FG structure I notice that the
> backbones are not in planes so definitely I need to run some
> minimization there. In the tutorial they were using simulating
> annealing, but I don't think I need more than energy minimization for
> that.
> What do you think?
So you've learned that any kind of simple restraint based on the input
FG structure is likely to produce a garbage result because the atomistic
detail of the input FG structure is garbage. Simulated annealing does
sound like a good way to start refining the structure. You need
something capable of more than local minimization, unlike EM. Tiny time
steps are probably necessary to cope with the large forces.
In GROMACS 4.5 you could use some COM virtual sites (or similar, see
manual) to have position restraints to the positions of the original
beads. If you feel the result of the above refinement has deviated too
much for whatever your real purpose is, then taking the refined
structure and introducing such v-site position restraints could be useful.
Mark
>
>
>
> 2012/2/10 Mark Abraham <Mark.Abraham at anu.edu.au
> <mailto:Mark.Abraham at anu.edu.au>>
>
> On 11/02/2012 12:41 AM, francesca vitalini wrote:
>> In order to overcome the problem I tried to fix everything except
>> the backbone (solvent, sidechain and CA, as I want the structure
>> to be maintained). However, if I do then I have problems with the
>> energy minimization as the force on the 15300 is infinite.
>>
>> Getting Loaded...
>> Reading file EM1-1.tpr, VERSION 3.3.1 (single precision)
>> Loaded with Money
>>
>> Steepest Descents:
>> Tolerance (Fmax) = 1.00000e+01
>> Number of steps = 2000
>> -------------------------------------------------------
>> inf, atom= 15300
>> Program mdrun, VERSION 3.3.1
>> Source code file: nsgrid.c, line: 226
>>
>> Range checking error:
>> Explanation: During neighborsearching, we assign each particle to
>> a grid
>> based on its coordinates. If your system contains collisions or
>> parameter
>> errors that give particles very high velocities you might end up
>> with some
>> coordinates being +-Infinity or NaN (not-a-number). Obviously, we
>> cannot
>> put these on a grid, so this is usually where we detect those errors.
>> Make sure your system is properly energy-minimized and that the
>> potential
>> energy seems reasonable before trying again.
>>
>> Variable ci has value -2147483648 <tel:2147483648>. It should
>> have been within [ 0 .. 27744 ]
>> Please report this to the mailing list (gmx-users at gromacs.org
>> <mailto:gmx-users at gromacs.org>)
>> -------------------------------------------------------
>>
>> "Oh My God ! It's the Funky Shit" (Beastie Boys)
>>
>> Halting program mdrun
>>
>> You suggested to check if there is any overlapping.
>
> ... so you need to get out some visualization software and look at
> the transformed structure :)
>
>
>> There might be as my structure is obtained through a reverse
>> transformation from a CG representation. In the mapping the atoms
>> are positioned randomly in the bead. Now I'm running some energy
>> minimization to equilibrate those atoms. I had to solvate the
>> system after the mapping (couldn't do it before due to problems
>> with ions)but I haven't equilibrated it yet and I'm keeping it
>> fixed which could also be a source of overlapping.
>
> Local minimization with EM cannot in general take a "random"
> positioning of the generated atoms and make it one that will be
> stable under MD. Some structure knowledge needs to be build into
> the reverse transformation.
>
> Mark
>
>
>> Any ideas?
>> Thanks.
>> Francesca
>>
>>
>> 2012/2/10 Justin A. Lemkul <jalemkul at vt.edu <mailto:jalemkul at vt.edu>>
>>
>>
>>
>> francesca vitalini wrote:
>>
>> I achieve
>>
>> Steepest Descents converged to machine precision in 205
>> steps,
>> but did not reach the requested Fmax < 10.
>> Potential Energy = -1.49131940478719e+07
>> Maximum force = 1.09664530279637e+06 on atom 1520
>> (parto of the protein)
>> Norm of force = 2.28369808518165e+06
>>
>>
>> The magnitude of the force suggests atomic overlap somewhere.
>> Start by investigating the environment around atom 1520.
>>
>>
>> and the system looked with vmd doesn't look as if it was
>> exploding. However, I have warnings about the table
>> extension and I don't know why but gromacs writes pdb
>> files sometime. However I thought that there
>>
>>
>> The "step.pdb" files are written when mdrun is about to crash.
>>
>>
>> might have been an error in the way I defined the
>> position restraints, in fact in the mdp file I hade
>> define = -DEPOSRE while in the topology I had ifdef
>> DEFINE_WAT, so it might have moved it all without fixing
>> the water. So I tried again and this time I got
>>
>>
>> The "define" statements are literal, so be careful of typos.
>> -DEPOSRE will not work when the topology calls for -DPOSRES.
>> So unless you've changed default naming for "define"
>> statements, you're not going to get what you expect.
>>
>>
>> Steepest Descents converged to machine precision in 72 steps,
>> but did not reach the requested Fmax < 10.
>> Potential Energy = -2.0135496e+07
>> Maximum force = 2.0486184e+12 on atom 4479
>> Norm of force = 7.2424045e+13
>>
>>
>> Again, symptomatic of severe atomic overlap.
>>
>>
>> but again the same issue with table extent and still the
>> production of pdb files.
>>
>> Any explanations?
>>
>>
>> Investigate the starting configurations near the problematic
>> atoms.
>>
>> http://www.gromacs.org/Documentation/Terminology/Blowing_Up#Diagnosing_an_Unstable_System
>>
>> -Justin
>>
>>
>> --
>> ========================================
>>
>> Justin A. Lemkul
>> Ph.D. Candidate
>> ICTAS Doctoral Scholar
>> MILES-IGERT Trainee
>> Department of Biochemistry
>> Virginia Tech
>> Blacksburg, VA
>> jalemkul[at]vt.edu <http://vt.edu> | (540) 231-9080
>> <tel:%28540%29%20231-9080>
>> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
>>
>> ========================================
>> --
>> gmx-users mailing list gmx-users at gromacs.org
>> <mailto:gmx-users at gromacs.org>
>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>> Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/Search before
>> posting!
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-users-request at gromacs.org
>> <mailto:gmx-users-request at gromacs.org>.
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>>
>>
>>
>> --
>> Francesca Vitalini
>>
>> PhD student at Computational Molecular Biology Group,
>> Department of Mathematics and Informatics, FU-Berlin
>> Arnimallee 6 14195 Berlin
>>
>> vitalini at zedat.fu-berlin.de <mailto:vitalini at zedat.fu-berlin.de>
>> francesca.vitalini at fu-berlin.de
>> <mailto:francesca.vitalini at fu-berlin.de>
>>
>> +49 3083875776 <tel:%2B49%203083875776>
>> +49 3083875412 <tel:%2B49%203083875412>
>>
>>
>>
>
>
> --
> gmx-users mailing list gmx-users at gromacs.org
> <mailto:gmx-users at gromacs.org>
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org
> <mailto:gmx-users-request at gromacs.org>.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
>
>
>
> --
> Francesca Vitalini
>
> PhD student at Computational Molecular Biology Group,
> Department of Mathematics and Informatics, FU-Berlin
> Arnimallee 6 14195 Berlin
>
> vitalini at zedat.fu-berlin.de <mailto:vitalini at zedat.fu-berlin.de>
> francesca.vitalini at fu-berlin.de <mailto:francesca.vitalini at fu-berlin.de>
>
> +49 3083875776
> +49 3083875412
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20120211/28390e1e/attachment.html>
More information about the gromacs.org_gmx-users
mailing list