Man this was harder to track down than it should have been.
Would you try adding the line:
SubFunctor::join(other);
to the end of SortAndCopy::join, around generic_projector.h:1649?
That seems to fix the problems I'm able to trigger easily; hoping it
will fix yours too. I have to run and be
Awesome, thanks Roy.
On Tue, May 14, 2019 at 2:36 PM Stogner, Roy H
wrote:
>
> On Mon, 13 May 2019, Alexander Lindsay wrote:
>
> > I could maybe think of a libmesh-only case, but if you're willing to
> > run MOOSE, you can run the
> > moose/test/tests/geomsearch/nearest_node_locator/nearest_node
On Mon, 13 May 2019, Alexander Lindsay wrote:
> I could maybe think of a libmesh-only case, but if you're willing to
> run MOOSE, you can run the
> moose/test/tests/geomsearch/nearest_node_locator/nearest_node_locator.i
> input file. It appears to reproduce the error every time (with
> --n-threa
On Mon, May 13, 2019 at 4:45 PM Alexander Lindsay
wrote:
> I could maybe think of a libmesh-only case, but if you're willing to run
> MOOSE, you can run the
> moose/test/tests/geomsearch/nearest_node_locator/nearest_node_locator.i
> input file. It appears to reproduce the error every time (with
>
I could maybe think of a libmesh-only case, but if you're willing to run
MOOSE, you can run the
moose/test/tests/geomsearch/nearest_node_locator/nearest_node_locator.i
input file. It appears to reproduce the error every time (with
--n-threads=2).
You're probably already aware of this, but for helg
On Thu, 9 May 2019, Alexander Lindsay wrote:
> I'm getting the helgrind error below. Is this a false positive?
My intuition says "no, this is a real bug", but I'm having trouble
figuring out what's really going on here. There's a race condition
between a read and a write to the same spot in th
