# SIMBIO/Designreport

### From SimBio - A generic environment for bio-numerical simulations

Design Report

D4.1a: Inverse Problem Methodology

Workpackage 4 Subtask 4.1

Detailed design report

## Introduction

Localizing the sources of electrical activity of the brain by inverse methods has an important impact for surgical planning, either to identify regions which generate activity due to pathologic alterations of nerve cells, like in epilepsy, or to delineate regions with functions of high impact, that should strictly be avoided to be excised. But inverse methods are not restricted to clinical use. They allow insight in the localization of neuronal processes by a high time resolution, which can not be achieved by imaging methods like functional MRI. Thus they can be applied for the exploration of a wide variety of aspects in neuroscience. Results of WP2, which provides individual conductivity maps, combined with FEM methods of WP3 will improve the performance of inverse methods beyond the current status.

The objective of WP 4 Subtask 4.1 will be the generation of a generic inverse toolbox containing a large variety of inverse problem solvers and an error estimation package, which will include methods to estimate the sensitivity of the results of source reconstruction to inaccuracies in forward modeling. Software design should assure a generic and modular implementation of the inverse methods. Thus there should be a simple interface to add new methods and to reuse already implemented algorithms.

In this design report the methods that will be included in the inverse toolbox are defined. Furthermore this report gives a guideline for the implementation of these methods. This is done by describing the methods, giving references to detailed descriptions of the methods and defining the software environment, e.g. used platforms, compilers, class interfaces, user interfaces, file interfaces and software quality management. This report should also give workgroups of other workpackages, (especially WP3 of the SimBio consortium) a complete and plain description how to integrate algorithms to the inverse toolbox.

## Inverse methods

## Software design of generic toolbox

## Error estimation package

### General Description

The objective of the error estimation package is to estimate the sensitivity of inverse current source reconstructions to errors, inaccuracies, and simplifications in the forward model in cooperation with WP 7 ST 7.1. The sensitivity of source reconstruction results due to errors in the estimation of tissue conductivity is an example of parameters to be investigated. This has for example implications for presurgical magnetic source imaging for tumor patients undergoing neurosurgery, since it is known that tumors are associated with changes in the tissue resistivity profile.

A starting point for sensitivity analysis will be a simple volume conductor. This will be a multiple layered sphere model with anisotropic but homogenous material behavior in every layer. In a second step realistic head models with individual conductivity tensor values will be used.

To obtain insight in the sensitivity of different inverse source reconstruction methods to changes in the forward model, different inverse methods can be used for inverse calculations. This is provided by the modularity of the inverse toolbox.

The accuracy of inverse reconstruction methods does not only depend on the model of forward calculations and the chosen inverse method but also on characteristics of the sources themselves. Characteristics of the sources which have effect on the accuracy of the inverse method are the number of sources, source positions, source orientations, and source magnitudes. Therefore these source parameters can be varied systematically inside the error estimation package.

The forward model parameters will be varied in the innermost layer of sensitivity analysis. The resulting sequence of parameter or model variations inside the error estimation package is shown in figure 4.1.

One iteration of the sequence concerning the variation of one parameter of the forward model consist of the following steps (fig. 4.2). Starting point is one set of source parameters. The forward problem is solved for this set of source parameters. The resulting potentials or magnetic fields at sensor positions serve in the next step as input values for an inverse analysis. The inverse procedure also needs a forward simulator. For this forward simulator one parameter the sensitivity of which is currently investigated is changed. The estimated sources by the inverse method are then compared with the given source configuration. Generally the simulators for the initial forward computation with and for the inverse algorithm are identical. In Addition, the framework of the error estimation package allows to use different simulators to compare results between different kinds of simulators.

For single dipoles one can compare distances of the positions of the dipoles (x, y, z), differences of angles between source directions, and differences of source magnitudes between original and reconstructed sources. Following similarity measures can be determined. For source models using a discrete parameter space: mean and maximum difference of the amplitude, mean and largest angle between moments, correlation between magnitudes of sources.

But also other combinations are possible. The original source can be for example a single dipole and the inverse method uses a linear estimation method. In this case one can compare position, orientation, and magnitude of the reconstructed source with the largest moment.

### Class interface

To obtain a general framework for the analysis of sensitivities of source reconstructions due to changes in the forward model the modular class structure of the inverse toolbox can be extended. Fig. 4.3 shows the class interface of the error estimation package.

In the center of the class structure is the abstract class “anAbstractErrorEstimator” which defines general properties of error estimators. It is derived from the abstract class “anAbstractAnalyzer”. The error estimator class contains references to several other abstract classes. First there is a reference to the “anAbstractSourceParameterGenerator” class. This class provides a systematic variation of source parameters. It has a second reference to the class “anAbstractSimulatorEEGMEG”. This simulator is used for forward calculations. The “anAbstractErrorEstimator” class has a further reference to the “anAbstractAnalyzerInverse” class for the reconstruction of the sources by an inverse method. Using the abstract class interface all inverse methods which are realized in the inverse toolbox are available in the error estimation package. The simulator for the inverse calculations is used with one parameter varied for the sensitivity analysis. For this reason the parameters of the simulator can be requested and set using a general set of methods to access the simulator parameters.

