Influences on the running time

There were several decisions to be made during the process of software development

that have influenced the runtime performance of thefmrieeg_{C++ algorithm. As noted}

above, high diligence was put into using efficient linear algebra routines building on BLAS and LAPACK. Additionally, when installing the software the user can customize the compilation and installing process to some extend to increase the runtime performance of the algorithm even more. Customizing, however, can only be done within the scope of

the given software application framework. There are less options when configuring the R-package installation. Hence, in the following, we differentiate between the R-package and binary program building.

Modifying the building process ofCfmrieegMain

The building process of the CfmrieegMain program can be modified at two stages:

Changes can be applied to the building configuration of (A) the self-contained package

of automatically built sublibraries and of (B) a separate fmrieeg _{library compilation}

with links to already installed external libraries. For (A) configurations can be changed

by modifying the makefile ‘makefileCpp’ contained in directorysrc _{of the R-package.}

For (B) the makefile ‘makefileCpp’ contained in thefmrieegDP_resp.fmrieeg_subfolder

can be adapted (depending on whether the single- or double precision library should be compiled).

In the following, we discuss three options to increase the runtime performance of

CfmrieegMain_{: (1) the use of alternative BLAS/LAPACK library installations; (2) the}

choice between a single- or double-precision version offmrieeg_{; (3) usage of own in-}

stallations of external libraries. Modifications in form of (1) and (2) can be accomplished

within the compilation process of the self-contained package (case (A)). Thus, we primarily

focus on realizing changes that can be made to (A). In contrast to this, full flexibility,

e.g. in the choice of external library installations, can only be handled by case (B). This,

however, requires that the user knows how to compile external libraries on her/his own. Because of this, we only comment very briefly on incorporating a specific external library implementing the METIS algorithm (see below).

An optimized BLAS/LAPACK library increases the speed of thefmrieegalgorithm in

any case. For high performance, we recommend to install an optimized native BLAS implementation like ATLAS (Whaley and Petitet, 2005) or GotoBLAS (Goto and Van De Geijn, 2008), which also include optimized LAPACK routines. Note that GotoBLAS must be compiled in the single-threaded version to not interfere with CHOLMOD routines. To link against an optimized library, adjust the MY_BLASLAPACK_LIBS statement in the makefile

‘makefileCpp’ contained in foldersrc_{of the R-package. The alternative BLAS/LAPACK}

versions can then simply be incorporated in the building ofCfmrieegMain_{. Acceleration,}

generally, depends on the size of the image data. For a whole-brain analysis, we expect a

program to the GotoBLAS library and achieved an acceleration of factor 4 in a brain image

analysis of an fMRI time series with27 257voxels.

Thefmrieegalgorithm originally has been implemented using single-precision variables (except for code sections where a higher accuracy is needed for specific calculations). Reasons for this were threefold: We decided to use float variables on the basis that image data at hand did not need high precision data formats for being available as short integers. Hence, on the one hand, float variables offered the advantage of saving working memory and, on the other hand, running time potentially could be decreased. Acceleration, however, could not be observed on a Quad-Core AMD Opteron(tm) Processor 8384 (64 bit system). Nevertheless, the user might revert to the single-precision library when working memory is limited or another platform promises an increase in speed when processing

floats instead of doubles. The single precisionCfmrieegMainprogram can be compile

by setting configurations in the makefile ‘makefileCpp’ provided in directorysrcof the

R-package alike (see description contained).

A further factor that might influence running time is the inclusion of the METIS C-library (Karypis and Kumar, 1998). The METIS algorithm is capable of calculating an advan- tageous permutation to reduce the bandwidth of sparse Laplacian matrices used in the time-consuming update of large GMRF maps as described in Section 5.2.2. Depending

on the voxel grid at hand, the METIS algorithm can increase the speed of thefmrieeg

algorithm. Because of its license, the METIS C-library is neither distributed with the SuiteSparse library, which includes CHOLMOD, nor with our self-contained package,

which is used to build CfmrieegMain_{. Therefore, an individual installation of the}

