[MOAB-dev] Strategies for fixing 2nd adjacency calls in iMesh

James Porter jvporter at wisc.edu
Mon Mar 21 18:40:16 CDT 2011


On 03/21/11, Tim Tautges   wrote:
> Can you review what the problem is, i.e. what the test is expecting vs. what MOAB's giving it?  It seems to me that the results of the 2nd adjacency call should be consistent with the diagonal entries in getAdjTable, which is a fancy way of saying that if internal edges/faces aren't represented, don't expect to get the target dimension entities through those bridge entities.

Without any patches, the test currently fails on second adjacency calls with source_dim = 0, bridge_dim = 1 or 2, target_dim = 3. It expects a bunch of results (200 of them), but we return nothing, presumably because faces and edges aren't explicitly represented.

I then patched MeshTopoUtil to skip the bridge_dim if it's strictly between source_dim and target_dim. This fixed the tests mentioned above, but caused these tests to fail:

  Source type:    vertex  Bridge type:      edge Target type: all types
  Source type:    vertex  Bridge type:      face Target type: all types
  Source type:    vertex  Bridge type: all types Target type:    region
  Source type:    vertex  Bridge type: all types Target type: all types

The failures are essentially the opposite of what they were originally. That is, we return a bunch of results (again, 200 of them) but the unit tests expect no results. I assume this is for the same reason.

One potential problem with the second way is that the unit tests are never skipped when iBase_ALL_TYPES is specified. If you explicitly specify a dimension, it will consult the AdjTable, but it's not smart enough to do this for iBase_ALL_TYPES. Fixing that would probably fix the tests with my patch, though I'm still not sure that's quite right.

- Jim


More information about the moab-dev mailing list