A new implementation of Project support was recently merged into SMTK and will be part of SMTK 21.05 and the functionality exposed in CMB 21.05. There are some concepts/relationships that are still being ironed out, especially with respect to the next strep: Workflow & Task Support.
A project is basically a container of SMTK Resources that grouped together so that user no longer needs to ensure that all of the necessary resources required for his/her task/workflow are loaded into / saved from ModelBuilder.
Lets assume you wanted to define an operator that would process the above project. To access Model 1, the operator could ask the project for its model resources. It could do similar actions for mesh and attribute resources in order to access Mesh 1 and Attribute 1 respectively.
But what if the project had more that one model? Well the operation could ask for the model resource by name, but that would mean that name is hardwired into operation and it’s up to the user to name the resource appropriately. Not a very elegant solution with no UI support. Alternatively, the operation could require the user to specify the required resources directly and by-pass the project all together, though that would reduce the potentially benefits of having operations take in projects.
To deal with this issue, SMTK Project introduces the concept of a role. A project role represents what a resource (unique role) or set of resources (non-unique role) represents with respect to the project. Below is an example of a casting project with roles.
The roles provide a conceptualization of the resources stored in a project. Model 1 represents the mold to be used in the casting, while Model 2 represents both the mold and the void region that the material will be poured into. The project also contains 4 different attribute resources:
- Attribute 1 - represents the simulation specification for calculating the required view factors
- Attribute 2 - represents the simulation specification for preheating the mold
- Attribute 3 - represents the simulation specification for pouring the material into the mold
- Attribute 4 - represents the simulation specification of cooling the mold and solidifying the material
Now an operation that takes in a project could request a resource based on its role. Instead of asking for Model 1, it can now ask the project for the “Mold” resource. This now eliminates the user from having to either guess the names of the required resources or having to pass them in as parameters.
Besides providing a labeling/structure mechanism for the resources within a project, a role can potentially have the following aspects:
- Constraints - the ability to restrict a role with respects to the resources that can be assigned to it. This could include:
- Resource Type
- Properties associated to the Resource
- Role Exclusivity - if a resource is already associated to Role X it can not be associated to Role Y
- Role Perquisite - a resource can be associated to Role Y iff it is associated to Role X
- Functional Constraints
- Number of Required Resources - how many resources must to associated to the Role
- Is Extensible - can the Role have a range of Resources associated with it
Similar to Roles, a SMTK Resource can have set of Properties associated with it. Besides the above potential aspects of Roles, the other major difference would be that assigning a Resource to a Role does not effect the state of the Resource itself, while adding a Property to a Resource does. When a Resource is assigned to a Role, it is not modified, only the Project would need to be saved.
Roles do have a very close resemblance with the Attribute Resource’ s Reference Item.
Now lets assume we want to do something with the contents of a Project. As we have already mentioned we could associate a set of operations with the project, but what about user-driven tasks. For example, the user needs to fill out the Pre-Heat Specification before they can run the Pre-Heat Simulation. Capturing this will be the responsibility of the Task.
For simplicity sake, lets assume we have a Task that will define and run a Truchas Simulation. The Task will have a set of requirements that need to be met in order start the Task. In this example lets assume that the generic Truchas Task has the following requirements:
- Heat Transfer Model
- Truchas-based Attribute Resource
- Optionally an Induction Heating Model
The Project designer (or user) would then “connect” the Project’s roles (or resources) with the Task’s requirements as shown below:
Here you see the same task instanced 3x’s, with each instance being given different resources for its requirements. As a result, each instance produces different results needed by the overall workflow. The clouds represent information not stored explicitly by the project. These assets can include the following:
- Input files generated by the task
- Job submission information (though there is work in progress to have this information stored in the Project
- Simulation Results
- Post Processing Results
In many cases the information generated from one task is needed by another. The location and filenames of the results from one task sometimes need to be passed into another. One possible approach would be to have the task “fill in” the relevant information into a requirement that represents the specification of a dependent task as shown below.
Here you can see the tasks optionally taking in an attribute resource that represents the specification of a dependent task.
Note that all of the linkages shown between the Tasks and Project Resources would be persistent.
In real life, simulations / workflows tend not to be executed once. Researchers/Engineers will create variations of a Project’s workflow. If we look at the problem from this point of view, then many of the details we have attributed to Project is really attributed to a Workflow instance.
Here we have extend the Project to have multiple resources assigned to the same Role. For each workflow instance the user is allow to choose a resource from the role that will then be properly assigned to the Task’s Requirements. In this conceptual figure, the specifications are “owned” by each Workflow instance but we could instead also treat them as we do the model resources and have then belong explicitly to the Project’s roles. The reason I think this might be better is that during the workflow, the attributes are associated with components of the models. If the specifications were selectable, then in certain cases the user would not be able to also select the models.