Re: FATAL ERROR:BAD GLOBAL EXCLUSION COUNT:Please help

From: Werner Crous (crous.werner_at_gmail.com)
Date: Thu Mar 18 2010 - 04:23:55 CDT

Dear Chris

Thank you for the response. I did try splitpatch and this also did not work
and I do not really want to have flexible bonds between the heavy atoms and
hydrogens. Since the problem, I tried to use the input coordinates of the
file that I

On Wed, Mar 17, 2010 at 7:13 AM, Chris Harrison <charris5_at_gmail.com> wrote:

> Werner,
>
> Please have a look at the NAMD troubleshooting guide:
> http://www.ks.uiuc.edu/Research/namd/wiki/index.cgi?NamdTroubleshooting
>
> Pay particularly close attention to the "Bad global exclusion count"
> section and the suggested fix:
>
> -----
> These errors generally indicate that two atoms that are (ususally
> implicitly) excluded are on non-neighboring patches or are more than the
> cutoff distance apart. The situation is analogous for bond, angle, dihedral,
> or improper count errors.
>
> This is often caused by similar input problems as in "Atoms moving too
> fast" above. In particular, atoms with uninitialized coordinates (0,0,0) may
> cause this error on the first timestep.
>
> This will also happen if you have a periodic cell and the input coordinates
> to NAMD are wrapped on a per-atom basis so that there are bonds to hydrogen
> atoms extending across the cell (i.e., you load the psf and pdb in VMD and
> see very long bonds to hydrogens). *You can work around this with the
> ancient "splitPatch position" option, which makes every atom its own
> hydrogen group (this option disables rigid bonds and hurts performance, so
> don't use it normally). It's better to just fix the input coordinates so
> that the bonds look normal in VMD. *
>
> Another possibility is that some atoms are specified more than once, for
> example one residue ends up in two chains. This is very difficult to spot in
> VMD as these duplicate atoms have the same coordinates.
>
> -----
>
> Should this fail to fix your problem, please let us know.
>
>
> Chris
>
>
> --
> Chris Harrison, Ph.D.
> Theoretical and Computational Biophysics Group
> NIH Resource for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave., Urbana, IL 61801
>
> char_at_ks.uiuc.edu Voice: 217-244-1733
> http://www.ks.uiuc.edu/~char <http://www.ks.uiuc.edu/%7Echar>
> Fax: 217-244-6078
>
>
> On Sat, Mar 13, 2010 at 11:22 AM, Werner Crous <crous.werner_at_gmail.com>wrote:
>
>> Dear NAMD-users
>>
>> I setup a large system in CHARMM, done minimization and 200ps NPT
>> dynamics, with no problems. However, when I tried to continue dynamics with
>> NVT in NAMD I got the error listed in the subject line. I read almost every
>> account of this error on the list, and it seems to me that it has to do with
>> the way in which NAMD partitions the system in patches and that some of the
>> water molecules in my system, that were wrapped to the unit cell by NAMD,
>> were "split" in the process with some atoms of the water molecules at the
>> top and others at the bottom of the unit cell. As I understand it, NAMD
>> cannot put molecules with "elongated bonds " longer than the cut-off
>> distance in a patch and this causes the error. I do not understand how this
>> could have happened since I imaged my water molecules in CHARMM by residue.
>> Can someone please tell me if there is a quick way of fixing this and how to
>> prevent this error form occurring in the future? I ran successful
>> simulations with NAMD in the past and this is the first time this error
>> occurs.
>>
>> Best regards
>> --
>> Werner Crous
>> Scientific Computing Research Unit
>> University of Cape Town
>> Rondebosch 7701
>> South Africa
>> Phone: +27 21 650 2530 (O)
>> Fax: +27 21 686 4333
>> http://scru.uct.ac.za
>> http://scientificomputing.com
>>
>
>
>
>
>

-- 
Werner Crous
Scientific Computing Research Unit
University of Cape Town
Rondebosch 7701
South Africa
Phone: +27 21 650 2530 (O)
Fax: +27 21 686 4333
http://scru.uct.ac.za
http://scientificomputing.com

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 05:22:49 CST