Anatomy of an application

Any MEM or MassInf application consists of two parts.

The interface performs all the file handling, graphics and general control. Also, and most importantly, the interface provides a mathematical description of the physical system via two (or for non-linear systems, three) custom routines.

The kernel software is a general engine for determining the optimum image parameters, and apart from these three routines does not need to know anything at all about the specific application. MEM applications use our MemSys kernel,while Massive Inference calculations use the MitSys kernel.

The Interface.

For MemSys, two compulsory routines, OPUS and TROPUS, specify the mapping between source ("image") pixel fluxes and (noise-free) data. In general, OPUS is equivalent to a matrix multiplication, where the matrix is dimensioned as the number of source pixels times the number of data pixels. Many problems however have symmetries which allow this process to be represented by a much faster operation, such as a convolution (which can be implemented via a 2-D Fourier Transform). For non-linear transfer functions, the user also has to supply one further routine, MEMEX.

OPUS, TROPUS (transpose OPUS) and MEMEX (if needed) are called directly by the MemSys or MitSys kernels, and so have to be written with standard argument lists.

File handling includes getting the data from the input file, putting it into a suitable array, and then writing the source distribution into an appropriately formatted output file. The complexity of the file format will depend on whether the data are being treated as a simple pixel array, or have associated physical information, such as pixel size and orientation, true pixel flux scaling etc. In the latter case, if there are no other constraints, then we suggest you consider using the FITSIO subroutine library from Goddard Space Flight Centre.

In general we recommend using a separate graphics package for data display. This minimizes the complexity of the main application, and also gives users much more freedom when it comes to presentation. If the graphics must be included in the application, then we advise the use of Tim Pearson's PGPLOT subroutine library from CalTech, which is available for most common platforms and many others as well.

Finally, any application interface also requires some code for control of the process. This should allow the user to specify input and output files, to set any control parameters, and to control the iteration itself -- for example, by specifying how many iterations to perform before displaying the new image. It also specifies how the various arrays are to be stored in memory, how and when they should be saved to disk, and how much "debugging" information to display on the progress of the iteration.

Further information

Details of our Products.
Detailed Documentation