<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">If I understand you correctly, Actually the association should pay attention to the group bits.<div><br></div><div>Bob</div><div><br><div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Robert M. O'Bara, MEng.<br>Assistant Director of Scientific Computing<br><br>Kitware Inc.<br>28 Corporate Drive<br>Suite 101<br>Clifton Park, NY 12065<br><br>Phone: (518) 881- 4931</div><div><br></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br><div><div>On Nov 17, 2014, at 10:20 PM, Yumin Yuan <<a href="mailto:yumin.yuan@kitware.com">yumin.yuan@kitware.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Dave,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 9:55 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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><span class="HOEnZb"><font color="#888888"><span style="background-color:rgba(255,255,255,0)"><br></span></font></span></div></blockquote><div><br></div><div>I agree, and (2) or (3) options above sound reasonable to me.</div><div><br></div><div>Yumin</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class="HOEnZb"><font color="#888888"><div><span style="background-color:rgba(255,255,255,0)"></span></div><div><span style="background-color:rgba(255,255,255,0)"> David</span></div></font></span><div><div class="h5"><div><br>On Nov 17, 2014, at 17:55, Yumin Yuan <<a href="mailto:yumin.yuan@kitware.com" target="_blank">yumin.yuan@kitware.com</a>> wrote:<br><br></div><blockquote type="cite"><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>> 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" target="_blank">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></blockquote></div><br></div></div>
</blockquote></div></div></div></blockquote></div><br></div></div>
</blockquote></div><br></div></body></html>