SCIRun threads run in a single process space, so they have the same PID. The distinct PIDs that Linux and SGI report are not their process as much as their thread Ids.

Add a line like: $m1-c needexecute to the end of the .net file. This causes that module, in this case $m1, and all modules it depends on, or depends on it, to execute.

In cases where performance does not matter, use Vector. When peak performance is required, consider using Array1. In some cases, Array1 is significantly faster.

Set the initial value in the TCL set_defaults method. Otherwise, there is a race condition between values being set in the saved net, and setting their defaults in the c++ constructor.

This is currently unimplemented.

The network may have been executed with a Reader, and one of two things is happening: one, data was saved with an older version of SCIRun that is not recognized (this can be fixed), or two, the data is corrupted and has somehow been truncated.

Both errors occur when TextPioStream is reading a stream of data from the disk. SCIRun uses the TextPioStream class to serialize data to the disk for save and read operations on data such as Fields and Matrices. The first error message occurs at line 566 of SCIRun/src/Core/Persistant/Pstreams.cc in TextPioStream::expect (char). That function was called by TextPioStream::io(string &) on line 503 of the same file, which prints the (String input failed) messages. The TextPioStream was expecting to read a quoted ("") string from the data stream, but received the end of the file.

Two Possibilities:

1) The port visibility is determined by the .xml file. It is likely that there is a dangling parenthesis; you did not close a tag. Also, make sure the "<!DOCTYPE" tag at the top of the file contains the right path, because it is the file location. Moving files can sometimes cause the file to break.

2) The problem can be in the tcl_command method of the .cc file. Every module that implements this virtual method is required to pass unrecognizable messages to the Module base class. If these messages are not passed, the network editor's request for the "impotinfo" and "oportinfo", needed to create ports, is not handled. To verify if this is the problem, look at the end of the tcl_command method to see if you have the Module::tcl_command() call: If(args[1} = = "redraw") {...} else { Module: :tcl_command(args, userdata); }

To use fortran in the sub.mk file, there are lines such as:

	  SRC += $(SRCDIR)/file.F

	  LIBS := $(F_LIBRARY)

	$(SRCDIR)?file.o: $(SCRCDIR)/file.h

They add the .F file to the list of sources. Tell make to use F_LIBRARY (fortran library) in linking, and tell it the .o file depends on a .h file. The calls to these fortran functions are direct calls from the C++ side.

In BioPSE there is a module called ShowLeads that takes a matrix as input, and renders a 2d graph. The module assumes that rows are a time series of data, with columns the timestep values.

In cases where performance does not matter, use std::vector. In cases where optimal performance is needed ,however, compare the performance of std::vector and SCIRun::Array1. In some cases, SCIRun::Array1 is significantly faster.

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

Modules that start at one level sometimes divide or merge to a different level. When designing and writing the code, it is important to think in terms of modularity, even within a single module, so subsequent divisions or reorganization is possible. One approach is to present the design for a new module or set of modules to the group. Perhaps others are interested in some part of the functionality, or can provide existing modules for the new module. This way, there is benefit from the collective plans and knowledge of the group.

Yes, here is the code used to support the coding standard:

	  
	  ; Filename: sci-c++-style.el
	  ; Author: Marty Cole
	  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	  (defun c-no-initializer-indent (langelem)
	  ;; using in a statement block intro...
	  (save-excursion
	  (let* ((curpos (point))
	  retval)
	  (setq retval (if (search-forward "{" (c-point 'eol) t)
	  (* -1 c-basic-offset) c-basic-offset))
	  (goto-char curpos)
	  retval)))

	  (defun my-c-mode-common-hook ()
	  ;; my customizations for all of c-mode and related modes
	  (c-set-style "gnu")
	  (set 'c-label-minimum-indentation 0)
	  (c-set-offset 'substatement-open 0)
	  (c-set-offset 'innamespace 0)
	  (c-set-offset 'statement-cont 'c-no-initializer-indent)
	  )

	  (add-hook 'c-mode-common-hook 'my-c-mode-common-hook)
	  
	

Place this in the .emacs file.

The SCIRun coding standard can be found online.

At present, remote access to the code repository requires a SCI account. To get the most recent released version, visit SCI's web site to download archives. Users may place the resulting files on their own code repository site and manage their own development.

The nature of SCIRun as an interactive, user driven program makes testing modules and their interactions challenging. A user interface that contains a state manager that accepts and manages input from all user interface elements is being developed. One advantage of such a manager is the replacement of the interactive input with a program that supplies a script of interaction requests. the state manager can respond as if a user executed the requests manually. Development of this structure is in progress.

Go to an XML web site such as faq.oreillynet.com/XML/index0.shtm or www.xml.com/pub/a/98/10/guide0.html.

Each module in BioPSE requires an XML-based description of its functionality. The information in the XML module description provides information to assist the module-maker, and helps create the template for a module. The XML module description also forms the basis of a Reference Manual of all modules, and provides information to SCIRun about the number of types of ports the module needs when it appears in a network diagram. The document XML Module Descriptions (Explicated) describes the format and content of the XML file in detail.

XML requires adherence to the language standard, unlike HTML, that permits implicit actions such as environments that are never closed properly. Use a validation tool to ensure an XML module description file adheres to BioPSE specifications.

There is nothing wrong with the machine, nor is it a coding error. There is a conflict with IRIX and the SCIRun memory allocator that has never been tracked down. It is a rare occurrence.

There are container classes for GeomObj's -- these are themselves GeomObj's that contain one or more GeomObj's inside of them. They are useful for building up scene graphs. The container used is a GeomMaterial -- its constructor takes a GeomObj (e.g. a GeomCylinder) and a MaterialHandle. (Note: the constructor for a Material can be as simple as passing in a Color triple!)

When creating a new Port, add a file into Dataflow/Ports/. The .cc file for the new Port type should have a specification for a name and for a color. See SCIRun/src/Dataflow/Ports/MatrixPort.cc as an example.

GuiVars are needed. GuiVars enable the sharing of a variable between C++ and tcl, and are the only values that save to the tcl scripts. Look at any module with a gui for an example (GuiString, GuiInt, GuiDouble, and in particular, look at their constructor). Synch with the tcl side by specifying the name of the var on the tcl side.

On the C++ side:

	    GuiInt myint_;

	    // Initialization in constructor --
	    myint_("myint", id, …)
	  

One the tcl side:

	    set $this-myint 1    # or whatever value you want
	  

Look at ShowField.cc and .tcl for examples.

A thread starts running immediately, unless Stopped or NotActivated in the Thread constructor. In that case, use thread->resume() or thread->activate() (respectively) to start the thread running. Stopped/thread->resume() is the preferred method.

After adding the file to the GUI directory two things must be done in order for the interface to show up in SCIRun. First you must add the file's name to the sub.mk file located in the GUI directory where your file was place. Add it to SRCS placing it before the INSERT FILE HERE comment. The second thing you need to do is recompile. This generates a new tclIndex file with the information SCIRun needs to load your user interface.

You need to copy the gl headers from the nvidia driver installation into place, then recompile scirun. The volume vis uses extensions, so it needs them defined in the headers.

You also need a graphics card that supports 3d textures, which I believe you have or you would see a solid white cube.

cp /usr/share/doc/NVIDIA_GLX-1.0/include/GL/* to /usr/include/GL

See: /scratch/usr/share/doc/NVIDIA_GLX-1.0/README

PETsc is not required. You only need it if there was some specific solvers you wanted.