Re: [Libmesh-users] Adaptative Mesh Refinement

[Vinicius C. R. <vin...@co...>]

Hi again, it sounds possible that the issue is the hanging nodes. if I only
do one refinement step no error occurs. Adding another step, same
exception. Since I am hard flagging the elements to be refined, quite a few
hanging nodes appear already in the first refinement step. I tried calling
init() before start refining and reinit() at the end of each refinement
step, but another error occurred (this one I couldn't check the stack, the
debugger didn't manage to stop before finishing the execution).

I am not worried if the refinement is propagated through some of the non
selected elements, I was actually expecting this to happen. Is there a way
to detect hanging nodes so I can set the neighbor elements to be refined as
well? Another option I can think is implementing an ElementFlagging object,
but if I use the refine element flag in It I imagine I would fall into the
same problem I was trying to avoid in the first place.


2018-06-05 16:29 GMT-03:00 John Peterson <jwp...@gm...>:

>
>
> On Tue, Jun 5, 2018 at 1:04 PM, Vinicius C. Reis <vin...@co...
> > wrote:
>
>> Sorry about that, I should have imagined... Well, exception and stack
>> trace
>> from a fresh run in the text dump below. I managed to reproduce it in a
>> quite smaller code, what would be the best way to share, paste it into an
>> email or through git repository?
>>
>
> libMesh::System::reinit_constraints (this=0xc26700)
>> libMesh::System::init_data (this=0xc26700)
>> libMesh::ExplicitSystem::init_data (this=0xc26700)
>> libMesh::ImplicitSystem::init_data (this=0xc26700)
>> libMesh::LinearImplicitSystem::init_data (this=0xc26700)
>> libMesh::System::init (this=0xc26700)
>> libMesh::EquationSystems::init (this=0x7fffffffd800)
>> main (argc=1, argv=0x7fffffffdfe8)
>
>
> Hmm... it's likely the problem is related to whatever you are doing to the
> Mesh before you call init(). I don't think you can have refinement/hanging
> nodes in the Mesh before calling init(), for example, but I could be wrong
> about this.
>
> --
> John
>