[MOAB-dev] Attaching a C++ class to Mesh entities?

[Tim Tautges]

On 10/11/2013 01:29 PM, Anthony Scopatz wrote:
> Hello All,
>
> Thanks for your responses, from the responses it seems that going with an external data structure that is related to
> mesh in some way is the right way to proceed.  Particular responses follow.
>
> *@Tim*, I am interested in the iRel/Lasso idea but it is not clear to me how it applies.  From the description of Lasso
> <http://trac.mcs.anl.gov/projects/ITAPS/wiki/Lasso> it seems that it relates entities and entity sets to each other and
> does relate not external data structures to entities.  Maybe I am misreading that.  If you have a clearer description of
> how it would work in this context that would be great.
>
> Now, as per PyNE's Material class, I have been hacking on it in one form or another since 2007. I am fairly confident
> that it does the right thing for most nuclear engineering (NE) applications.  We separate out intrinsic properties
> (mass, density, etc) to be fields on the class and we let extrinsic properties (name, citation info, etc) live in the
> metadata. I am not sure how useful it is to non-physics applications.  There are definitely some aspects of the API that
> are NE specific (element grouping, etc) that could be pared down. However, the thing that I think it misses is chemical
> form information. I am mostly convinced that there is no good, semantic way to represent chemical forms that isn't
> unique string or integer ids.  However, I am not a chemist so maybe there are.  I am willing to open up and explore this
> issue again because right now our answer is to shove chemical form information into the metadata.  That was kind of a
> long winded answer, but the point is that a lot of thought has gone into this class over the years by myself and others.
>

Yes, iRel/Lasso relates entities together (entities that are stored in different libraries).  It's a way of relating 
things together without requiring a code dependency between the libraries.  The key here is that you have an interface 
for which you can define a data model consisting of something analogous to entities, tags, sets, and interface, with the 
most abstract notion of what each of those are.

In the case of materials, I'd suspect that you could define entities as mixtures of different materials, or entities as 
fundamental (defined by the library) materials and sets as collections/mixtures of materials.  Whatever "handle" you 
used to refer to those materials through your API would be the thing associated with something on the MOAB side.  You 
probably know enough about your material capability now to define an API that has some stability, while still allowing 
you to change how things are modeled or other capabilities under that API.

One of the important parts of Lasso/iRel is the ability to restore relations on existing data sets already extant in the 
libraries.  This is important because the details of how each of those databases is saved/restored by their respective 
libraries is opaque above their interfaces.  In the most general approach, I think of this restoring mechanism as having 
the application specify rules for how things are matched together.  Currently, for mesh/geometry, this rule is:
   Mesh: set with tag:GEOM_DIMENSION=<d>, tag:GLOBAL_ID=<i>   <==>  Geom: entity with entity_type()=<d>, tag:GLOBAL_ID=<i>
entity_type() is a function on the iGeom interface that gives the topological dimension of an entity.  This rule just 
happens to be the way we've found to restore mesh-geometry relations for cubit models, though we're building the same 
types of things into MeshKit too.  You could use any kind of rule you want, as long as it can be expressed in terms of 
the data models and APIs for the interfaces you're relating together.

The alternative would be to embed the material data directly in MOAB, and have any applications look for it and evaluate 
it directly.  However, I think that makes it more difficult to maintain and use in multiple applications, or if your 
application is not a very simple one.

- tim

> *@Vijay*, Thanks for the information about "Accessing all of the fields via a tag_get_data/tag_iterate at every cell can
> become expensive."  If this had been cheap it may have been worth the loss of structure.  We are definitely in a
> situation where we need all of the fields.
>
>     But from a visualization perspective, I would imagine you wouldn't care about looking at say the absorption
>     cross-section distribution in your mesh?
>
>
> Actually, this is something we do care about a lot.  This is why I have pushed for yt-MOAB integration.  Writing an
> absorption cross section derived field based on PyNE using yt would be 2 - 3 lines of code including the import.
>
>     This would be the most optimal setting since you can directly access
>     any specific data field with indexing based on GLOBAL_ID of the entity
>     rather than traversing through each data tag individually.
>
>
> This seems like the thing to do then.
>
>     It would also mean that the object hierarchy be part of the user data structure
>     and not persisted via MOAB.
>
>
> That is correct, but we have mechanisms for persisting multiple materials already.  The user data structure would
> persist itself by persisting the mesh and the materials separately.  It would not be hard or a burden at all.
>
>     AFAIK, you could possibly do this with byte arrays rather than storing
>     the pointer directly in which case you would just perform a cast on
>     the pointer to tag data and use your objects directly. When you have
>     ghosted elements etc, I am not entirely sure what will happen here.
>     Tim, perhaps a test case for using MB_TYPE_OPAQUE with serialized
>     objects might be useful.
>
>
> I had thought about this option even though you loose introspection into the material.  My concern here was that we'd
> need to know the size, or the max size, of the flattened material.  Is this true?  Or can each entity have a variable
> length byte array?  This comes up because each material may have different species that it contains and any amount of
> information can go into the metadata.  It seems like a reasonable idea, but I am not sure how practical it is.  Any
> advice you would be great.
>
> *@Jed*,
>
> On Fri, Oct 11, 2013 at 11:17 AM, Jed Brown <jedbrown at mcs.anl.gov <mailto:jedbrown at mcs.anl.gov>> wrote:
>
>     Anthony Scopatz <scopatz at gmail.com <mailto:scopatz at gmail.com>> writes:
>      > There are a handful of data fields on this class:
>      >
>      > composition: map<int, double>
>
>     You want to allocate dynamically for each cell in your mesh?  (This
>     isn't necessarily bad; dynamic allocation isn't all that expensive and
>     it depends what else you are doing.)
>
>
> Yes this is exactly what we want to do because the species that live on the mesh will change as a function of time.
> There are ~4000 known nuclides, a cell may start with 2 of them and may grow to 400 of them...or not.  Hard coding an
> array of approved species is one of the great failings of many NE codes, in my opinion.
>
>
>      > mass: double
>      > density: double
>      > atoms_per_mole: double
>      > meta: a JsonCpp instance for storing metadata
>
>     Again, a different instance for each cell, or is there a lot of
>     repetition across cells?
>
>
> Different instances for each cell.  You can't assume repetition.
>
>
>      > 2. Keep an external dictionary / map which is keyed by the entity and
>      > valued by Material objects
>
>     Arrays work well for this.
>
>
> Wouldn't using arrays assume some nominal ordering of the cells?  Using a 3D array and indexing by i, j, k  seems like
> it would only work for Hex8.
>
> Thanks again all for your help.  I have a pretty clear idea of what needs to be done from the PyNE side to get an MVP.
>   And of course I am interested in seeing MOAB / Lasso support for Materials...especially if this is PyNE based.
>
> Be Well
> Anthony
>

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
  phone (gvoice): (608) 354-1459      1500 Engineering Dr.
             fax: (608) 263-4499      Madison, WI 53706