[MOAB-dev] nonconforming meshes and high order elements, iMeshP

[Jason Kraftcheck]

Jed Brown wrote:
> I'm fairly early in the development of an hp-element code and have some
> questions about MOAB (and other ITAPS components).
> 
> In some of my computations, the mesh is nonconforming, hence I am
> working with a full representation (regions, faces, edges, and vertices,
> with the interior of each corresponding to degrees of freedom in the
> global system), but I now have to store the adjacencies manually.  Is
> there anything I should take into consideration now to make load
> balancing and adaptivity easier when I get to them?

Not that I know of.

>  Will any of the
> other ITAPS components function on a nonconforming mesh?
> 

It depends the component.  I am not aware of any formal discussion of or
policy for handling of non-conformal meshes by the ITAPS group.

> Is there a recommended way to store higher order parametric mappings?  I
> realize that other ITAPS components (i.e. surface tracking) may not have
> this sort of functionality, but I'd like to make it as painless as
> possible.
> 

I don't think the iMesh extension for higher-order mappings has been
finalized yet.

> I've browsed iMeshP.h and it seems that we need a way to get an
> iMeshP_PartitionHandle?  What is the timeline for this component being
> usable?  Is there a usage example anywhere?
> 
> If I save my mesh in .h5m format, all my metadata is there, but I'm not
> aware of software to visualize this directly. 

There is ongoing work to allow VisIt
(https://wci.llnl.gov/codes/visit/FAQ.html) to interact directly with an
iMesh implementation.  This combination will allow visualization of any file
MAOB (or any other iMesh implementation) can read.

> If I save in exodusII, I
> lose all metadata.  So it seems the only option is .vtk which is slower
> and annihilates everything but Int and Double data.  Perhaps the best
> way to handle this is to write a XDMF generator for the h5m format.  XML
> is ugly, but this would allow Paraview, among others, to read the h5m
> file.  Is h5m a stable format and is there a formal spec?

The format has been fairly stable.  There isn't a formal spec.  The
documentation in mhdf/inc/mhdf.h in the MOAB source describes the table
contents.  If you want to read .h5m files, you might consider using the
utility library in the mhdf/ subdir of the MOAB source.

>  I might be
> able to write an XDMF header generator, especially if it would be useful
> to others.
> 

Support for more file formats is always useful.  If you wish to implement
such a tool as either a part of MOAB's .h5m writing code or as a stand-alone
tool, we'd be happy to include it with the MOAB source.

> I noticed that iMesh_getVtxCoordIndex() ignores its 5th argument (entity
> adjacency type).
> 

It is ignored if a value other than ALL_TOPOLOGIES is passed for the 4th
argument, as topology is a subset of type.

> I think iMesh_getAdjTable() is not correct.  The table
>   1 1 1 1
>   1 0 0 0
>   1 0 0 0
>   1 0 0 1
> indicates that vertex-any, any-vertex, and region-region adjacencies are
> available in O(1), but all others are unavailable.  Certainly this is
> not consistent with the results of iMesh_getAdjEntities().
> 

I agree that this appears to be incorrect.  Would you like to submit a
defect report (http://trac.mcs.anl.gov/projects/ITAPS/wiki/MOAB) or would
you prefer that I do so?

- jason