[gmx-users] Energy minimization Error
Mark Abraham
Mark.Abraham at anu.edu.au
Sat Feb 11 01:11:35 CET 2012
On 11/02/2012 4:15 AM, francesca vitalini wrote:
> Ok now I have tryied to restart it all and the problem seems to be
> that the system has some overlapping. In fact, no matter what I
> freeze, water, CA or nothing, I get this error message
>
> VERSION 3.3.1
>
> This program is free software; you can redistribute it and/or
> modify it under the terms of the GNU General Public License
> as published by the Free Software Foundation; either version 2
> of the License, or (at your option) any later version.
> If you want to redistribute modifications, please consider that
> scientific software is very special. Version control is crucial-
> bugs must be traceable. We will be happy to consider code for
> inclusion in the official distribution, but derived work must not
> be called official GROMACS. Details are found in the README & COPYING
> files.
>
> :-) gaia30 (-:
>
> Option Filename Type Description
> ------------------------------------------------------------
> -s EM3.tpr Input Generic run input: tpr tpb tpa xml
> -o EM3.trr Output Full precision trajectory: trr trj
> -x EM3.xtc Output, Opt! Compressed trajectory (portable xdr
> format)
> -c EM3.gro Output Generic structure: gro g96 pdb xml
> -e EM3.edr Output Generic energy: edr ene
> -g EM3.log Output Log file
> -dgdl EM3.xvg Output, Opt. xvgr/xmgr file
> -field EM3.xvg Output, Opt. xvgr/xmgr file
> -table EM3.xvg Input, Opt. xvgr/xmgr file
> -tablep EM3.xvg Input, Opt. xvgr/xmgr file
> -rerun EM3.trr Input, Opt. Generic trajectory: xtc trr trj gro
> g96 pdb
> -tpi EM3.xvg Output, Opt. xvgr/xmgr file
> -ei EM3.edi Input, Opt. ED sampling input
> -eo EM3.edo Output, Opt. ED sampling output
> -j EM3.gct Input, Opt. General coupling stuff
> -jo EM3.gct Output, Opt. General coupling stuff
> -ffout EM3.xvg Output, Opt. xvgr/xmgr file
> -devout EM3.xvg Output, Opt. xvgr/xmgr file
> -runav EM3.xvg Output, Opt. xvgr/xmgr file
> -pi EM3.ppa Input, Opt. Pull parameters
> -po EM3.ppa Output, Opt. Pull parameters
> -pd EM3.pdo Output, Opt. Pull data output
> -pn EM3.ndx Input, Opt. Index file
> -mtx EM3.mtx Output, Opt. Hessian matrix
> -dn EM3.ndx Output, Opt. Index file
> -coarse ION.gro Input Generic trajectory: xtc trr trj gro
> g96 pdb
>
> Option Type Value Description
> ------------------------------------------------------
> -[no]h bool no Print help info and quit
> -nice int 19 Set the nicelevel
> -deffnm string EM3 Set the default filename for all file options
> -[no]xvgr bool yes Add specific codes (legends etc.) in the
> output
> xvg files for the xmgrace program
> -np int 1 Number of nodes, must be the same as used for
> grompp
> -nt int 1 Number of threads to start on each node
> -[no]v bool yes Be loud and noisy
> -[no]compact bool yes Write a compact log file
> -[no]sepdvdl bool no Write separate V and dVdl terms for each
> interaction type and node to the log file(s)
> -[no]multi bool no Do multiple simulations in parallel (only with
> -np > 1)
> -replex int 0 Attempt replica exchange every # steps
> -reseed int -1 Seed for replica exchange, -1 is generate
> a seed
> -[no]glas bool no Do glass simulation with special long range
> corrections
> -[no]ionize bool no Do a simulation including the effect of an
> X-Ray
> bombardment on your system
>
>
> Back Off! I just backed up EM3.log to ./#EM3.log.2#
> Getting Loaded...
> Reading file EM3.tpr, VERSION 3.3.1 (single precision)
> Loaded with Money
>
>
> Back Off! I just backed up EM3.edr to ./#EM3.edr.2#
> Steepest Descents:
> Tolerance (Fmax) = 1.00000e+01
> Number of steps = 200
> ------------------------------------------------------- inf,
> atom= 15321
> 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. It should have been within [ 0 ..
> 42875 ]
> Please report this to the mailing list (gmx-users at gromacs.org
> <mailto:gmx-users at gromacs.org>)
> -------------------------------------------------------
>
> "With a Lead Filled Snowshoe" (F. Zappa)
>
> Halting program mdrun
>
> gcq#159: "With a Lead Filled Snowshoe" (F. Zappa)
>
> --------------------------------------------------------------------------
> MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
> with errorcode -1.
>
> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
> You may or may not see output from other processes, depending on
> exactly when Open MPI kills them.
>
>
> So... How ca I overcome the issue of overlapping atoms?
Generate better FG structures using a better method.
Try vacuum MD or SA with tiny time steps and no bond constraints.
Mark
> Thanks
> Fra
>
> 2012/2/10 francesca vitalini <francesca.vitalini11 at gmail.com
> <mailto:francesca.vitalini11 at gmail.com>>
>
> In fact in the reverse transformation I'm feeding the CG structure
> information.
> 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?
>
>
>
>
> 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 <tel:%2B49%203083875776>
> +49 3083875412 <tel:%2B49%203083875412>
>
>
>
>
> --
> 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/9f1f6368/attachment.html>
More information about the gromacs.org_gmx-users
mailing list