If building ITK 2.0.1 on OS X 10.3, users may see the following errors:

	
InsightToolkit-2.0.1/bin/libitkvnl.dylib...
ld: vnl_math.o illegal reference for -dynamic code (section   
difference reference from section (__TEXT,__eh_frame) relocation   
entry (0) to symbol: ___isnan defined in dylib: /usr/lib/libm.dylib)
/usr/bin/libtool: internal link edit command failed
make[9]: *** [/Users/blah/Code/C++/ITK/InsightToolkit-2.0.1/ 
bin/ libitkvnl.dylib] Error 1.
	

The solution is to either checkout a recent CVS copy of ITK (directions are on the ITK download page), or edit the file: INSIGHT_ROOT/Utilities/vxl/core/vnl/vnl_math.cxx, changing line 62 from:

# define isnan __isnan
to
# define isnan(x) __isnand((double)x)

This simple fix will allow ITK 2.0.1 to compile on OS X.

Nvidia FX class or better and ATI Radeon 9500 or better video cards will work.

An accelerated graphics card driver must also be installed. An accelerated graphics card driver offloads graphics computations to the graphics card hardware and results in faster graphics. Acclerated drivers enable scientific imaging modalities, such as volume rendering, to happen on the graphics card.

A later FAQ shows how to determine the type of graphics card installed.

Accelerated Nvidia drivers can be downloaded from Nvidia's web site.

Accelerated ATI drivers can be downloaded from ATI's web site.

Note that a non-accelerated driver is normally installed in a typical Linux installation. A later FAQ shows how to determine if an accelerated driver is installed.

There are two commands that can be used: lspci and glxinfo. The lspci command can be used to identify the card even when no graphics drivers are installed, but it may not report the exact model of the card correctly.

The glxinfo command will report the exact model of the card installed, but it will only work if the graphics drivers are properly installed and Xwindows is up and running. The glxinfo command must be run from an xterm that is being displayed on the machine's local monitor (it cannot be run from a remote ssh login or from a text-only console).

Here is a sample run of lspci and glxinfo:

$ /sbin/lspci | grep VGA
01:00.0 VGA compatible controller: nVidia Corporation NV35GL [GeForce FX 5900]  
$
$ cat /var/log/XFree86.0.log |grep -i GPU
(II) NVIDIA Unified Driver for all NVIDIA GPUs
(--) Chipset NVIDIA GPU found
(II) NVIDIA(0): NVIDIA GPU detected as: GeForce FX 5900 Ultra
(--) NVIDIA(0): Interlaced video modes are supported on this GPU
$
$ glxinfo |grep renderer
OpenGL renderer string: GeForce FX 5900 Ultra/AGP/SSE
	  

If your card was detected when linux was loaded on the machine, then a section in /etc/X11/XFree86Config, similar to the following, will be found:

Section "Device"
     Identifier  "Videocard0"
     Driver      "nvidia"
     VendorName  "Videocard vendor"
     BoardName   "NVIDIA GeForce 4 (generic)"
EndSection

If there are multiple "Device" sections, look towards the end of the file for a section named "Screen" to determine which "Device" is currently being used.

Please note that there are multiple X11 implementations, and the exact configuration file names, locations and formats may vary slightly depending on your linux distribution. Please see XFree86 and X.org for an up to date description of the configuration files.

Look in /etc/X11/XF86Config or /etc/X11/xorg.conf for a section named “Device”. The accelerated ATI driver is called “fglrx”:

Section "Device"
    ⋮
    Driver      "fglrx"  <== accelerated
    Driver      "radeon" <== non-accelerated
    Driver      "ati"    <== non-accelerated
	  

The Accelerated Nvidia driver is called “nvidia”

Section "Device"
    ⋮
    Driver       "nvidia"  <== accelerated
    Driver       "nv"      <== non-accelerated
	  

Look in /proc/driver/nvidia:

$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA Linux x86 NVIDIA Kernel Module  1.0-5336  Wed Jan 14 18:29:26 PST 2004
	  

Above, the driver version is 5336.

Or, run glxinfo

$ glxinfo | grep version
server glx version string: 1.3
client glx version string: 1.3
OpenGL version string: 1.4.1 NVIDIA 53.36
glu version: 1.3

