Bug #84

AdaptiveRefinement::refine_and_project fails with assertions enabled in dolfin

Added by Balthasar Reuter over 4 years ago. Updated over 4 years ago.

Status:NewStart date:05/07/2013
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

When compiling dolfin with --enable-debug (and hence activating dolfin_assert()), refinement with projection fails inside the RivaraRefinement:

terminate called after throwing an instance of 'std::runtime_error'
  what():  *** Assertion (&entity.mesh() == _mesh) [at ../../include/dolfin/mesh/MeshFunction.h:146 in get()]
[hpc101:04107] *** Process received signal ***
[hpc101:04107] Signal: Aborted (6)
[hpc101:04107] Signal code:  (-6)
[hpc101:04107] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7ff0c9dcbcb0]
[hpc101:04107] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7ff0c8c73425]
[hpc101:04107] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7ff0c8c76b8b]
[hpc101:04107] [ 3] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x11d) [0x7ff0ca55769d]
[hpc101:04107] [ 4] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb5846) [0x7ff0ca555846]
[hpc101:04107] [ 5] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb5873) [0x7ff0ca555873]
[hpc101:04107] [ 6] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb596e) [0x7ff0ca55596e]
[hpc101:04107] [ 7] ./cylinder(_ZN6dolfin6Logger8__assertESs+0x64) [0x7ef364]
[hpc101:04107] [ 8] ./cylinder(_ZN6dolfin15__dolfin_assertESsmSsSsz+0x3bb) [0x7f2aab]
[hpc101:04107] [ 9] ./cylinder(_ZN6dolfin16RivaraRefinement6refineERNS_4MeshERNS_12MeshFunctionIbEEdddb+0x2d6) [0x81bb66]
[hpc101:04107] [10] ./cylinder(_ZN6dolfin7unicorn18AdaptiveRefinement18refine_and_projectERNS_4MeshESt6vectorISt4pairIPNS_8FunctionES5_IPNS_4FormEjEESaISB_EERNS_12MeshFunctionIbEE+0xff0) [0x768860]
[hpc101:04107] [11] ./cylinder(_ZN6dolfin7unicorn9NSESolver5solveEv+0x77e1) [0x75c741]
[hpc101:04107] [12] ./cylinder(_Z5solveRN6dolfin4MeshERNS_10CheckpointERlR7timevalPS0_+0x77f) [0x5662ff]
[hpc101:04107] [13] ./cylinder(_ZN6dolfin7unicorn13unicorn_solveERNS_4MeshERNS_10CheckpointERlR7timevalRiPFvS2_ESA_PFvS2_S4_S5_S7_PS1_ESB_+0xa4) [0x78b5c4]
[hpc101:04107] [14] ./cylinder(main+0x1d1) [0x5637e1]
[hpc101:04107] [15] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7ff0c8c5e76d]
[hpc101:04107] [16] ./cylinder() [0x564d41]
[hpc101:04107] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 5 with PID 4107 on node hpc101.csc.kth.se exited on signal 6 (Aborted).
--------------------------------------------------------------------------

This is due to the fact, that RivaraRefinement gets called with a new mesh as a copy of the old mesh and a cell_marker-function, that is defined on the old mesh.

My two approaches to fix that were
  • copying the cell_marker-function to a new function that is defined on the new mesh
  • creating a copy of the original mesh (called old_mesh), calling RivaraRefinement with the original mesh and creating the functions to be projected using old_mesh

Unfortunately both failed with the same exception:

  what():  *** Assertion (global_indices[3].count(i)) [at MeshDistributedData.cpp:294 in get_cell_global()]
[hpc101:05768] *** Process received signal ***
[hpc101:05768] Signal: Aborted (6)
[hpc101:05768] Signal code:  (-6)
[hpc101:05768] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f4a4f0b9cb0]
[hpc101:05768] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f4a4df61425]
[hpc101:05768] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f4a4df64b8b]
[hpc101:05768] [ 3] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x11d) [0x7f4a4f84569d]
[hpc101:05768] [ 4] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb5846) [0x7f4a4f843846]
[hpc101:05768] [ 5] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb5873) [0x7f4a4f843873]
[hpc101:05768] [ 6] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb596e) [0x7f4a4f84396e]
[hpc101:05768] [ 7] ./cylinder(_ZN6dolfin6Logger8__assertESs+0x64) [0x7ef344]
[hpc101:05768] [ 8] ./cylinder(_ZN6dolfin15__dolfin_assertESsmSsSsz+0x3bb) [0x7f2a8b]
[hpc101:05768] [ 9] ./cylinder(_ZN6dolfin19MeshDistributedData15get_cell_globalEj+0xe3) [0x806e73]
[hpc101:05768] [10] ./cylinder(_ZN6dolfin16DiscreteFunction11init_ghostsEv+0x214) [0x85bb54]
[hpc101:05768] [11] ./cylinder(_ZN6dolfin16DiscreteFunction4initERNS_4MeshERNS_13GenericVectorERKN3ufc4formEj+0xe8) [0x85c838]
[hpc101:05768] [12] ./cylinder(_ZN6dolfin16DiscreteFunctionC2ERNS_4MeshERNS_13GenericVectorERNS_4FormEj+0x15b) [0x85cc2b]
[hpc101:05768] [13] ./cylinder(_ZN6dolfin8Function4initERNS_4MeshERNS_13GenericVectorERNS_4FormEj+0x61) [0x7c0ee1]
[hpc101:05768] [14] ./cylinder(_ZN6dolfin7unicorn18AdaptiveRefinement18refine_and_projectERNS_4MeshESt6vectorISt4pairIPNS_8FunctionES5_
[hpc101:05768] [15] ./cylinder(_ZN6dolfin7unicorn9NSESolver5solveEv+0x77e1) [0x75c741]
[hpc101:05768] [16] ./cylinder(_Z5solveRN6dolfin4MeshERNS_10CheckpointERlR7timevalPS0_+0x77f) [0x5662ff]
[hpc101:05768] [17] ./cylinder(_ZN6dolfin7unicorn13unicorn_solveERNS_4MeshERNS_10CheckpointERlR7timevalRiPFvS2_ESA_PFvS2_S4_S5_S7_PS1_E
SB_+0xa4) [0x78b5a4]
[hpc101:05768] [18] ./cylinder(main+0x1d1) [0x5637e1]
[hpc101:05768] [19] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f4a4df4c76d]
[hpc101:05768] [20] ./cylinder() [0x564d41]
[hpc101:05768] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 6 with PID 5768 on node hpc101.csc.kth.se exited on signal 6 (Aborted).
--------------------------------------------------------------------------

I didn't figure out whats the reason for that, if for example the distributed data gets modified (due to some shared pointers or similar). Since copying the mesh should also copy MeshDistributedData and with it all the necessary maps etc.

It is also possible, that this assertion fails anyway and I just didn't reach it with the original code due to the earlier failure.

However, running it with assertions disabled, seems to work fine. Nevertheless, the assertion failing in the latter case seems reasonable, since the not-existence of the entry leads to creating a default-entry in the map.

History

#1 Updated by Balthasar Reuter over 4 years ago

Short update: the two issues are unrelated.
Commenting out the refinement but no other changes (which is like no cells marked for refinement) still produces the second failure.
Calling RivaraRefinement with a new MeshFunction, defined on the new_mesh, works as expected and solves the first issue.

Also available in: Atom PDF