Bring RGG session into CMB6 Design Discussion


#1

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.

    Figure1. defining a cross-section of the pin including the optional cell material surrounding it using the pin editor.

    Figure2. defining a sub-assembly duct using the Duct Editor.

    Figure3. a 2D schematic editor and a 3D view of an assembly looking down the z axis

    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
    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.

    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).

    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.

#2

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.


#3

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.


#4

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.


#5

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?


#6

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 :slight_smile:


#7

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


#8

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.


#9

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