<div dir="ltr">Hello All, <div><br></div><div>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.</div>
<div><br></div><div><b>@Tim</b>, I am interested in the iRel/Lasso idea but it is not clear to me how it applies. From the <a href="http://trac.mcs.anl.gov/projects/ITAPS/wiki/Lasso" target="_blank">description of Lasso</a> 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><b>@Vijay</b>, Thanks for the information about "<span style="font-family:arial,sans-serif;font-size:13px">Accessing </span><span style="font-size:13px;font-family:arial,sans-serif">all of the fields via a tag_get_data/tag_iterate at every cell can </span><span style="font-size:13px;font-family:arial,sans-serif">become expensive.</span>" 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. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">But from </span><span style="font-family:arial,sans-serif;font-size:13px">a visualization perspective, I would imagine you wouldn't care about </span><span style="font-family:arial,sans-serif;font-size:13px">looking at say the absorption cross-section distribution in your mesh</span><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">?</span></blockquote>
<div><br></div><div>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. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">This would be the most optimal setting since you can directly access<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">any specific data field with indexing based on GLOBAL_ID of the entity<br></span><span style="font-family:arial,sans-serif;font-size:13px">rather than traversing through each data tag individually.</span></blockquote>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">This seems like the thing to do then.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">It would </span><span style="font-family:arial,sans-serif;font-size:13px">also mean that the object hierarchy be part of the user data structure<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">and not persisted via MOAB.</span></blockquote><div><br></div><div><font face="arial, sans-serif">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.</font></div>
<div><font face="arial, sans-serif"><br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">AFAIK, you could possibly do this with byte arrays rather than storing<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">the pointer directly in which case you would just perform a cast on<br></span><span style="font-family:arial,sans-serif;font-size:13px">the pointer to tag data and use your objects directly. When you have<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">ghosted elements etc, I am not entirely sure what will happen here.<br></span><span style="font-family:arial,sans-serif;font-size:13px">Tim, perhaps a test case for using MB_TYPE_OPAQUE with serialized<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">objects might be useful.</span></blockquote><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><b>@Jed</b>, </span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><div class="gmail_extra">On Fri, Oct 11, 2013 at 11:17 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Anthony Scopatz <<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>
</div>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></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
> mass: double<br>
> density: double<br>
> atoms_per_mole: double<br>
> meta: a JsonCpp instance for storing metadata<br>
<br>
</div>Again, a different instance for each cell, or is there a lot of<br>
repetition across cells?<br></blockquote><div><br></div><div>Different instances for each cell. You can't assume repetition. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
> 2. Keep an external dictionary / map which is keyed by the entity and<br>
> valued by Material objects<br>
<br>
</div>Arrays work well for this.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Be Well</div><div>Anthony</div></div><br></div></div></div>