On Wed, 29 Oct 2014, Robert Blake wrote:
> We're running into a intermittent deadlock when calling
> assign_global_indices(). The problem only appears on >= 5 processors,
> and even then it only appears intermittently.
I'd like to try and replicate, but if it's an intermittent problem
then every bit of information you've got might help: OS, compiler,
configure settings, METHOD, config summary (which isn't redundant
w/settings, since a lot of options are autodetected), libMesh version
(release number or git hash), etc.
> Here's the error we see:
>
> Assertion `hi <= node_upper_bounds[communicator.rank()]' failed.
> hi = 887794606_2212644264_162978473
> node_upper_bounds[communicator.rank()] = 583640776_2377824377_539889346
> [0] src/mesh/mesh_communication_global_indices.C, line 412, compiled Oct
> 29 2013 at 08:06:24
>
> Valgrind for this code returns no problems, both with and without the
> intermittent error.
>
> The code generating this error is as follows:
>
> int main(void) {
I assume a LibMeshInit goes here?
> //create a mesh
> const int dim=3;
> Mesh mesh(dim);
> MeshTools::Generation::build_cube(mesh,
> 5000, 5000, 5000, //increase this if needed to generate the bug.
You're configuring with 8 byte dof indices, I assume? Otherwise
there's no way you're going to be running successfully with more than
a few billion elements.
Actually, wait a minute. Glancing at our libHilbert code it looks
like it's hard-coded to use 32-bit integers. That's not *necessarily*
the end of the world (it still means using 96 bits total, there
should be no collisions on a simple 5000^3 cube, and IIRC we have code
for handling collisions) but it still worries me. Ben, thoughts?
---
Roy
------------------------------------------------------------------------------
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
