On Sun, Jun 10, 2018 at 10:02 PM, Vinicius C. Reis <viniciusr...@coc.ufrj.br > wrote:
> Hi again, it sounds possible that the issue is the hanging nodes. if I only > do one refinement step no error occurs. Yes, but presumably there are still hanging nodes even after one level of refinement is performed, unless you are referring to one *uniform* refinement step... > 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). > OK, this is what I was going to suggest (calling reinit() between each round of refinement), and it should work. It's possible to you are still doing something in your hard flagging step that we are not set up to handle, a stack track would be helpful, as would sharing the actual code you've written. > 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? Refining neighbors doesn't get rid of hanging nodes, it just makes a hanging node with some other neighbor. You can only eliminate hanging nodes by doing uniform refinement... -- John ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
