Bridge adjacencies query performance

[Guilherme Caminha]

I have finished the first prototype for my numerical solver, and running a profiler I have noticed that most of the time (55%) is spent within the get_bridge_adjacencies method (see attachment, following the leftmost nodes). Since I am running some finite volumes methods, the query for adjacency is inherently associated with the algorithms.

So, I believe this is expected by design due to the nature of the mesh storage technique, and the bridge adjacencies need (I believe) to be calculated every time. It might also be worth noting that this method is being called in a tight python loop.

Therefore, I'd like to know if there's another built-in method for getting those adjacencies? I am aware of AHF which, according to some benchmarks, is faster in doing some of those, but as discussed in another issue, it does not support polyhedral meshes.

I could also try to "preprocess" or cache those adjacencies, and store them in tags, similarly to what AHF seem to do. Is this a valid strategy?

[Iulian Grindeanu]

yes, you should "cache" the adjacencies, especially if the mesh is not changing. Yes, the adjacencies are computed every time; the first time they also involve creation of the "bridge" entities, if they are not there already. What is the dimension of the bridge? I mean, what is a typical call for get_bridge_adjacencies? Also, caching is something you can do outside moab, or moab can help if you create a tag and store the result. If the result is the same "size", you should use a dense tag for storage (for example, there are 2 polyhedra adjacent to any face in the model, one could be 0 for boundary faces). If you store the polyhedra adjacent to a vertex, that is usually not constant size, you should use a sparse tag.

[Guilherme Caminha]

That's great info, thanks. In general, my queries are to find faces that form a polyhedron, or polyhedra around a polyhedron through its faces (mostly similar in 2d changing polyhedron to polygon and face to edge). So I will probably be going to use sparse tags as you pointed out.

[Iulian Grindeanu]

so connectivity for a polyhedra is the list of faces, you probably know that;

if you need polyhedra adjacent to a polyhedron, then yes, you should cache them if you need that repeatedly.

[Iulian Grindeanu]

I wanted to say you need a variable size tag

or create a vector of entities, pointed to by the tag (in which case the tag can be of fixed size, and dense, and type OPAQUE, because it is a pointer to the vector ); Of course, you have to manage the lifecycle of those local vectors. It is in a way similar to caching the info yourself.

[Guilherme Caminha]

Okay, now it makes more sense. I was scratching my head thinking how sparse tags would make a difference. I'll see what is the best way to do this with Python, since there are now a few optipns. Thanks.