Difference between revisions of "Slicer3:Pipeline Integration"

From NAMIC Wiki
Jump to: navigation, search
m (Update from Wiki)
Line 1: Line 1:
 
# The main features of the project
 
# The main features of the project
 
## http://pipeline.loni.ucla.edu
 
## http://pipeline.loni.ucla.edu
# The main outstanding questions that must be answered before you can complete the project ::
+
# The main outstanding questions that must be answered before you can complete the project ::
 
## Pipeline -> Slicer3
 
## Pipeline -> Slicer3
 
### Once the API for submission to Slicer3 is released, we can integrate it into the Pipeline.
 
### Once the API for submission to Slicer3 is released, we can integrate it into the Pipeline.
 
## Slicer3 -> Pipeline
 
## Slicer3 -> Pipeline
### We have made considerable progress in making Pipeline more stable, robust and scalable. Detailed progress is listed below ::
+
### We have made considerable progress in making Pipeline more stable, robust and scalable. Detailed progress is listed below ::
#### GUI : A new and improved graphical interface is now available. The gui is now much simpler in design and easier to use. The list of improvements/ new features is as follows :
+
#### GUI : A new and improved graphical interface is now available. The gui is now much simpler in design and easier to use. The list of improvements/ new features is as follows :
 +
 
 +
<verbatim>
  
 
  - Completely new data model/xml
 
  - Completely new data model/xml
Line 21: Line 23:
 
  - Scalable GUI functionality - is able to handle hundreds of modules in a single workflow
 
  - Scalable GUI functionality - is able to handle hundreds of modules in a single workflow
  
# ## ### #### DataModel : The data model, associated XML descriptions have been simplified greatly. The data model has been decoupled from the execution and the GUI, this component has been completed
+
</verbatim?
#### Translation : The translation portion of the software is responsible for accomodating logic that separates GUI/Execution vs Execution. This component has been completed, it takes the workflow and converts it into a flattened graph (it loses the property of module groups at this stage) and constructs the commands using the data model
+
 
#### Validation : The validation portion conducts sanity checks on the workflow. It allows the user to fix errors prior to "actual" execution and informs the user of all steps needed to make the workflow run
+
# ## ### #### DataModel : The data model, associated XML descriptions have been simplified greatly. The data model has been decoupled from the execution and the GUI, this component has been completed
#### Execution : The execution portion now is an independent component that is agnostic of the data model and can be invoked on the command line directly. Self-sufficient workflows (with previously bound parameters), can be now invoked and executed from the commandline, bypassing the GUI entirely. Workflows or pipes can now be executed both locally and on the LONI grid. The scalability has dramatically improved from 30 inputs to thousands of inputs per workflow. The changes in the execution model are ::
+
#### Translation : The translation portion of the software is responsible for accomodating logic that separates GUI/Execution vs Execution. This component has been completed, it takes the workflow and converts it into a flattened graph (it loses the property of module groups at this stage) and constructs the commands using the data model
 +
#### Validation : The validation portion conducts sanity checks on the workflow. It allows the user to fix errors prior to "actual" execution and informs the user of all steps needed to make the workflow run
 +
#### Execution : The execution portion now is an independent component that is agnostic of the data model and can be invoked on the command line directly. Self-sufficient workflows (with previously bound parameters), can be now invoked and executed from the commandline, bypassing the GUI entirely. Workflows or pipes can now be executed both locally and on the LONI grid. The scalability has dramatically improved from 30 inputs to thousands of inputs per workflow. The changes in the execution model are ::
  
 
  - Agnostic of the data model
 
  - Agnostic of the data model

Revision as of 03:59, 26 January 2007

Home < Slicer3:Pipeline Integration
  1. The main features of the project
    1. http://pipeline.loni.ucla.edu
  2. The main outstanding questions that must be answered before you can complete the project ::
    1. Pipeline -> Slicer3
      1. Once the API for submission to Slicer3 is released, we can integrate it into the Pipeline.
    2. Slicer3 -> Pipeline
      1. We have made considerable progress in making Pipeline more stable, robust and scalable. Detailed progress is listed below ::
        1. GUI : A new and improved graphical interface is now available. The gui is now much simpler in design and easier to use. The list of improvements/ new features is as follows :

<verbatim>

- Completely new data model/xml
- Significantly easier parameter editing
- Cleaner drag and drop of modules
- Easier list processing
- Stronger type checking (with feedback to help the user)
- Variable can be used on parameter bindings
- Personal Library of workflows and moduels
- Copy/Paste of single modules and groups of modules (and still retain connections)
- Undo/Redo on most operations
- Workflows can be layed out horizontally now
- Faster and easier zooming
- Scalable GUI functionality - is able to handle hundreds of modules in a single workflow

</verbatim?

  1. ## ### #### DataModel : The data model, associated XML descriptions have been simplified greatly. The data model has been decoupled from the execution and the GUI, this component has been completed
        1. Translation : The translation portion of the software is responsible for accomodating logic that separates GUI/Execution vs Execution. This component has been completed, it takes the workflow and converts it into a flattened graph (it loses the property of module groups at this stage) and constructs the commands using the data model
        2. Validation : The validation portion conducts sanity checks on the workflow. It allows the user to fix errors prior to "actual" execution and informs the user of all steps needed to make the workflow run
        3. Execution : The execution portion now is an independent component that is agnostic of the data model and can be invoked on the command line directly. Self-sufficient workflows (with previously bound parameters), can be now invoked and executed from the commandline, bypassing the GUI entirely. Workflows or pipes can now be executed both locally and on the LONI grid. The scalability has dramatically improved from 30 inputs to thousands of inputs per workflow. The changes in the execution model are ::
- Agnostic of the data model
- Minimal synchronization to express sequentiality and/or parallelism
- Local execution and LONI grid execution supported
- Detailed logs to keep track of progress
- Periodic status messages passed to GUI for immediate user feedback
- Scalability of execution allows running > 1000 inputs per workflow
  1. To start a pipeline on the commandline with parameters:

java -classpath pipeline.client.jar ui.cli.Main -execute prebound_workflow

Team Members:

  • Jagadeeswaran Rajendiran - UCLA