Parallelization
There are different layers of parallelization possible in the searchtree methodology. In the current implementation of the algorithm, the following parallelization features are all available and parameterized independently:

Parallelization of contingency simulations: In a security analysis, the loadflow computation for all contingencies can be done in parallel. A parameter is available to specify how many threads are available for each security analysis. This parallelization is directly operated by the loadflow module itself. It is especially very useful for the preventive perimeter, where all postcontingency flows must be calculated after each contingency.

Parallelization of topological actions: The consequences of each topological action must be evaluated independently. These evaluations can therefore be done in parallel threads

Parallelization of curative perimeters optimisation: After the preventive optimization finished, all the curative perimeters can be optimized independently. These optimizations can also be done in parallel, using dedicated threads.

Parallelization of studied situations (timestamps): When performing optimisation on multiple timestamps, it is also possible to separate the computation of the different studied situations on different threads.
Searchtree depth
The higher the number of critical branches, critical outages and remedial actions, the longer the calculation. For instance, an optimizer will try different combinations of topological actions to solve one constraint (RA1+RA2, RA1+RA3, RA2+RA3, RA1+RA2+RA3….). Simulating all combinations to find the best set would require more time than finding the first set respecting the criteria.
The complexity here can be defined as the maximal number of consecutive chosen network actions, also called searchtree depth.
For studies where complexity is high but performance is not the main priority, the searchtree depth can be configured accordingly in order to assess more combinations.
For operational process (such as capacity calculation/security analysis), where expectation for performance can be high, searchtree depth will be configured in order to match the allotted time for the calculation process.
By defining the searchtree depth as a parameter, CASTOR can be used easily in both applications.
Later on, that search tree depth will be configurable per TSO to reflect the maximum consecutive remedial actions allowed by national operators due to the timing constraint for realtime operations. For now only the total depth is taken into consideration.
Networkactionminimumimpactthreshold
In addition to searchtree depth, the networkactionminimumimpactthreshold is also configurable to adjust the optimization with performance expected by the operational process. The networkactionminimumimpactthreshold represents the minimal relative/absolute increase of objective function between two consecutive chosen network actions.
This minimal relative gain is expressed as a percentage of previous objective function (0.2 for 20%). By setting this parameter at a higher value, this could fasten the computation time while focusing only on the most efficient remedial actions. This avoids simulating a high number of remedial actions to only have a small gain on a single CNEC.
This parameter can be defined also through absolute increase :
 minimum impact (in MW or A) for the application of topological remedial action
 minimum impact (in MW/degree or A/degree) for the use of PST/HVDC