# Bring RGG session into CMB6 Design Discussion

**URL:** https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192
**Category:** Computational Model Builder (CMB)
**Created:** [December 4, 2018, 5:43pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192 "2018-12-04T17:43:28Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![Haocheng\_Liu](https://discourse.kitware.com/user_avatar/discourse.kitware.com/haocheng_liu/32/36_2.png) [@Haocheng\_Liu](https://discourse.kitware.com/u/Haocheng_Liu)
#### Post date: [December 4, 2018, 5:43pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/1 "2018-12-04T17:43:28Z")

</div>

Reactor modeling capability is introduced into SMTK2 and CMB5. Since now SMTK3&CMB6 should be released anytime soon, this topic is targeted to discuss the functionality and limitation of current rgg(AKA reactor geometry generator) session and future work on the reactor modeling. Simulation workflow and execution on HPC systems should be discussed in another post.

# Current RGG session in SMTK2 and CMB5

- Able to model various pins, duct structures, sub-assemblies and a reactor core in the Simulation Model ToolKit (SMTK) and demonstrated using the Computational Model Builder (CMB)’s ModelBuilder Application.  
 ![image](https://discourse.kitware.com/uploads/default/original/1X/8a3d647fcb22331b0f564931a70825121810f285.png)  
Figure1. defining a cross-section of the pin including the optional cell material surrounding it using the pin editor.  
 ![image](https://discourse.kitware.com/uploads/default/original/1X/0cd8122d2e2606d0be6db77fa3ecfe047fb07754.png)  
Figure2. defining a sub-assembly duct using the Duct Editor.  
 ![image](https://discourse.kitware.com/uploads/default/original/1X/bdcc897cc1f18ba15a722ed0cff24c3a0abba56c.png)  
Figure3. a 2D schematic editor and a 3D view of an assembly looking down the z axis  
 ![image](https://discourse.kitware.com/uploads/default/original/1X/3ad166930f8bd7d7b6b764034a6822fa82687a4a.jpeg)  
Figure4. a complex example reactor consisting of 919 sub-assemblies and over 56,000 pins
- Able to define materials which fit PyARC specification.
- Able to read a reactor in rxf file format(a native file format for RGGNulcear application)
- Able to export a reactor in son file format(Standard Object Notation) and smtk file format(native smtk file format)
- Able to handle complex reactors which contain half a million of glpyhs.

# TODO list in SMTK3 and CMB6

- RGG session should have its own descriptive phase generator other than using the generic tree view which lists all sub components. Below is a possible tree view.  
 ![assemblyView](https://discourse.kitware.com/uploads/default/original/1X/5c941d34990a5cbf12293ca04864502dc12766cc.png)  
Figure5. a sample tree view for the nuclear core
- Given the fact that nuclear pins are long thin cylinders, a z scale slider should be provided to let users adjust the comparative height.  
 ![combine_images](https://discourse.kitware.com/uploads/default/original/1X/f3f902742ba878f85f39d568d17cd4ede2b09d25.jpeg)  
Figure6. on right hand side is a sample assembly and on left hand side is a sample assembly whose z value is scaled to provide a clear view
- Assembly/core schematic editor should provide rich methods to plan the layout for pins/assemblies such as(layout items via ring/circle/diangle).  
 ![possibleLayouts](https://discourse.kitware.com/uploads/default/original/1X/816336a0a9440256e5d271adac2e69f13e1cc301.png)  
Figure 7. example of possible smart layout tools
- Current nuclear modeling uses pin&duct-centric paradigm to meet customer’s needs. We should provide a layer-centric paradigm to meet other customer’s specification.
- Incomplete/missing features
  - Modification of a nuclear pin&duct&assembly should propagate downstream. Currently  
if a user modifies a pin, he/she needs to manually call apply on all rgg entities(assembly and core) which relies on this pin.
  - generate a vessel for the reactor
  - filter the visibility of rgg entities via material(Ex. a user only wants to see parts whose material are sodium)
  - add unit tests for all rgg operations
  - Instead of breaking a rgg entity to sub layers and glyph the entity at layer level  
(Ex. If a nuclear pin consists of two cylinders, then the glyph representation of this pin  
actually contains two glyphs), it should be glyphed as a whole. SMTK2 is not able  
to do so because it cannot specify colors for sub-blocks in a vtkMultiBlockDataset.

---

<div class="post-metadata">

### Author: ![tj.corona](https://discourse.kitware.com/user_avatar/discourse.kitware.com/tj.corona/32/35_2.png) [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [December 4, 2018, 8:12pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/2 "2018-12-04T20:12:00Z")

</div>

> Given the fact that nuclear pins are long thin cylinders, a z scale slider should be provided to let users adjust the comparative height.

That would be a really cool feature.

---

<div class="post-metadata">

### Author: ![tj.corona](https://discourse.kitware.com/user_avatar/discourse.kitware.com/tj.corona/32/35_2.png) [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [December 4, 2018, 8:14pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/3 "2018-12-04T20:14:12Z")

</div>

The SMTK 2.0 RGG session has operators to create a model/pin/duct/assembly and a separate operator to edit them. Would it make sense to expose the choices of the edit operators in their respective create operators? For example, CreatePin would have an API like EditPin, and [Apply] would create a pin with the provided specs.

---

<div class="post-metadata">

### Author: ![Haocheng\_Liu](https://discourse.kitware.com/user_avatar/discourse.kitware.com/haocheng_liu/32/36_2.png) [@Haocheng\_Liu](https://discourse.kitware.com/u/Haocheng_Liu)
#### Post date: [December 4, 2018, 8:24pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/4 "2018-12-04T20:24:57Z")

</div>

> [@tj.corona](#):
>
> The SMTK 2.0 RGG session has operators to create a model/pin/duct/assembly and a separate operator to edit them. Would it make sense to expose the choices of the edit operators in their respective create operators? For example, CreatePin would have an API like EditPin, and [Apply] would create a pin with the provided specs.

Do you mean that `CreatePin` would have a same UI as `EditPin` so that it exposes more specification at creation time?  
For now after the `CreateFoo` operation finishes, CMB5 would automatically switch to the `EditFoo` operator via a hack.

---

<div class="post-metadata">

### Author: ![tj.corona](https://discourse.kitware.com/user_avatar/discourse.kitware.com/tj.corona/32/35_2.png) [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [December 4, 2018, 8:26pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/5 "2018-12-04T20:26:19Z")

</div>

> Do you mean that `CreatePin` would have a same UI as `EditPin` so that it exposes more specification at creation time?

Yup. What was it we were hacking around?

---

<div class="post-metadata">

### Author: ![Haocheng\_Liu](https://discourse.kitware.com/user_avatar/discourse.kitware.com/haocheng_liu/32/36_2.png) [@Haocheng\_Liu](https://discourse.kitware.com/u/Haocheng_Liu)
#### Post date: [December 4, 2018, 8:34pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/6 "2018-12-04T20:34:00Z")

</div>

> [@tj.corona](#):
>
> > Do you mean that `CreatePin` would have a same UI as `EditPin` so that it exposes more specification at creation time?
> 
> Yup. What was it we were hacking around?

In CMB5 after `Edit Foo` operations finishes, it would use several if statements to detect and switch current  
active operators in the operation panel. I believe there is a smart and clean way to achieve such in CMB6 🙂

---

<div class="post-metadata">

### Author: ![tj.corona](https://discourse.kitware.com/user_avatar/discourse.kitware.com/tj.corona/32/35_2.png) [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [December 4, 2018, 8:35pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/7 "2018-12-04T20:35:26Z")

</div>

If `CreateFoo` were to expose `EditFoo`'s options, would it be necessary to open `EditFoo` when `CreateFoo` executes?

---

<div class="post-metadata">

### Author: ![dcthomp](https://discourse.kitware.com/user_avatar/discourse.kitware.com/dcthomp/32/10_2.png) [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [December 4, 2018, 8:42pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/8 "2018-12-04T20:42:55Z")

</div>

> [@tj.corona](#):
>
> > [@Haocheng\_Liu](#):
> >
> > Given the fact that nuclear pins are long thin cylinders, a z scale slider should be provided to let users adjust the comparative height.
> 
> That would be a really cool feature.

How was this accomplished? Are you changing the transform on the representation’s actors or regenerating the geometry? If the latter, it feels like an operation. If the former, it feels like a GUI feature that does not affect the model.

---

<div class="post-metadata">

### Author: ![Haocheng\_Liu](https://discourse.kitware.com/user_avatar/discourse.kitware.com/haocheng_liu/32/36_2.png) [@Haocheng\_Liu](https://discourse.kitware.com/u/Haocheng_Liu)
#### Post date: [December 4, 2018, 9:22pm UTC](https://discourse.kitware.com/t/bring-rgg-session-into-cmb6-design-discussion/192/9 "2018-12-04T21:22:33Z")

</div>

> [@dcthomp](#):
>
> > > Given the fact that nuclear pins are long thin cylinders, a z scale slider should be provided to let users adjust the comparative height.
> > 
> > That would be a really cool feature.
> 
> How was this accomplished? Are you changing the transform on the representation’s actors or regenerating the geometry? If the latter, it feels like an operation. If the former, it feels like a GUI feature that does not affect the model.

TBD. That’s one of the things on my long list I want to discuss with you David!