There is one method within the simulator to return the number of variable forward parameters: getNumberofParameters(). Each parameter can be described by a name, a unit (e.g. mm), maximum and minimum values, default and current values. Table 4.1 shows the methods to get and set parameter values for single parameters. First one can get a name or a description of a parameter. The next method allows to get the units of the respective parameter. For the sensitivity analysis standard values, and minimum and maximum values for the deviation can be requested and set. Finally there are methods to set and get the current value of a parameter. Thus inside the implementation of error estimation classes one can request properties of parameters and change them systematically to determine the sensitivity of source reconstructions due to changes of parameters of the forward model.

Name | Return type | Description |
---|---|---|

ParameterNgetName(int ParameterNumber,string outName) | bool | Get name or description of a parameter |

ParameterNgetUnit(int ParameterNumber,string outUnit) | bool | Get unit of a parameter |

ParameterNsetMinimum(intParameterNumber, double inMinimum) | bool | Set minimum value of a parameter. Minimum is used as lower deviation in sensitivity analysis. |

ParameterNgetMinimum(intParameterNumber, double outMinimum) | bool | Get minimum value of a parameter. Minimum is used as lower deviation in sensitivity analysis. |

ParameterNsetMaximum(intParameterNumber, double inMaximum) | bool | Set Maximum value of a parameter.Maximum is used as upper deviation in sensitivity analysis. |

ParameterNgetMaximum(intParameterNumber, double outMaximum) | bool | Get Maximum value of a parameter.Maximum is used as upper deviation in sensitivity analysis. |

ParameterNsetDefault(intParameterNumber, double inDefault) | bool | Set default/standard value of a parameter |

ParameterNgetDefault(intParameterNumber, double outDefault) | bool | Get default/standard value of a parameter |

ParameterNsetValue(int ParameterNumber,double inValue) | bool | Set value of a parameter. |

ParameterNgetValue(int ParameterNumber,double outValue) | bool | Get value of a parameter. |

Table 4.1 Methods to request and set values of parameters of a forward simlator.

To compare the results between the original source parameters and the parameters of the reconstructed parameters sources the “anAbstractErrorEstimator” class has a reference to the “anAbstractSourceSimilarityMetric” class, which provides methods to compare source positions, directions and magnitudes. The method computesimilaritymeasure() provides besides a matrix with similarity values a description of the contents of the array. To obtain a complete description of parameter variations and deviations of the reconstructed sources the getResult() method of the “anAbstractErrorEstimator” class provides following information:

- Parameter name/description,
- Parameter unit
- Default/standard value of parameter
- Changed simulator parameter for inverse analysis
- Original source parameters
- Reconstructed source parameters
- Description of the values of similarity metric
- Matrix with values of similarity metric

Thus, by abstract class definitions and modular design a huge number of parameters can be varied inside the error estimation package using one general approach. Additional descriptions of parameters and results, which are necessary for an interpretation and discussion of results, are incorporated in the definition of simulator classes and classes defining a similarity measure and can be extended by the user.

## Software quality management

### Software version control

To keep track of changes during software development and to allow distributed software development version control will be used during the generation of the inverse toolbox. New versions will be set up after implementing significant alterations and subsequent testing. Software which is not generated at A.N.T. Software b.v. will be merged to a common new version at A.N.T. Software b.v.. For each version a directory will be set up containing the implementation and a document describing the changes compared to the last version. Software versions will be placed on the network server at A.N.T. Software b.v. in the directory:

…\simbio\simbio_ipm_software_versions

The names of the directories for the individual versions will have the following naming convention including the date of their creation:

simbio_ipm_ver_yyyy_mm_dd.

On file level each change has to be documented in the file header by inserting a new line. This line should contain the date of change the person who performed the change and a description of the alterations inside the code.

// $2 23.08.2000 Alfred A. added index fields for FEM-node maps // $1 11.07.2000 Matthias D. created #ifndef __anAbstractGridGenerator_c_H__ #define __anAbstractGridGenerator_c_H__ …

### Software test protocols

Inside the inverse toolbox complex algorithms will be realized. Thus their implementation will be thoroughly tested and testing will be documented in a standardized way. The documentation will reside on the network server at A.N.T. Software b.v. in the directory:

…\simbio\softwarequalitymanagement\testprotocols

Test protocols will include following general information: date, person, version, compiler, tested method. Then the test procedure will be described, followed by their results, which can be numerical values, verbal descriptions or pictures. The details of a test procedure are defined in parallel to their implementation and the implementation will contain a reference to the test procedure document.

Methods of the inverse toolbox will be tested inside a complete test environment implemented for Microsoft Windows 95-98-NT. Besides data import, viewing and analysis features, this environment incorporates an open interface for adding new methods.:

Test procedures for methods inside the inverse toolbox can be divided into three different categories

