[gmx-developers] bug in 407 with charge groups

Berk Hess hess at cbr.su.se
Tue Nov 2 18:19:05 CET 2010


On 11/02/2010 05:28 PM, Berk Hess wrote:
> On 11/02/2010 04:18 PM, David van der Spoel wrote:
>   
>> On 2010-11-02 16.02, Berk Hess wrote:
>>     
>>> Hi,
>>>
>>> There is a MAX_CHARGEGROUP_SIZE defined in forcerec.h.
>>> This can simply be lowered to 32 (with proper documentation next to 32).
>>>
>>>       
>> The 32 comes from the 32 bit for the t_excl type (unsigned long),
>> something completely different in other words. I put hard checks in
>> grompp for charge groups of 32 atoms now, this has been committed as
>> well.
>>
>>     
> Are you sure exactly 32 works fine and the limit is not 31?
> Then I will change the limit in forcerec.h.
> That check is even more important, since that is in mdrun where the
> actual limitation is.
>
> Berk
>   
Your fix was not very clean with a number 32 in grompp.c.
I put a single definition of MAX_CHARGEGROUP_SIZE=32 in nblist.h,
which is now used both in grompp and mdrun.

Berk
>>     
>>> Berk
>>>
>>> On 11/02/2010 03:03 PM, David van der Spoel wrote:
>>>       
>>>> On 2010-11-02 14.09, David van der Spoel wrote:
>>>>         
>>>>> On 2010-11-02 13.45, Berk Hess wrote:
>>>>>           
>>>>>> Have you checked if the bug is really gone in 4.5.x?
>>>>>> 4.5 has all-vs-all loops, which are used by default (thus no neighbor
>>>>>> searching).
>>>>>> Could you try to run with GMX_NO_ALLVSALL?
>>>>>>             
>>>>> Good point. The bug is still there.
>>>>> I will file a bugzilla.
>>>>>           
>>>> http://bugzilla.gromacs.org/show_bug.cgi?id=608
>>>>
>>>> Charge groups of>  32 atoms will silently give the wrong result. Shall
>>>> I put back the fatal error that used to exist in grompp?
>>>>
>>>> In that case we need to release 4.0.8 (and possibly 3.3.5 as well?).
>>>>
>>>>         
>>>>>> Thanks,
>>>>>>
>>>>>> Berk
>>>>>>
>>>>>> On 11/02/2010 01:31 PM, David van der Spoel wrote:
>>>>>>             
>>>>>>> A local user here brought to my attention that in 4.0.7 there is a
>>>>>>> serious bug due to charge groups. If you have a small molecule with
>>>>>>> all atoms in one charge group and infinite cutoffs in vacuo the
>>>>>>> energy
>>>>>>> is wrong. If you put each atom in it's own charge group the
>>>>>>> result is
>>>>>>> correct (as compared to Macromodel). The reason appears to be
>>>>>>> that the
>>>>>>> neighborlist is incorrect:
>>>>>>>
>>>>>>> 1 cg/molecule
>>>>>>> <  Coulomb + LJ 0.000569 0.022 29.0
>>>>>>> 1 cg/atom
>>>>>>>               
>>>>>>>> Coulomb + LJ 0.000620 0.024 24.9
>>>>>>>>                 
>>>>>>> in other words, 51 interactions are left out. In 4.5.x this bug
>>>>>>> is no
>>>>>>> longer there, so it would be good if the fix that went into 4.0.x as
>>>>>>> well. I can't seem to find any notion of this being fixed in the git
>>>>>>> logs of ns.c though.
>>>>>>>               
>>>>>>             
>>>>>
>>>>>           
>>>>
>>>>         
>>>       
>>
>>     
>   




More information about the gromacs.org_gmx-developers mailing list