The main role of SMTK is the managing of the three core resources required in a numerical simulation:
Simulation Information / Attributes
Note that not all of these resources may be needed by the simulation and the interpretation of what they represent is dictated by the specific simulation workflow being defined. Also other types of resources may be required by the workflow that will need to interact with the above three (in particularly with the attribute resource).
Looking at how the above three types of resources have been designed in SMTK 1.x, I think there is some commonality that we can exploit and provide even more useful functionality.
Resources in SMTK 1.x
Currently the above three resources have no common inheritance though they do have some common characteristics:
Each Resource is typically stored atomically in a file or data management system. Therefore they are typically identified by a URL.
An Attribute Resource is represented by a single attribute system
A Model Resource is represented by a collection of models
A Mesh Resource is represented by a collection of meshes
john> I might not understand the current design, but I don't think that a collection of SMTK 1 models is stored atomically in one file. Do you mean one .smtk file? I think that can only reference one model.
bob - Actually if there are more than one models in the native model file, the smtk file must also have multiple models (one per native model)
Each Resource is composed of a set of Resource Components:
The Attribute System is composed of Attributes
The Model System is composed of Model Entities
The Mesh System is composed of Sets of Mesh Entities
Each Resource Component has an UUID assigned to it
In addition there are well defined "linkages" between resources and their components:
Attributes can be associated with Model Entities
Attribute Items can refer to Model Entities
Attribute Items can refer to Mesh Entities
Model Entities can refer to the set of Mesh Entities that are classified on them
Mesh Entities know what Model Entity they are classified on
Note that each of the above resource component associations are modeled differently in the current implementation.
In SMTK 1.x, there are also two Manager classes for Model and Meshes
SMTK Model Manager
The Model Manager class manages all Model Resources and Model Resource Components. This means that if several Model Resources are loaded, the Model Manager provides access to all of the Resource Components regardless of which model they belong to. Also the collections of models stored in the Model Resource is not currently represented in either the Model Manager or in the SMTK Model System.
SMTK Mesh Manager
The Mesh Manager is similar to the Model Manager in that it provides access to mesh resources. In this case these are Mesh Collections since a mesh file may contain more than one mesh.
In SMTK 1.x there is no manager for Attribute Systems and the management of these systems are left to the application.
Resources in SMTK 2.0
Resource Base Class
The base class for all resources modeled in SMTK would contain the following information:
URL - where is the resource currently located
UUID - some unique identifier so if a resource's URL was changed externally there is still some way of determining if this is the correct resource
Meta Data - information (probably in the form of a key,value dictionary
For example we could have subgroup information for geometry models (discrete, oce, polygon)
Roles - what role this represents: Coastline, Car, Wind-tunnel, etc..
Versioning - history of saved versions of the resource
Component Structure - something that describes the parts of the resource, for example:
Attribute Resources - attribute, definition
Geometric Models - vertices, edges, faces, volumes, aux geometry, component
Meshes - Mesh Sets, Data Set (i.e. simulation field values)
Been Modified - indicates that the resource has been modified since it was last saved. This would be represented as a simple flag that can be set and cleared
Resource Links - a set of resources that this resource references - Note that this does not mean that these resources must be loaded in prior to this resource being load into memory
(Maybe) - a mapping between the component structure and the relevant workflow. For example in a surface water problem a vertex might be a hard point, an edge could be a coastline, and a face a water area.
Resource Manager - this can be NULL meaning that the resource is not being managed and is up to the application to take care of it
Ability to map an UUID to a Resource Component
Ability to get a set of Components based on Type and/or Meta Data
Static Method for Creating an Empty Instance of itself.
Note that all resources would be modeled as shared pointers
Also note that there is no longer a type() method to indicate what type of resource the resource is. The idea behind this decision is that dynamic casting would be used to determine if a resource is of a specific type.
Model Collection - a collection of geometric models that can be stored in a file
Mesh Collection - same as in SMTK 1.x
Attribute Collection - what the current Attribute System is in SMTK 1.x
Resource Component Base Class
A Resource component is a part of a resource and relates to the component structure of the resource so for example a resource component of a geometric model could be a vertex, edge, face, volume, aux geometry, etc.. In the case of a Mesh Collection, resource components could include PointSets, CellSets(including their dimension) and Fields. Likewise for an Attribute Collection, the only component is an Attribute.
All resource components would consist of the following:
As with Resources, Components would be modeled as shared pointers.
Note that once again there is no type() method. The reason is that each derived resource has its own interpretation of what the type represents. For example, the Model Resource interprets the type as a set of bits that represent different aspects of the model entity
Derived Resource Component Classes
Based on the current types of resources the derived classes would be:
Resource Manager Class
The Manager is responsible for managing a set of Resources and would include the following functionality:
Find a Resource based on UUID (if it knows the URL it can also load it in if needed)
Load in or retrieve a Resource based on URL
Unmanage a Resource - remove the resource from the manager. This would remove its URL and UUID as well from the manager
Free - unload the Resource but keep track of its URL and UUID
Save/Load a state file that represents the resource UUIDs and URLs that it knew about
Ability to register resource readers/operators to the manager
Ability to register creation functions/operators to the manager
Is a Resource currently loaded?
Does it manage a specific Resource?
Haocheng > Is it safe for me to say that this class would govern model collection, mesh collection and attribute system right? In SMTK 2.0 we would have only one manager - a resource manager?
Changes to Model System
Rename current Model::Manager to be a Model::Collection
Need to change map from UUID to Entity to Shared Ptr of Entity
Need interface to access Shared Entity Pointers
Changes to the Attribute System
Rename System to Collection to be more consistent
Add ResourceComponentItem and ResourceComponentItemDefinition classes
The existing Model and Mesh Entity Item and Definition classes would derive from these
Change Model Association to become ResourceComponentAssociation and use the above new structure
Should this functionality be moved to the Resource class?
How should time stamping work?
Should we use coming like boost's Posix time?
Should Roles functionality be added to Resource and ResourceComponent
Resource Manager Operations?
How do we associate Resource Creation, Read, and Write Operations to a type of Resource?