[MOAB-dev] Attaching a C++ class to Mesh entities?
Tim Tautges
tautges at mcs.anl.gov
Fri Oct 11 17:57:03 CDT 2013
Sounds good, if I still have a job...
- tim
On 10/11/2013 05:53 PM, Anthony Scopatz wrote:
> 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 <mailto: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>
> <mailto:jedbrown at mcs.anl.gov <mailto:jedbrown at mcs.anl.gov>>> wrote:
>
>
> Anthony Scopatz <scopatz at gmail.com <mailto:scopatz at gmail.com> <mailto: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 <mailto:tautges at mcs.anl.gov>) (telecommuting from UW-Madison)
> phone (gvoice): (608) 354-1459 <tel:%28608%29%20354-1459> 1500 Engineering Dr.
> fax: (608) 263-4499 <tel:%28608%29%20263-4499> Madison, WI 53706
>
>
--
================================================================
"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
More information about the moab-dev
mailing list