[gmx-developers] bug in 407 with charge groups

[Justin A. Lemkul]

Berk Hess wrote:
> 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.
>>

Wouldn't the code you added always print "The largest charge group contains 32 
atoms. The maximum is 32." ?

     if (maxsize > MAX_CHARGEGROUP_SIZE)
     {
         gmx_fatal(FARGS,"The largest charge group contains %d atoms. The 
maximum is 32.",MAX_CHARGEGROUP_SIZE);
     }


Would a more suitable change be:

     if (maxsize > MAX_CHARGEGROUP_SIZE)
     {
         gmx_fatal(FARGS,"The largest charge group contains %d atoms. The 
maximum is %d.",maxsize,MAX_CHARGEGROUP_SIZE);
     }

-Justin

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

-- 
========================================

Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin

========================================