NestedRefine initialize can't reach an error

[Guilherme Caminha]

The line

MB_SET_ERR(MB_FAILURE, "Not supported 2D entity type: POLYGON");

cannot be reached, because the check_mixed_entity_type method from HalfFacetRep.cpp returns true if there's a polygon in the mesh, therefore running:

MB_SET_ERR(  MB_NOT_IMPLEMENTED, "Encountered a mesh with mixed entity types");

instead.

[Vijay M]

We turned AHF to be default on master to see if users notice either regressions or capability issues. However, lack of support for mixed-meshes and polygon/polyhedra elements is an issue. So I plan to turn AHF off and get the original behavior again soon. I will submit a PR for this this week.

Anyway, the issue you raise actually catch two different cases that are unsupported. Hope that is clear.

1. Mixed meshes
2. Polygon support.

[Guilherme Caminha]

@vijaysm Yeah I understand that. I was just reporting this seemingly not-coverable code.

Also, I was hoping to be able to use the built-in refiner with some polygonal - polyhedral meshes, but looks like this is not going to be possible soon. Is there other simple options for that or I should get ready to build something for my cases?

[Vijay M]

Well uniformly refining a polygon is not clearly defined, especially when we are using templates. The best we could do is if the dual of your input mesh is delaunay, then we can refine that and then re-compute the dual to get a refined polygonal mesh. I can't think of anything that would extend cleanly otherwise. If you are interested in something like this, we can perhaps add support. @iulian07 @nray

[Guilherme Caminha]

True, I see that. At first, my intention was to have non-conformities within the mesh, such as:

Allowing that, the refinement would be trivial, since conformities would not need to be handled.

But, as far as I'm concerned, MOAB doesn't allow that directly. I was thinking on a workaround for that by adopting polygonal meshes. The mesh would be conformal, but the geometry could be preserved. Of course then more thought would need to be put on the adaptation problem, which could lead to dropping this strategy since the simplicity of non-conformal meshes would not exist anymore.

In any case, does the NestedRefine support local refinements? I have used this library before: http://sites.uclouvain.be/madlib/ (this website is not updated, and the software seems to be stale anyway). It would be nice to have something like this incorporated, which supports things like sizefields, etc.

[Tim Tautges]

"Well uniformly refining a polygon is not clearly defined, especially when we are using templates. "

Why not just use successive dualization, which is the same as midside subdivision? That would be guaranteed to work in 2d, and in 3d would require 3-valent vertices in the polyhedra?

[Vijay M]

@Estanho We should be able to handle hanging nodes without any issues as is. MOAB does not care about non-conformal meshes to start off with. However, adjacency queries (vertex->element or vice-versa) may not work correctly right now. I have received several requests to fix this and will bump it up our priority list once the current release is done. I think going the route of polygons to handle non-conformities will be an overkill for your case.

The necessary local refinements are available at NestedRefine/Templates.hpp. However, I don't think we have exposed this cleanly to the user as of now. Again, this is on the list of TODO items as we expand our support for AMR in the near future. @nray comments on how to use NestedRefine for local refinements ?

I have also looked at madlib before and it definitely looked interesting. Can investigate this further to see if we can at least provide a similar interface and/or expose some of the adaptive refinement ideas implemented there. There is also the pragmatic library [1], but support for something like this is not planned yet.

@tautges Yes I think midside subdivision is certainly doable in 2-d but I expect uniform refinements to return elements of the same type (not mixed types). There is also an interesting preprint that I found online on this [2].

1. https://github.com/meshadaptation/pragmatic
2. http://alpha.math.uga.edu/~mjlai/papers/COMAID_1559.pdf

[Guilherme Caminha]

@vijaysm Adjacency queries would probably be important for any numerical scheme working on non-conformal meshes. For example, I believe it should be allowed for an edge (in 2D) to have more than three adjacent faces. Or, for example, taking this mesh:

If I took a bridge adjacency query through bridge_dim=1 and to_dim=2, from any of the three elements, the other two should be returned.

Also, I didn't know about pragmatic. Thanks for the recommendation.

When I worked with MAdLib, its interface looked a lot like FMDB, which I believe was ITAPS compliant. That might be a green flag.

[Navamita Ray]

@Estanho Can you point me to the test or example which lead to the not-coverable code along with the configuration parameters ? I will take a look at it.

@vijaysm The NestedRefine is not designed to operate locally only on a set of entities from an initial mesh. There is an assumption of contiguous memory layout or its id-space for the 0-level mesh and the inter-level mesh queries rely on this assumption to perform offset based computations.

[Vijay M]

@nray Thanks for that explanation. I think it should be relatively simple to create local templates for the standard element zoo that we have in MOAB. Of course, we will have to also support the correct adjacency query that will be important for solvers, one of the cases being the one mentioned by @Estanho.

[Guilherme Caminha]

@nray I will upload an example, but any polyhedral mesh will do this.

@vijaysm I also found a paper about the AHF implementation. I wasn't aware that it supported non-manifold meshes. The paper also says that as a future work it would be easy to support polyhedral meshes. Also, it says that it doesn't really have non-conformity capabilities, which surprised me a bit since it supports non-manifold meshes.

[Guilherme Caminha]

@nray If you run, for example, the UniformRefinement.cpp example, with this (vtk) mesh: https://pastebin.com/10ktBNzX , you should be able to reproduce the issue.

[Vijay M]

@nray Did you get a chance to take a look at this ?