On Thu, 24 Jul 2014 14:36:24 -0700
Jason Swails <jason.swails.gmail.com> wrote:
> On Thu, Jul 24, 2014 at 7:47 AM, Hannes Loeffler
> <Hannes.Loeffler.stfc.ac.uk
> > wrote:
>
> > On Fri, 11 Jul 2014 08:16:55 -0700
> > Jason Swails <jason.swails.gmail.com> wrote:
> >
> > >
> > > On Jul 11, 2014, at 1:41 AM, Sushil Mishra
> > > <sushilbioinfo.gmail.com> wrote:
> > >
> > > > Dear all,
> > > >
> > > > Has someone tried to debug this issue ? I have the same issue
> > > > under ubuntu 12.04 in x86_64 HP workstation. It works fine on
> > > > the structure dummy atoms. If someone would like to reproduce
> > > > the problem, there is a structure attached herewith.
> > >
> > > I can confirm that parmchk2 segfaults for me as well on my Linux
> > > machine. However, "parmchk" works just fine, and in this case is
> > > functionally equivalent to parmchk2 (since no parameters can be
> > > found, anyway). It works fine on my Mac.
> > >
> > > In the meantime I'll look into the segfault.
> >
> > I have tried to run this with gdb and gdb thinks the segfaults
> > happens in line 1618 of parmchk2.c . The problem apparently is the
> > variable pid used in this line for indexing which evaluates to -1
> > for unknown atom types. That's the preset value in assign_parmid()
> > (lines 1404ff). I guess the numbers in parmid are bcc types.
> >
>
> I had completely forgotten about this, apologies. Indeed, when I
> trigger a core dump and print the stack trace from that using GDB I
> see the same thing.
>
> I'm not sure what the best solution is, although obviously pid cannot
> be used to access array elements when it's set to -1. It seems that
> the parameter determination was coded under the assumption that pid
> would never be out of bounds of the parm array, so this is unlikely
> to be a trivial 1-line fix. Protection has to be added to basically
> every section (chk_bond, chk_angle, chk_torsion, chk_improper, and
> the check_vdw functions).
The quick fix seems to be to add those "dummy" types (du, zz)
to PARMCHK.DAT. So parmchk2 now looks like doing the "right" thing.
But I am not sure if there would be any downside to this.
Maybe PARMCHK.DAT should have an entry for an 'unknown' atom type to
which assign_parmid links parmid to whenever there is no match with a
known type. A warning could be issued to the user when that happens
although the current strategy is simply to flag this ("ATTN, need
revision") in the comment section in the frcmod file created.
Cheers,
Hannes.
--
Scanned by iCritical.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jul 25 2014 - 03:00:02 PDT
