Jedes Simulationsteam findet irgendwann seinen bevorzugten Solver, und das aus gutem Grund: Lizenzkosten, Teamvertrautheit und bestehende Modellbibliotheken drängen alle zur Standardisierung auf eine Plattform. Das ist eine vernünftige betriebliche Entscheidung. Technisch ist sie weniger vernünftig, denn LS-DYNA, PAM-CRASH, Nastran und Abaqus wurden gebaut, um unterschiedliche Arten von Fragen gut zu beantworten, und sich einfach auf den gerade geöffneten Solver zu verlassen, kann die Analyse selbst unbemerkt formen.
Wo die Solver-Wahl wirklich zählt
Explizite Solver wie LS-DYNA und PAM-CRASH sind für kurzzeitige, hochgradig nichtlineare Ereignisse gebaut - Crash, Impact, Falltests - bei denen große Verformungen und Kontakt in Millisekunden ablaufen. Implizite Solver wie Nastran und Abaqus sind für das Gegenteil gebaut: lineare und nichtlineare Strukturanalyse, statische und dynamische Belastung, modale und Ermüdungsstudien, bei denen sich die Physik über einen längeren Zeitraum abspielt und Stabilität wichtiger ist als reine Geschwindigkeit pro Schritt. Ein Crash-Ereignis durch einen impliziten Solver laufen zu lassen, oder eine langsame strukturelle Ermüdungsstudie durch einen expliziten, ist technisch möglich und praktisch mühsam - Sie kämpfen mit dem Solver, statt die technische Frage zu beantworten.
Wo es weniger stark ins Gewicht fällt
Bei vielen gängigen linearen Strukturanalysen liefern Nastran und Abaqus vergleichbare Ergebnisse, und die Wahl hängt eher von Teamvertrautheit, bestehenden Modellbibliotheken oder nachgelagerten Berichtsanforderungen ab als von einem echten technischen Vorteil. Das ist genau die Art von Entscheidung, bei der „welche Lizenz wir gerade haben“ eine völlig legitime Antwort ist. Der Fehler liegt nicht darin, einen Standard-Solver zu wählen, sondern darin, diesen Standard nie zu hinterfragen, wenn das vorliegende Problem nicht dazu passt.
Warum wir solverunabhängig bleiben
Solverunabhängigkeit ist keine Marketingposition, sie verändert, wie ein Projekt von Tag eins an abgegrenzt wird. Statt zu fragen „wie bringen wir das im vorhandenen Solver zum Laufen“, lautet die erste Frage „was braucht diese Physik tatsächlich“. Meistens landet man bei einer vertrauten Antwort. Gelegentlich nicht - und genau dann bewahrt Solver-Flexibilität ein Projekt davor, ein schlechtes Ergebnis pünktlich statt ein gutes Ergebnis etwas später zu liefern.
Nicht sicher, welcher Solver zu Ihrem nächsten Projekt passt? Sehen Sie sich unsere Multi-Solver-Simulation an oder sprechen Sie mit uns über die Details.