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

Fri Oct 11 17:53:03 CDT 2013

Hey Tim,

Maybe it would be best if we sat down and talked about this.  I am going to
be in WI towards the end of the month.  Maybe we can sneak some time then.

Be Well
Anthony

On Fri, Oct 11, 2013 at 3:50 PM, Tim Tautges <tautges at mcs.anl.gov> wrote:

>
>
> 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<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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20131011/725472e1/attachment.html>