[gmx-developers] next Gromacs release

[Erik Marklund]

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.

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


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