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

David van der Spoel spoel at xray.bmc.uu.se
Wed Apr 11 09:51:10 CEST 2007

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

More information about the gromacs.org_gmx-developers mailing list