... | @@ -19,8 +19,9 @@ Task Design |
... | @@ -19,8 +19,9 @@ Task Design |
|
---
|
|
---
|
|
* Define a Task object that represents a specific activity in a workflow
|
|
* Define a Task object that represents a specific activity in a workflow
|
|
* A task would have associated with it the following:
|
|
* A task would have associated with it the following:
|
|
* Resources (and their specific roles) related by the Task - these could be owned by the Task itself, made available to the Task, or created and returned by the Task
|
|
* Resources (and their specific roles) related by the Task - these could be owned by the Task itself, made available to the Task, or created and returned by the Task. For example a Task could require model1 (discrete model) and model2(polygon model). In the case of attribute system, it would specify the templates that should be used.
|
|
* Set of operators needed by the task (along with how to visualize them)
|
|
* List of Plugin to be loaded
|
|
|
|
* Set of operators needed by the task (along with how to visualize them) This could include meshing, job submission, and post-processing operations.
|
|
* Set of Views/Layouts
|
|
* Set of Views/Layouts
|
|
* Sub-Tasks
|
|
* Sub-Tasks
|
|
* Active Condition - when can the Task be active
|
|
* Active Condition - when can the Task be active
|
... | @@ -124,6 +125,9 @@ In terms of resources (meshes, models, and attributes systems) - the model defin |
... | @@ -124,6 +125,9 @@ In terms of resources (meshes, models, and attributes systems) - the model defin |
|
* Task 3 has its own for the meshing information (unless like Task 2, the user is allowed to modify the model boundary which would require the need of accessing Task 1's attribute system
|
|
* Task 3 has its own for the meshing information (unless like Task 2, the user is allowed to modify the model boundary which would require the need of accessing Task 1's attribute system
|
|
* Task 4 uses the attribute system created in Task 2
|
|
* Task 4 uses the attribute system created in Task 2
|
|
|
|
|
|
|
|
### Task Options/Initialization
|
|
|
|
The above workflow works well when starting from scratch but lets assume someone already had created a geometric model and wants to share it - If Task 1 had an option to load in a model then the user would simply load in the geometry and select task completed. Another potential sub-use case concerns Task 2. Say that in order to start the process of defining the simulation the user needed to specify the number of parameters being solved for (the Proteus Hydro code is structured this way) - so the Task when initially opened would prompt the user for this information and then initialize the attribute system appropriately.
|
|
|
|
|
|
### Task Completion
|
|
### Task Completion
|
|
There needs to be a mechanism to indicate that a task is completed (or at least completed enough to move to the next dependent task). So each task would have an optional completion validator. Ideally SMTK would provide some simple ones that the designer could use in their task description - for example in the above workflow the validation criteria could be the following:
|
|
There needs to be a mechanism to indicate that a task is completed (or at least completed enough to move to the next dependent task). So each task would have an optional completion validator. Ideally SMTK would provide some simple ones that the designer could use in their task description - for example in the above workflow the validation criteria could be the following:
|
|
|
|
|
... | @@ -134,3 +138,7 @@ There needs to be a mechanism to indicate that a task is completed (or at least |
... | @@ -134,3 +138,7 @@ There needs to be a mechanism to indicate that a task is completed (or at least |
|
* Task 5: None
|
|
* Task 5: None
|
|
|
|
|
|
In terms of when to evaluate the completion criteria, ideally each active task could call its validation method after an operation is executed - conversely the user could be made to hit a completed button when he/she thinks the task is completed. In this approach if the task's validation checker passes, the task is marked as done and cannot be edited further and the tasks that depend on it that can be made active are activated. Note that there would be an edit button for completed tasks. When a tasks is reopened for editing, all dependent tasks are "frozen" until the task validated as completed.
|
|
In terms of when to evaluate the completion criteria, ideally each active task could call its validation method after an operation is executed - conversely the user could be made to hit a completed button when he/she thinks the task is completed. In this approach if the task's validation checker passes, the task is marked as done and cannot be edited further and the tasks that depend on it that can be made active are activated. Note that there would be an edit button for completed tasks. When a tasks is reopened for editing, all dependent tasks are "frozen" until the task validated as completed.
|
|
|
|
|
|
|
|
### Tasks and Task Templates
|
|
|
|
Analogous to SMTK 1.0 a Task Template is used to generate a Task while a Task is represents the state of the instantiated Task. Tasks can be saved out and loaded back in again in order to allow the user to pick up where he/she left off.
|
|
|
|
|