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

[Anthony Scopatz]

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.

*@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> wrote:

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