- Comparing the results of a method with a solution which can be derived analytically.
- Real data can be used for methods which are implemented inside the ASA software packages of A.N.T. Software b.v. or the original Cauchy software . For these software packages reference results exist for specified data sets, which can be compared to results of methods implemented in the inverse toolbox. Once reference solutions are established for the inverse toolbox, they replace the reference solutions of the ASA package.

Initial testing of a method covers an extensive testing of their complete functionality. Whenever possible results are compared to analytically derived results. This testing has to be repeated each time changes are performed to this method.

If a new version of the inverse toolbox is created every method of the inverse toolbox available at the current stage of development will be covered by at least one test procedure. For example, testing of criteria and optimizer will be included in the dipole fit test. This test procedures will consist in the comparison of results to reference results.

Testing of methods may have some problems inherent to the used methods. If nonlinear search algorithms are used for the determination of source parameters they may not find the same optimal set of parameters as a reference solution, without being incorrect. In addition small differences to references solutions may be due to numerical inaccuracies or implementation details. Generally it should be checked if results of methods are reasonable, for example if sources have plausible positions or magnitudes.

Table 5.1 contains a list how the methods of the inverse toolbox will be tested.

Method | Comparison with analytical solution | Comparison with reference data (criterion for comparison) |
---|---|---|

Dipoles with fixed positions for all time points | - | Distance to reference solution |

Dipoles with rotating directions and fixed positions | - | Distance to reference solution |

Moving dipoles | - | Maximum distance to reference solution |

Criterion: Minimum square error | Computation for example matrices | - |

Criterion: Maximum entropy | Computation for example matrices | - |

Criterion: Maximum probability | Computation for example matrices | - |

Parameter optimization: Simplex algorithm | Determination of parameters of non-linear functions | - |

Parameter optimization: Levenberg Marquardt algorithm | Determination of parameters of non-linear functions | - |

Parameter optimization: Simulated annealing | - | Maximum distance to reference solution |

Loreta | - | Comparison to reference results (original “Loreta”software) |

Truncated singular value decomposition | Computation for example matrices | - |

Tikhonov-Philips-regularization | Computation for example matrices | - |

Linear estimation | - | Correlation, relative maximum difference magnitudes, largest angle between moments |

“Goal Function Scan” (GFS) | - | Correlation |

“Multiple Signal Characterization” (MUSIC) | - | Correlation |

Spheres | - | Included in dipole fit |

BEM | - | Included in dipole fit,linear estimation, GFS and MUSIC test procedure |

FEM | - | Correlation, relative maximum difference magnitudes, largest angle between moments |

Table 5.1 List of test procedures of the methods inside the inverse toolbox.

### Bug database

To have an overview about software bugs and unsolved problems a database will be used to keep information about bugs, their current status, and how they were probably solved. Thus every bug has to be registered. The database will consist of one table containing the fields shown in table 5.2.

Name | Type | Description |
---|---|---|

number | number | Assigned 4 digit bug number |

status | text | Can be bad if unsolved or ok if the bug has been fixed |

reported (date) | date | Date of the registration of this bug. |

by whom | text | Person who registrates the bug |

description | memo | Short description of the problem. |

reproduction information | memo | Description how the bug can be reproduced. If necessary leave some sample data in a directory that starts with the bug number. |

category | text | This can be bug, deficiency, or wish. |

due | date | Date when bug has to be solved |

priority | text | assign any of these: very high, high, regular, low, very low |

solved (date) | date | Date when bug is solved. |

solved by | text | Person who solved the bug |

files | memo | Files changed to fix the bug |

remarks | memo | Remarks concerning the bug or how it was solved |

Table 5.2 Fields of bug database.

The bug database will reside on the network server at A.N.T. Software b.v. in the directory:

…\simbio\softwarequalitymanagement\bugdatabase

The database will be realized using the Microsoft Access 97 database. Bugs registered at other locations than A.N.T. Software B.V. will be merged to the database. If SimBio projects partners need data of the bug database, they will receive a current copy of the database or an exported sheet containing the information in a nonproprietary file format. In addition a bug report containing unsolved bugs will be sent to st41@simbio.de in HTML format once a week.

### Backup protocol

The software of the inverse toolbox will be written on a CD once a week at A.N.T. Software b.v.. This will include all documents concerning SimBio which are resident at A.N.T. Software b.v.. To have an overview about of the backups of software and documents they will be registered in a spreadsheet. The spreadsheet will reside on the network server at A.N.T. Software b.v. in the directory:

…\simbio\softwarequalitymanagement\backuphistory.

Fields of the spreadsheet are listed in table 5.3.

Name | Description | Date scheduled | Date, when the backup is scheduled |
---|---|---|---|

Directories | Directories, which have to be backed up | ||

CD-ID | Identification of backup cd | ||

Responsible | Person, who is responsible for the backup | ||

Date done | Date, when the backup is done | ||

Performed by | Person, who performed the backup |

Table 5.3 Fields of the spreadsheet, which is used for the backup history.