SuiteSparse library may be desired to incorporate the METIS C-library routines. To revert to the METIS algorithm, the library must be installed on your platform (METIS is

available athttp://glaros.dtc.umn.edu/gkhome/metis/metis/overview) and

SuiteSparse has to be recompiled to find the METIS library (for more information on

this, seehttp://www.cise.ufl.edu/research/sparse/SuiteSparse/). To link

against external libraries adapt the makefile ‘makefileCpp’ in thefmrieeg_orfmrieegDP

subfolder of the R-package foldersrc_{(depending on whether the single- or double preci-}

sion library should be compiled). Adjust the METIS_LPATH (METIS_LIB) and SUITES- PARSE_DIR statements within the makefile to link against METIS and an own SuiteSparse installation.

Changing installation settings within R

It must be ensured that installation of R-packages work on both windows and unix sys- tems. Although compilation of package-specific source code can be configured using a

‘MAKEVARS’ (‘MAKEVARS.win’) makefile included in folder src, the standard instal-

lation process of an R-package must be accomplishable with the software components provided by the R-package and a standard R installation. Especially, inclusion of external libraries is problematic, because their presence cannot generally be assumed. An How-To on installing general C/C++ libraries on a windows system and including them in an R-package installation process is beyond the scope of this introduction, hence, we give some advice on including external libraries on a unix system.

As noted in the preceding section there may be reasons to use BLAS and LAPACK libraries not included by default. Foremost, the inclusion of an optimized BLAS is desirable, but the user might also want to include a library providing single-precision routines. An installa- tion of the software environment R makes a BLAS and LAPACK library available. These

libraries provide double-precision routines only, so that the single-precision fmrieeg

library cannot be used by default. If another BLAS/LAPACK library should be used, we recommend to proceed as follows.

We assume that an alternative BLAS/LAPACK library (like ATLAS or GotoBLAS) is in- stalled. If one of these should be used within the R-package, it must be ensured that the whole R environment uses this library as well to avoid conflicts. There are different ways of incorporating a shared BLAS library. Probably the most easy one is to sym- link a dynamic BLAS library to ‘R_HOME/lib/libRblas.so’ as described in the R Instal-

lation and Administration-guide (available at http://cran.r-project.org/doc/

manuals/R-admin.pdf_{). Accordingly, the library containing LAPACK routines must}

be symlinked to ‘R_HOME/lib/libRlapack.so’. If an R-package with BLAS/LAPACK rou- tines is now installed within this modified R version, it now uses routines of the specified alternative library/libraries.

If single-precision routines should be used or the external BLAS/LAPACK library is called

by a cblas interface, corresponding ‘MAKEVARS’ statements of theRfmrieeg_package

have to be adjusted as described there.

External libraries like METIS and an accordingly recompiled SuiteSparse can be included by changing the ‘MAKEVARS’ (‘MAKEVARS.win’) file to include corresponding ‘include’- paths and linking statements. Some changes to the present form of the ‘MAKEVARS’ have to be applied that are not provided by us, but can be accomplished by the user.

Reasons for conducting the studies in this chapter are threefold: First, we want to base model building decisions upon the results of data arising under controlled conditions. Second, uninformed fMRI activation detection schemes should be compared to algorithms found in the literature to assess their basic performance. Third, promising EEG-enhanced detection schemes should be compared to uninformed schemes to assess whether our models are generally capable of increasing sensitivity by the use of spatial EEG informa- tion. Model building decisions are based on convergency properties and the capability of yielding sensible estimates for latent fMRI and/or EEG predictor components. Per- formance is assessed by the power of the different algorithms to detect activated voxels. Simulation studies are designed in such a way that a true activation map is at hand. Hence, we quantify performance in terms of sensitivity and specificity.

This chapter is divided into two parts: The first section, Section 6.1, contains simulation studies based on an artificial simulation design. This section includes an evaluation of different predictor forms leading to model selection decisions. In Section 6.2, a simulation study is based on the structure of a given real-world dataset.

6.1 Simulation studies based on artificial data

In this section, simulation setup is based on an artificial simulation design. We control position, spread and composition of regions of activation or rather non-activation with each region being very homogenous. In Section 6.1.1, we describe the simulation design that is used to investigate the performance of models in a controlled setting. Notation and parameter settings common to all models used in this study are introduced in Section 6.1.2. In Section 6.1.3, we evaluate different predictor forms of the EEG hierarchy, i.e. the way EEG information is included in the model. Besides this, the type of spatial prior (i.e. CAR versus IGMRF prior) and the accelerated version of the CAR algorithm are examined.

We conclude with a recommendation on which algorithm should be used in further analyses. In Section 6.1.4, we compare the performance of our proposed models based solely on fMRI (so-called null models) to competing activation detection methods. Finally, in Section 6.1.5, we evaluate whether the recommended combined fMRI-EEG algorithms have increased sensitivity compared to their corresponding null models. Performance of different algorithms is then evaluated at different noise levels.