SOFiSTiK Forum

Substantial improvements have been implemented into the DYNA/ASE/TALPA solvers of the 23 versions.



Abstract

Acceleration factors were observed up to 10. The new, direct SPARSE solver can be obtained without the need to buy additional licenses.



SOFIMSHA / SOFIPLUS / ELLA / STAR2 already are or will also be switched.

During the band width optimization it will already be determined which solver should be applied (CTRL OPTI 2 or 50)

Parallelization however can only be conducted with an ISOL (Iteration Solver) license.



More exact

Generally one differentiates between iterative and direct solvers – the iterative one work with the least of matrix entries and are usually the fastest in solving the equation system. The speed advantage however is used up by many load cases. Example: A high rise building with 200.000 dof and 5 load combinations can optimally be analyzed this way. A bridge with 3.000 dof and 500 load cases should better by solved directly.



Of the iterative solvers we’ve decided for the so called Preconditioned Conjugate Gradient Solver, our default for CTRL SOLV 2 is the so called Cholesky pre-conditioning. Entry CTRL SOLV 2, requires ISOL license, the fastest per load case, maybe in case of the iterative solving instabilities will be overseen therefore warning as of 2nd Order Theory. By now a quite good parallelization.



We now have 3 (!) of the direct solver.



The old blocked Gauss-Skyline Solver (now new CTRL SOLV 9): Can be recognized at the classical ‘Tringulisation Block xx’, divides the coefficient matrix stored in the so called Skyline Scheme into several blocks and inverts these block by block. M parameter can influence the block size, due to historical reasons, as parts of the equation system then don’t have to be held in the RAM (in-core). Band width optimization is very important for this type of solver. Up until now it was our default solver.



The new parallelizable in-core Gauss Skyline (CTRL SOLV 1 and default for band width optimization, which means CTRL OTPI 0,1,2, systems): categorically keeps the equation system in RAM (by now one usually has a lot of it), uses in case of ISOL licensing the parallelization on multi-processors and/or multi core machines. Faster than the old Gauss Solver and can correspondingly be sped up through parallelization (already observed, up to factor 2).



The new Sparse Solver (CTRL SOLV 3 and default on minimum Fill-In, which means CTRL OPTI 50 optimized systems): works as well in-core but stores the coefficient matrix very clever, doesn’t need time consuming band width optimization (would rather damage) but stores on the so called minimum Fill-in optimized storage which is very fast. Much faster than the Gauss Solver (observed for 80.000 dof already speed-up of 5 compared to Gauss), absolutely state-of-the-art and just a direct solver, can also be applied for the above mentioned bridge. Parallelization runs, but it is still being worked on.





Which of these (last two) new solver will be applied as default, depends on the type of optimization, which means if a band width optimization runs when exporting from SOFiPLUS, then Gauss – if a optimization for the Sparse solver runs, then Sparse solver. Therefore the manual entry CTRL SOLV 1 or 3 is then not require at first or could even damage.



Very exact

See attached manual pages for CTRL SOLV