<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Yumin,</div><div><br></div><div>You are correct; the Exodus bridge doesn't create faces or volumes inside the groups. However it does mark the groups as MODEL_DOMAIN or <span style="background-color: rgba(255, 255, 255, 0);">MODEL_BOUNDARY depending on whether they contain volumes or faces/edges/nodes, respectively. We could (1) change the bridge to create either a single volume or face per group; or (2) add some logic to associations so that they pay attention to group constraint bits like those above; or (3) do #2 but with dimension-specific constraint bits (like "this group may only hold 1-d and 2-d cells").</span><br></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">It would not be simple to change the bridge to expose every element side or node as a separate model entity because the numbering in Exodus files is painfully complex. At that point, we are better off reviving more discrete model functionality from v3 to v4.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> David</span></div><div><br>On Nov 17, 2014, at 17:55, Yumin Yuan <<a href="mailto:yumin.yuan@kitware.com">yumin.yuan@kitware.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 5:43 PM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br><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">Hi all,<br>
<br>
I've merged some changes to master that store element block, side set, and node set IDs on the SMTK model entities. So, in Python you can<br>
<br>
# ... load file as in script below ...<br>
result = rdr.operate()<br>
model = smtk.model.ModelEntity(res.findModelEntity('model').value(0))<br>
for group in model.groups():<br>
print <a href="http://group.name" target="_blank">group.name</a>(), group.stringProperty('exodus type'), group.integerProperty('exodus id')<br>
<br>
and get<br>
<br>
Unnamed block ID: 1 Type: HEX ['element block'] [1]<br>
Unnamed block ID: 2 Type: HEX ['element block'] [2]<br>
Unnamed set ID: 4 ['side set'] [4]<br>
Unnamed set ID: 1 ['node set'] [1]<br>
Unnamed set ID: 100 ['node set'] [100]<br>
<br></blockquote><div><br></div><div>Nice!</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">
I am about halfway through modernizing the Hydra Python exporter script to use the new model. Once I'm done and Yumin has the association widget working we should have an end-to-end demo. (!!!)<br>
<br> </blockquote><div><br></div><div>The association widget is working now. I have to change the template file a little bit.<br></div><div>Associations="f" ==> Associations="g" // for group</div><div>Associations="r" ==> Associations="m" // for model to assign material, I guess the "Exodus" reader-parser did not construct a volume.<br></div><div><br></div><div>Caveat, there are some runtime warnings from cmb_v4 related to "<span style="color:rgb(128,0,0);font-family:Courier;font-size:13pt">duplicate command function".</span> I think this is happening when loading CMB_plugin, and erdcAppCommon is also linking against CMB_plugin. I will track this down later.</div>
<div><br></div><div> </div><div>Yumin</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"> David<br>
<br>
> ...<br>
<div class=""><div class="h5">> I can certainly help with the exporter part. I will call you to discuss a bit.<br>
><br>
> Yumin<br>
><br>
> On Mon, Nov 17, 2014 at 11:29 AM, David Thompson <<a href="mailto:david.thompson@kitware.com">david.thompson@kitware.com</a>> wrote:<br>
> Hi Yumin,<br>
><br>
> I've pushed a simple example bridge to SMTK master that uses VTK's Exodus reader to read side and node set information in as groups. No cells (volumes/faces/edges/vertices) are included, but the blocks and sets have tessellation information. You can do this:<br>
><br>
> import smtk<br>
> mgr = smtk.model.Manager.create()<br>
> sess = mgr.createSession('exodus')<br>
> rdr = sess.op('read')<br>
> rdr.findAsFile('filename').setValue('can.ex2')<br>
> res = rdr.operate()<br>
> me = smtk.model.ModelEntity(res.findModelEntity('model').value(0))<br>
> print '\n'.join([<a href="http://x.name" target="_blank">x.name</a>() for x in me.groups()])<br>
><br>
> which will print this:<br>
><br>
> Unnamed block ID: 1 Type: HEX<br>
> Unnamed block ID: 2 Type: HEX<br>
> Unnamed set ID: 4<br>
> Unnamed set ID: 1<br>
> Unnamed set ID: 100<br>
><br>
> Because each group has a Tessellation associated with it you should be able to render the side and node sets as well as element blocks. There are a few things left to do and then we will have an end-to-end example of simulation preparation using (unaltered) Exodus files.<br>
><br>
> 1. Verify that the vtkModelMultiBlockSource properly includes the tessellation information attached to the side and node sets.<br>
> 2. Add properties to the groups from the Exodus reader's metadata (describing set IDs).<br>
> 3. Adapt an exporter to the new model.<br>
><br>
> I can do #1-2, but will need some help with #3.<br>
><br>
> David<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>
</div></blockquote></body></html>