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

From NAMIC Wiki
Jump to: navigation, search
m (Update from Wiki)
 
Line 1: Line 1:
 
  Back to [[NA-MIC_Collaborations|NA-MIC_Collaborations]]
 
  Back to [[NA-MIC_Collaborations|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, LONI Pipelines, and Grid Services without 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. Such processing modules can be discovered at runtime and delivered to clinicians as plugins to Slicer3.
+
'''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. 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. 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.  
  
'''Progress:''' An initial implementation is complete and under evaluation. The command line processing is automatically generated from the XML decription file. The generation process has been added to CMake.
 
  
 
'''Key Investigators'''<nowiki>: </nowiki>
 
'''Key Investigators'''<nowiki>: </nowiki>

Revision as of 20:58, 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. 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. 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: Slicer3:Execution_Model