[Smtk-developers] Exodus bridge

[Robert Michael O'Bara]

If I understand you correctly, Actually the association should pay attention to the group bits.

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




On Nov 17, 2014, at 10:20 PM, Yumin Yuan <yumin.yuan at kitware.com> wrote:

> Hi Dave,
> 
> On Mon, Nov 17, 2014 at 9:55 PM, David Thompson <david.thompson at kitware.com> wrote:
> Hi Yumin,
> 
> 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 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").
> 
> 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.
> 
> 
> I agree, and (2) or (3) options above sound reasonable to me.
> 
> Yumin
>  
>     David
> 
> On Nov 17, 2014, at 17:55, Yumin Yuan <yumin.yuan at kitware.com> wrote:
> 
>> 
>> 
>> On Mon, Nov 17, 2014 at 5:43 PM, David Thompson <david.thompson at kitware.com> wrote:
>> Hi all,
>> 
>> 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
>> 
>>   # ... load file as in script below ...
>>   result = rdr.operate()
>>   model = smtk.model.ModelEntity(res.findModelEntity('model').value(0))
>>   for group in model.groups():
>>     print group.name(), group.stringProperty('exodus type'), group.integerProperty('exodus id')
>> 
>> and get
>> 
>>   Unnamed block ID: 1 Type: HEX ['element block'] [1]
>>   Unnamed block ID: 2 Type: HEX ['element block'] [2]
>>   Unnamed set ID: 4 ['side set'] [4]
>>   Unnamed set ID: 1 ['node set'] [1]
>>   Unnamed set ID: 100 ['node set'] [100]
>> 
>> 
>> Nice!
>>  
>> 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. (!!!)
>> 
>>      
>> 
>> The association widget is working now. I have to change the template file a little bit.
>> Associations="f" ==> Associations="g" // for group
>> Associations="r" ==> Associations="m" // for model to assign material, I guess the "Exodus" reader-parser did not construct a volume.
>> 
>> Caveat, there are some runtime warnings from cmb_v4 related to "duplicate command function". I think this is happening when loading CMB_plugin, and erdcAppCommon is also linking against CMB_plugin. I will track this down later.
>> 
>>  
>> Yumin
>> 
>>   David
>> 
>> > ...
>> > I can certainly help with the exporter part. I will call you to discuss a bit.
>> >
>> > Yumin
>> >
>> > On Mon, Nov 17, 2014 at 11:29 AM, David Thompson <david.thompson at kitware.com> wrote:
>> > Hi Yumin,
>> >
>> > 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:
>> >
>> >   import smtk
>> >   mgr = smtk.model.Manager.create()
>> >   sess = mgr.createSession('exodus')
>> >   rdr = sess.op('read')
>> >   rdr.findAsFile('filename').setValue('can.ex2')
>> >   res = rdr.operate()
>> >   me = smtk.model.ModelEntity(res.findModelEntity('model').value(0))
>> >   print '\n'.join([x.name() for x in me.groups()])
>> >
>> > which will print this:
>> >
>> >   Unnamed block ID: 1 Type: HEX
>> >   Unnamed block ID: 2 Type: HEX
>> >   Unnamed set ID: 4
>> >   Unnamed set ID: 1
>> >   Unnamed set ID: 100
>> >
>> > 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.
>> >
>> > 1. Verify that the vtkModelMultiBlockSource properly includes the tessellation information attached to the side and node sets.
>> > 2. Add properties to the groups from the Exodus reader's metadata (describing set IDs).
>> > 3. Adapt an exporter to the new model.
>> >
>> > I can do #1-2, but will need some help with #3.
>> >
>> >         David
>> >
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20141119/ed2890cd/attachment.html>