Re: [AMBER-Developers] Segfault in pmemd or sander on heating

From: David Cerutti <>
Date: Mon, 18 Mar 2019 16:37:05 -0700

When I built that structure I took away the half occupancy waters in favor
of one or the other. The leap program's side chain reconstructions may
also have required a choice of one state or another, alternating for a
tyrosine iirc.

On Mon, Mar 18, 2019, 2:19 PM James Holton <> wrote:

> I've been banging my head against this for a few days now.
> I THINK the problem is partial-occupancy waters in the deposited 1aho
> structure. There are pairs of 0.5-occupied waters in close proximity.
> These seem to hold a lot of stored energy. I also think the leap-built
> side chains are creating clashes.
> Another problem was that I set the C-alpha restraints too high. I've put
> that back now. Was trying to create a reference where the C-alphas were
> in exactly the same place as they are in the x-ray structure. I guess
> I'll have to use my pdb-editing-foo to do that properly.
> Something else that seemed to help was running the pdb through
> minimization in refmac first. I'm not sure why. Does the amber
> minimizer use the periodic boundary conditions? Does it use
> electrostatics? Is there a way to turn electrostatics off?
> Anyway. I still don't have a happy solution, but I'll keep you posted.
> -James
> On 3/18/2019 7:33 AM, David A Case wrote:
> > On Sat, Mar 16, 2019, James Holton wrote:
> >
> >> Ok. Got a weird one.
> >
> > Are you sure the minimization (probably run on the CPU version of pmemd)
> > went well? Does the energy reported in Heat.out for step 0 match the
> > energy you got from the final step of the minimization?
> >
> > Getting a giant velocity component (vmax) at step 0 generally reflects
> > bad starting coordinates.
> >
> > About the errors: the CUDA errors are probably inevitable: the code is
> > highly optimized, and not wasting time checking for possible errors.
> >
> > I agree that getting a segfault with sander should not happen. But this
> > appears to be coming from a big coordinate shift, which pushes some atom
> > out the range of the index table that sander uses to implement periodic
> > boundary conditions.
> > I ran the sander job with pmemd instead, and got (presumably) the same
> > segfault, indicating the problem is in some code common to the two
> > programs. Will look into this more.
> >
> > ...thx...dac
> >
AMBER-Developers mailing list
Received on Mon Mar 18 2019 - 17:00:02 PDT
Custom Search