## 2 Materials and Methods
### TVB-AdEx to GPUs  
To accommodate the intricate regimes associated with various parameter settings within the TVB-AdEx model, a GPU-accelerated version has been developed. The TVB model generator, RateML, offers the capability to create customized rate-based or mean-field models. In the standard workflow of this tool, an XML file can be populated with TVB generic properties, including the derivative functions of the model. This file is then translated into a fully fledged TVB model or a GPU model and driver for the execution of the model. Because the AdEx model has a complex transfer function, in describing the firing rate of the neuron populations, the regular usage of RateML is not possible. However, the GPU model introduced here is based on the blueprint for TVB GPU models, manually annotated with the added model complexity, including the function calls to the transfer function (\(zerlaut.c\)). The transfer function itself is specified in a separate header file (\(zerlaut.h\)). Next to a GPU model which supports parameter sweeps, the model driver (\(model\_driver\_zerlaut.py\)) object is also generated when invoking RateML. Furthermore, this driver has been manually annotated for the computation and comparison of the functional connectivity (FC) to an externally obtained FC. The model driver and model for the TVB simulation using the GPU AdEx can be initiated on any CUDA-capable GPU device. An example of the execution command is as follows:  
Python model_driver_zerlaut_mpi.py -s0 6 -s1 6 -s2 6 -s3 6 -s4 6  -n 5000 -dt 0.1 -vw -cs 3 -cf connectivity_zerlaut_68.zip  -ff pearson_0.4_72_-64_-64_19 -gs  
A number of simulator settings are exposed to the user on command line. Many more settings are exposed to the user but the most important are highlighted. The \(s0\)-\(s4\) are the flags that set the resolution for the sweep parameters of the specified parameters. That is, -s0 6 generates six values equally spaced within the defined range for the first parameter of the space to be explored. Normally, the lower and upper bounds of the parameters to sweep can be indicated in the XML file or can be changed in the driver file. This will result in the generation of an array of all the possible parameter combinations, representing the total work-items. The work-items correspond to the grid size indicating the total threads which \begin{table}
\begin{tabular}{l c c c c c c c c c} \hline
**Cell Type** & \(P_{0}\) & \(P_{HV}\) & \(P_{eV}\) & \(P_{\tau NV}\) & \(P_{\mu 2}\) & \(P_{\sigma 2}\) & \(P_{\tau NV2}\) & \(P_{V\sigma}\) & \(P_{\mu V\tau N}\) & \(P_{eV\tau N}\) \\ \hline RS-Cell & \(-48.9\) & \(5.1\) & \(-25.0\) & \(1.4\) & \(-0.41\) & \(10.5\) & \(-36.0\) & \(7.4\) & \(1.2\) & \(40.7\) \\ \hline FS-Cell & \(-51.4\) & \(0.4\) & \(-8.3\) & \(0.2\) & \(-0.5\) & \(1.4\) & \(-14.6\) & \(4.5\) & \(2.8\) & \(15.3\) \\ \hline \end{tabular}
\end{table} 
Table 1: Polynomial of the phenomenological voltage threshold for the transfer function (mV). spawn on the GPU. Each thread spawned is a TVB simulation with a unique parameter combination. The two-dimensional grid for the GPU threads is determined recursively according to the number of work-items. The program will try to fit the work-items in blocks of 32 \(\times\) 32 threads and increase the number of blocks, alternating for the x- and y-axis dimensions in order to find the optimal population of the GPU. The simulation of the GPU consists of two loops, an inner-loop, which determines the number of iterations of the simulation on the GPU, and an outer-loop, which determines the number of times a GPU-instance spawns. The \(-n\) sets the number of simulation steps for the outer-loop and determines the number of times a GPU-instance is spawned. The steps for the inner-loop are computed by dividing the period of the time-series by the delta-time, \(-dt\).