On this page:

What is the difference between standard, advanced, and multi-threaded solvers?

Answer: The differences between these solver options are described as follows:

Solver Options

Standard solver
- best for small problems
- utilizes only single core/CPU
- provides full instability information, which is useful for checking model stability before a long analysis

Multi-threaded solver
- best for medium to large problems
- fully utilizes all cores/CPUs
- fully runs in RAM for speed
- provides no instability information

Recommendations:
- Use the Standard or Advanced (default) solver to check for stability early in the development of models.
- Modal analysis using eigen vectors can help find instabilities.
- Switch to the Multi-threaded solver for speed when the model is well developed and stable.
- Use the Advanced solver instead if the model is too large and the Multi-threaded solver reports memory limitations.

GUI process
- best for small problems
- analysis runs within the software, such as with SAFE.exe
- benefit: less disk operations (I/O) are performed
- drawback: the software itself consumes memory, leaving less available for analysis, which slows operations and prevents the ability to run larger models

Separate process
- best for medium to large problems
- the analysis model is written to the disk and read by CSI.SAPFire.Driver.exe, then analysis is run within CSI.SAPFire.Driver.exe
- benefit: the analysis engine has access to more memory, therefore larger problems can be solved and analysis runs faster
- drawback: time is lost to write and read the analysis model

Auto
- default setting
- the necessary memory is estimated, then compared to the physical ram available. If enough RAM is available, the analysis runs in GUI process. If not, it is shelled out to CSI.SAPFire.Driver.exe.

If the Analysis Process option is set to “Separate Process”, it is possible to run up to eight load cases in parallel and significantly reduce the total analysis time for models with many long-running load cases.
Running multiple load cases in parallel puts a higher demand on system resources (e.g. memory, CPU, and disk) than running them sequentially, and can slow down other tasks running on the system, hence is best for fast, dedicated analysis machines.
Running more load cases than the number of physical cores in parallel generally does not speed up the analysis, hence is not recommended.