NAMIC Wiki - User contributions [en]

Slicer3:Grid Interface UseCases

2007-07-05T23:18:46Z

NeilJones: /* EM Segmentation */

=== Use Cases ===

Here are two base use cases that we can consider as an initial step in moving the Grid Interface (Grid Wizard) into NA-MIC DBP analyses. These two use cases are "deliverables" for NAMIC, but on different time frames---the first use case should be completed, documented, demonstrated, and in the hands of users by early August. The second use case should be completed, documented, demonstrated, and in the hands of users by mid-to-late September.

==== EM Segmentation ====

The EM (Expectation Maximization) Segmenter is an algorithm that performs a two-step iterative optimization procedure to detect "stuff" from "non-stuff" (where usually "stuff" is "white matter" and "non-stuff" is everything that isn't). The algorithm itself is slow, but frequently needs to be run on many data sets as an initial step in some larger scientific analysis problem. One of the main problems with EM Segmentation is that configuring a set of parameters for a segmentation run is, mildly put, a bit of an art rather than a specific procedure. We propose that Slicer's main function here is as an exploratory data analysis platform:

# User loads an image into Slicer
# User goes through a several step process in configuring and initializing the EM algorithm
# User performs EM segmentation on a subsection of a single volume
# User goes back to step 2, until satisfied that the EM iterations are converging to a useful (though local) optimum.
# User saves a "parameter file" [need more info here about what this is] and then performs the EM segmentation algorithm on the whole volume.
# User looks wistfully at a directory, and wishes that she could just "run it on all those files", rather than repeating the process from step 1.

There are a couple of problems with these last two steps, including the general warning from Slicer 101 claiming: don't run this on a machine with less than 2 Gb of RAM, and even that might not be enough sometimes. This is an obvious case for where we can benefit from performing an initial analysis on a cluster, and then performing a batch analysis "in the large" on a cluster.

What we propose as a software deliverable comes in four parts:
# A configured GridWizard system for the NAMIC cluster that a user can install into his or her own workspace (users can reconfigure for other clusters, but this may not be terribly friendly)
# An EM Segmenter Slicer command-line module that allows a user to perform a single segmentation on a cluster, or a batch segmentation on a cluster
# Documentation on how to use both of above
# A roll, RPM, or tarball for EMSegmenter for 32-bit and 64-bit Linux cluster so that it can easily be installed on many compute nodes simultaneously

In these use cases, we presume that the user is, virtually speaking, inside the SPL proper and does not need to contend with gatekeeper's s/KEYS password system. We also assume the following "preamble" to each use:
# User loads an image into Slicer
# User configures EM Segmenter
# User performs small segmentation locally

The usage we propose of EMSegmenter is in two parts: simple, and batch. "Batch" here simply means "the processing of multiple files simultaneously"; in each case, the job physically runs on a batch-oriented processing system.

* Simple mode
# Preamble...
# User launches Segmentation on a cluster (specifically, the NAMIC cluster)
# Window pops up with the task to be performed
# User reviews the "task list" and clicks "run"
# Job starts
# Job output ends up on an sshfs-mounted directory
# User can reload results into Slicer, check for accuracy.
* Mega-mode
# Preamble...
# User chooses a directory
# User enters a file glob (i.e., filter) into a parameter box in Slicer; this file glob applies to files in the chosen data directory but is not recursive; the file glob may not adhere #: to strict POSIX guidelines (? or [] might not be implemented)
# User choose "launch"
# Window pops up with the list of tasks that need to be performed
# User reviews the task list, and clicks "run"

In either case, a future version should include some additional features from the "job manager" window that pops up when the user wants to run batch jobs:

# Ability to monitor jobs
# Ability to inspect job outputs (PBS stderr streams, etc)
# Ability to inspect the job artifacts (parallelization scripts)
# Ability to choose the scheduling algorithm (and all that implies): do it all statically, or on a first-come-first-served basis.
# Ability to select multiple clusters, connected remotely

Many of these features are already present in GridWizard, but validation that they work with the above use case needs to be done _after_ the software is successfully demonstrated.

(Note: http://wiki.na-mic.org/Wiki/index.php/Slicer3:EM has more information about the newer EMSegmenter.)

==== SPHARM-PDM: Spherical Harmonic-based Brain Shape Analysis ====

The SPHARM-PDM based shape analysis aims at analyzing group shape differences in sub-cortical structures, such as the caudate or hippocampus. The overall procedure converts a binary segmentation first into a surface mesh and then computes a parametric shape description using spherical harmonic basis functions for encoding separately the x, y, and z coordinates of the surface. The first order ellipsoid alongside the spherical parametrization established via equal-area transform establishes the correspondence between objects. An icosahedron subdivision of the spherical parametrization results in a sampled triangulation with inherent correspondence between objects. The sampled surfaces of two groups are then compared via multivariate Hotelling T^2 group mean difference evaluated using a non-parametric permutation test.

A key step in the SPHARM-PDM processing is the initial mapping of an arbitrary binary segmentation onto a surface of spherical topology and then onto spherical coordinates. The software that performs this is part of the SPHARM 1.7 toolkit, using the commands SegPostProcess and GenParaMesh. The SPHARM-PDM description is the computed from this information via ParaToSPHARMMesh. The statistical analysis is computed via the tool StatNonParamPDM.

The goal of our activities is to take a large list of segmentations and process these through the first 3 steps in parallel. The time savings is obvious: 60 volumes acquired throughout a day can be processed in parallel in under two hours on a moderate cluster; on a single processor, it could take more than 5 days or longer.

SPHARM-PDM shape analysis is quite different from EMSegmenter. Here, we can rely on two things:

# The user does not need to start slicer in order to start a job
# The user is comfortable with command-line applications

This is an ideal situation for =gwiz-run=, a command-line application scheduler.

The software we propose for this use case comes in three parts:

# A configured GridWizard for the NAMIC cluster, which can be installed by a user into his or her own workspace
# A software package (RPM, tarball, or rocks roll) for 32- and 64-bit clusters to install the SPHARM-PDM software
# A set of "template" commands that the user can apply to process large numbers of images

Like the EMSegmenter use case above, we assume that the user is virtually inside the SPL and does not have to contend with the gatekeeper login system, or is using the BIRN cluster. Similarly, the cluster will need to have an =ssfs= filesystem mounted to some remote data repository (or the cluster needs to be the repository). The usage we propose of SPHARM is as follows:

# User gathers a large set (>= 25, <= 500) of files to process
# User picks a set of configuration parameters
# User goes to a NAMIC wiki page listing a "template command"
# User runs the =gwiz-gui= application
# User cut-and-pastes the template command into the gui, edits it as appropriate
# User reviews task list, optionally chooses to change the scheduling algorithm's parameters, clicks "Go"

The "nice-to-have's" from EMSegmenter apply here as well.

'''Additional comments by Martin:'''

The above scenario is really only short term vision, what we really need is a GUI that lets users select the datasets and parameters. Then the user clicks a 'run' button and everything is automatically being distributed to the grid and run.

Slicer3:Grid Interface UseCases

2007-06-28T16:03:05Z

NeilJones:

=== Use Cases ===

Here are two base use cases that we can consider as an initial step in moving the Grid Interface (Grid Wizard) into NA-MIC DBP analyses. These two use cases are "deliverables" for NAMIC, but on different time frames---the first use case should be completed, documented, demonstrated, and in the hands of users by early August. The second use case should be completed, documented, demonstrated, and in the hands of users by mid-to-late September.

==== EM Segmentation ====

The EM (Expectation Maximization) Segmenter is an algorithm that performs a two-step iterative optimization procedure to detect "stuff" from "non-stuff" (where usually "stuff" is "white matter" and "non-stuff" is everything that isn't). The algorithm itself is slow, but frequently needs to be run on many data sets as an initial step in some larger scientific analysis problem. One of the main problems with EM Segmentation is that configuring a set of parameters for a segmentation run is, mildly put, a bit of an art rather than a specific procedure. We propose that Slicer's main function here is as an exploratory data analysis platform:

# User loads an image into Slicer
# User goes through a several step process in configuring and initializing the EM algorithm
# User performs EM segmentation on a subsection of a single volume
# User goes back to step 2, until satisfied that the EM iterations are converging to a useful (though local) optimum.
# User saves a "parameter file" [need more info here about what this is] and then performs the EM segmentation algorithm on the whole volume.
# User looks wistfully at a directory, and wishes that she could just "run it on all those files", rather than repeating the process from step 1.

There are a couple of problems with these last two steps, including the general warning from Slicer 101 claiming: don't run this on a machine with less than 2 Gb of RAM, and even that might not be enough sometimes. This is an obvious case for where we can benefit from performing an initial analysis on a cluster, and then performing a batch analysis "in the large" on a cluster.

What we propose as a software deliverable comes in four parts:
# A configured GridWizard system for the NAMIC cluster that a user can install into his or her own workspace (users can reconfigure for other clusters, but this may not be terribly friendly)
# An EM Segmenter Slicer command-line module that allows a user to perform a single segmentation on a cluster, or a batch segmentation on a cluster
# Documentation on how to use both of above
# A roll, RPM, or tarball for EMSegmenter for 32-bit and 64-bit Linux cluster so that it can easily be installed on many compute nodes simultaneously

In these use cases, we presume that the user is, virtually speaking, inside the SPL proper and does not need to contend with gatekeeper's s/KEYS password system. We also assume the following "preamble" to each use:
# User loads an image into Slicer
# User configures EM Segmenter
# User performs small segmentation locally

The usage we propose of EMSegmenter is in two parts: simple, and batch. "Batch" here simply means "the processing of multiple files simultaneously"; in each case, the job physically runs on a batch-oriented processing system.

* Simple mode
# Preamble...
# User launches Segmentation on a cluster (specifically, the NAMIC cluster)
# Window pops up with the task to be performed
# User reviews the "task list" and clicks "run"
# Job starts
# Job output ends up on an sshfs-mounted directory
# User can reload results into Slicer, check for accuracy.
* Mega-mode
# Preamble...
# User chooses a directory
# User enters a file glob (i.e., filter) into a parameter box in Slicer; this file glob applies to files in the chosen data directory but is not recursive; the file glob may not adhere #: to strict POSIX guidelines (? or [] might not be implemented)
# User choose "launch"
# Window pops up with the list of tasks that need to be performed
# User reviews the task list, and clicks "run"

In either case, a future version should include some additional features from the "job manager" window that pops up when the user wants to run batch jobs:

# Ability to monitor jobs
# Ability to inspect job outputs (PBS stderr streams, etc)
# Ability to inspect the job artifacts (parallelization scripts)
# Ability to choose the scheduling algorithm (and all that implies): do it all statically, or on a first-come-first-served basis.
# Ability to select multiple clusters, connected remotely

Many of these features are already present in GridWizard, but validation that they work with the above use case needs to be done _after_ the software is successfully demonstrated.

==== SPHARM: Spherical Harmonic-based Brain Shape Analysis ====

SPHARM is a numerical algorithm aimed at analyzing shape differences between medical volumes. [this description is probably wrong --- need to read the SPHARM paper, obviously] The overall procedure involves taking a valume and essentially performing a Fourier-like analysis where the volume is decomposed into spherical harmonics (the spherical harmonics here taking the place of sinusoidal functions in a standard fourier transform). If you have two volumes and you perform this mapping, you can examine the coefficients of corresponding harmonics to see where bulges or shrinkage occur, etc.

A key step in the SPHARM processing is the initial mapping of an arbitrary volume onto spherical coordinates. The software that performs this is part of the SPHARM 1.7 toolkit, using the command (tbd). We would like to be able to take a large list of volumes and process these through the first step in parallel. The time savings is obvious: 60 volumes acquired throughout a day can be processed in parallel in under half an hour one a moderate cluster; on a single processor, it could take half a week or longer.

SPHARM, and the way that it is used in dtMRI imaging, is different from EMSegmenter. Here, we can rely on two things:

# The user does not need to start slicer in order to start a job
# The user is comfortable with command-line applications

This is an ideal situation for =gwiz-run=, a command-line application scheduler.

The software we propose for this use case comes in three parts:

# A configured GridWizard for the NAMIC cluster, which can be installed by a user into his or her own workspace
# A software package (RPM, tarball, or rocks roll) for 32- and 64-bit clusters to install the SPHARM software
# A set of "template" commands that the user can apply to process large numbers of images

Like the EMSegmenter use case above, we assume that the user is virtually inside the SPL and does not have to contend with the gatekeeper login system, or is using the BIRN cluster. Similarly, the cluster will need to have an =ssfs= filesystem mounted to some remote data repository (or the cluster needs to be the repository). The usage we propose of SPHARM is as follows:

# User gathers a large set (>= 25, <= 500) of files to process
# User picks a set of configuration parameters
# User goes to a NAMIC wiki page listing a "template command"
# User runs the =gwiz-gui= application
# User cut-and-pastes the template command into the gui, edits it as appropriate
# User reviews task list, optionally chooses to change the scheduling algorithm's parameters, clicks "Go"

The "nice-to-have's" from EMSegmenter apply here as well.

Slicer Grid Computing

2007-06-28T04:14:01Z

NeilJones: /* To do */

== Items discussed ==

* Stephen Aylward (KitWare) presented BatchMake interface to Condor
* Neil Jones (BIRN) presented GridWizard
* Group discussed different data storage technologies: MIDAS, BIRN Federated Data/XNAT/HID, etc.

== Where we are ==

Both BatchMake and GridWizard have (partially working) demos of launching multiple processes on remote machines. However, there's still a set of questions as to how these systems will interface with the Slicer environment to meet community needs. To that end, it's worth figuring out the answers to a few questions:

* What is the main community we should target? Will there be different modes of interaction for algorithm developers and domain scientists?
* What are two specific use cases of a Slicer user interacting with batch processing facilities through Slicer? Where does data come from, where does it need to end up? What data needs to get passed back to Slicer itself?
* What are two specific use cases of a NAMIC user interacting with batch processing facilities, perhaps outside of Slicer?
* Stephen (Aylward) presented a soup-to-nuts backend for managing "experiments", data, and displaying metrics computed from images in graphical form. Neil (Jones) discussed the infrastructure to manage the running of large number of jobs and the portal dashboard used to track the jobs.
** What facilities within Slicer or within other environements (e.g. portal or stand-alone applications) are necessary to track and manage these jobs.
* What look-and-feel of modules in Slicer is required? Do we need special "grid"-type parameters in the execution model, or should we just adhere to "min parameter", "max parameter", "step" notion?
** Can we handle configuration of either tool out of band from Slicer?
** Can we handle monitoring out of band from Slicer?

Until now, we have been focused on the infrastructure development: developing tools to perform generic batch processing. The tools are at a stage where progress (aside from just improving the tools but not deploying them) can be made in applying these to specific research needs.

== Introduction ==

NA-MIC and BIRN, in many respects, have some similar problems but in different domains. At BIRN, we need to launch lots of shape analysis tools from a portal environment. At NAMIC, we would like to launch lots of shape analysis tools from a rich client application (Slicer). While the "environment" is different, the constant is that we both need to launch large computationally intensive jobs on distributed clusters. The logistical problem is straightforward to see: how can we launch and manage many jobs in a repeatable and standardized fashion, without tailoring it specifically to a particular cluster? One might think that these problems are trivially solved; after all, haven't lots of people faced this problem before? Well, they have, and there are many solutions available, but the fact that nobody has been able to get these things to work in our respective contexts is indicative that there *is* a problem, even if nobody can really explain *why* the problem exists in the first place. But we have this shared problem, and we have similar infrastructural needs, so the project have collaborated.

It's not always clear to people in the respective projects---aside from upper management, that is---what the benefit of the NAMIC-BIRN collaboration is, at least at anything more than NAMIC using BIRN's SRB system as a distributed file system mainly "because it's there" and setting up a whole new AFS system is probably more annoying than just relying on SRB. But this, I claim, is a short-sighted complaint. NAMIC's value-add to BIRN is that the specific usage requirements and software distribution channel available from NAMIC will help improve the GridWizard software by making it clear which features need to be improved and which features are window dressing; it is precisely this feedback that has been missing from most other Grid Scheduling projects, which explains why the road to hell is paved with useless globus software. The value-add to NAMIC for relying on BIRN's job launching infrastructure is that computational jobs can be handled faster, started from less-powerful machines (i.e., you work on a laptop and launch a complicated analysis, and pick it up later), and opens up a new use for Slicer as an exploratory data analysis tool.

Since we have similar problems, we've developed similar frameworks. BIRN has GridWizard, a project that's been in development for the better part of a year. Slicer can accept plugins from KitWare that work over BatchMake. Still, none of these have been terribly helpful to actual researchers yet since they have been toolkits under development, rather than toolkits with specific use cases. Enough with the toolkit development already---time to actually generate some results!

=== Use Cases ===

Here are two base use cases that we can consider as an initial step in coordinating the two projects, such that each project benefits more than not. These two use cases are "deliverables" from BIRN to NAMIC, but on different time frames---the first use case should be completed, documented, demonstrated, and in the hands of users by early August. The second use case should be completed, documented, demonstrated, and in the hands of users by mid-to-late September.

==== EM Segmentation ====

The EM (Expectation Maximization) Segmenter is an algorithm that performs a two-step iterative optimization procedure to detect "stuff" from "non-stuff" (where usually "stuff" is "white matter" and "non-stuff" is everything that isn't). The algorithm itself is slow, but frequently needs to be run on many data sets as an initial step in some larger scientific analysis problem. One of the main problems with EM Segmentation is that configuring a set of parameters for a segmentation run is, mildly put, a bit of an art rather than a specific procedure. We propose that Slicer's main function here is as an exploratory data analysis platform:

# User loads an image into Slicer
# User goes through a several step process in configuring and initializing the EM algorithm
# User performs EM segmentation on a subsection of a single volume
# User goes back to step 2, until satisfied that the EM iterations are converging to a useful (though local) optimum.
# User saves a "parameter file" [need more info here about what this is] and then performs the EM segmentation algorithm on the whole volume.
# User looks wistfully at a directory, and wishes that she could just "run it on all those files", rather than repeating the process from step 1.

There are a couple of problems with these last two steps, including the general warning from Slicer 101 claiming: don't run this on a machine with less than 2 Gb of RAM, and even that might not be enough sometimes. This is an obvious case for where we can benefit from performing an initial analysis on a cluster, and then performing a batch analysis "in the large" on a cluster.

What we propose as a software deliverable comes in four parts:
# A configured GridWizard system for the NAMIC cluster that a user can install into his or her own workspace (users can reconfigure for other clusters, but this may not be terribly friendly)
# An EM Segmenter Slicer command-line module that allows a user to perform a single segmentation on a cluster, or a batch segmentation on a cluster
# Documentation on how to use both of above
# A roll, RPM, or tarball for EMSegmenter for 32-bit and 64-bit Linux cluster so that it can easily be installed on many compute nodes simultaneously

In these use cases, we presume that the user is, virtually speaking, inside the SPL proper and does not need to contend with gatekeeper's s/KEYS password system. We also assume the following "preamble" to each use:
# User loads an image into Slicer
# User configures EM Segmenter
# User performs small segmentation locally

The usage we propose of EMSegmenter is in two parts: simple, and batch. "Batch" here simply means "the processing of multiple files simultaneously"; in each case, the job physically runs on a batch-oriented processing system.

* Simple mode
# Preamble...
# User launches Segmentation on a cluster (specifically, the NAMIC cluster)
# Window pops up with the task to be performed
# User reviews the "task list" and clicks "run"
# Job starts
# Job output ends up on an sshfs-mounted directory
# User can reload results into Slicer, check for accuracy.
* Mega-mode
# Preamble...
# User chooses a directory
# User enters a file glob (i.e., filter) into a parameter box in Slicer; this file glob applies to files in the chosen data directory but is not recursive; the file glob may not adhere #: to strict POSIX guidelines (? or [] might not be implemented)
# User choose "launch"
# Window pops up with the list of tasks that need to be performed
# User reviews the task list, and clicks "run"

In either case, a future version should include some additional features from the "job manager" window that pops up when the user wants to run batch jobs:

# Ability to monitor jobs
# Ability to inspect job outputs (PBS stderr streams, etc)
# Ability to inspect the job artifacts (parallelization scripts)
# Ability to choose the scheduling algorithm (and all that implies): do it all statically, or on a first-come-first-served basis.
# Ability to select multiple clusters, connected remotely

Many of these features are already present in GridWizard, but validation that they work with the above use case needs to be done _after_ the software is successfully demonstrated.

==== SPHARM: Spherical Harmonic-based Brain Shape Analysis ====

In a similar vein to LDDMM, SPHARM is a numerical algorithm aimed at analyzing shape differences between medical volumes. [this description is probably wrong --- need to read the SPHARM paper, obviously] The overall procedure involves taking a valume and essentially performing a Fourier-like analysis where the volume is decomposed into spherical harmonics (the spherical harmonics here taking the place of sinusoidal functions in a standard fourier transform). If you have two volumes and you perform this mapping, you can examine the coefficients of corresponding harmonics to see where bulges or shrinkage occur, etc.

A key step in the SPHARM processing is the initial mapping of an arbitrary volume onto spherical coordinates. The software that performs this is part of the =XXXX= (little help here?) toolkit, using the command =XXXX= (help here too!). We would like to be able to take a large list of volumes and process these through the first step in parallel. The time savings is obvious: 60 volumes acquired throughout a day can be processed in parallel in under half an hour one a moderate cluster; on a single processor, it could take half a week or longer.

The EMSegmenter use cases is bologna software: it's cold and best thinly Sliced. SPHARM, and the way that it is used in dtMRI imaging, is different. Here, we can rely on two things:

# The user does not need to start slicer in order to start a job
# The user is comfortable with command-line applications

This is an ideal situation for =gwiz-run=, a command-line application scheduler.

The software we propose for this use case comes in three parts:

# A configured GridWizard for the NAMIC cluster, which can be installed by a user into his or her own workspace
# A software package (RPM, tarball, or rocks roll) for 32- and 64-bit clusters to install the SPHARM software
# A set of "template" commands that the user can apply to process large numbers of images

Like the EMSegmenter use case above, we assume that the user is virtually inside the SPL and does not have to contend with the gatekeeper login system, or is using the BIRN cluster. Similarly, the cluster will need to have an =ssfs= filesystem mounted to some remote data repository (or the cluster needs to be the repository). The usage we propose of SPHARM is as follows:

# User gathers a large set (>= 25, <= 500) of files to process
# User picks a set of configuration parameters
# User goes to a NAMIC wiki page listing a "template command"
# User runs the =gwiz-gui= application
# User cut-and-pastes the template command into the gui, edits it as appropriate
# User reviews task list, optionally chooses to change the scheduling algorithm's parameters, clicks "Go"

The "nice-to-have's" from EMSegmenter apply here as well.

=== The Plan ===

Slicer Grid Computing

2007-06-27T16:22:18Z

NeilJones:

Slicer Grid Computing

2007-06-27T15:11:43Z

NeilJones:

== Items discussed ==

* Stephen Aylward (KitWare) presented BatchMake interface to Condor
* Neil Jones (BIRN) presented (briefly) GridWizard
* Group discussed different data storage technologies: MIDAS, BIRN Data Repository/XNAT, etc.

== Where we are ==

Both BatchMake and GridWizard have (partially working) demos of launching multiple processes on remote machines. However, there's still a lack of clarity of exactly what it is that the Slicer community needs. To that end, it's worth figuring out the answers to a few questions:

* What is the main community we should target? Core 1, 2, or 3?
* What are two specific use cases of a Slicer user interacting with batch processing facilities through Slicer? Where does data come from, where does it need to end up?
* What are two specific use cases of a NAMIC user interacting with batch processing facilities, perhaps outside of Slicer?
* Stephen (Aylward) presented a soup-to-nuts backend for managing "experiments", data, and displaying metrics computed from images in graphical form.
** Does this fit in well with the above use cases?
** If it is a requirement, who supports this? Stephen pointed out that the code is all in PHP and not terribly portable to new machines; this will need to be RPMd if BIRN is responsible for it.
* What look-and-feel of modules in Slicer is required? Do we need special "grid"-type parameters in the execution model, or should we just adhere to "min parameter", "max parameter", "step" notion?
** Can we handle configuration of either tool out of band from Slicer?
** Can we handle monitoring out of band from Slicer?

Until now, we have been content with infrastructure development: developing tools to perform generic batch processing. But it's becoming clear that we can't really make much more progress (aside from just improving the tools but not deploying them) without concrete goals.

Slicer Grid Computing

2007-06-27T15:09:57Z

NeilJones:

== Items discussed ==

* Stephen Aylward (KitWare) presented BatchMake interface to Condor
* Neil Jones (BIRN) presented (briefly) GridWizard

== Where we are ==

Both BatchMake and GridWizard have (partially working) demos of launching multiple processes on remote machines. However, there's still a lack of clarity of exactly what it is that the Slicer community needs. To that end, it's worth figuring out the answers to a few questions:

* What is the main community we should target? Core 1, 2, or 3?
* What are two specific use cases of a Slicer user interacting with batch processing facilities through Slicer? Where does data come from, where does it need to end up?
* What are two specific use cases of a NAMIC user interacting with batch processing facilities, perhaps outside of Slicer?
* Stephen (Aylward) presented a soup-to-nuts backend for managing "experiments", data, and displaying metrics computed from images.
** Does this fit in well with the above use cases?
** If it is a requirement, who supports this?
* What look-and-feel of modules in Slicer is required? Do we need special "grid"-type parameters in the execution model, or should we just adhere to "min parameter", "max parameter", "step" notion?
** Can we handle configuration of either tool out of band from Slicer?
** Can we handle monitoring out of band from Slicer?

Until now, we have been content with infrastructure development: developing tools to perform generic batch processing. But it's becoming clear that we can't really make much more progress (aside from just improving the tools but not deploying them) without concrete goals.

Engineering:TCON 2007

2007-04-19T19:27:07Z

NeilJones: /* 2007-04-19 */

Back to [[TCON:Main|TCON:Main]]

==2007-05-03 ==
Agenda:
*Summer Project Week Kickoff

==2007-04-26 ==
Agenda:

==2007-04-19 ==
Agenda:
* http://www.na-mic.org/Bug/view.php?id=38 A bug in TIFF IO. Given a high-priority rating by Ron. Volunteer needed.
* There is an emerging slate of bioinformatics platforms for research: BIRN, XNAT, CaBig, I2B2 etc. Slicer3 will need to work with these environments.
** We are already working with BIRN on [http://www.xnat.org XNAT], [http://www.nbirn.net/downloads/index.shtm HID], and [http://www.nbirn.net/downloads/xcede/index.shtm XCEDE]
** What kind of additional interactions should we attempt for the near term?
** What kind of functional behaviour is realistic, given resources available?
** Does [[media:Slicer3-Architecture.jpg | this diagram]] accurately reflect our approach?
* NITRC Administrative Supplements available (Steve)
** See announcement [http://grants.nih.gov/grants/guide/notice-files/NOT-EB-07-002.html]
** Dave Kennedy plays a major role in the program
** Applications are accepted any time, but there's a review coming up so getting proposals in by May 15th is a good idea
** These supplements can support documentation and integration of tools into the NITRC (Neuroimaging Informatics Tools and Resources Clearinghouse)
** NITRC is based to some extent on [http://gforge.org/ gforge].
** Goal is for "modifying, documenting, and otherwise making more adoptable, interoperable, and usable existing neuroimaging informatics tools and resources."
* Patching vtkImageReslice in Slicer-2-6 VTK, also do we want a Slicer-2-7 branch of VTK/ITK?

Attendees: Jim, Steve, Ron, Jeff, Nicole, Will, Stephen, Neil

* TIFF Bug: Jim will ask one of his people to look into the TIFF bug.
*

==2007-04-12 ==
Agenda:
*Slicer2 RuleBasedSegmentation Module (for the DLPFC semi-automatic segmentation)
*Further discussion of large scale experiment control (Dan, Steve, Sebastien)
*Process for annual report (Tina, Jim)
*Collaboration grant updates
*fBIRN / BIRN informatics update (Steve)

Attendees: Jim, Dan, Sebastien, Brad, Tina, Vince, John, Ramsey, Nicole, Stephen, Jeff
Notes:
* (Pre meeting discussion of sunspots)
* Rule-Based Segmentation Module
** Marek would like to use it for his data
** GATech provided info on work so far, Brad has reviewed
** VTK/ITK implementation issues that can be easily resolved
** Slicer2 module needs to be integrated with actual filter
** Delphine and Ramsey wrote the interface and filters based on Jim Fallon's rules
** Slicer2 implementation relies on subvolume and draw capabilities (discussion of slicer3 implementation).
*** possible new subvolume selector to add to slicer3
*** could use new editor in slicer3 for ROI
*** also need some kind of wizard or detailed instructions to help guide
*** then the rule based code could be a command line module
** GATech is planning to do a project with Jim Fallon using the Slicer
** At project week we can look at getting Marek up to speed on Slicer2 and the engineering group can work on a slicer3 implementation.
* Issue with NAMICSandBox ability to commit? John may be specific to John.
* Update on Neil's work on the GWiz (Grid Wizard) and discussions with Jeff and Steve at fBIRN meeting
* Stephen update
** Starting to do 'batchboard' tests on bspline registration
** planning public face for registration optimized methods
** integration of BatchMake and CMake for running tests on multiple platforms
* Sebastien is doing timing tests on various machines at BWH
** ITK timer class does the clocking (wall clock timing) but could look at performance timers at the processor API (build in the CPU).
** Process priority is set high to get best guess of fastest behavior
** may need an administrative approach to avoid multiple jobs running during night performance tests
** new features being added to cmake/ctest/batchmake to help determine machine environment, could be extended
* Progress report mechanics
** The report describes just the current year (not the cumulative sum of all the years).
** Tina is going to send email about the themes for the progress report
** Need to be sure the pdf has clickable URLs for wiki page entries
** Discussion of Impact for the highlights section
*** non-na-mic people at the programmer events and AHM
* Update on XCEDE work at fBIRN AHM

==2007-04-05 ==
Agenda:
*Collaboration proposal Peter Y.

Minutes:

* Attendees: Peter, Dan, Jim, Katie, Steve, Wendy, Nicole, Vince, Tina, Will, Sebastien, Stephen, Brad

Discussion of Peter Yim's plans for disseminating algorithms through the NA-MIC Kit.
* Biomedical Engineering, UNC, NIH
* Algorithms for MRA, vessel reconstruction
** Segmentation, skeletonization
** University of Medicine and Dentistry of NJ
** Vascular diagnostics, quantifying angiogenesis, stroke...
* Algorithms could be valuable, but aren't written in a way that can be disseminated (written in C for IRIS Explorer)
** Peter needs to have collaborators to re-write the code
** Peter can provide the clinical background and potential user community
* Could be good candidates for integration into ITK
** Need to review what it means for the NIH patented technology to be deployed
** Some of the algorithms require close interaction and others are more automated
* Discussion of the possible allocations of effort and collaboration

* Discussion of [[Slicer3:Large scale experiment control brainstorming]]

==2007-03-29 ==

Agenda:
* DBPII: Marek (harvard), Csaba (JHU)
* [[2007_Annual_Scientific_Report|Progress Report]]:the folks who lead the sections last time are invited to do the same again this year
* [[Slicer3:MiniRetreat March 29, 30, 2007 | Slicer Mini-retreat (ongoing)]] - Jim and Dan at 1249

Highlights:

Attendees: Will, Jim, Wendy, Csaba, Marek, Nicole, Katie, Dan, Steve, Sebastien, Brad, Ron, Tina
*Marek - vcsf data on 5 patients. familiar with software and algorithms available in na-mic. segmentation and fine tuning of algorithms is needed in slicer. Would like to use GeorgiaTech algorithm for automated segmentation of DLPFC.
*Csaba putting details of JHU project on wiki. Will schedule himself into the tcon in about 4 weeks.

==2007-03-22 ==

Agenda:

*Progress Reports - the folks who lead the sections last time will be invited to do the same again this year, or to nominate someone else who they will help.
*DBP-II - algorithms contacts added by Ross. (UNC: Guido, Harvard: Polina, MIND: Bruce Fischl, JHU: Allen)
*Invitation sent to [[DBP2]] for this call, with the following agenda suggestion:
**Notes: Marek has conflict on 3/22 and will attend 3/29 tcon.
**reminder that he would like your pages to be updated in March. Example of an updated page is: http://www.na-mic.org/Wiki/index.php/DBP2:MIND
**introducing you to your namic engineering contact points and the role they will be playing. (we expect to introduce you to your namic algorithms core contact points at a later point as well).
**summer project week at MIT (June 25-29). Ron's expectation is that by then (1) you will have identified a problem that can be solved with the na-mic kit in a 6-month timeframe and the results for which you will use in your work, (2) you will send an engineer and data to this project week, and the engineer will be able to articulate to the larger group what the problem is, and use that week to work on it with the na-mic team.

Jim has notes and attendees to add.

==2007-03-15 ==

Agenda:

* Heads up: [[2007_Annual_Scientific_Report|2007 Progress Report]]. Recommendations needed from Ron on section/theme leads.
* Dissemination and Outreach for the rest of us (Will, Tina)
* [[DBP2]] Points of Contact (DBP, Engineering, Algorithm). Need contact information for DBP2s. Algorithm contact points still need to be added. (Update: email sent to Ross 3/1 and 3/15 with request to provide names in march.)
* Performance analysis tools and strategies: [[ITK_Registration_Optimization]], [[Slicer3:Performance_Analysis]] (Steve Pieper, Sebastian Barre, Stephen Aylward, Katie Hayes)
* Slicer release schedule (Steve)

*'''Question''' from Douglas Alan: At the January NA-MIC All Hands meeting in SLC, Mike Halle and I met with Bill Lorensen and Jim Miller to discuss how in Slicer we might pass a FITS world coordinate system transform (and its inverse) from an ITK FITS image reader to the resulting Slicer VTK image so that Slicer can then be enhanced to use the transform to properly display the world coordinates. The proposed solution was for me to define a subclass of itk::Transform (i.e., FITSWCSTransform) that would handle the WCS transform, and once I had completed this (which I have) for me to then modify my FITSImageIO reader so as to include a pointer to a FITSWCSTransform object in the FITSImageIO's MetaDataDictionary. As it turns out, there seems to be a snafu with this plan: the MetaDataDictionary of an ITK image appears to be stripped from the image whenever it passes through an ITK filter. Or so it is the case, at least, for the filters that I have tried. Any ideas on how we should proceed, in light of this?

Notes:

Attendees: Jim, Steve, Will, Katie, Nicole, Raymundo, Stephen, Sebastien, Wendy, Tina, Jeff

* Schedule for the progress report in on the wiki. Last year's report is also available. Assignments are imminent.
* Need to update the NA-MIC web presence. ''Wiki to web'' will be used to author and publish the content. Ron will set the vision for the web presence statement (DBP focus? Theme focus? Core focus?). Everyone is responsible ensuring all NA-MIC activities and contributions are advertised.
* Tina will get the contact info for the DBP2's
* Stephen is pulling together a test application to run across systems to evaluate registration performance.
** Note that only one optimizer is relevent to B-Spline registration (LBFGS-B?)
** Torsten has a hierarchical B-Spline algorithm that Killian uses as the yardstick.
** Brad developing proposal to evaluate EM pipeline soup-to-nuts for sources of errors.
* Steve and Katie looking at Callgrind and Callgrind Control to track the overhead of observers and potentially the over-calling of callbacks.
* Tracker performance okay but the images update slowly
* Slicer3 release at the end of March
** DTI tools availability gated by MICCAI deadline
** Launchers work with getbuildtest but may have impacted CPack installations.
** ModelMaker needs MRML read/write (Jim!)
** Filebrowser will be available
** Any features to suppress?
** Any additional documentation needed?
* Slicer 2.7 release at the end of March
** Mostly bug fixes but a few new features
* Jim will talk to Mike about the FITS needs for the MetaDataDictionary and the pipeline.

==2007-03-08 ==

Agenda:

* Question from Steve: best way to handle "neurological" analyze files (where right-is-right unlike radiological files where "left -is-right"). The [http://www.oasis-brains.org oaisis brains] data collection from mBIRN stores their data this way and the ITK IO factory doesn't have a way to know which kind of file these are.
* [[Slicer3::Python | Python in Slicer]] - project overview: Dan
* Google Summer of Code - are there any project takers?

Notes:
* Update - it turns out oasis-brains.org analyze files are stored in radiological convention but displayed in neurological convention, so everything is as 'correct' as it can be for this file format. But the ambiguity remains about the real meaning of analyze files, so in the future oasis will supply nifti formated files.

==2007-03-01 ==

Agenda:
* Adding Engr+Algorithms core representatives to each DBP-II team: [[DBP2:MIND]]
* [http://code.google.com/soc/ Google Summer of Code]
* [http://nifti.nimh.nih.gov/dfwg/internal/wiki/sifti_home/ SIfTI] effort to standardize spatial transform files. (login info will be given on the phone)
* Technical Slicer3 item: command line executables

Notes:
* Eng contacts for DBP-II:
** Katie Hayes for the JHU project
** Jim Miller for UNC
** Brad Davis for Harvard (Confirmed)
** Steve Pieper for MIND
* Summer of Code
** Generally agreed to be a good idea if there's time
** Check with Luis
* SIfTI
* Command Line Interface to EMSegmenter
** Jim will work on making MRML scenes come as arguments to command line modules and give an example that can be used for EMSegmenter and other projects like the ModelMaker.

==2007-02-22 ==

Attendees: Wendy, Jim, Nicole, Dan, Andy, Katie, Tina, Ron

Highlights:
* match dbp-IIs to engineering core members (Jim and Tina to do offline)
* contact dpbs regarding participation in project week (Tina)

== 2007-02-15 ==

Agenda:

Attendees: Jim, Nicole, Tina, Katie, Jags

== 2007-02-08 ==

Agenda:
*Please note that we now use a new TCON#. If you don't have it, please send an email to namic-eng@na-mic.org.
*Review remaining [[2007_Project_Half_Week#Projects|Project Half-Week Updates]]

== 2007-02-01 ==

Agenda:
*First call with Jim's tcon # (was emailed to participants)
*Review [[2007_Project_Half_Week#Projects|Project Half-Week Updates]]

== 2007-01-25 ==

Attendees: Bill, Jim, Steve, Wendy, Nicole, Katie, Brad, Andy & Jags

Agenda:
*Last call with Bill as the PI...
*Next TCON (Feb 1) to review 4-block from project half week. Will use Jim's tcon #.

Highlights:
*New phone number for TCON next week; email Jim for the number
*Problem with region growing?
*Bye, Bill! We'll see you in three weeks when you get bored with retirement.

== 2007-01-18 ==
Attendees: Bill, Tina, Steve, Katie, Sebastien, Zack, Jags

* Slicer3 release schedule discussion
* Which teem are we on?
* Status of filebrowser?
** Current unix browser does not allow for making a new directory
** Does the new one support specifying a list of file types? (Yes)
* Feb 1/8 for project half-week results 4-blocks review?

Highlights:
*Feb 1 and 8 for project half-week results 4-blocks review
*12 days till Bill's retirement...
*OHMB workshop agenda info by Steve: DTI tutorial for Slicer3 is a candidate topic.

== 2007-01-11 ==

No tcon this week. [[AHM_2007]] in progress.

== 2007-01-04 ==

Agenda and Highlights:
* [[2007_Project_Half_Week|Project Half-Week Activities]] - Focus on Slicer3 Projects. And any others that need resolution of title/team. 4-blocks should appear asap. Each project lead will use these to introduce their project on Wednesday, Jan 10th.
* There are pages in google cache that are not yet on the namic-wiki. What is the process for pulling those in? Should each person who finds a page just cut and paste the text as best as they can? How should we use the "wanted pages" list on the wiki?

Highlights:
*Slicer3 Projects have been added to the wiki.
*Wanted page list is being pared down as a high priority item,.
*Jim and Bill will be on Daniel Goldberg's project half week project.

Attendees: Bill, Will, Ron, Steve, Jim, Stephen, Neil, Andy, Luis, Nicole, Katie, Wendy, Jags, Tina

SlicerOnBIRN

2007-04-19T16:11:03Z

NeilJones: /* Running Slicer (2) on Data */

=Introduction=
NA-MIC uses the BIRN infrastructure to store some data sets provided by Core 3. Some of those data sets are only for internal use by NA-MIC participants. There are also data sets that are available for anybody to use in their research. This page explains how to

* get an account for BIRN
** if you are a NA-MIC participant
** if you are not a NA-MIC participant
* find NA-MIC data on portal
* find available non-NA-MIC data on the portal
* launch Slicer from the portal to view the data

=Getting a BIRN Portal Account=

[[image:portal-main.png|150px|thumb|Portal Main page]]

Visit the BIRN Portal, and click the tab labelled "Request an account". Fill out the appropriate information. Your account application will be reviewed by a human and verified. When your account has been accepted, you will be emailed an "activation link". Click on this link to view the portal as a registered user. The entire process usually takes less than a day. When logged in, you should be taken to the "My Space" page, which represents all of the projects that you have access to.

[[image:portal-logged-in.png|150px|thumb|Logged in to the BIRN Portal]]

=Getting access to NAMIC data=

NAMIC data is stored as part of the "NAMIC" project within the BIRN Portal. In order to get access to the data, you need to be a member of the NAMIC project. If NAMIC is listed in your projects from your "My Space" page, you need to take no further action. If it is not listed, you simply need to join.

Visit the overall BIRN Projects page by clicking the "Projects" link in the "Collaboration" tab's submenu.

[[image:projects-tab.png|150px|thumb|BIRN Portal projects page]]

Search for the NAMIC project---the easiest approach is to hit ^F or Cmd-F (Mac) and type NAMIC.

[[image:namic-project.png|150px|thumb|NAMIC Project entry]]

On the right hand side is a column "Membership?". Click the "Request" link. You will receive an email stating that you have requested membership into the project.

[[image:membership-request.png|150px|thumb|Requesting admission to the NAMIC project]]

When the project administrator has viewed your request and approved you, you will receive an email that you have been accepted into the project. Visiting the portal will allow you to complete the cycle, by clicking the "Accept" link.

[[image:membership-request-accepted.png|150px|thumb|Accepted into the NAMIC project]]

=Searching NAMIC data=

From the "My Space" section, click on the NAMIC project in your "Projects Overview" tab.
[[image:namic-project-space.png|150px|thumb|NAMIC Project space]]

Select "SRB Project Folders". From here, either browse for specific data (if you know what you're looking for) or search by meta data.

[[image:namic-file-space.png|150px|thumb|SRB File Space for NAMIC project]]

Use the MetaDataUtils to search for files of a particular type. Select the "search" icon [[image:Search-icon.png]]. Search on any of the following fields.

DataStatus \in (1---meaning?)

Institution (obvious)

ScannerField <=> field strength, in Tesla

ScannerManufacturer (obvious)

ScannerModel (one of Echospeed...)

ScannerScanType (DTI (others?))

SubjectDiagnosis (one of Unknown...)

SubjectGroup (One of Unknown...)

=Searching for non-NAMIC Data=

From the Data Management tab, simply visit the project home directory of whatever project you are interested in. If the data is public, you will be able to view it. If the data is not public (and you don't see it), please request access to that project using similar steps to above. You can search for data using the metadata search utilities described above.

=Running Slicer (2) on Data=

# Open the Data Management page, either by logging in and selecting the appropriate Tab, or by jumping straight to the NAMIC project's SRB directory
# Navigate to a DICOM file
# Choose the launcher tool ([[image:rocket.jpg|50px]]) in the upper right
# Select the radio button on the right hand side next to the appropriate file
# Agree to any of the security-related pop-ups
# The GridLauncher dialog will pop up; verify the settings
# Click "Launch", and slicer-2 will run and preload the data

[[image:Slicer-launch.png|150px|thumb|Portal launcher tool]]

[[image:Slicer-launched.png|150px|thumb|GridLauncher running on local PC preparing to run Slicer 2]]

Launching of Slicer 3 will be added to the portal soon.

File:Slicer-launched.png

2007-04-19T16:09:53Z

NeilJones:

File:Slicer-launch.png

2007-04-19T16:09:37Z

NeilJones:

SlicerOnBIRN

2007-04-19T16:09:14Z

NeilJones:

=Introduction=
NA-MIC uses the BIRN infrastructure to store some data sets provided by Core 3. Some of those data sets are only for internal use by NA-MIC participants. There are also data sets that are available for anybody to use in their research. This page explains how to

* get an account for BIRN
** if you are a NA-MIC participant
** if you are not a NA-MIC participant
* find NA-MIC data on portal
* find available non-NA-MIC data on the portal
* launch Slicer from the portal to view the data

=Getting a BIRN Portal Account=

[[image:portal-main.png|150px|thumb|Portal Main page]]

Visit the BIRN Portal, and click the tab labelled "Request an account". Fill out the appropriate information. Your account application will be reviewed by a human and verified. When your account has been accepted, you will be emailed an "activation link". Click on this link to view the portal as a registered user. The entire process usually takes less than a day. When logged in, you should be taken to the "My Space" page, which represents all of the projects that you have access to.

[[image:portal-logged-in.png|150px|thumb|Logged in to the BIRN Portal]]

=Getting access to NAMIC data=

NAMIC data is stored as part of the "NAMIC" project within the BIRN Portal. In order to get access to the data, you need to be a member of the NAMIC project. If NAMIC is listed in your projects from your "My Space" page, you need to take no further action. If it is not listed, you simply need to join.

Visit the overall BIRN Projects page by clicking the "Projects" link in the "Collaboration" tab's submenu.

[[image:projects-tab.png|150px|thumb|BIRN Portal projects page]]

Search for the NAMIC project---the easiest approach is to hit ^F or Cmd-F (Mac) and type NAMIC.

[[image:namic-project.png|150px|thumb|NAMIC Project entry]]

On the right hand side is a column "Membership?". Click the "Request" link. You will receive an email stating that you have requested membership into the project.

[[image:membership-request.png|150px|thumb|Requesting admission to the NAMIC project]]

When the project administrator has viewed your request and approved you, you will receive an email that you have been accepted into the project. Visiting the portal will allow you to complete the cycle, by clicking the "Accept" link.

[[image:membership-request-accepted.png|150px|thumb|Accepted into the NAMIC project]]

=Searching NAMIC data=

From the "My Space" section, click on the NAMIC project in your "Projects Overview" tab.
[[image:namic-project-space.png|150px|thumb|NAMIC Project space]]

Select "SRB Project Folders". From here, either browse for specific data (if you know what you're looking for) or search by meta data.

[[image:namic-file-space.png|150px|thumb|SRB File Space for NAMIC project]]

Use the MetaDataUtils to search for files of a particular type. Select the "search" icon [[image:Search-icon.png]]. Search on any of the following fields.

DataStatus \in (1---meaning?)

Institution (obvious)

ScannerField <=> field strength, in Tesla

ScannerManufacturer (obvious)

ScannerModel (one of Echospeed...)

ScannerScanType (DTI (others?))

SubjectDiagnosis (one of Unknown...)

SubjectGroup (One of Unknown...)

=Searching for non-NAMIC Data=

From the Data Management tab, simply visit the project home directory of whatever project you are interested in. If the data is public, you will be able to view it. If the data is not public (and you don't see it), please request access to that project using similar steps to above. You can search for data using the metadata search utilities described above.

=Running Slicer (2) on Data=

# Open the Data Management page, either by logging in and selecting the appropriate Tab, or by jumping straight to the NAMIC project's SRB directory
# Navigate to a DICOM file
# Choose the launcher tool ([[image:rocket.jpg|50px]]) in the upper right
# Select the radio button on the right hand side next to the appropriate file
# Agree to any of the security-related pop-ups
# The GridLauncher dialog will pop up; verify the settings
# Click go, and slicer-2 will launch

[[image:Slicer-launch.png|150px|thumb|Portal launcher tool]]

[[image:Slicer-launched.png|150px|thumb|GridLauncher running on local PC preparing to run Slicer 2]]

Launching of Slicer 3 will be added to the portal soon.

SlicerOnBIRN

2007-04-19T16:04:56Z

NeilJones: /* Running Slicer (2) on Data */

=Introduction=
NA-MIC uses the BIRN infrastructure to store some data sets provided by Core 3. Some of those data sets are only for internal use by NA-MIC participants. There are also data sets that are available for anybody to use in their research. This page explains how to

* get an account for BIRN
** if you are a NA-MIC participant
** if you are not a NA-MIC participant
* find NA-MIC data on portal
* find available non-NA-MIC data on the portal
* launch Slicer from the portal to view the data

=Getting a BIRN Portal Account=

[[image:portal-main.png|150px|thumb|Portal Main page]]

Visit the BIRN Portal, and click the tab labelled "Request an account". Fill out the appropriate information. Your account application will be reviewed by a human and verified. When your account has been accepted, you will be emailed an "activation link". Click on this link to view the portal as a registered user. The entire process usually takes less than a day. When logged in, you should be taken to the "My Space" page, which represents all of the projects that you have access to.

[[image:portal-logged-in.png|150px|thumb|Logged in to the BIRN Portal]]

=Getting access to NAMIC data=

NAMIC data is stored as part of the "NAMIC" project within the BIRN Portal. In order to get access to the data, you need to be a member of the NAMIC project. If NAMIC is listed in your projects from your "My Space" page, you need to take no further action. If it is not listed, you simply need to join.

Visit the overall BIRN Projects page by clicking the "Projects" link in the "Collaboration" tab's submenu.

[[image:projects-tab.png|150px|thumb|BIRN Portal projects page]]

Search for the NAMIC project---the easiest approach is to hit ^F or Cmd-F (Mac) and type NAMIC.

[[image:namic-project.png|150px|thumb|NAMIC Project entry]]

On the right hand side is a column "Membership?". Click the "Request" link. You will receive an email stating that you have requested membership into the project.

[[image:membership-request.png|150px|thumb|Requesting admission to the NAMIC project]]

When the project administrator has viewed your request and approved you, you will receive an email that you have been accepted into the project. Visiting the portal will allow you to complete the cycle, by clicking the "Accept" link.

[[image:membership-request-accepted.png|150px|thumb|Accepted into the NAMIC project]]

=Searching NAMIC data=

From the "My Space" section, click on the NAMIC project in your "Projects Overview" tab.
[[image:namic-project-space.png|150px|thumb|NAMIC Project space]]

Select "SRB Project Folders". From here, either browse for specific data (if you know what you're looking for) or search by meta data.

[[image:namic-file-space.png|150px|thumb|SRB File Space for NAMIC project]]

Use the MetaDataUtils to search for files of a particular type. Select the "search" icon [[image:Search-icon.png]]. Search on any of the following fields.

DataStatus \in (1---meaning?)

Institution (obvious)

ScannerField <=> field strength, in Tesla

ScannerManufacturer (obvious)

ScannerModel (one of Echospeed...)

ScannerScanType (DTI (others?))

SubjectDiagnosis (one of Unknown...)

SubjectGroup (One of Unknown...)

=Searching for non-NAMIC Data=

From the Data Management tab, simply visit the project home directory of whatever project you are interested in. If the data is public, you will be able to view it. If the data is not public (and you don't see it), please request access to that project using similar steps to above. You can search for data using the metadata search utilities described above.

=Running Slicer (2) on Data=

# Open the Data Management page, either by logging in and selecting the appropriate Tab, or by jumping straight to the NAMIC project's SRB directory
# Navigate to a DICOM file
# Choose the launcher tool ([[image:rocket.jpg|50px]]) in the upper right
# Select the radio button on the right hand side next to the appropriate file
# Agree to any of the security-related pop-ups
# The GridLauncher dialog will pop up; verify the settings
# Click go, and slicer-2 will launch

Launching of Slicer 3 will be added to the portal soon.

SlicerOnBIRN

2007-04-19T16:04:14Z

NeilJones:

=Introduction=
NA-MIC uses the BIRN infrastructure to store some data sets provided by Core 3. Some of those data sets are only for internal use by NA-MIC participants. There are also data sets that are available for anybody to use in their research. This page explains how to

* get an account for BIRN
** if you are a NA-MIC participant
** if you are not a NA-MIC participant
* find NA-MIC data on portal
* find available non-NA-MIC data on the portal
* launch Slicer from the portal to view the data

=Getting a BIRN Portal Account=

[[image:portal-main.png|150px|thumb|Portal Main page]]

Visit the BIRN Portal, and click the tab labelled "Request an account". Fill out the appropriate information. Your account application will be reviewed by a human and verified. When your account has been accepted, you will be emailed an "activation link". Click on this link to view the portal as a registered user. The entire process usually takes less than a day. When logged in, you should be taken to the "My Space" page, which represents all of the projects that you have access to.

[[image:portal-logged-in.png|150px|thumb|Logged in to the BIRN Portal]]

=Getting access to NAMIC data=

NAMIC data is stored as part of the "NAMIC" project within the BIRN Portal. In order to get access to the data, you need to be a member of the NAMIC project. If NAMIC is listed in your projects from your "My Space" page, you need to take no further action. If it is not listed, you simply need to join.

Visit the overall BIRN Projects page by clicking the "Projects" link in the "Collaboration" tab's submenu.

[[image:projects-tab.png|150px|thumb|BIRN Portal projects page]]

Search for the NAMIC project---the easiest approach is to hit ^F or Cmd-F (Mac) and type NAMIC.

[[image:namic-project.png|150px|thumb|NAMIC Project entry]]

On the right hand side is a column "Membership?". Click the "Request" link. You will receive an email stating that you have requested membership into the project.

[[image:membership-request.png|150px|thumb|Requesting admission to the NAMIC project]]

When the project administrator has viewed your request and approved you, you will receive an email that you have been accepted into the project. Visiting the portal will allow you to complete the cycle, by clicking the "Accept" link.

[[image:membership-request-accepted.png|150px|thumb|Accepted into the NAMIC project]]

=Searching NAMIC data=

From the "My Space" section, click on the NAMIC project in your "Projects Overview" tab.
[[image:namic-project-space.png|150px|thumb|NAMIC Project space]]

Select "SRB Project Folders". From here, either browse for specific data (if you know what you're looking for) or search by meta data.

[[image:namic-file-space.png|150px|thumb|SRB File Space for NAMIC project]]

Use the MetaDataUtils to search for files of a particular type. Select the "search" icon [[image:Search-icon.png]]. Search on any of the following fields.

DataStatus \in (1---meaning?)

Institution (obvious)

ScannerField <=> field strength, in Tesla

ScannerManufacturer (obvious)

ScannerModel (one of Echospeed...)

ScannerScanType (DTI (others?))

SubjectDiagnosis (one of Unknown...)

SubjectGroup (One of Unknown...)

=Searching for non-NAMIC Data=

From the Data Management tab, simply visit the project home directory of whatever project you are interested in. If the data is public, you will be able to view it. If the data is not public (and you don't see it), please request access to that project using similar steps to above. You can search for data using the metadata search utilities described above.

=Running Slicer (2) on Data=

# Open the Data Management page, either by logging in and selecting the appropriate Tab, or by jumping straight to the NAMIC project's SRB directory
# Navigate to a DICOM file
# Choose the launcher tool ([[image:rocket.jpg|75px]])
) in the upper right
# Select the radio button on the right hand side next to the appropriate file
# Agree to any of the security-related pop-ups
# The GridLauncher dialog will pop up; verify the settings

Launching of Slicer 3 will be added to the portal soon.

File:Rocket.jpg

2007-04-19T16:03:32Z

NeilJones:

SlicerOnBIRN

2007-04-19T16:03:14Z

2007-04-16T18:02:02Z

NeilJones: BIRN Portal front page

BIRN Portal front page

2007-01-02T20:09:00Z

NeilJones:

'''Project'''<nowiki>: Integration of NAMIC Kit and the 'Grid' </nowiki>

'''Goals'''<nowiki>: </nowiki>

* Provide a tool for the NA-MIC kit to enable distributed execution of programs
* Supply interfaces to these tools via [[Slicer3:Execution_Model|Slicer3:Execution_Model]]
* Identify constraints and requirements for Slicer3 for cluster-based execution

'''Current Status'''<nowiki>: </nowiki>

* Tool (GridWizard) currently under development
* CLRegistration is considered a key use case for Grid computation for the NA-MIC kit
* Exact changes to [[Slicer3:Execution_Model|Slicer3:Execution_Model]] are under consideration
* Shown below is one proposal
* Another proposal is to use the <channel> element (in, out, inout)
* Lists and file globs may cause some problems in the Slicer3 display

'''Example of Grid Interface XML Awareness'''<nowiki>: >./gi-init -xml </nowiki>

<?xml version="1.0" encoding="utf-8"?>
<executable>
<category>execution environment</category>
<title>Slicer3 Grid Interface</title>
<description>Launches executables in a grid environment</description>
<version>1.0</version>
<documentationurl></documentationurl>
<license></license>
<contributor>Brendan Faherty</contributor>

<parameters>
<label>Grid Interface Parameters</label>
<description></description>

<flag>
<flag>-i</flag>
<description>Use to pass XML instructions through STDIN</description>
<label>XML STDIN</label>
</flag>

<file>
<flag>-f</flag>
<descriptions>use to pass XML instructuions through a file</description>
<label>XML File</label>
</file>
</executable>

The XML file that might be referenced via "gi-init -f JOB.xml" >cat CLRegistration.xml

<?xml version="1.0" encoding="utf-8"?>
<executable>
<executable>CLRegistration</executable>
<path>/path/to/CLRegistration</path>

<parameters>
<integer>
<flag>b</flag>
<value>30</value>
</integer>

<integer>
<flag>s</flag>
<value>10000</value>
</integer>

<string>
<flag>i</flag>
<longflag>iterations</longflag>
<value>200,100</value>
</string>

<string>
<flag>l</flag>
<value>0.05,0.005</value>
</string>

<double>
<flag>t</flag>
<value>100.0</value>
</double>

<file>
{! -- will be passed as "-Fixed Image1" --}
<flag>-Fixed</flag>
<name>Image1</name>
<protocol>srb</protocol>
<path>/home/Projects/NAMIC_0003/Files/Havard/active_morph/HUV109121/images/</path>
<transfer>singleton</transfer>
</file>

<file>
{! -- will be passed as "-Moving Image2" --}
<flag>-Moving</flag>
<name>Image2</name>
<protocol>srb</protocol>
<path>/home/Projects/NAMIC_0003/Files/Havard/active_morph/HUV109121/images/</path>
<transfer>directory_non_recursive</transfer>
</file>

<file>
{! -- will be passed as "-Output Data" --}
<flag>-Output</flag>
<name>Data</name>
<path>/home/Projects/NAMIC__0003/Files/Harvard/archive_morph/HUVA0123123/</path>
<protocol>srb</protocol>
<transfer>directory_recursive</transfer>
</file>
</parameters>

</executable>

'''Team Members'''<nowiki>: </nowiki>

* Jeff Grethe- UCSD
* Neil Jones - UCSD
* Steve Pieper - BWH
* Daniel Blezek - GE