I've tried to change the code as you suggested, but still, this error
occurred. Probably, I need to change somewhere else?
In the attachment, there is a file, that I changed so you can check it in
case I did something wrong.
Best wishes,
Evgenia Elizarova
ср, 9 дек. 2020 г. в 11:50, David Cerutti <dscerutti.gmail.com>:
> 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
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Dec 11 2020 - 06:00:06 PST
