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

[David van der Spoel]

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.

One does get problems with inconsistent shifts as soon as one has 
distances larger than half the box though...

-- 
David.
________________________________________________________________________
David van der Spoel, PhD, Assoc. Prof., Molecular Biophysics group,
Dept. of Cell and Molecular Biology, Uppsala University.
Husargatan 3, Box 596,  	75124 Uppsala, Sweden
phone:	46 18 471 4205		fax: 46 18 511 755
spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++