[MOAB-dev] r2543 - MOAB/trunk

[Jason Kraftcheck]

Tim Tautges wrote:
> 
> 
> kraftche at mcs.anl.gov wrote:

>> +    // Put additional higher-order nodes into element connectivity list.
>> +    // Cubit saves full connectivity list only for NodeHex and NodeTet
>> +    // elements.  Other element types will only have the corners and
>> +    // the mid-element node if there is one.  Need to reconsturct
>> additional
>> +    // connectivity entries from mid-nodes of adjacent lower-order
>> entities.
>> +  int node_per_elem = cub_elem_num_verts[blockh->blockElemType];
>> +  if (MBCN::VerticesPerEntity(blockh->blockEntityType) == node_per_elem)
>> +    return MB_SUCCESS;
>> +  +    // Can't use MBInterface::convert_entities because block could
>> contain
>> +    // both entity sets and entities.  convert_entities will fail if
>> block
>> +    // contains an entity set, but we still need to call it on any
>> elements
>> +    // directly in the block (rather than a geometry subset).  So bypass
>> +    // MBInterface and call HOFactory directly with an MBRange of
>> entities.
> 
> Why not modify the convert_entities function to handle this case?  ("It
> would take too much time" is a fair answer in this case).
> 
> - tim

I could change the function such that it recursively retrieved entities from
the set, which would fix the issue I encountered as long as none of the sets
contained vertices.  I chose this way because it seemed to be the least
likely to behave strangely given atypical input.  The only way to make this
work (I tried a few other things that didn't work) is to get the desired HO
element type from the block and convert the elements based on the block
type.  However, Cubit can export strange things like a block with a quad9
type that contains both quads and triangles.  This way only the quads get
mid-edge nodes added and the triangles do not.

- jason