Planning for SMTK v3.1 and v4.0

Simulation Modeling Toolkit (SMTK) Design
1

Below are lists of things we hope to accomplish in SMTK 3.1 and 4.0.
This post is a wiki entry: anyone logged in can (and should) edit it to add new items. You can also post comments below to discuss items in the list.

SMTK 3.1

  • Geometry library. Split smtk::model::Tessellation out of smtkCore and put it into a library dependent on VTK-m or VTK. This would let us avoid overhead when processing large models.
  • PV Widgets. Improved ParaView widget integration
    • bounding boxes provided by sets of model entities and/or entire model resources
    • better ties between attributes and widgets so that attribute item initialization can be geometry-aware (note that this is related to the Extended attribute modeling item as that would be one way to accomplish this coupling.
  • Extended attribute modeling. Provide methods to express constraints between attributes and their items. Examples include:
    • Suppose we have an integer item named dimension and a group item named coordinate. We might want the coordinate’s numberOfGroups() to be constrained to match the value held in dimension.
    • Suppose we have a modeling operation whose parameter is an attribute. The attribute accepts a clipping plane as a base point and normal that we wish to expose via a ParaView widget. The widget should have its bounds initialized to the bounding box of all the model entities associated to the operation’s attribute.
  • Contract tests. SMTK should test its ParaView extensions with contract tests using modelbuilder. We need a way to test the UI components (both ParaView and Qt) as SMTK changes, not just when we advance SMTK inside CMB. This should also help us package and build modelbuilder.
  • Asynchronous operations. Preliminary support had to be pulled because of Qt interactions but we should fix this.
  • OpenCascade (part 1). Preliminary support for displaying CAD models, perhaps with a few operations.
  • Discrete session. Functionality from the discrete session should migrate into the mesh and/or vtk sessions.
  • Workflow (part 1). Prototype architecture for modelbuilder to load and select from 1 or more workflows that control (a) which plugins are loaded (b) what operations and other UI elements are available based on the state of resource and operation managers and the application selection.
  • Operation UI cleanup and editing UIs. The current operation panel is clunky. At a minimum it should be split into a separate plugin so that when Workflow (part 1) lands it can be omitted. Additionally, we should explore how to allow applications or workflows perform operations in response to direct manipulation rather than indirect operation-panel edits. For example, double-clicking on model entities in the render view might provide a transform widget for placement or might provide handles for changing its shape based on the particular workflow or application.
  • Serialization.
    • Current usage of try catch block should be simplified since now nlohmann json provides is_null(), is_array(), and etc API. Though in order to catch json::type_error and json::out_of_range exceptions, try catch block should remain untouched.
    • Replace std::exception with nlohman::exception.
    • Use smtk logger to report errors or warnings instead of io stream.
  • Documentation. Finalize the documentation style.
  • Resource Portability. Make it possible to move resource files from one directory to another, and also from one machine to another.
  • Save Model Resource Without Copying Native Model (This might be “back to the future”.) Neil at LANL asked if we can save our .smtk file without making a copy of the model file that was imported when the resource was created, or writing the h5m file in the case of mesh sessions. This will be important when users start scaling to “big” meshes.
    • Internally, loading a resource of this type might be the equivalent of re-importing the native file while using the uuids and other meta data in the .smtk file.
    • If we can support it, I would also want to store a checksum in the .smtk file, to optionally verify that the native file had not changed.
    • It would also be nice to have an option to specify the native filename (path), overriding the path stored in the .smtk file.
  • Initialize pqAttributePanel without marking resource as modified. When loading an attribute resource (.smtk file) into modelbuilder, the resource gets marked as modified because each time a qtItem is initialized, it emits a signal because it’s value changed, which ends up setting the resource’s modified flag. Our qt extension needs to be updated to distinguish between changes due to a qtItem being initialized versus edits made by users.

SMTK 4.0

  • Split smtkCore. Instead of having one core library, we should have smtkCommon, smtkResource, smtkAttribute, smtkModel, etc.
  • Cumulus integration. On top of Asynchronous operations, we should provide a cumulus launcher that can host simulations on HPC and/or cloud resources, including a way to browse long-running, externally-managed operations across restarts of the UI or python interpreter.
  • Web integration. Explore ways to tie SMTK’s JSON resources to vtk.js, simput, Jupyter, etc.
  • OpenCascade (part 2). More fully featured geometric modeling and meshing of OpenCascade geometry.
  • Workflow (part 2). Complete workflows for at least 3 different applications.
  • PV Client/Server. Handle ParaView when the server is remote from the client.
  • Modes. Add support for modal interaction to paraview and then modelbuilder, starting with selection. Provide (1) the modes themselves which have no explicit UI representation; (2) a toolbar item showing the current mode; and possibly (3) a more involved UI that allows users and/or workflows to switch modes by pushing/popping them onto or out of a stack.
  • Sessions. Resurrect rgg session. Also resurrect polygon session (custom operation views for editing polygons required).
  • Cursor classes. Rework smtk::model::EntityRef (and smtk::mesh::Component and possibly add smtk::attribute::Cursor). The idea is to separate the classes that contain state and the classes that query and modify the state. Separating the data and method classes makes serialization/deserialization easier. Having a separate class that performs modifications is desirable as it helps delineate what code modifies resources and will make adding undo/redo easier later. Currently, EntityRef and all its subclasses only hold a weak-pointer to a model resource and a UUID. We can change them to hold a weak-pointer to a model Entity and split them into read-only (e.g., QueryFace) and read-write (e.g., MutableFace) classes.
2

@tj.corona @Bob_Obara @Haocheng_Liu @johnt Does anyone have opinions on whether bumping ParaView and VTK to catch the new VTK module system should happen for 3.1 vs 4.0?

3

I suggest let’s wait until Ben bumps ParaView’s VTK and see how smtk&CMB interact with it. If it works smoothly then It’s a 3.1 thing.

4

I’m not so sure we should be aggressive unless paraview is going to have a (non-patch) release before we expect SMTK 3.1 to land. I don’t think there is much of anything we need beyond paraview 5.6.x for what’s currently listed in SMTK 3.1.

5

@tj.corona Please add mesh-system tasks.

6

SMTK 4.0 should probably have “update to use new VTK module system” on its list (I can’t edit here).

D’oh, I see the rest of the conversation now. Seems I don’t get emails for direct mentions… I’d suggest waiting until 4.0.

7

@johnt The UI Tests item is a duplicate of Contract tests; I’m going to merge the two. I agree that we need to do a lot more testing but we need a reliable way to perform the tests.

8

+1 I missed the duplication with contract tests. Thanks. And yes, the key is a reliable way to test UI components.

9

@dcthomp @johnt would you mind looping me into the discussion about testing?

10

@tj.corona So far the only discussion is here, but I will be sure to mention you if it continues,

11

Note that for the Discrete session task, we will need to

  • revisit the MeshSelectionItem class
  • expand on SMTK’s parsing of the ParaView selection (in order to create selections of mesh primitives and non-vertex mesh points).

We may also want to figure out how to use ParaView’s ExtractSelection filter in “preserve topology” mode (where a scalar point-data or cell-data array is created on the existing VTK data instead of subsetting the data so it only includes the selected points/cells) or something like it. SMTK might keep around a point-data and cell-data array that users iteratively edit via a GUI on top of ExtractSelection; this would be a flexible way to accept changes to model faces & edges.

12

I am hopeful that this issue was resolved here.

13

I believe this will require the ability to select mesh cells. @dcthomp we have talked about this before, and it seemed to be doable but tricky.

14

Another bullet for SMTK v3.1 or v4.0 is the addition of another mesh backend. This has been discussed at length, and there are a couple of directions we can go (stl-only backend, vtk backend, something else). It would be nice to have backends that complement the primary use-cases for meshing (mesh generation, mesh manipulation, mesh visualization, etc).

15

Yes, I think packaging is OK now, although we haven’t had any nightly builds to test since Jan 27.

16

Added bullet “Save Model Resource Without Copying Native Model”

17

Added bullet “Initialize pqAttributePanel without marking resource as modified”

18

@johnt Is is possible that the .smtk file does not contain some attributes that the panel shows? When a new attribute instance is created (e.g., as required by an instanced view), then the attribute resource should be marked modified. Normally this only happens when importing a .sbt template file, but if a user saves a .smtk attribute resource without having visited all the tabs in the attribute panel, some fixed instances may still be missing from that file.

19

No, the modified signal is emitted by qtItems whenever their value changes, including when initialized. So, for example, I have an attribute resource containing one material attribute. When I load the resource, a different view (tab) is displayed by default. When I click on the material tab, the one material attribute is displayed and the resource is marked modified. That is because the Qt items are being created for the first time, and when (at least some of) the individual values are initialized, a signal gets emitted by the Qt item(s) indicating it was modified, which in turn bubbles up to mark the resource as modified. I can post an issue with an example if it is something you can look at.

20

Oh, I probably should have added that the resource is marked as modified just in the process of loading it from file. I stuck some printf’s in to see how many times the modified signal was being emitted, and counted 234 times for my test case. There certainly aren’t 234 attributes in the file, and none should be created when I load the file.