Introduction to RGG session

Simulation Modeling Toolkit (SMTK) Design
1

This post serves as a brief introduction and documentation for RGG session.

Brief introduction

  • RGG stands for reactor geometry generator. This session enables the creation of detailed large and complicated reactor models (geometry/mesh) for different types of physics simulations. A lattice hierarchy-based approach is used to create these reactor models from pin, duct to assembly and core.
  • RGG session rendering utilizes the glyphing functionality in VTK to handle millions of elements. See Rendering part for details.
  • To create a nuclear core, a list of smtk operators are provided for users. See Operators section for details.
  • So far RGG session supports meshkit, pyarc and proteus simulation. See Simulation section for details.
  • It’s a sucessor for standalone RGG application. For user convenience, it also comes with a superbuild.
  • Related post bring rgg to CMB6.
  • Testing data repo is here.

RGG geometries

  • The base elements in RGG session are pin, duct, assembly and core. They are serialized and deserialized through JSON. RGG session supports either a hex or a rect core. At construction time, user needs to specify the geometry type, z origin and height.

Pin

  • Pin is a base nuclear element which consists of several geometries(cylinder or frustum). A user can specify the sub pieces along the height and layer materials along the radius. It’s stored as a string property in a smtk auxiliary geometry.

Duct

  • Duct is a base nuclear element which consists of several geometries depending on whether it’s a hex or rect core. A user can specify the segments along the height(line extension) where each piece can have its own layer materials along the radius(Annular extension)… It’s stored as a string property in a smtk auxiliary geometry.

Assembly

  • Assembly is a container which holds one kind of duct and various kinds of pins.The pins are placed in a rectangular grid or a hex grid. A unique label shall be provided. It’s stored as a string property in a smtk group.

Core

  • Core is a container which holds various kinds of assemblies.The assemblies are placed in a rectangular grid or a hex grid. It’s stored as a string property in a smtk group.

Operators

Core generation ops

  • EditPin: Create or edit a nuclear pin. A unique label shall be provided.
  • EditDuct: Create or edit a nuclear duct.
  • EditAssembly: Create or edit a nuclear assembly. It provides a layout to specify pin placements.
  • EditCore：Create or edit a nuclear core. It provides a layout to specify assembly placements.
  • Delete: Delete a rgg entity.

Simulation ops

  • AddMaterial: Specify a custom material.
  • RemoveMaterial: Remove a custom material.
  • ExportInp: Export the core according inp file format.
  • Generate_mesh: launch Meshkit meshing jobs.

I/O ops

  • Read: Write a core according to native smtk format.
  • Write: Read a core according to native smtk format.
  • ReadRXFFile: Read the native old rgg application file into smtk.

Rendering

  • RGG rendering relies on smtk. It utilizes the AuxiliaryGeometryExtension visitor paradigm so that all rgg entities are handles by rggAuxiliaryGeometryExtension class. So far pin and duct have their own geometry generation logic.

Referring to assembly and core, they are rendered as glyphs of prototype geometries which are generated by rggAuxiliaryGeometryExtension. The benefit of using prototype geometries is using fewer vtkActors which is a huge boost to rendering performance. See details in post Rendering pipeline refactor. See details about glyphing in EditAssembly&&EditPin operators who are using the same OperationHelper::glyph* helper functions.

Simulation

proteus - Ask TJ

pyarc

  • Export RGG core according to son file format.

MeshKit

  • Export RGG core according to inp file format and mesh the core via Cubit. See details in MeshKit workflow.

TODO

  • Add more convenient functions for entity layouts such as fill the ring/ fill the row or fill the diagonal, etc.
  • Test simulation work flows with CMB6.
  • Add more GUI tests.
2

RGG has been updated so it can be added as a contract test to smtk. All 6 tests pass. Current GUI interaction has some issues:

  • If you load the plugin after starting CMB, selecting one of the reactor pieces in the resource panel works, but the 3D view doesn’t update to just show the pins or ducts.
  • If the plugin is auto-loaded, when you select a piece in the resource panel, the 3D view updates, but the piece is immediately de-selected, causing the operation list to reset. Unchecking the ‘limit to selection’ box lets you choose the ‘edit pin’ operation and choose a pin from the operation editor.

Do we care about the first case? The second one needs fixed for RGG session to be usable interactively.

1 Like
3

Can you try starting CMB, loading the RGG plugin, and then clicking the “Reset Server” button and see if things work as you’d expect them? We have a lot of hooks that trigger on the construction of a new server. If that works, then we can put it as a to-do to retroactively perform “on new server” actions when a plugin is loaded.

4

Not quite… If I perform those actions, then load an reactor .rxf file, modelbuilder segfaults

A small piece of the stacktrace:

#0  smtk::geometry::Manager::visitBackends(std::function<void (smtk::geometry::Backend const&)>) const (this=0x55555769d750, visitor=...)
    at /home/aron.helser/projects/cmb/smtk/src/smtk/geometry/Manager.cxx:24
