Modeling arrays on geometry

Simulation Modeling Toolkit (SMTK) Design
1

We have several use cases (anatomical data annotation, hydrological simulations) that involve modeling functions defined over volumes (from regularly sampled volumetric image data to explicit structured grids to fully unstructured grids). One of the operations we want to support is resampling these functions from one type of geometry (say image data) onto another (say an unstructured mesh of some feature in the domain covered by the image). An example is creating a label map on an image by marking voxels containing polygons:

image
image1834×1336 321 KB

  1. How should spatially-varying (or spatiotemporally-varying) fields be modeled in SMTK? While some applications are focused on analytical or procedural expressions, the use case we are dealing with now is experimental data (MRI/CT scans). Our current approach for image data is to create some model entity as a “child” of an smtk::model::Volume cell to represent the field. But the smtk::model::Resource doesn’t have an entity for this kind of thing. Some alternatives:

    1. Don’t model field data as “first class” data. This is the status quo. We could use SMTK’s geometry system (via point-data or cell-data in the VTK backend) or property system (to map field arrays to properties on components rather than to components themselves) to expose fields.
    2. Create “bogus” smtk::model::Face or smtk::model::AuxiliaryGeometry entities to represent field data.
    3. Switch aeva away from smtk::model::Resource to smtk::graph::Resource. Then we can simply create a new “Field” component.

  2. Once we have a choice made for how to represent fields defined over geometric models, what user interface component(s) are available for selecting fields? If we keep with the status quo (1.1), then some new widget will be required.If we start modeling fields as components (1.2 or 1.3 above), we can use qtReferenceItem to identify allowable components as long as the Resource’s query() method supports some way to find field components.

Anybody have preferences? I personally prefer 1.3 (use smtk::graph::Resource), but that does involve a fair amount of work compared to the alternatives.