<div dir="ltr">Hi John and Dave,<div><br></div><div>The current "Export Simulation" is going through vtkPythonExporter, which is adding some python paths and also using vtkCMBModelWrapper to set up GridInfo stuff. The python-path part could be common to all bridges, but the vtkCMBModelWrapper-related GridInfo should be part of the discrete bridge. This means we can't use current "Export" framework for exodus-bridge.</div><div><br></div><div>One way to do the "Export" for exodus-bridge is to add an ExportSimOperator. Actually all bridges probably should have this operator, and for discrete bridge, this new operator can just use vtkPythonExporter.</div><div><br></div><div>Yumin</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 5:55 PM, Yumin Yuan <span dir="ltr"><<a href="mailto:yumin.yuan@kitware.com" target="_blank">yumin.yuan@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="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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></span><div>Nice!</div><span class=""><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></span><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><span class="HOEnZb"><font color="#888888">
<div><br></div><div> </div><div>Yumin</div></font></span><div><div class="h5"><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><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></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>