[gmx-developers] bug in 407 with charge groups

[Berk Hess]

Hi,

There is a MAX_CHARGEGROUP_SIZE defined in forcerec.h.
This can simply be lowered to 32 (with proper documentation next to 32).

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.
>>>
>>
>>
>
>