|
|
# Enhancing Resources in SMTK 2.0
|
|
|
|
|
|
The main role of SMTK is the managing of the three core resources required in a numerical simulation:
|
|
|
|
|
|
* Models
|
|
|
* Meshes
|
|
|
* 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
|
|
|
* 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 is provides access to mesh resources. In this case these are Mesh Collections since a mesh file may contain more than one mesh.
|
|
|
### Attribute Management
|
|
|
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
|
|
|
* Type - what type of resource this is (initially I was thinking this would be a string so we can dynamically extend the types of resources - currently we have geometric model, mesh, and attribute
|
|
|
* 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 - something to indicate the resource has been modified since it was last saved
|
|
|
* Component Structure - something that describes the parts of the resource, for example:
|
|
|
* Attribute Resources - attribute
|
|
|
* Geometric Models - vertices, edges, faces, volumes, aux geometry, component
|
|
|
* Meshes - Mesh Sets
|
|
|
* Been Modified - indicates that the resource has been modified since it was last saved
|
|
|
* 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
|
|
|
|
|
|
#### Derived Resource Classes
|
|
|
The set of resource classes would include:
|
|
|
|
|
|
* 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, the only resource component is a Mesh Set. Likewise for an Attribute Collection, the only component is an Attribute.
|
|
|
|
|
|
All resource components would consist of the following:
|
|
|
|
|
|
* UUID
|
|
|
* Type
|
|
|
* Meta Data
|
|
|
* Roles
|
|
|
* Versioning
|
|
|
* Owning Resource
|
|
|
|
|
|
As with Resources, Components would be modeled as shared pointers.
|
|
|
|
|
|
#### Derived Resource Component Classes
|
|
|
Based on the current types of resources the derived classes would be:
|
|
|
|
|
|
* Model Entity
|
|
|
* Attribute
|
|
|
* Mesh Set
|
|
|
|
|
|
### 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? |