I did some investigations on a separate topic, and systems set up with
ff19SB may fail for reasons relating to a bug in the bond work unit
allocation when CMAPs are involved. I will be patching the code ASAP, but
in lieu of the patch you can go into ${AMBERHOME}/src/pmemd/src/cuda/ and
access the file bondRemap.cpp. This is a problem with how the host sets up
the tables for the GPU to execute, but the fix is to look at or about line
395 and change the code block starting there to:
if (objcode == ANGL_CODE || objcode == NMR3_CODE || objcode == CMAP_CODE)
{
if ((objcode == ANGL_CODE && ispresent[2] == 0) ||
(objcode == CMAP_CODE && ispresent[4] == 0)) {
bw->atomList[nunitatom] = p1atm[objID];
nunitatom++;
}
if (unitMapCounts == NULL) {
itmp = unitMap->data;
itmp[p1atm[objID]] = unitID;
}
else {
unitMap->map[p1atm[objID]][unitMapCounts->data[p1atm[objID]]] =
unitID;
unitMapCounts->data[p1atm[objID]] += 1;
}
}
The crucial thing is that "if (ispresent[2] == 0)" changes to either of two
pairs of conditions, involving the objcode as well as the array tracking
whether an atom in the object is already present in the work unit's import
group. I have already verified that this is a bug and that fixing it
solves a similar problem in one of the Simmerling lab's systems, where it
would cause failures like what you are seeing after 35k, 55k, or even 100k
steps. But, if you can modify your own code and re-run your test to
confirm that this solves your problem, that would be ideal.
Thanks,
Dave
On Fri, Dec 4, 2020 at 11:13 AM David A Case <david.case.rutgers.edu> wrote:
> On Mon, Nov 30, 2020, Женя Елизарова wrote:
> >
> >I tried different force fields for protein. It occured that the problem
> (an
> >error "cpubuffer..") was with ff19SB force field. Calculations with
> another
> >types of force fields (14,99) are more stable. Does it mean that i can't
> >use that force field? Or maybe you know how to fix it?
>
> One thing worth trying: get you system well-equilibrated with ff14SB,
> then switch prmtop files to one for ff19SB, and continue the simulation
> after (potential) bad interactions have been removed. It would be of
> interest to know if the ff19SB-related problems still show up.
>
> ....regards...dac
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Dec 09 2020 - 01:00:03 PST