The most complicated datatypes in SCIRun are fields, the latter is the merger of data and actual geometry. The difficulty starts with the fact that SCIRun supports a range of different geometry (mesh) types and different interpolation schemes of data on top of that as well as different type of data (scalars, vectors, and tensors).
The problem is the huge number of possible combinations and how to write optimal code for that is general enough so it does not need to replicated indefinitely. A solution to problem is using templated code where mesh and field parameters and templated and only filled in at compiler time.
Up until recently all the code that dealt with fields within SCIRun took this templated concept one step further and actually only compiled code when it was needed while SCIRun was running. This is a reasonable solution as long as you have a compiler available (most Windows platforms do not) and it requires very robust code, as the code is not tested when SCIRun is compiled and hence the consequence was that SCIRun was really fragile, but fast.
An alternative for dynamically compiling what you need is using virtual function calls, which basically uses a lookup table to find the right function to call. Depending on the type of mesh the lookup table changes. In earlier days virtual function calls were expensive, however modern compilers will make them relatively efficient. Hence the advantages of virtual function calls is that one does not need to worry about invoking a compiler, dynamically creating files that can be compiled hence less hassle.
The development of the virtual branch tries to accomplish the following:
 Allow both virtual function calls into the field classes as well as allowing dynamic compilation in the same source tree.
 Upgrade interfaces so they are robust (needed for dynamic compilation) and can be shared with the virtual function calls.
 Upgrade the field classes so they support cubic and quadratic meshes better.
 Upgrade support for rendering dynamic compiled algorithms and virtual function calls.
 Currently SCIRun field classes use a combination of virtual functions and dynamic function calls. They are both in the same interface which causes two problems, whenever a function internally calls a virtual function the advantage of doing dynamic compilation is compromised (e.g. basis_order() function) and whenever a dynamically compiled function is instantiated all virtual functions are recompiled into that library as that is the nature of virtual function calls. Hence the interface between both needs to be separated.
Technical Details Implementation
How to deal with field datatypes?
Non linear mesh/field elements
Go back to Documentation:SCIRun:DevManual