[gmx-developers] Nr of graph edges per atom and distance restraints

[Berk Hess]

David van der Spoel wrote:

> Berk Hess wrote:
>
>> David van der Spoel wrote:
>>
>>> hessb at mpip-mainz.mpg.de wrote:
>>>
>>>>> Juergen Haas wrote:
>>>>>
>>>>>>> To get things right,
>>>>>>> you are using only distance restraints, no orientation restraints
>>>>>>> and you get a segfault around line 166 or orires.c, not disre.c ??
>>>>>>
>>>>>>
>>>>>> in that case I forgot to switch off orires...:(
>>>>>> to wrap it up: the segfault seems to have been linked to fftw 
>>>>>> commands
>>>>>> and it
>>>>>> turned out that I overlooked a trivial error: the lam/fftw 
>>>>>> environment
>>>>>> on my
>>>>>> newly installed machine was broken.
>>>>>> Fixing that solved all problems and I could use the suggested 
>>>>>> hack of
>>>>>> increasing g->maxedge.
>>>>>>
>>>>>> Thanks!
>>>>>> Juergen
>>>>>>
>>>>> To finally fix the bugzilla 66, which number of did you use 
>>>>> instead of 4
>>>>> on line 229 of mshift.c?
>>>>
>>>>
>>>>
>>>> This is not relevant.
>>>> The code is quite small and puts only the chemical bonds in the graph
>>>> for interactions within three bonds.
>>>> But one can define as many long-range distance restraints as one 
>>>> likes.
>>>> Therefore there is not limit to the number of graph edges.
>>>>
>>>>> Alternatively, the condition & IF_CHEMBOND on line 201 could be 
>>>>> replaced
>>>>> by & IF_BOND
>>>>
>>>>
>>>>
>>>> This does not help.
>>>
>>>
>>>
>>> I think it will because then distance restraints are included, now 
>>> only true chemical bonds are, and then the number will be determined 
>>> dynamically.
>>>
>> Ah, right.
>> But we don't want that as a general solution,
>> since that could cost a lot of extra allocation and might hurt cache 
>> performance.
>>
>> A solution for distance restraints would be to add tp==F_DISRES.
>> But there was recently also someone with too mant harmonic bonds...
>> So we should think of a robust solution.
>>
>> I just looked into the code and since there is g->nedge,
>> we could first just count everything, then fill the graph as is done 
>> now,
>> then shrink the array while resetting the g->edge pointers
>> and realloc.
>>
>> Berk.
>
>
> I've implemented this in the CVS head branch, and it works fine at 
> least with particle decomposition. Question is whether we want this in 
> 3.3 as well?  It is not a lot of work, so that's not the problem.

You mean count everything, fill and the shrink?
I think it would be nice to have in 3.3, if we are ever going to release 
a 3.3.2.

>
> One does get problems with inconsistent shifts as soon as one has 
> distances larger than half the box though...
>
That can never be avoided.
One should then increase the box size.

Berk.