24	    visitor(*entry.second);
#1  0x00007fffc85e1883 in smtk::geometry::Manager::<lambda(const smtk::resource::Resource&, smtk::resource::EventType)>::operator() (event=<optimized out>, resource=..., __closure=<optimized out>)
    at /home/aron.helser/projects/cmb/smtk/src/smtk/geometry/Manager.cxx:59
#2  std::_Function_handler<void(const smtk::resource::Resource&, smtk::resource::EventType), smtk::geometry::Manager::registerResourceManager(const Ptr&)::<lambda(const smtk::resource::Resource&, smtk::resource::EventType)> >::_M_invoke(const std::_Any_data &, const smtk::resource::Resource &, smtk::resource::EventType &&) (__functor=..., __args#0=..., __args#1=<optimized out>)
    at /usr/include/c++/7/bits/std_function.h:316
5

That part of the stack trace indicates that the RGG session is trying to use the new smtk::geometry::Geometry… what resource type does it inherit? If it inherits the VTK session’s resource, then it will need to be updated to use the new rendering backend (this should also improve speed).

6

When I look at the RGG repo, it does not appear to inherit the VTK session’s resource. So… I am surprised that this code is exercised at all.

7

Some followup: via both debugger and std::cout, we verified that the size of the resource’s m_geometry map was 0 but nonetheless, for (auto& entry : m_geometry) { ... } was invoking code inside the loop (on what was clearly nonsense, since the map was empty). Looks like either memory stomping or a compiler error.

8

On a lark, try iterating m_geometry in a different way (e.g. use iterators explicitly, or a good old-fashioned for loop).

9

Simply putting an if (m_geometry.empty()) { return; } before the loop was enough to get past the crash. But that’s not something I would commit to the repo until we know what it causing the problem.

10

Something must be messing with memory. Updated to smtk master, rebuilt, now I get this printout (reversed from the last one):

> 4       0x7f48ff46b2cb smtk::geometry::Manager::visitBackends(std::function<void (smtk::geometry::Backend const&)>) const + 187
> 3       0x7f48ff469dd4 smtk::geometry::Resource::geometry(smtk::geometry::Backend const&) + 324
> 2       0x7f48ff46ab36 smtk::common::Generator<std::tuple<std::shared_ptr<smtk::geometry::Resource>, smtk::geometry::Backend const&>, std::unique_ptr<smtk::geometry::Geometry, std::default_delete<smtk::geometry::Geometry> >, smtk::common::detail::NullGeneratorBase>::operator()(std::tuple<std::shared_ptr<smtk::geometry::Resource>, smtk::geometry::Backend const&> const&) + 246
> 1       0x7f48f3bcbf27 smtk::session::polygon::vtk::RegisterPolygonVTKBackend::valid(std::tuple<std::shared_ptr<smtk::geometry::Resource>, smtk::geometry::Backend const&> const&) const + 39
> 0       0x7f49292e6890 /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890) [0x7f49292e6890]

In any case, modelbuilder has never functioned correctly for me after I click ‘reset server’ - after opening a file, the resource panel doesn’t populate. We could go down this rabbit hole, or concentrate on behavior when RGG is auto-loaded.

11

I suspect that ‘reset server’ is doing something naughty. It would be nice to understand what it is doing (perhaps with valgrind?), but I agree getting RGG working on auto-load is the priority and should also be the easier thing to do (since you know how to discover what is resetting the selection).

12

RGG session was clearing the selection intentionally: MR
The purpose was to avoid drawing the geometry with the purple selection color. Ideas on how to avoid that without clearing the selection?

13

I don’t see an easy way. There might be a hack or two in addition to the “right way.”

  • Instead of emptying the selection, maybe changing the selection value to something non-standard would leave the part selected but not highlighted? I don’t remember offhand how selected bits are processed by the representation, but it is possible that selecting the part with a value of 4 (or any value that does not set the lower 2 bits that are used for the primary and hover selections) would render as desired but still register the selection as far as the operation panel is concerned. I would consider this a hack.
  • Currently, vtkSMTKResourceRepresentation invokes a function named something like “SelectedFootprint” (search for Footprint) to choose what renderable objects should be highlighted to illustrate a selection. We should at some point allow plugins to provide custom logic. That part is not a hack, but using such a mechanism to prevent highlighting for RGG would be a hack.
  • IMNSHO, the non-hack solution is to have a modal workflow such that when users select a part, the operation and resource panels respond by showing tasks contextual to that part. But this will require some work that Bob has yet to do…
14

Looks like RGG is already doing this - the selection label being used is in smtkRGGSelectionBehavior::m_selectionValue("rgg selected"). This results in selected pins and ducts not being drawn with the selected color, but assemblies and the core have a boundary that is still drawn with the selected color. I’ll investigate why the boundary doesn’t get the new selection label.

15

This is probably a difference between how glyphs and “regular” surfaces are handled by the representation. They should behave the same way.