## 4 Evaluation via Use Cases
### Refactorisation in Real-Time Simulation  
In this use case, we analysed the performance of the refactorisation and solution steps of the NICSLU method. As explained in Section 2.1, the computational efficiency of both refactorisation and solution steps are of particular relevance in real-time simulation scenarios, in which the integration of nonlinear component models leads to varying matrix entries. In addition, we considered the proposed partial refactorisation implementation and comparatively analysed its potential performance improvements.  
As a use case, we performed an EMT simulation with a high level of detail of the aforementioned WSCC 9 bus benchmark system. Instead of incorporating ideal voltage source models to represent the synchronous generation, we employed a detailed model that describes the component behaviour by a ninth-order nonlinear ODE system. The model is a VBR model [25], which involves time-varying conductances. These conductances are updated within the MNA system matrix once per simulation step and, hence, require matrix refactorisation. The number of network nodes of the EMT benchmark system is \(K=9\), the matrix size is \(N=63\) with \(NNZ=198\), and the number of varying matrix entries, which originate from the included VBR models, is \(NVE=27\). In this use case, the measurements of the average computation time for refactorisation and solution steps were repeated 20 times to reduce the effect of variance.  
Considering the full refactorisation of the system matrix in each time step, Figure 6 demonstrates that EigenNICSLU results in a speedup of 18.9 compared to EigenSparse for the computation of the refactorisation. Moreover, the computation times required by EigenNICSLU for determining the solution vector are 4.3 times as fast as with EigenSparse.  
For a better understanding of the impact of partial refactorisation, Figure 7a shows the original input matrix pattern in this use case. The numerically varying entries are marked in red. This matrix was permuted and factorised in NICSLU to yield the pattern visible in Figure 7b. Here, the entries changing between subsequent LU factorisations are marked in red. It is observed that only a few columns have varying entries. Those columns are \(\{36,55,56,57,58,59,60,61,62\}\), which make up the resulting factorisation path when using the adopted algorithm. The path contains nine columns, meaning that only 14.3% of all columns have to be refactorised.  
Figure 5: Solution computation times for an increasing number of system copies (the speedup is defined as the computation time of EigenSparse divided by that of EigenNICSLU).  
When the factorisation path is considered during refactorisation by employing EigenPartialNICSLU, the refactorisation computation time is further improved, as shown in Figure 6. The corresponding speedup of EigenPartialNICSLU compared to EigenNICSLU was 1.8. The solution computation time remained the same, as the resulting LU decomposition matrix did not differ between EigenPartialNICSLU and EigenNICSLU. Furthermore, no modifications to the RHS solving routine were performed in EigenPartialNICSLU, so in both cases, the same computations were performed in the solution step. However, developing and analysing a partial RHS solving routine that uses a suitable dependency path algorithm, similar to what is performed for partial refactorisation, can be part of a future investigation.