Stand up an exodus session...

... in this repository using cmb/plugins/opencascade-session> as a template.

• Copy the cmake directory from the opencascade session, renaming ocXXX.cmake to exodusXXX.cmake.
  • Remove the OpenCascade dependency and require VTK.
• Copy the files from smtk/session/opencascade into smtk/session/exodus with the following changes:
  • Adapt Shape.{h,cxx} to omit OCC headers and a protected vtkSmartPointer<vtkDataObject> ivar (so that the node itself owns the data). This node type will serve as a base class for ElementBlock, SideSet, and NodeSet classes. The Shape should also have a Component* m_parent ivar that stores a raw pointer to its parent group (see below) and an int m_pedigreeId ivar referencing the block/set ID from the file.
  • Create a Group.{h,cxx} class similar to Shape that holds raw pointers to children Shapes instead of VTK data. This node type will serve as a base class for grouping all ElementBlocks (and SideSets and NodeSets) togther. It will also be a base class for a File node type that represents an exodus file. An exodus resource may contain multiple Files, each of which will reference groups of blocks by type.
  • Copy the arcs/{ParentsAs,ChildrenAs}.h files (but not the .txx files). Adapt the .txx files to provide implementations that use ivars in the shape and group classes to find parents/children.
  • Copy the smtk/session/opencascade/vtk/Geometry.{h,cxx} into smtk/session/exodus/Geometry.{h,cxx}, moving it out of the vtk directory since the exodus session will rely on VTK directly. Add the Geometry registration to smtk/session/exodus/Registrar.
  • Create new Import, Read, and Write operations.
    • The Import operation should create a File node and arcs that connect it to groups (one for element blocks, one for side sets, one for node sets). The File should have a string property that lists the source Exodus file. The Shape subclasses should have their pedigreee ID set.
    • The Write operation should include a JSON object mapping pedigree IDs to UUIDs (as well as JSON for the components, especially the Files so their locations are serialized).
    • The Read operation should use the above to determine what Files to load with a vtkExodusIIReader and how to map blocks from its output to the components created by deserializing the JSON.

assigned to @bob.obara

@bob.obara:

• I started working on this FYI.
• I cannot push any code to gitlab because there is no default branch. And only an Owner or Maintainer can create a default branch. So as the only "real" owner (besides TJ and Kitware Buildbot), would you please create a master branch and make it default? I presume you can do that from the web settings (?) I'll keep going in the meantime.

FYI here's what happens when I try to push a branch:

remote: GitLab: 
remote: A default branch (e.g. master) does not yet exist for cmb/plugins/exodus-session
remote: Ask a project Owner or Maintainer to create a default branch
remote: 
remote:   https://gitlab.kitware.com/cmb/plugins/exodus-session/-/project_members
remote: 
To git@gitlab.kitware.com:cmb/plugins/exodus-session.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@gitlab.kitware.com:cmb/plugins/exodus-session.git'

@dcthomp and @bob.obara I might not get far on this, FYI, as my comprehension is limited. Nonetheless, a couple questions have come to mind:

• Minor point, but should we rename smtk::session::exodus::Shape to something like smtk::session::exodus::Set?
• Do we need/want to support File nodes? The immediate use cases use a single Exodus file per analysis. (Actually there are ACE3P applications with multiple exodus files, but they are better served if each file is modeled as a separate smtk resource.)

... should we rename smtk::session::exodus::Shape to something like smtk::session::exodus::Set?

I'm not picky about Shape, but it should not be set. Exodus has two things that hold geometric objects: blocks (primary geometry) and sets (references to subsets of primary geometry). Shape is intended to be a base class for both. I picked Shape because it implies geometry (unlike collections of sets/blocks which do not have geometry).

Do we need/want to support File nodes?

Yes. It is the top-level thing you can use to iterate over children to identify everything the file contains. With only 1 File, you have a tree. If you want to support a forest of Files later, we can add a Files or FileGroup or FileCollection node. But having a tree to iterate makes important things (like substituting a new exodus file for an old one) easy.

As for class name, perhaps "Entity" or "MeshSet" would make sense, but let's stick with "Shape".

@dcthomp New question -- Should Shape.h include a type enum?

enum ShapeType
{
  NodeSetType = 0,
  SideSetType,
  ElementBlockType
}

virtual ShapeType shapeType() = 0;

As far as the enum values, why not use the vtkExodusIIReader enum (or at least match its values)?

Specifically, the ObjectType enum. It may have values you don't care about yet, but a lot of them you will and they all come from the Exodus specification.

@dcthomp @bob.obara --

I think I am as far as I should go open-loop. That is, I think I reached the point where David should take a look and decide whether this track is worth continuing or discarding.

• As noted previously, I am not able to push to this repository so I created my own at https://gitlab.kitware.com/john.tourtellott/johns-exodus-session.
• I followed David's directions generally, though there are gaps where my understanding came up short. Most notable omissions are with graph arcs and vtk stuff (for viewing).
• I created one operation -- Import -- that produces a resource with the right number of graph nodes for my minimal test case.
• I made separate subclasses for NodeSet, SideSet, and ElementBlock, though right now there's no logic in them.
• I made a Model class for graph nodes that correspond to Exodus files.
• I made some metaprogramming calls that might not be "right". And I noted in Resource.h one specialization that just dont work for some reason.

Let's discuss next week and decide what to do next.

Question about arcs: The OCC session only has Shape nodes (I think), whereas the Exodus session will have 3 different node types (so far) - Shape, Group, Model. Based on that, do we need to generalize the ParentAs and ChildAs classes to have both "from" and "to" parameters? e.g., template<typename FromType, typename ToType>.

Separate question about C++ in general, if you are interested. I have a templated Resource::createComponent() method with one specialization at https://gitlab.kitware.com/cmb/plugins/exodus-session/-/blob/getting-started/smtk/session/exodus/Resource.h#L68-76 . I expect the specialization to be called at this line in my Import operation but the compiled code calls the generic version instead. If you know why the specialized method is ignored, please clue me in.

... The OCC session only has Shape nodes ...

Nope. Vertex, Edge, Face, Solid, etc. all inherit Shape. See the Traits.h definition of the NodeTypes tuple. The child classes use the ParentAs, ChildrenAs inside member functions.

@john.tourtellott Currently, you have Model own shared pointers to its child Group nodes. Instead, I would have the Resource own all shared pointers and child nodes use raw or weak pointers (for Exodus, a raw pointer should be fine). Having the model construct the Group nodes is good. Its destructor should probably remove the Groups from the resource... if Model is going to manage those objects, it should do so for their lifecycle.