[gmx-developers] next Gromacs release

[Rossen Apostolov]

Hi Erik,

On 06/10/2010 10:12 PM, Erik Marklund wrote:
> Hi,
>
> Hm. Embarassingly, it turns out that my posre-tpr didn't have any 
> position restraints. That sure explains it. I guess the bug can be 
> closed.
>
>
> As for the g_hbond specifics, I first got error messages, then a 
> segfault. It's easily circumvented by adding the following check:
>            if (func_type == F_POSRES)
>            {
>                continue;
>            }
> which i did put in my version, but it seems I forgot to push it. The 
> line that causes the problems reads:
>                
> i+=interaction_function[top->idef.functype[interaction->iatoms[i]]].nratoms+1) 
> {
> If interaction->iatoms[i] doesn't index idef.functype, then a lot of 
> things can happen.
>
> I'll push my gmx_hbond.c right away.
>
Did you already updated the file? Can you close the bug if so.

Rossen
> Erik
>
> Berk Hess skrev:
>> Hi,
>>
>> For a tpr I made it works fine.
>> Could you attach a tpr to the bugzilla?
>>
>> I already noticed the lacking documentation in idef.h, I fixed that now.
>>
>> Berk
>>
>> Erik Marklund wrote:
>>> Hi,
>>>
>>> I suspected something along those lines. But why then is
>>> top->idef.iparams_posres == NULL? g_hbond reads the tpr-file with
>>> read_tpx_top, which in turn calls read_tpx() and
>>> gmx_mtop_t_to_t_topology(). Here's what I spot when running gdb:
>>>
>>> 1057                interaction=&(top->idef.il[func_type]);
>>> (gdb) p top->idef    $1 = {
>>>  ntypes = 412,
>>>  atnr = 16,
>>>  functype = 0x1002000,
>>>  iparams = 0x799000,
>>>  fudgeQQ = 0.833299994,
>>>  cmap_grid = {
>>>    ngrid = 0,
>>>    grid_spacing = 0,
>>>    cmapdata = 0x0
>>>  },
>>>  iparams_posres = 0x0, <==== Lookie here!
>>>  iparams_posres_nalloc = 0,
>>> ...
>>>
>>> This suggests that the posres stuff isn't passed to the t_topology
>>> properly. Dunno if this is a big issue for the analysis tools though.
>>>
>>> Furthermore, if this is not a bug then I think one should extend the
>>> unusually descriptive comment in idef.h to make it clear that the
>>> t_ilist indexes the ipatams_posres[], and not params and functype[] as
>>> the comment now states:
>>>
>>> /*
>>> * The struct t_ilist defines a list of atoms with their interactions.
>>> * General field description:
>>> *   int nr
>>> *      the size (nr elements) of the interactions array (iatoms[]).
>>> *   t_iatom *iatoms
>>> *      specifies which atoms are involved in an interaction of a 
>>> certain
>>> *       type. The layout of this array is as follows:
>>> *
>>> *       
>>> +-----+---+---+---+-----+---+---+-----+---+---+---+-----+---+---+...
>>> *       
>>> |type1|at1|at2|at3|type2|at1|at2|type1|at1|at2|at3|type3|at1|at2|
>>> *       
>>> +-----+---+---+---+-----+---+---+-----+---+---+---+-----+---+---+...
>>> *
>>> *      So for interaction type type1 3 atoms are needed, and for type2
>>> and
>>> *      type3 only 2. The type identifier is used to select the
>>> function to
>>> *      calculate the interaction and its actual parameters. This type
>>> *      identifier is an index in a params[] and functype[] array.
>>> */
>>>
>>> hess at sbc.su.se skrev:
>>>> Hi,
>>>>
>>>> Due to the molecular topology change for 4.0
>>>> posres now indexing into idef.iparams_posres iso idef.iparams.
>>>> This is required, because position restraints are the only
>>>> interactions with different parameters for each molecule.
>>>>
>>>> Berk
>>>>
>>>>
>>>>> I found a new bug while attempting to fix bug 334 and submitted a new
>>>>> bugzilla (http://bugzilla.gromacs.org/show_bug.cgi?id=428). I'm not
>>>>> entirely sure this is a bug, or the way it's intended, but the 
>>>>> t_ilist
>>>>> contains strange things when the a tpr file is generated with 
>>>>> position
>>>>> restraints. I can easily make a fix for this in gmx_hbond.c, but 
>>>>> that's
>>>>> not how to mend broken things if the error really is in grompp.
>>>>>
>>>>> To summarize, top->idef.il[F_POSRES] dereferences the wrong 
>>>>> functypes.
>>>>> For my test system it dereferences LJ (SR):
>>>>>
>>>>>   (gdb) p top->idef.il[44].iatoms[0]
>>>>>   $31 = 0
>>>>> ...
>>>>>   (gdb) p top->idef.functype[0]
>>>>>   $36 = 31
>>>>>   (gdb) p interaction_function[31].longname
>>>>>   $37 = 0x5fa3ba "LJ (SR)"
>>>>>
>>>>> Is this really the way it should be?
>>>>>
>>>>> Erik
>>>>>
>>>>> Rossen Apostolov skrev:
>>>>>> To all developers,
>>>>>>
>>>>>> The new release of Gromacs is coming close. Before releasing the new
>>>>>> packages though, in the next couple of weeks until June 15:
>>>>>>
>>>>>> * everything in bugzilla should be cleared (David already started
>>>>>> exterminating :). If you see a bug that you can fix or help with,
>>>>>> please do so.
>>>>>> * if there are still any known issues, please file a bug asap or 
>>>>>> send
>>>>>> a patch.
>>>>>> * do not add any new features! Berk has some AmberFF stuff but apart
>>>>>> from that everything new should wait for the next release
>>>>>> * make sure that everything compiles without warnings on all 
>>>>>> platforms
>>>>>> that you have access to
>>>>>>
>>>>>> Hopefully all that will be done by the 15th and have a bug-free
>>>>>> summer:)
>>>>>>
>>>>>> Cheers,
>>>>>> Rossen
>>>>> -- 
>>>>> -----------------------------------------------
>>>>> Erik Marklund, PhD student
>>>>> Dept. of Cell and Molecular Biology, Uppsala University.
>>>>> Husargatan 3, Box 596,    75124 Uppsala, Sweden
>>>>> phone:    +46 18 471 4537        fax: +46 18 511 755
>>>>> erikm at xray.bmc.uu.se    http://folding.bmc.uu.se/
>>>>>
>>>>> -- 
>>>>> gmx-developers mailing list
>>>>> gmx-developers at gromacs.org
>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> Please don't post (un)subscribe requests to the list. Use the
>>>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>>>
>>
>
>