|
|
Line 1: |
Line 1: |
− | * Define what is a "case" (a collection of data for processing). For example:
| + | <big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer_3.0_Some_preliminary_discussion_points here]</font></big> |
− | ** a MRML file with URL references that the pipeline elements resolve, or,
| |
− | ** a zip file with a MRML file and associated data inside of it.
| |
− | | |
− | Also, what MRML functionality do we need for real-world cases processed outside of Slicer? Is ITK-like functionality a good place to start?
| |
− | | |
− | * Provide a way to declare and fill in a pipeline's "case variables" (parameters that vary by case) and "global variables" (parameters that control the execution of the pipeline itself, such as where to run, how many processes, simple credentials, etc). Here's where pipeline parameter introspection comes in, but it doesn't have to be really complicated for this pass.
| |
− | | |
− | * Enough event loop to monitor dispatched processes. For short-running processes, it might be just exec and wait. For long-running processes that have remote job control, you might just poll the scheduler with a ticket and wait for a response. LONI and Grid experts can help here. For shared libraries, you could do a thread.
| |
− | | |
− | Could this be implemented as a single PipelineMonitor object?
| |
− | | |
− | * UI for parameter specification and case manipulation.
| |
− | | |
− | * LONI / Grid pipeline prototyping and parameter agreement.
| |
− | | |
− | * For a use case with many cases (say, run on a grid or cluster), is any information read or interpreted in Slicer? The case for a shared memory model proposed by Guido and Ross would seem incompatible with running 50 cases on a cluster.
| |
Revision as of 17:33, 21 May 2008
Home < Slicer 3.0 Some preliminary discussion pointsNote: We are migrating this content to the slicer.org domain - The newer page is here