Difference between revisions of "NA-MIC/Projects/NA-MIC Kit/Execution Model"

From NAMIC Wiki
Jump to: navigation, search
Line 10: Line 10:
 
* Dan Blezek, Jim Miller and Bill Lorensen (GE)
 
* Dan Blezek, Jim Miller and Bill Lorensen (GE)
  
Links: [[Slicer3:Execution_Model|Slicer3:Execution_Model]]
+
Links:  
 +
 
 +
* [[Slicer3:Execution_Model|Slicer3:Execution_Model]]
 +
* [[Slicer3:Execution Model Documentation | Slicer3 Execution Model Documentation]]

Revision as of 21:05, 19 April 2007

Home < NA-MIC < Projects < NA-MIC Kit < Execution Model
Back to NA-MIC_Collaborations

Objective: The Slicer3 Execution Model realizes the "Extensible Algorithmic Framework" goal by providing an interactive point-and-click interface to ITK-based command line executables as well as a batch processing interface to execute large scale experiments on clusters and grids. This objective is reached without requiring extensive re-engineering by the algorithm developer. The Execution Model uses an XML syntax to describe algorithm options and user interface controls. Slicer3 constructs the appropriate user interfaces from this description and manages the data transfer to and from the algorithm module. Modules are discovered at runtime and delivered to clinicians as plugins to Slicer3.

Progress: A base implementation of module discovery, user interface construction, and module execution is integrated into Slicer3. The implementation supports modules packaged as command line executables as well as modules loaded as dynamic libraries. A rich set of parameter types can be provided to a module including: images, models, fiducials, booleans, integers, floating point numbers, strings, lists, and enumerations. Additional parameter datatypes such as scenes, comma separated value files, and transforms are under development. Parameter sets can be archived as part of a MRML scene in Slicer3. Parameters are realized in the Slicer3 user interface using a rich set of widgets that include: node selectors, sliders, text entries, spin boxes, check boxes, radio buttons, and directory browsers. Modules can report multistage progress and modules can be terminated from Slicer3. Modules are run in a separate thread of execution and are queued so that only one module will execute at a time. Modules report information to the standard Slicer3 logging facility. Extensive documentation on the execution model is available describing the XML module description, the parameter types, command line parameter parsing tools, the automatic user interface construction, process control tools, and CMake configurations for new modules.


Key Investigators:

  • Dan Blezek, Jim Miller and Bill Lorensen (GE)

Links: