<div dir="ltr">Hey Tim, <div><br></div><div>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.</div><div><br></div><div>Be Well</div>
<div>Anthony</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 3:50 PM, Tim Tautges <span dir="ltr"><<a href="mailto:tautges@mcs.anl.gov" target="_blank">tautges@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 10/11/2013 01:29 PM, Anthony Scopatz wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hello All,<br>
<br>
Thanks for your responses, from the responses it seems that going with an external data structure that is related to<br>
mesh in some way is the right way to proceed. Particular responses follow.<br>
<br></div>
*@Tim*, I am interested in the iRel/Lasso idea but it is not clear to me how it applies. From the description of Lasso<br>
<<a href="http://trac.mcs.anl.gov/projects/ITAPS/wiki/Lasso" target="_blank">http://trac.mcs.anl.gov/<u></u>projects/ITAPS/wiki/Lasso</a>> it seems that it relates entities and entity sets to each other and<div class="im">
<br>
does relate not external data structures to entities. Maybe I am misreading that. If you have a clearer description of<br>
how it would work in this context that would be great.<br>
<br>
Now, as per PyNE's Material class, I have been hacking on it in one form or another since 2007. I am fairly confident<br>
that it does the right thing for most nuclear engineering (NE) applications. We separate out intrinsic properties<br>
(mass, density, etc) to be fields on the class and we let extrinsic properties (name, citation info, etc) live in the<br>
metadata. I am not sure how useful it is to non-physics applications. There are definitely some aspects of the API that<br>
are NE specific (element grouping, etc) that could be pared down. However, the thing that I think it misses is chemical<br>
form information. I am mostly convinced that there is no good, semantic way to represent chemical forms that isn't<br>
unique string or integer ids. However, I am not a chemist so maybe there are. I am willing to open up and explore this<br>
issue again because right now our answer is to shove chemical form information into the metadata. That was kind of a<br>
long winded answer, but the point is that a lot of thought has gone into this class over the years by myself and others.<br>
<br>
</div></blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
Mesh: set with tag:GEOM_DIMENSION=<d>, tag:GLOBAL_ID=<i> <==> Geom: entity with entity_type()=<d>, tag:GLOBAL_ID=<i><br>
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.<br>
<br>
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.<br>
<br>
- tim<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*@Vijay*, Thanks for the information about "Accessing all of the fields via a tag_get_data/tag_iterate at every cell can<div><div class="h5"><br>
become expensive." If this had been cheap it may have been worth the loss of structure. We are definitely in a<br>
situation where we need all of the fields.<br>
<br>
But from a visualization perspective, I would imagine you wouldn't care about looking at say the absorption<br>
cross-section distribution in your mesh?<br>
<br>
<br>
Actually, this is something we do care about a lot. This is why I have pushed for yt-MOAB integration. Writing an<br>
absorption cross section derived field based on PyNE using yt would be 2 - 3 lines of code including the import.<br>
<br>
This would be the most optimal setting since you can directly access<br>
any specific data field with indexing based on GLOBAL_ID of the entity<br>
rather than traversing through each data tag individually.<br>
<br>
<br>
This seems like the thing to do then.<br>
<br>
It would also mean that the object hierarchy be part of the user data structure<br>
and not persisted via MOAB.<br>
<br>
<br>
That is correct, but we have mechanisms for persisting multiple materials already. The user data structure would<br>
persist itself by persisting the mesh and the materials separately. It would not be hard or a burden at all.<br>
<br>
AFAIK, you could possibly do this with byte arrays rather than storing<br>
the pointer directly in which case you would just perform a cast on<br>
the pointer to tag data and use your objects directly. When you have<br>
ghosted elements etc, I am not entirely sure what will happen here.<br>
Tim, perhaps a test case for using MB_TYPE_OPAQUE with serialized<br>
objects might be useful.<br>
<br>
<br>
I had thought about this option even though you loose introspection into the material. My concern here was that we'd<br>
need to know the size, or the max size, of the flattened material. Is this true? Or can each entity have a variable<br>
length byte array? This comes up because each material may have different species that it contains and any amount of<br>
information can go into the metadata. It seems like a reasonable idea, but I am not sure how practical it is. Any<br>
advice you would be great.<br>
<br></div></div>
*@Jed*,<br>
<br>
On Fri, Oct 11, 2013 at 11:17 AM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a> <mailto:<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>>> wrote:<div>
<div class="h5"><br>
<br>
Anthony Scopatz <<a href="mailto:scopatz@gmail.com" target="_blank">scopatz@gmail.com</a> <mailto:<a href="mailto:scopatz@gmail.com" target="_blank">scopatz@gmail.com</a>>> writes:<br>
> There are a handful of data fields on this class:<br>
><br>
> composition: map<int, double><br>
<br>
You want to allocate dynamically for each cell in your mesh? (This<br>
isn't necessarily bad; dynamic allocation isn't all that expensive and<br>
it depends what else you are doing.)<br>
<br>
<br>
Yes this is exactly what we want to do because the species that live on the mesh will change as a function of time.<br>
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<br>
array of approved species is one of the great failings of many NE codes, in my opinion.<br>
<br>
<br>
> mass: double<br>
> density: double<br>
> atoms_per_mole: double<br>
> meta: a JsonCpp instance for storing metadata<br>
<br>
Again, a different instance for each cell, or is there a lot of<br>
repetition across cells?<br>
<br>
<br>
Different instances for each cell. You can't assume repetition.<br>
<br>
<br>
> 2. Keep an external dictionary / map which is keyed by the entity and<br>
> valued by Material objects<br>
<br>
Arrays work well for this.<br>
<br>
<br>
Wouldn't using arrays assume some nominal ordering of the cells? Using a 3D array and indexing by i, j, k seems like<br>
it would only work for Hex8.<br>
<br>
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.<br>
And of course I am interested in seeing MOAB / Lasso support for Materials...especially if this is PyNE based.<br>
<br>
Be Well<br>
Anthony<br>
<br>
</div></div></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
==============================<u></u>==============================<u></u>====<br>
"You will keep in perfect peace him whose mind is<br>
steadfast, because he trusts in you." Isaiah 26:3<br>
<br>
Tim Tautges Argonne National Laboratory<br>
(<a href="mailto:tautges@mcs.anl.gov" target="_blank">tautges@mcs.anl.gov</a>) (telecommuting from UW-Madison)<br>
phone (gvoice): <a href="tel:%28608%29%20354-1459" value="+16083541459" target="_blank">(608) 354-1459</a> 1500 Engineering Dr.<br>
fax: <a href="tel:%28608%29%20263-4499" value="+16082634499" target="_blank">(608) 263-4499</a> Madison, WI 53706<br>
<br>
</div></div></blockquote></div><br></div>