You need to install the Nvidia OpenGL header files (they don't get installed by default). In order to install the headers, you need to give the --opengl-headers option to the install script, for example:

./NVIDIA-Linux-x86-1.0-6111-pkg1.run --opengl-headers
	  

For more help, type

./NVIDIA-Linux-x86-1.0-6111-pkg1.run -A --help
	  

After installing the Nvidia OpenGL headers, you should find files gl.h, glx.h, glxtokens.h in directory /usr/include/GL. Also check to make sure that those files are the Nvidia versions and not the Mesa version (Mesa is a software-only OpenGL implementation that comes packaged with linux):

$ pwd
/usr/include/GL
$ head gl.h

* Mesa 3-D graphics library
	  

The above output indicates the presence of Mesa headers. Install the Nvidia headers.

$ head gl.h

** Copyright 1998-2002, NVIDIA Corporation.
	  

The above output shows that Nvidia headers are installed.

If in doubt, reinstall the driver. See the previous FAQ entry.

Here are the quantities that we're interested in and the units that they carry:

As for the scales of those units (e.g. centi-, milli-, etc), those are up to the user—SCIRun doesn't actually keep track of them all that well. SCIRun assumes that the dipole source are in amps / meter, that the conductivities are in siemens / meter, that the model geometry is in meters, and it therefore reports its results in volts. If this isn't true (e.g. you know that your model is in mm), then you have to carry those scale factors through your computation (e.g. know that the results you get out are in kv).

The rule of thumb is that if we increase the conductivity, then we decrease the potentials by that same scale factor. Conversely, if we increase the dipole source moment, then we increase the potentials by that same scale factor. i.e. V = I / sigma. Similarly, if we hold everything else constant, but increase the size of the domain, then we decrease the potentials by that same scale factor.

For example, the SCIRun Utah Torso model has a length scale of centimeters (10^(-2) meters) and conductivity units of (siemens / meter), so our output potentials are in hectovolts (10^2 volts).

Try this: Rename ~/.scirunrc to ~/.scirunrc.O. Run SCIRun again. If the problems resolve then merge any changes you made in ~/.scirunrc.O into the new ~/.scirunrc created by SCIRun and delete ~/.scirunrc.O.

SCIRun should be compatible with any SGI machine running Irix 6.5.

SCIRun has been tested on the following Linux distributions: (With past versions we have run on RedHat 7 and 8, and Mandrake 8. While these systems should still work, all local systems have been updated to Redhat 9 and Mandrake 9.2.)

SCIRun has been tested on the following PC processor configurations:

SCIRun has been tested with the following PC graphics cards:

It is important to understand the hierarchy of computational problem solving environments developed at the SCI Institute. From a historical perspective, SCIRun, which started development in 1992, was the original implementation of the computational framework. Since then, SCIRun and its computational workbench infrastructure has been the origin of many significant application-specific projects. Two major examples are the DOE sponsored Uintah system and the NIH sponsored BioPSE system (from the National Center for Research Resources (NCRR) Center at Utah). The target applications of the Uintah project are combustion, computational fluid dynamics, and mechanical modeling implemented on large-scale, distributed, shared memory architectures. The goal of the BioPSE project is to create software for geometric modeling, simulation, and visualization for solving bioelectric field problems. A secondary goal of the SCIRun system is to make source code for problem solving environments publicly available to the scientific community.

To realize these significant projects, the SCIRun infrastructure has required significant reorganization, extension, and enhancement. Even with these changes, SCIRun remains the core infrastructure for problem solving environments, and the name used to refer to the entire ensemble of software. Thus, a user may install and operate the core SCIRun software and also augment its functionality with one or more of the “packages” such as BioPSE. SCI anticipates that the collection of packages will grow as the advantages of the SCIRun infrastructure become available to scientists and engineers of all disciplines.

Figure 1. BioPSE Software System

This figure shows the relationship among SCIRun and its packages. BioPSE consists of the basic SCIRun software together with the BioPSE modules and support libraries.

In addition to major projects that have both leveraged and advanced SCIRun, there exist a number of smaller packages that extend SCIRun's utility. Examples include the Teem package for raster data processing, the NetSolve package for linear algebra subroutines (developed by researchers at the University of Tennessee and Knoxville), and a communications interface recently introduced to the Matlab program. SCI has developed various forms of software wrappers or interfaces that allow SCIRun to leverage the strengths of third party tools, links referred to as "bridges."

There are instances when a tighter level of integration than a bridge between SCIRun and third-party software is necessary. One example is the addition of mpeg support for capturing animations from the SCIRun Viewer module. SCI uses the Berkeley and Alex Knowles' mpeg encoding tools. Another example is the set of image generation and manipulation tools from Paul Haeberli called libimage. To indicate if such tools are available, the configure scripts for SCIRun contain optional control flags.

The combination of a robust infrastructure and modular extensibility through packages and third-party libraries allows SCIRun to grow and adapt to changing needs and opportunities.

“BibTeX” and “plain text” citations can be used. Here are SCIRun and BioPSE citations.

Thank you for the citation(s). Use of SCIRun/BioPSE citations in projects and publications helps ensure the continued funding of the SCIRun/BioPSE project. Please send citations to macleod@sci.utah.edu.

A set of command line utilities, called converters, convert “foreign” data into SCIRun file objects (and vice-versa). See Section Importing and Exporting SCIRun Data in the SCIRun User's Guide for information on the use of converter programs.

See also Appendix A of the BioFEM tutorial for information about getting finite element models imported into BioFEM.

By default, the negative-z axis points down, positive-x points to right, and positive-y points up. If the Axes is turned on, arrows point in +/-{x,y,z}. To remember which is which: (R,G,B) = (X,Y,Z). Arrows pointing in positive directions are brighter than arrows pointing in negative directions. ???One last note, click on the "Views" button at the botton-right of the ViewWindow and snap to a "canonical" view (e.g. "Look down +Z axis, Up vector +Y").???

Currently, everything must be scaled down to the size of unit-axes, by using the Math::BuildTransform and Field::TransformField modules.

SCIRun does not yet (support in being investigated) run on Opteron. SGI Irix is the only supported 64 bit platform.

SCIRun/BioPSE fully supports inhomogeneous, anisotropic conductivities for FEM and FDM simulations; an Nx6 matrix can be built that provides a unique tensor for every element in the domain. See Appendix A of the BioFEM tutorial for more information about getting finite element models imported into BioPSE.

No. There has been discussion about creating a native Windows port of SCIRun, however, SCI has not committed to this project.

This problem appeared with the Mac OSX 10.3.2 system update. To fix this problem, manually edit line 54 of file SCIRun/src/scripts/program.mk, inserting "-bind_at_load" after "$(CXX)". Then remove the SCIRun executable and type gmake.

This problem has been resolved in SCIRun release 1.20.2.

The difference between these modules is that the ApplyFEMCurrrentSource module is used to apply Neumann boundary conditions; known values related to the first spatial derivative of the potential, (e.g. flux, current density, dipoles).

The ApplyFEMVoltageSource module is used to apply Dirichlet boundary conditions; known values for the potential at specific locations. In both cases, boundary conditions affect the right side of the linear system, which is why both modules take an optional RHS ColumnMatrix as input, and produce a modified RHS ColumnMatrix as output. In the case of a Dirichlet BC, the stiffness matrix must also be modified, which is why ApplyFEMVoltageSource requires the stiffness matrix as input, and produces a modified stiffness matrix as output.

Typically, ApplyFEMCurrentSource takes two Fields as input: a TetVolField that specifies the geometry and conductivity information for the volume (e.g. brain-eg-mesh.tvt.fld), and a collection of dipole sources (PointCloudField<Vector>).

In contrast, the ApplyFEMVoltageSource applies Dirichlet condition at location in the mesh where potentials are known. Unlike the ApplyFEMCurrentSource, the ApplyFEMVoltageSource requires a second upstream module. Specifically, an InsertVoltageSource module is required. The user passes the TetvolField of conductivity (e.g. brain-eg-mesh.tvt.fld) into the first Field input port of InsertVoltageSource, and a PointCloudField<double> specifying the positions and voltages of the known potentials into the second Field input port. The module identifies which nodes of the mesh the Dirichlet conditions will be applied, and stores that information with the output TetvolField. The output TetVolField, which now has the Dirichlet BC information stored as a Property of the field, is passed into the first input port of ApplyFEMVoltageSource.

One feature of SCIRun/BioPSE is that it dynamically compiles some parts of the code at run-time based on the data passed through the network. If installed from an RPM (and unless instructed otherwise) SCIRun will try to generate code in /usr/local/SCIRun/linux/on-the-fly-libs/. SCIRun won't (usually) have privilages to write to this directory. The issue is fixed by creating a directory in your home directory, and setting the SCIRUN_ON_THE_FLY_LIBS environment variable to point to the new directory. For example:

  mkdir /home/dmw/on-the-fly-libs/
  setenv SCIRUN_ON_THE_FLY_LIBS /home/dmw/on-the-fly-libs/
	

SCIRun must be restarted to effect these changes.

Problems with the 4191 Nvidia drivers cause GL programs to misbehave. There has been success using the 3xxx Drivers (except 3D texturing). Determine what drivers are being used on the linux box by typing "rpm -qa grep NVIDIA".

In order for alpha to be applied, the downstream module needs to have the "Enable Transparency" box selected under the "Faces" tab.

No.

Yes. The ShowSlices module will display orthogonal slices of a 3D nrrd in a 2D OpenGL window.

One of the features of SCIRun/BioPSE is that it dynamically compiles some parts of the code at run-time based on the data that you're passing through your network. In order for this to work, the software needs to be able to dynamically create files. However, because you have installed the software from RPM, the directory that the dynamic files are wrtten to by default, /usr/local/SCIRun/linux/on-the-fly-libs/, is owned by root—which is why the program is having problems. You can fix this by creating a different directory that you own, and setting your SCIRUN_ON_THE_FLY_LIBS environment variable to point at that new directory. This environment variable overrides the default location, so that should fix the problem you're having. For example:

	    mkdir /home/dmw/on-the-fly-libs/
	    setenv SCIRUN_ON_THE_FLY_LIBS /home/dmw/on-the-fly-libs/
	

Add the following line to the end of the net file:

	  $m1-c needexecute 
	

Adding the above line causes the execution of module $m1, plus the execution of all of modules that $m1 depends on, and the execution of all modules that depend on $m1.

There are problems with the 4191 Nvidia drivers, causing GL programs to behave badly. There has been success using the 3123 drivers (except for 3D texturing). Determine what drivers are being used on the linux box by typing "rpm -qa | grep NVIDIA".

Since 4191 is the most recent driver on nvidia's web site, go back and use the 3123 drivers. NVIDIA does not have prebuilt rpms for RedHat 8.0, but it is easy to build from the source rpms:

	     # Removes the old installation.  The actual number may need to be changed
	     rpm -e NVIDIA_GLX-1.0-4191 NVIDIA_kernel-1.0-4191

	     # Build the rpm from the source
	     rpmbuild --rebuild NVIDIA_kernel-1.0-3123.src.rpm

	     # Install the rpm.  Note: the actual path may differ from system to system.
	     rpm -ivh /usr/src/redhat/RPMS/i386/NVIDIA_kernel-1.0-3123.i386.rpm

	     # The GLX rpm does not have to build from source (not kernel dependant),
	     # but I did anyway.
	     rpmbuild --rebuild NVIDIA_GLX-1.0-3123.src.rpm
	     rpm -ivh /usr/src/redhat/RPMS/i386/NVIDIA_GLX-1.0-3123.i386.rpm
	   

If SCIRun is not configured with --enable-64bit, the program will not use more than approximately 2G of memory.

There are two general solutions to the bioelectric inverse problem. One formulation tries to recover equivalent dipole sources. The other tries to recover the voltages on an interior surface that is assumed to encompass any source (i.e. there are no sources located between the measurement surface and the interior surface).

In the first formulation (surface-to-source inversion), the inverse problem can be over-constrained (searching for a single dipole that accounts for the outer surface measurements), or under-constrained (searching for a large number of dipoles that are distributed through the domain). The over-constrained case is called parameterized inversion, The under-constrained case is called non-parameterized. In the parameterized case, a search algorithm locates the dipole that best reproduces the measured data. In the non-parameterized case, find the minimum-norm solution that best fits some a-priori information about the data (e.g. the solution should be spatially focused).

The inverse problem is ill-conditioned because of the poorly-specified boundary conditions on the inner surface. The formulation uses the transfer matrix built from a combination of sub-matrices from the stiffness matrix. SCIRun solves the resulting linear systems, but not by computing an explicit inverse. Rather, an iterative (conjugate-gradient) algorithm is used. There is a preliminary version of this code, unfortunately, it has not yet been released in BioPSE. For the moment, see this SPIE `95 paper, which describes this technique in more detail. This algorithm will be part of BioPSE in early Spring.

Each module for a given package has its own .xml file that describes it. When SCIRun starts, it parses all .xml files in the packages (under Dataflow/XML) and tries to find the matching code within the related .so files. If the .so files cannot be found, the message “No such file or directory”" is given. If the .so can be found, but the code for a particular module does not exist within the library, the message “can't find symbol” is given.

The message(s) may or may not indicate a problem with SCIRun. For some modules, the .xml file may be listed, but the code has not been completed (this may be common for module developers). For other modules, the SCIRun installation is some how corrupt (.so files have been deleted, moved, etc.)

The solution is to build libraries the .xml files need or remove the offending .xml files.

The most likely reason for seeing this is that you have found a bug in SCIRun with the locking of the X display. You should report this problem to scirun-develop@sci.utah.edu. The last time this error occurred it was in Dataflow/Modules/Render/OpenGL.cc and required that a glGetIntegerv() call be placed within a gui->lock()/unlock() section.