In seinem Bericht über das 6. Treffen der FDS-Usergroup in Berlin fasste Gregor Jäger die einzelnen Vorträge der Referenten zusammen und bewirkt zumindest mit dem Fazit eines Vortrages („Validierungsrechnungen für ANSYS CFX und FDS anhand eines spezifischen Brandszenarios“) reges Erstaunen bei mir:
„Am zweiten Tag berichtete Prof. Krause (Universität Magdeburg) von Validierungsrechnungen mit den Programmen ANSYS CFX und FDS. Gegenstand des im Rahmen der Masterarbeit von Herrn Rabe an der Beuth Hochschule für Technik in Berlin durchgeführten Vergleichs war die am NIST unter der Bezeichnung Dunes 2000 Experiments durchgeführte Versuchsreihe (NIST TN 1455-1). Aus den Ergebnissen der Untersuchung zog Prof. Krause die These, dass die heute zur Verfügung stehenden Programme ANSYS CFX mit einem Fahrzeug der Marke Audi und das Programm FDS mit einem Auto der Marke Trabant vergleichbar sind.“
Was für ein Fazit.
Intention
Mir stellen sich bei solch einem Fazit mehr Fragen, als dass ich Antworten bekommen hätte:
Was will uns Prof. Krause mit seinem Vortrag und dem (sicher absichtlich) provozierenden Fazit genau sagen?
- Vergleichbar mit einem Bürger der DDR hat jeder seriöse Brandschutzingenieur mit Interesse an numerischen Ingenieurmethoden des Brandschutzes nur eine Wahl: er nutzt FDS oder geht zu Fuß (Handformeln oder Anwendung von rein deskriptiven Regelwerken) oder
- FDS hat für den Brandschutz das bewirkt, was etwa Henry Ford oder eben der Trabi im Osten geschafft hat: eine Demokratisierung der individuellen Fortbewegung, also dass jedem fachlich entsprechend ausgebildetem Ingenieur heute fortschrittliche numerische Werkzeuge zur Verfügung stehen?
Ich stimme beiden Aussagen (bedingt) zu, hätte mir aber gewünscht, dass beide Aussagen deutlicher vermittelt und begründet werden, da das Fazit sonst aufgrund seiner weitgehend undokumentierten Herleitung zu Missverständnissen führen kann. Ein Beispiel hierfür?
Ein Vertreter eines großen kommerziellen CFD-Programmpaketes könnte sich in seiner, bei jedem neuen Release wiederkehrenden, Werbeaussage bestätigt fühlen „Jetzt noch bessere Ergebnisse in noch kürzerer Zeit!„
Vergleiche was zu vergleichen ist
Das würde übertragen auf den „Krause’schen Vergleich“ bedeuten, dass Ansys CFX von 0 auf 100 km/h in ca. 4,2 Sekunden beschleunigt (aktueller Audi S8), während FDS hierfür knapp 25 s benötigt (Trabant).
Ist FDS unter vergleichbaren Randbedingungen ca. 6 x langsamer als die großen kommerziellen CFD-Pakete? Fragwürdig.
In der Regel sind solche Benchmarks großer kommerzieller CFD-Programmpakete eher theoretischer Natur oder vergleichen gar die sprichwörtlichen Äpfel mit Birnen. Ein kommerzieller Druck im Hintergrund ist hier kontinuierlich gegeben.
Die ersten 64-bittigen Programmversionen wurden beispielsweise pauschal mit einem satten Geschwindigkeitsvorsprung gegenüber den 32-bittigen Versionen beworben, was sich erstmal bezweifeln lässt. Tatsächlich wurde als Referenzbeispiel bspw. eine Simulation gewählt, die deutlich mehr als 4 GB RAM benötigte, wodurch 32-bittige Programmversionen von vornherein deutliche Nachteile aufwiesen. Als ausschließlich 32-bittige Programmversionen zur Verfügung standen, wurden solche Simulationen allerdings nicht als Referenzbeispiel für die eigenen Benchmarks gewählt, weil die Ergebnisse inakzeptabel schlecht gewesen wären und nichts über die tatsächliche Leistungsfähigkeit der Solver ausgesagt hätten.
Ein weiteres Beispiel für „Äpfel-und-Birnen“ bzw. neue Fragen statt Antworten? In Ihrem Vortrag zum „Workshop Brandschutzforschung“, der parallel zu den zweiten Magdeburger Brand- und Explosionsschutztagen gehalten wurde, „Vergleich von Computational Fluid Dynamics-Programmen in der Anwendung auf Brandszenarien in Gebäuden“ Folie 11 [2] (der Vortrag basiert augenscheinlich auf derselben Arbeit von Herrn Frederik Rabe) wird beispielsweise bei einem Vergleich zwischen Ansys CFX und FDS bemängelt, dass der FDS’sche Strömungslöser im Vergleich zu CFX keine Einstellmöglichkeiten der Solver-Parameter (zum Konvergenzverhalten?) bietet.
Hier frage ich mich, was die Autoren uns damit sagen wollen? Bei einem direkten 2-Schritt-Löser ist das eigentlich nicht verwunderlich, nicht negativ und schlicht eine Eigenschaft eines direkten Lösers. Zur Ehrenrettung: gemeint sein könnte das iterative Lösungsverfahren bei der Verwendung mehrerer MESHes in FDS, nur wurde das 1. nirgends dokumentiert und 2. stimmt die Aussage betreffend der fehlenden Parameter hier nicht (mehr).
Voraussetzungen für eine Vergleichbarkeit
Und hier kommen wir zu einem weiteren Kritikpunkt an wertenden Aussagen zu Ergebnissen von FDS-Simulationen:
Werden die durchgeführte Simulation und das als Vergleich dienende Experiment nicht vollständig veröffentlicht (bspw. Original-Messreihen, Angaben zur Genauigkeit der Messungen mit statistischen Wahrscheinlichkeiten, Randbedingungen der durchgeführten Experimente, Eingabedateien etc.), um eine Ãœberprüfbarkeit der verglichenen Simulationen bzw. Brandversuche zu ermöglichen, ist jede Aussage zur Qualität von FDS von vornherein kritisch zu hinterfragen und schlechtestenfalls als wertlos anzusehen. Warum? Genau genommen bedeuten die Ergebnisse des Vortrags nicht „FDS ist ein Trabi, Ansys CFX ein Audi A8, Fluent ein 5er BMW“, sondern in der vorgestellten Form nichts weiter als „FDS fährt sich mit dem Team Krause-Rabe als Fahrer wie ein Trabi, Ansys CFX wie ein Audi A8„. Das kann aber, bei allem Respekt, auch schlicht am Fahrer und seinem Copiloten liegen. Der Wert der getroffenen Aussage geht mit Blick auf die Qualitäten von FDS gegen Null.
Leider muss die Präsentation der Arbeit von Herrn Rabe durch Herrn Prof. Krause vor diesem Hintergrund kritisch hinterfragt werden:
- Das Darstellen von zwei Bildern nebeneinander als Auswertung der Ergebnisse ist für solch eine vernichtende Wertung, wie durch Herrn Prof. Krause vorgebracht, einfach nicht ausreichend. Um zu so einem Schluss zu kommen, muss man schon belastbare Zahlen liefern, um den vermuteten Fehler auch quantifizieren zu können.
- Die Auswertungen sind nicht annähernd ausreichend dokumentiert. Zu Beginn des Vortrags wird zumindest noch dokumentiert WAS und WIE hier überhaupt gerechnet wird (LES, RANS, FDS mit einem MESH oder mehreren, welche Version wurde verwendet, welche anderen Randbedingungen wurden gesetzt). Kurz darauf geht der Vortragende großzügig über solche Kleinigkeiten hinweg.
- Die bebilderten Vergleiche sind im Wesentlichen Vergleiche zwischen FDS und CFX. Dies erlaubt lediglich die Aussage: FDS ist anders als CFX (oder eben CFX ist anders als FDS). Die Aussage A ist besser als B lässt sich hierdurch allerdings nicht ableiten.
- Wenn man schon Bilder vergleichen will ohne eine belastbare quantitative Auswertung zu bieten, muss darauf hingewiesen werden, dass die grafischen Auswertungen teilweise weitgehend übereinstimmen (Folien 10 und 11 [1]). Ein Fazit wie vorgetragen, lässt sich daraus ganz gewiss nicht ableiten. Andersherum würde ich fragen: „Wenn mein Trabi in 5 Sekunden von Null auf 100 km/h beschleunigt, lohnt dann die Investition von 120.000 € in einen Audi S8?“.
- Ein Highlight des Vortrages: der erste quantitative Vergleich auf Folie 19 des Vortrags [1]. 2 Diagramme, gleich mehrfach unterschiedlich skaliert, die Beschriftung der Messreihen in der Legende vertauscht, keine Mittelung der oszillierenden Werte (noch „unvergleichbarer“ hätte man die Ergebnisse eigentlich nur noch präsentieren können, wenn man Fahrenheit in einem Diagramm mit Kelvin im anderen verglichen hätte) und dann die Krönung: die FDS-Simulationsergebnisse liegen teilweise deutlich näher an den Messwerte als die von CFX.
Die Frage an den Vortragenden kann eigentlich nur noch lauten: „Herr Prof. Krause, was wollen Sie uns genau sagen? Trabi schlägt Audi?„. Vielleicht stört sich der Vortragende aber auch an den Oszillationen (durch Anwesende wurde mir das berichtet) und nicht an den eigentlichen Simulationsergebnissen (die bei FDS genauer an den Messreihen liegen als bei Ansys CFX). Sollte dies tatsächlich das Ziel der geäußerten Kritik sein, bin ich jetzt restlos verwundert. Die Messung der Temperatur in einer turbulenten Strömung heißer Gase kann in FDS über den Befehl &DEVC mit der Messgröße ‚TEMPERATURE‘ erfolgen. Hier gibt FDS schlichtweg auf direktem Weg die Gastemperatur aus und dass die in Grenzbereichen zwischen heißem und kühlem Fluid durchaus oszillieren kann, sollte unstrittig sein.
Dass Messergebnisse in Realität nicht diese Schwankungen aufweisen, hat einen anderen Grund: Messfühler haben eine Masse und die erwärmt sich eben langsamer, wodurch Oszillationen ausgefiltert werden (siehe die untenstehende Abbildung).
Durch die einfache Nutzung der Zielgröße „THERMOCOUPLE“ werden das „Problem“ behoben und physikalische „korrekte“ Ergebnisse angezeigt. Darüber hinaus fallen mir auf Anhieb noch einige andere Lösungen für dieses „Problem“ ein, angefangen bei der Nutzung der FDS’schen Statistik-Funktionen, geometrischer Mittelwertbildung bis hin zur Anwendung von entsprechenden Funktionen in Tabellenkalkulationsprogrammen o. ä.
Das alles soll hier aber keine Rolle mehr spielen. Vielmehr stellt sich mir hier nur noch eine Frage: Gemessen an so einem vernichtenden Fazit, handelt es sich hier wirklich um einen Fehler in FDS oder hat vielleicht der Nutzer nicht die nötige Sorgfalt bei der Auswertung und Eingabe walten lassen? Ich lasse die Frage unbeantwortet. - Auf Folie 22 [1] wird OpenFOAM (so wird es übrigens richtig geschrieben) noch als Ersatzteillager dargestellt, auf Folie 26 [1] dann stolz in der eigenen Anwendung präsentiert.
- Wie kommt es eigentlich zu der Bewertung von Fluent als BMW 5er Limousine auf Folie 22 [1]? Der gesamte Vortrag enthält keine einzige Aussage zu Fluent.
FDS im Vergleich zu anderen Programmpaketen
Vielleicht wollte der Vortragende aber auch etwas ganz anderes zum Ausdruck bringen: „Ansys CFX ist weder schneller noch qualitativ besser im Bereich der Brandsimulation, aber es ist deutlich komfortabler!„. Dieser Aussage kann man einerseits eine gewisse Rechtfertigung nicht absprechen, andererseits ist sie weitgehend trivial (und leider ebenfalls noch nicht einmal dargelegt). Aussagen wie „Smokeview retro“ Folie 23 [1] könnten spielend gekontert werden mit dem Gegenargument „’Validierungsrechnungen für ANSYS CFX und FDS anhand eines spezifischen Brandszenarios‘ sehr retro“ 🙂 (Der Leser möge mir hier meine flapsige Äußerung verzeihen, aber in diesem Stil kommen wir wirklich nicht weiter.). Die Kritik an Smokeview ist außerdem technisch falsch. Smokeview ist aus meiner Sicht ein guter und vor allem exakt auf FDS und die Bedürfnisse von Brandschutzingenieuren ausgelegter Postprocessor. Glenn Forney arbeitet kontinuierlich an einer Verbesserung von Smokeview und Verbesserungsvorschläge werden teilweise binnen weniger Tage eingearbeitet. In Wirklichkeit zielt Prof. Krauses´ Kritik (wenn man „retro“ überhaupt noch als Kritik bezeichnen will) wohl auf GLUT (das „OpenGL Utility Toolkit“), mit dem die grafische Oberfläche Smokeviews umgesetzt wurde. Glenn Forney weiß um das Thema und plant selber die Implementierung eines leistungsfähigen Ersatzes zu GLUT.
Die FDS-Entwickler beschränken sich selber auf das Entwickeln des eigentlichen Simulationskerns und eines Postprocessors, ausdrücklich nicht auf einen Preprocessor und die Ingenieure der ehemaligen DDR mussten den Trabant unter den Randbedingungen einer kommunistischen Marktwirtschaft mit dem Ziel der Mobilisierung eines ganzen Landes entwickeln, nicht mit einem luxuriösen Sportwagen im Hinterkopf. Im Widerspruch zu der oben vermuteten Kernaussage des Vortrags zeigt das Autoren-Team Rabe/Prof. Krause dann in seinem Vortrag [2] wieder Screenshots von Pyrosim. Ist das Modellieren von Simulationen mit FDS also doch nicht ganz so unkomfortabel wie auf Folie 23 [1] dargestellt (http://code.google.com/p/fds-smv/wiki/Third_party_Tools)?
Es ist unstrittig, dass die großen kommerziellen CFD-Programmpakete in vielen Bereichen deutliche Vorteile gegenüber FDS bieten. Nur war und ist es eben niemals das Ziel der FDS-Entwickler gewesen, in allen Bereichen konkurrieren zu wollen. Hier vergleicht der Vortrag schon nicht mehr einen Audi mit einem Trabant, sondern bspw. ein Flugzeug mit einem Auto und kommt zum Schluss: „Das Auto an sich ist unterlegen, denn es kann nicht fliegen!„.
Andererseits hat FDS in dem Gebiet auf dem es konkurrieren will, durchaus Vorteile gegenüber den großen CFD-Programmpaketen. Ich wage zu bezweifeln, dass ein Anfänger mit diesen mit ungefähr 10 – 20 Zeilen Eingabe eine geometrische einfache Brandsimulation erstellen kann. Auch habe ich für diese noch kein systematisch veröffentlichtes V&V-Paket mit Bezug auf den Brandschutz gesehen, das im Umfang mit dem von FDS mithalten kann und eine nennenswerte Nutzerschaft im Interessengebiet Brandsimulation ist mir auch unbekannt. Letztendlich zielt FDS anders als viele andere Programme genau auf den Anwenderkreis der Brandschutzingenieure. Als ein solcher bin ich dankbar dafür, dass die Entwickler mich von der Aufgabe entbinden bspw. aus zehn verschiedenen Turbulenzmodellen wählen zu müssen, um qualitativ hochwertige Ergebnisse erzielen zu können.
Nicht zuletzt machen die Randbedingungen bei der Nutzung von FDS das Programm auch für Hochschulen sehr interessant, was letztendlich dazu führt, dass Brandschutzingenieure tendenziell mit FDS umgehen können und, hier sind wir uns hoffentlich alle einig: gemessen an der großen Masse der Anwender liegen die Probleme bei der Anwendung von CFD-Programmen im Brandschutz heute vielfach beim Anwender, nicht beim verwendeten Programm.
Warum dieser Kommentar?
Der Leser dieser Zeilen wird es bereits gemerkt haben, wenn nicht gebe ich es hier freiwillig zu, das Fazit des Vortrages hat mich persönlich ein wenig geärgert. Hierfür gibt es im Wesentlichen drei Gründe:
- Provokante Schlüsse zu ziehen ist ein probates Mittel, um das manchmal dröge Themengebiet der numerischen Simulation der Ausbreitung von Verbrennungsprodukten griffig zu vermitteln. Das machen viele Vortragende (in der FDS-Usergroup fallen mir hier auf die schnelle beispielsweise Herr Rogsch, Frau Dr. Kilian oder Herr Münch ein, deren Arbeiten an bzw. zu FDS von mir genau so sehr geschätzt werden wie ihr Vortragsstil) und daran gibt es nichts auszusetzen. Ein signifikanter Unterschied zu der Arbeit von Herrn Prof. Krause ist der, dass alle 3 Vorgenannten signifikante Beiträge zur Entwicklung von FDS beigetragen haben und FDS auch dank ihnen heute besser ist als noch vor einigen Jahren, wovon wiederum alle Anwender und auch die Entwickler profitieren. Die Ergebnisse der vorgestellten Arbeit sind in der präsentierten Form jedoch weitgehend wertlos und inhaltsfrei. Die Präsentation selber ist eher kritisierenswert als das kritisierte Programm. Eine Verbesserung kritikwürdiger Punkte lässt sich so nicht erreichen.
- Will man dass Fazit seiner Arbeit unbedingt in solch provokanter Form äußern, sollte man meiner Meinung nach darauf achten, dass man sich im Vorfeld durch eine saubere Aufarbeitung der durchgeführten Arbeit und eine aussagekräftige Auswertung der Ergebnisse absichert. Weniger ist hier manchmal mehr. Tut man das nicht und macht sich angreifbar bzw. äußert weitgehend wertlosen Allgemeinplatz als vernichtendes Ergebnis, könnte der ein oder andere auf die Idee kommen, dass es gar nicht um das Ergebnis, sondern um „15-Minutes-of-Fame“ geht. Vor diesem Hintergrund wirkt der Vergleich der Arbeit von wahrscheinlich mehreren hundert Softwareentwicklern und Mathematikern auf der einen und einer handvoll Entwickler auf der anderen Seite auf mich persönlich deplatziert und unangemessen. Vor allem gilt dies, wenn der Autor eines solchen Vortrags selber damit nichts zur Verbesserung von FDS beiträgt.
- Die Entwickler von FDS und jeder ambitionierte Anwender wissen um die Limitierungen von FDS und zumindest die Entwickler arbeiten hart, mit sehr viel persönlichem Engagement, an der stetigen Verbesserung von FDS in vielen Bereichen. Wer die Entwicklung der vergangenen Jahre beobachtet hat, weiß was hier geleistet wurde.
Ein sehr wichtiges Werkzeug hierfür war und ist die wissenschaftlich saubere Analyse der einzelnen Modelle und deren Auswirkung auf die praktisch relevanten Ergebnisse.
Eine sehr wichtige Funktion kam hierbei in den vergangenen Jahren den verschiedenen Hochschulen zu, was wiederum durch die offenen Randbedingungen bei der Anwendung von FDS unterstützt wurde.
Wenn nunmehr der Vortrag eines Vertreters einer namhaften deutschen Hochschule es schafft, alle oben genannten Kritikpunkte in sich zu vereinen ohne einen Impuls zu einer Verbesserung von FDS zu geben, empfinde ich es mit Blick nach Magdeburg als schade, dass eine renommierte Hochschule ihr Potential so vergeudet.
Probleme mit Ingenieurmethoden
In Wirklichkeit liegen unsere Probleme bei der Sicherung von Qualität bei der Anwendung von numerischen Ingenieurmethoden des Brandschutzes aber auch (nicht nur) an anderer Stelle:
- es gibt aktuell schlicht kein durchgängiges System der Qualitätssicherung bei der Anwendung von numerischen Ingenieurmethoden,
- von einer fachlich qualifizierten Prüfung auf Augenhöhe kann keine Rede sein,
- das Fehlen quantitativer Vorgaben zu den Randbedingungen macht aus den Ingenieurmethoden häufig Verhandlungssache und
- auch wenn mittlerweile einige Hochschulen das Themengebiet der Brandsimulation auf dem Lehrplan haben, kommen hier in der Regel ganz sicher keine fertig ausgebildeten Ingenieure von den Hochschulen (Ausnahmen bestätigen die Regel) und die weiterführende fachliche Qualifikation in diesem Spezialgebiet bedarf nach wie vor eines hohen persönlichen Einsatzes.
Zusammenfassend muss man leider mit Blick auf den diskutierten Vortrag Folgendes sagen:
Der Vortrag enthält
- viel Triviales (Abrisskanten haben Einfluss auf die Strömung, nicht näher quantifiziert und ausschließlich anhand eines Bildes aufgezeigt)
- einige nicht näher dargelegten Behauptungen („Smokeview retro„)
- unnötig Provokantes (Audi und Trabant)
- unsaubere Auswertungen (mehrfach unterschiedlich skalierte Diagramme, die auch noch falsch ausgewertet werden)
- und schlichtweg unsinnige bzw. falsche Behauptungen (keine Einstellmöglichkeiten des Strömungslösers).
Die ausgezeichnete Arbeit von Herrn Rabe als Grundlage für den Vortrag liegt mir leider nicht vor, so dass ich hierzu nichts sagen kann.
Wie ernst das Fazit von Herrn Prof. Krause hinsichtlich FDS genommen werden kann, muss vor diesem Hintergrund jeder für sich entscheiden.
Eine persönliche Anmerkung:
Auch wenn ich meine Kritik am Vortrag von Herrn Prof. Krause (ausdrücklich nicht an der Arbeit von Herrn Rabe, diese liegt mir nicht vor) durchaus launisch formuliert habe, möchte ich nicht missverstanden werden. Leider ergab sich noch nicht die Möglichkeit, Herrn Prof. Krause persönlich kennenzulernen. Vor dem Hintergrund seiner Vita halte ich es für nahezu ausgeschlossen, dass er alle genannten Kritikpunkte an seinem Vortrag nicht hätte besser lösen können.
Der Kern des Problems liegt oft an anderer Stelle: ein guter Vortrag kostet eine Menge Zeit. Was liegt da näher als auf die ausgezeichnete Arbeit eines Studenten zurückzugreifen und diese persönlich souverän und provokant aufgepeppt zu präsentieren? Wenn Herr Prof. Krause sich im Voraus schon selber entschuldigt, dass er nicht mehr die Zeit gehabt hat, den Vortrag sprachlich zu homogenisieren („Ich bitte um Nachsicht: Languages sind a little bit durcheinander mixed-up.„), könnte man diesen Verdacht hegen. Ob das Ergebnis in diesem Fall ein befriedigendes Niveau erreicht, lasse ich offen.
Quellenangaben:
[1] Frederik Rabe, Ulrich Krause, 6. Anwendertreffen der FDS-Usergroup, 15. bis 16.11.2012, Berlin, Tagungsband – Zusammenstellung der Vorträge, „Validierungsrechnungen für ANSYS CFX und FDS anhand eines spezifischen Brandszenarios“
[2] Frederik Rabe, Anja Hofmann, Ulrich Krause, „Vergleich von Computational Fluid Dynamics-Programmen in der Anwendung auf Brandszenarien in Gebäuden„
Sehr geehrter Herr Prof. Krause,
vielen Dank für Ihre ausführliche Antwort auf meinen Beitrag.
Leider ist er nicht mit „Klarnamen“ unterzeichnet und ich kenne nur Boris Jelzin und Boris Becker, von denen ich nicht glaube, dass sie sich in diesem Blog äußern (der eine ist tot und der andere kann nicht richtig deutsch).
Wir haben also ein Semi-Blind-Date. Sei’s drum.
Auch wenn Blind-Dates je nachdem ihren ganz eigenen Charme haben können, möchte ich unter keinen Umständen den Eindruck erwecken mich hinter einem Pseudonym im Internet verstecken zu wollen. Da wir auf F-Sim nur zu dritt posten, bin ich stillschweigend davon ausgegangen, dass meine Identität klar ist (siehe hierzu auch den Kommentar von Gregor Jäger). Mein Name ist Boris Stock, ich bin neben Herrn Gregor Jäger und Herrn Karl Wallasch einer der Betreiber von F-Sim.
Was wollte ich mit meinem Beitrag auf dem User Group Meeting sagen: Ich habe ja gar nichts gegen FDS, ich benutze es ja selbst. Ja! Ehrlich!
Natürlich ist es ein gewaltiger Fortschritt, in Brandsimulationen FDS zu benutzen gegenüber Zonenmodellen. Natürlich sind Zonenmodelle wegen der Nicht-Berücksichtigung des
Strömungsgescwindigkeitsfeldes für Brandsimulationen gänzlich unbrauchbar.
(Upps, jetzt habe ich wahrscheinlich den nächsten erzürnten Blogeintrag provoziert.)
In der Tat haben Sie das (bestimmt nicht ganz unbeabsichtigt) gerade getan. Als Ingenieur erlaube ich mir das mit Blick auf einige wenige, stark eingeschränkte Fragestellungen unter begrenzten Randbedingungen auch anders zu sehen. Den „erzürnten Blogeintrag“ überlasse ich aber hier anderen. Diese Schlacht wurde schon vor ca. 10 Jahren in der Fachpresse von namhaften Vertretern der Brandschutz- bzw. Entrauchungsszene geschlagen. Meines Wissens nach ohne klares Ergebnis. Zumindest gibt die eine Fraktion immer noch an, Zonenmodelle seien unbrauchbar (und hoffen u. a. auf eine hohe Auslastung ihres Windkanals oder ähnlichem), während die andere Fraktion eifrig Parameterstudien rechnet und auf das Gesetz der großen Zahl verweist.
Durchaus weiß ich auch zu schätzen, welchen Beitrag wir den amerikanischen Steuerzahlern zu danken haben, dass sie uns dieses Werkzeug schenken.
So unterschiedlich können Sichtweisen auf ein und dasselbe sein. Mein Dank ging immer an die Entwickler, sei es beim NIST oder sonst wo auf der Welt. Das ist, als würde man den Ansys-Kunden für CFX danken, denn ohne die, könnte Ansys auch kein CFX entwickeln und vertreiben.
Es ist nur so: ein explizites Differenzenverfahren auf einem orthogonalen, kartesischen Gittern ist die simpelste Form, partielle Differentialgleichungen numerisch zu lösen.
Das ist an sich nicht schlecht, aber es limitiert die Anwendungsmöglichkeiten vehement. Bei gekrümmten oder schiefwinkligen Konturen ist eben Ende der Fahnenstange.
Das ist unstrittig. Die FDS-Entwickler geben seit einiger Zeit selber an, dass Sawtooth nicht richtig funktioniert, IBM noch ein Weilchen dauert und man aktuell schlicht keine Möglichkeit hat mit FDS gekrümmte Flächen exakt zu simulieren. Ob man mit diesen Vereinfachungen in Form von Fehlern bei den Ergebnissen in der praktischen Anwendung leben kann und ob es wirklich zielführender ist ganz ohne physikalische Erkenntnisse mit der Brandschutzdienststelle etwas zwischen 2 und 5 % geometrischer Öffnungsfläche auszuhandeln, liegt in der Hand des Anwenders. Mir sind leider auch keine Aussagen über die tatsächlichen resultierenden Fehler aus diesen Vereinfachungen bekannt.
Ein luftgekühlter Zweitakt-Ottomotor ist auch die simpelste Form eines Verbrennungsantriebs für Straßenfahrzeuge.
Deshalb hinkt der Trabi-Vergleich NICHT.
De facto ist es gar kein Vergleich, sondern irgendwo im Bereich der Rhetorik anzuordnen. Als älterer Ostdeutscher würde ich mit einem Auto der Marke Trabi vielleicht sehr gute emotionale Erinnerungen an „die gute alte Zeit“ verbinden, als Porschefahrer den Wagen für eine Zumutung halten. Als Dacia Ostdeutschlands ist der Wagen ein erschwinglicher PKW, der Massen mobilisiert hat, jedoch im Vergleich zu einem gebrauchten VW technisch veraltet. „Vergleiche“ dieser Art bringen fachlich einfach nichts – für Niemanden. Vor dem Hintergrund einer sachlichen Analyse ist es vielleicht ein adäquates rhetorisches Mittel, mehr nicht.
Zwischen dieser Eigenschaft von FDS und den kommerziellen CFD-Codes liegen Welten.
Dem stimme ich uneingeschränkt zu.
Stichworte sind: unstrukturierte Gitter, hybride Gitter, adaptive Gitter, moving meshes, Mehrgitter-Verfahren, Grenzschichtadaptierung…
Alles keine Kinkerlitzchen – manchmal braucht man so etwas, z.B. wenn man relativ kleine Öffnungen in großen Räumen auflösen will.
Ich weiß das und bin begeistert von Randy McDermotts Plänen über den Zwischenschritt der embedded Meshes ein adaptives Mesh refinement implementieren zu wollen. Im Bereich der LES-Simulation ist das eine Art heiliger Gral der hinsichtlich der Qualität der Ergebnisse einen Quantensprung bedeutet. Wie sich FDS dann in einigen Jahren in Kombination mit der Immersed Boundary Method schlagen wird, werden wir sehen – genau auf diesem orthogonalen, kartesischen Gitter.
Einige logische Brüche in der Argumentation von „Boris“ sind evident. Einerseits betont er die erforderliche tiefgründige Qualifikation der Anwender (worin ich vollkommen zustimme), andererseits stellt er es als Vorteil dar, dass Anfänger mit 10 bis 20 Zeilen Brandsimulationen
ausführen könnten.
Da sehe ich keinen Widerspruch. Auf Seminaren kann ich Seminarteilnehmer nach ca. 1 – 2 Stunden ihre ersten Simulationen rechnen lassen und darauf dann aufbauen. Bei den großen, kommerziellen Programmpaketen funktioniert das definitiv nicht.
Hierzu möchte ich aber auch meinen eigenen Beitrag zitieren:
„In Wirklichkeit liegen unsere Probleme bei der Sicherung von Qualität bei der Anwendung von numerischen Ingenieurmethoden des Brandschutzes aber auch (nicht nur) an anderer Stelle:
• es gibt aktuell schlicht kein durchgängiges System der Qualitätssicherung bei der Anwendung von numerischen Ingenieurmethoden,
• von einer fachlich qualifizierten Prüfung auf Augenhöhe kann keine Rede sein,
• das Fehlen quantitativer Vorgaben zu den Randbedingungen macht aus den Ingenieurmethoden häufig Verhandlungssache und
• auch wenn mittlerweile einige Hochschulen das Themengebiet der Brandsimulation auf dem Lehrplan haben, kommen hier in der Regel ganz sicher keine fertig ausgebildeten Ingenieure von den Hochschulen (Ausnahmen bestätigen die Regel) und die weiterführende fachliche Qualifikation in diesem Spezialgebiet bedarf nach wie vor eines hohen persönlichen Einsatzes.“ Der Vorwurf ich wollte es befürworten, daß Anfängermit 1 – 2 Stunden „Erfahrung“ zukünftig Brandsimulationen rechnen sollten, dürfte damit entkräftet sein.
Dass es bis zur verantwortungsvollen praktischen Anwendung noch ein weiter Weg ist, sollte unbestritten sein und würde einen eigenen, umfangreicheren Beitrag füllen. Hier wird hoffentlich auch im Zuge der Basisnorm Ingenieurmethoden DIN 18009 entsprechendes kommen.
Sollten wir das wollen, dass „Anfänger“ auf Brandsimulationen losgelassen werden? Doch wohl nicht.
Das werden weder Sie noch ich verhindern können. Alles was wir dagegen tun können, ist Studenten möglichst viel mit auf den Weg zu geben. Und das oft gehörte Argument, entsprechende Simulationsprogramme müssten möglichst teuer und komplex sein, um Anfänger abzuschrecken, halte ich persönlich für Unsinn.
Außerdem entnehme ich „Boris'“ Darlegung, dass nur der Kritik äußern dürfe, der auch zur Produktentwicklung beitrage.
Also bitte! Das Recht auf freie Meinungsäußerung haben wir alle. „Boris“ nimmt sich ja auch die Freiheit, uns zu unterstellen, dass wir unser Potential vergeuden, nur weil wir uns nicht an einer bestimmten Software abarbeiten wollen.
Sollte ich den Eindruck erweckt haben Ihnen das Recht auf Ihre freie Meinung absprechen zu wollen, entschuldige ich mich in aller Form. Diese steht Ihnen natürlich nach Artikel 5 des Grundgesetzes wie jedem anderem deutschen Staatsbürger zu.
Das Gegenteil ist der Fall! Ich bitte Sie geradezu, Kritik an FDS zu äußern. Mein Problem ist nur, dass ich in Ihrem Beitrag keine sachliche Darlegung finden kann, welche die Qualität Ihrer Kritik rechtfertigen würde. Das Ganze liest sich wie die Einleitung zu einer hoch interessanten Vorlesungsreihe, nur fehlen eben die Vorlesungen.
Nehmen wir doch mal die viel kritisierte Beschränkung auf ein orthogonales, kartesisches Gitter. Das ist eine Vereinfachung die zu Fehlern führen kann. Prima, das weiß jeder, der sich auch nur ein bisschen mit der Materie beschäftigt hat. 2 Bilder nebeneinander, sehen nicht gleich aus, zackzack: FDS ist ein Trabi.
Das greift aus meiner Sicht deutlich zu kurz. Um das ganze zu einer sinnvollen Aussage zu führen, müsste man zumindest ein quantifizierbares, theoretisch hergeleitetes oder zumindest gut untersuchtes, möglichst einfaches Beispiel erarbeiten, um dann am Ende eine quantifizierte Aussage über den Fehler treffen zu können. Das ist sachliche Kritik, was Äußerungen zu einem Audi, BMW oder Trabant sind oder sein sollen oder wem sie was genau bringen sollen, ich weiß es immer noch nicht.
Hat „Boris“ sich etwa an der Weiterentwicklung der Universität Magdeburg beteiligt? Nicht, dass ich wüßte. (Kann natürlich noch nachgeholt werden, es gibt einige Fördervereine.)
Hier muss ich energisch widersprechen. Wenn ich meinen Posteingang der vergangenen Jahre durchsuche, habe ich fast den Eindruck in einer beratenden Funktion zum Thema FDS für Studenten in der Phase ihrer Diplomarbeit/Thesis mehr zu leisten als so mancher Vorlesungsbeauftragte in Magdeburg. Das muss so sein, sonst würde die ein oder andere Frage in der Form nicht kommen. Erfreuliche Ausnahmen bestätigen wie immer die Regel und davon kenne ich aus Magdeburg tatsächlich mindestens 2.
Auch ist die Zahl der Nutzer kein Hinweis auf die Qualität des genutzten Produktes, sondern nur auf die Erreichbarkeit.
Ich habe nie behauptet, dass die Zahl der Benutzer ein Kriterium für die Qualität des Programms ist. Ich behaupte, dass eine große, aktive Community rund um ein Produkt ein Vorteil ist. Zumindest schätze ich den fachlichen Austausch mit Kollegen zu dem Thema Ingenieurmethoden des Brandschutzes.
Weiter zum sachlichen Teil:
Bitte ja.
Die beobachteten Oszillationen sind eindeutig unphysikalisch. Da lt. Technical Reference Guide die Temperatur über thermodynamische Zustandsgleichungen letzlich aus der Divergenz des Geschwindigkeitsfeldes berechnet wird, müssten physikalisch erklärbare Oszillationen eine Periodendauer haben, die mit der Fluktuation des Geschwindigkeitsfeldes korreliert.
Also heißt das jetzt auf einmal, dass die Oszillationen selber nicht unphysikalisch sind, nur deren Frequenz nicht stimmt? Wenn dem so ist: wo sind die Oszillationen bei CFX hingekommen?
(Wirbelradius/Umfangsgeschwindigkeit). Stattdessen ist die Periodendauer der Oszillationen der Zeitschrittweite zuzuordnen.
Ich habe leider nicht die Rohdaten der Simulationen von Herrn Rabe, aber das möchte ich doch erst einmal bestreiten. Ich weiß nicht welche Geschwindigkeiten anlagen und welche Zellgröße Herr Rabe genutzt hat, aber in dem entsprechenden Diagramm würde ich (wenn die Messergebnisse vollständig und nicht nur auszugsweise genutzt werden) von einer Frequenz von ca. 0,5 Hertz ausgehen. Die tatsächliche Zeitschrittweite bei der Simulation mit FDS dürfte deutlich kleiner gewesen sein.
Außerdem tauchen die Oszillationen in den Vergleichsrechnungen mit CFX nicht auf.
Was natürlich als Beweis für die fehlenden Qualitäten von FDS genau gar nichts zu bedeuten hat. Genau genommen wissen weder Sie noch ich noch sonst Jemand außerhalb von Ansys genau was CFX überhaupt macht, da es leider nicht open source ist (und das ist nicht gleichbedeutend mit kostenlos). Gegebenenfalls haben die CFX-Entwickler dokumentiert was sie glauben da implementiert zu haben, nur kann das eben keiner überprüfen, bestenfalls wieder glauben oder durch reverse engineering probieren zu überprüfen. Vielleicht mittelt CFX ja? Oder es filtert Oszillationen aus? Oder es nutzt ein Modell zu einem physikalischen Messfühler?
Der Hinweis von „Boris“ auf Statistik-Funktionen, Mittelwertbildung etc. wäre zutreffend, wenn es sich um tatsächliche physikalische Messungen handelt.
Zur Beurteilung der Qualität eines numerischen Lösers führt die nachträgliche Datenmanipulation in die Irre.
Das wäre richtig, wenn das Beispiel von Herrn Rabe denn die Qualität eines numerischen Lösers untersuchen würde. Er vergleicht aber 2 komplexe Brandsimulationen in denen eine Vielzahl unterschiedlicher Modelle und Löser interagieren.
Ihre Aussage ist mit Blick auf die Qualität eines numerischen Lösers also richtig, im Sinne einer praktischen Anwendung mindestens strittig und nochmal: weder Sie noch ich wissen was CFX da macht oder nicht macht.
Ein Beispiel?
Smokeview interpoliert viele der dargestellten Ergebnisse, „manipuliert“ diese also. Ist das gut oder schlecht?
Schauen wir uns hierzu einfach die untenstehende Abbildung an:
Die einzelnen Bilder zeigen eine Schnittebene mit der Temperatur als Messgröße an. Unabhängig von den jeweiligen Werten (200°C oder 400°C): welche Darstellung würden Sie als physikalisch sinnvollste empfinden? Meinem Empfinden nach ganz klar die rechte Darstellung, die aber die am stärksten „manipulierte“ ist. Smokeview interpoliert die skalaren Werte zwischen den einzelnen Zellen (links), um so mit der Physik übereinstimmende Visualisierungen aus den modellhaft beschränkten Simulationsergebnissen zu extrahieren (rechts).
Ein gewisses Maß an „Deutung“ der erhaltenen Rohdaten ist also im Zuge einer Brandsimulation zwingend erforderlich, um aus Rohdaten Ergebnisse zu machen.
Wenn die oben kritisierte Aussage jetzt aber wirklich eine „Beurteilung der Qualität eines numerischen Lösers“ und nicht einfach der Vergleich zweier Brandsimulationen wäre, warum bitte sind dann die Abbildungen in der Präsentation „manipuliert“ (also nicht als uninterpolierte Rohdaten dargestellt), wenn das doch bei den Diagrammen „in die Irre“ führt? Das ist in meinen Augen „evident widersprüchlich“.
Warum bin ich der Meinung, Smokeview ist „retro“? Man schaue sich unvoreingenomen das Postprozessing kommerzieller Programme an und bilde sich selbst ein Urteil.
Ein konkretes Beispiel oder bleiben wir hier bei „Audi und Trabi“, „Äpfeln und Birnen“?
Die häufigste Kritik an Smokeview dürfte wie folgt aussehen:
• kann keine Stromlinien,
• interpoliert immer von Haus aus und liefert damit keine Rohdaten,
• kann keine schrägen Schnittebenen,
• kann immer nur vorausgewählte Ergebnisse, nie alles,
• gibt keine numerischen Werte aus.
Leider sind alle oben genannten Punkte falsch, aber das müssen wir hier nicht weiter vertiefen.
Was ist nun meine Motivation, mich pointiert so zu FDS zu äußern? „15 minutes of fame“, wie „Boris“ vermutet? Ach du liebes Herrgottchen – Ruhm brauche ich so
nötig wie eine Lungenentzündung.
Was eine mir sehr sympathische Einstellung ist.
Aber wenn ich am Rande einer Fachveranstaltung Bemerkungen höre wie „die anderen Programme (gemeint sind die kommerziellen) müssten erst nachweisen, dass sie das können, was
FDS kann“, dann ist das nicht nur der Witz des Monats.
Naja,
das kann man sicher so oder so verstehen. Es ist wohl unstrittig, dass ein allgemeiner Vergleich zwischen den großen CFD-Paketen und FDS in vielerlei Hinsicht zurzeit nicht zu Gunsten von FDS ausgehen kann.
Auf der anderen Seite habe ich weder zu CFX noch zu Fluent ein relevantes Dokument entsprechend den FDS V&V-Guides zum Thema Brandschutz gesehen und das auch da nicht alles Gold ist was glänzt, zeigt unter anderem auch genau das von Ihnen präsentierte Beispiel auf Folie 19 Ihres Vortrags: hier liefert FDS ja augenscheinlich bessere Ergebnisse als CFX. Da frage ich mich einfach: wenn CFX alles besser kann und das Programm darüber hinaus auch noch von 2 ausgewiesenen Experten genutzt wird und FDS in diesem Fall trotzdem die besseren Ergebnisse liefert, was wollen wir denn noch mehr um gute Ergebnisse zu erzielen?
Der Glaube, dass mit großen Programmpaketen alles besser ist, weil die eine ganze Menge Geld kosten und furchtbar viele, sehr komplexe Modelle nutzen können sowie der Kundendienst sowieso immer sagt „Die nächste Version kann das!“ ist so auch nicht richtig. Und wenn doch, dann muss das eben systematisch mit Bezug zum Brandschutz nachgewiesen werden. Solange das nicht geschieht, bin ich skeptisch. Den Luxus das „zu glauben“, kann ich mir als Ingenieur nicht leisten.
Vielmehr könnte sich daraus die Tendenz ergeben, FDS für Brandsimulationen zu einer Art Standard zu erklären. Dagegen habe ich etwas.
FDS ist eben nicht der Stand der Technik 2013, sondern in Bezug auf Löser, Vernetzung, Pre- und Postprozessing Stand der Technik von vielleicht 1985.
Das ist Fakt!
Welches Preprozessing?
Ich widerspreche Ihnen nicht (bis auf das Postprozessing). 1985 kommt ganz gut hin. Die Entwickler selber geben an, seit ca. Anfang der 80er Jahre an den Grundlagen zu arbeiten und daran wurde in der Vergangenheit auch nichts grundlegendes geändert. Allerdings haben Sie diese Kritik bisher auch gar nicht (zumindest im Tagungsband, mündliche Anmerkungen liegen mir nicht vor) in dieser Form geäußert. Bis auf das Thema Musik sind die 80er Jahre zwar nicht grundsätzlich als schlecht anzusehen, aber in Bezug auf den Bereich CFD ist seitdem eben viel geschehen. Allerdings darf man auch nicht übersehen, dass sich FDS weiterentwickelt. In vielen Bereichen wird FDS 6 deutlich besser sein als es FDS 4 war.
Und um ihren Trabi-Vergleich als (aus meiner Sicht) Willkür zu entlarven: der Porsche 964 ist Ende der 80er auf den Markt gekommen und der Wagen ist heute noch ein Hammer. Vielleicht wäre als Vergleich ein „FDS ist ein getunter 964er, CFX ein 997er!“ möglich? (Dem aufmerksamen Leser wird hier nicht entgehen, dass ich trickreich auf den 997er verweise und nicht etwa auf den noch besseren 991er 4s. So lasse ich Luft nach oben und unterstelle subversiv, dass auch die großen CFD-Pakete nicht perfekt sind!)
Dabei ist mir natürlich klar, dass wir an der Uni uns in einer komfortablen Situation befinden, weil wir für Forschungszwecke recht großzügige Rabatte auf die kommerziellen Programme bekommen.
Die Preispolitik der kommerziellen Anbieter trägt auch nicht unbedingt zur Verbreitung dieser Programme bei.
Natürlich haben viele Ingenieurbüros deshalb zunächst keine andere Option als FDS zu benutzen, zumindest solange nicht bis OpenFOAM (!) alltagstauglich ist.
Die Preispolitik interessiert mich nur am Rande. Neben FDS gibt es noch eine Reihe anderer Programme, auch mit Fokus auf den Bereich Brandschutz: Kobra3d, Sofi, Fluidyn, …. die allesamt deutlich preiswerter sind, sich aber nicht wirklich durchsetzen konnten. Ich mag schlicht den Gedanken der offenen Software (und hier unterscheidet das Englische zwischen ‚free software‘ (like free beer) and ‚open software‘ (like free speech), der Kooperation und ein weiterführendes Niveau der Validierung und Verifizierung ermöglicht.
Das ist ja alles in Ordnung, nur darf man halt nicht glauben, man hätte da etwas ganz besonders Tolles in der Hand.
Mit Blick auf Ihre Einleitung, sollte man aber auch nicht den Eindruck erwecken, FDS sei grundsätzlich unbrauchbar. Immerhin haben Sie ja Zugriff auf die großen Pakete und bekennen freimütig trotzdem FDS zu nutzen.
So, es ist jetzt 02:20 Uhr.
Bei weiterem Diskussionsbedarf kann „Boris“ ja mal seine Identität lüften.
Oben geschehen, vielleicht ergibt sich in Weimar eine Möglichkeit sich persönlich kennen zu lernen. Es würde mich freuen. Das Medium Internet ist doch trotz aller Vorzüge nur begrenzt für solche Diskussionen brauchbar.
Gute Nacht!
Ulrich Krause
Nochmals vielen Dank für Ihre Antwort, Ihre offene Meinung und die fachliche Kritik. Ich weiß den Diskurs wirklich zu schätzen.
PS: Hier noch Lesestoff:
Danke für die Literaturquellen. Ich werde probieren mir die genannten Veröffentlichungen zu besorgen.
Abschließend möchte ich noch kurz zusammenfassen, dass ich die in dem obenstehenden Kommentar geäußerten Standpunkte
• „FDS ist eben nicht der Stand der Technik 2013“,
• „(…) FDS für Brandsimulationen zu einer Art Standard zu erklären. Dagegen habe ich etwas.“
weder kritisiere noch bestreite. Auch bestreite ich nicht, dass die großen CFD-Pakete viele Vorteile gegenüber FDS aufweisen (aber eben auch einige Nachteile).
Was ich an dem Vortrag kritisiert habe, ist dass die teilweise vernichtende Kritik (als Reaktion auf zu optimistische Meinungen zu FDS) aus meiner Sicht deutlich zu heftig ausgefallen ist, da der ganze Vortrag tendenziell nicht auf einzelne Kritikpunkte an FDS abzielt, sondern fast schon eine grundsätzliche Nutzbarkeit im Bereich der Brandsimulation in Frage stellt und das leider ohne einen einzigen der genannten Kritikpunkte im Detail zu beleuchten oder auch nur quantifiziert darzustellen. Aus meiner Sicht ein gravierendes Ungleichgewicht, dass durchaus der Kürze der zur Verfügung stehenden Zeit geschuldet sein mag. Wenn sich im Rahmen bspw. des 7. Treffens der FDS-Usergroup die Chance bieten würde, die genannten Kritikpunkte im Detail zu beleuchten, würde ich das sehr begrüßen.
In der Hoffnung ihr Blind-Date damit nicht zu einer großen Enttäuschung gemacht zu haben,
verbleibe ich mit freundlichen Grüßen nach Magdeburg
Boris Stock
Sehr geehrter Herr Prof. Krause,
vielen Dank für Ihren Kommentar. Aus meiner Sicht wäre es wünschenswert, wenn Sie persönlich und die Universität Magdeburg weiterhin Ihr Potential in die Diskussion einbringen würden. Kritische Betrachtungen sind bei der Weiterentwicklung von Methoden und Programmen hilfreich und aus meiner Sicht notwendig. Enwicklungen durch eine Gruppe von reinen Enthusiasten eines bestimmten Programmes sind nicht immer förderlich. Der berühmte Blick über den Tellerrand ist ab und zu hilfreich.
Es wäre bedauerlich, wenn Sie dies als Vergeudung ansehen würden.
Das von Ihnen angesprochene Problem des „Klarnamen“ lässt sich mit Blick in das Impressum/ Kontakt dieser Seite sehr einfach auflösen. Autoren der Beiträge auf dieser Seite sind
– Herr Boris Stock,
– Herr Karl Wallasch und
– Herr Gregor Jäger.
Mit freundlichen Grüßen
Gregor Jäger
Was spricht gegen Trabis?
Hallo F-Sim-Community,
so ganz unkommentiert möchte ich den Beitrag von „Boris“ doch nicht stehen lassen.
Leider ist er nicht mit „Klarnamen“ unterzeichnet und ich kenne nur Boris Jelzin und Boris Becker, von denen ich nicht glaube, dass sie sich in diesem Blog äußern (der eine ist tot und der andere kann nicht richtig deutsch).
Wir haben also ein Semi-Blind-Date. Sei’s drum.
Was wollte ich mit meinem Beitrag auf dem User Group Meeting sagen:
Ich habe ja gar nichts gegen FDS, ich benutze es ja selbst. Ja! Ehrlich!
Natürlich ist es ein gewaltiger Fortschritt, in Brandsimulationen FDS zu benutzen gegenüber Zonenmodellen. Natürlich sind Zonenmodelle wegen der Nicht-Berücksichtigung des Strömungsgescwindigkeitsfeldes für Brandsimulationen gänzlich unbrauchbar.
(Upps, jetzt habe ich wahrscheinlich den nächsten erzürnten Blogeintrag provoziert.)
Durchaus weiß ich auch zu schätzen, welchen Beitrag wir den amerikanischen Steuerzahlern zu danken haben, dass sie uns dieses Werkzeug schenken.
Es ist nur so: ein explizites Differenzenverfahren auf einem orthogonalen, kartesischen Gittern ist die simpelste Form, partielle Differentialgleichungen numerisch zu lösen.
Das ist an sich nicht schlecht, aber es limitiert die Anwendungsmöglichkeiten vehement. Bei gekrümmten oder schiefwinkligen Konturen ist eben Ende der Fahnenstange.
Ein luftgekühlter Zweitakt-Ottomotor ist auch die simpelste Form eines Verbrennungsantriebs für Straßenfahrzeuge.
Deshalb hinkt der Trabi-Vergleich NICHT.
Zwischen dieser Eigenschaft von FDS und den kommerziellen CFD-Codes liegen Welten.
Stichworte sind: unstrukturierte Gitter, hybride Gitter, adaptive Gitter, moving meshes, Mehrgitter-Verfahren, Grenzschichtadaptierung…
Alles keine Kinkerlitzchen – manchmal braucht man so etwas, z.B. wenn man relativ kleine Öffnungen in großen Räumen auflösen will.
Einige logische Brüche in der Argumentation von „Boris“ sind evident. Einerseits betont er die erforderliche tiefgründige Qualifikation der Anwender (worin ich vollkommen zustimme), andererseits stellt er es als Vorteil dar, dass Anfänger mit 10 bis 20 Zeilen Brandsimulationen ausführen könnten.
Sollten wir das wollen, dass „Anfänger“ auf Brandsimulationen losgelassen werden? Doch wohl nicht.
Außerdem entnehme ich „Boris'“ Darlegung, dass nur der Kritik äußern dürfe, der auch zur Produktentwicklung beitrage.
Also bitte! Das Recht auf freie Meinungsäußerung haben wir alle. „Boris“ nimmt sich ja auch die Freiheit, uns zu unterstellen, dass wir unser Potential vergeuden, nur weil wir uns nicht an einer bestimmten Software abarbeiten wollen.
Hat „Boris“ sich etwa an der Weiterentwicklung der Universität Magdeburg beteiligt? Nicht, dass ich wüßte. (Kann natürlich noch nachgeholt werden, es gibt einige Fördervereine.)
Auch ist die Zahl der Nutzer kein Hinweis auf die Qualität des genutzten Produktes, sondern nur auf die Erreichbarkeit.
Viele der 3 Millionen Trabi-Fahrer hätten sicher nichts dagegen gehabt, auf Audi umzusteigen. Nur sind sie halt nicht ‚rangekommen.
Weiter zum sachlichen Teil:
Die beobachteten Oszillationen sind eindeutig unphysikalisch. Da lt. Technical Reference Guide die Temperatur über thermodynamische Zustandsgleichungen letzlich aus der Divergenz des Geschwindigkeitsfeldes berechnet wird, müssten physikalisch erklärbare Oszillationen eine Periodendauer haben, die mit der Fluktuation des Geschwindigkeitsfeldes korreliert.
(Wirbelradius/Umfangsgeschwindigkeit). Stattdessen ist die Periodendauer der Oszillationen der Zeitschrittweite zuzuordnen. Außerdem tauchen die Oszillationen in den Vergleichsrechnungen mit CFX nicht auf.
Der Hinweis von „Boris“ auf Statistik-Funktionen, Mittelwertbildung etc. wäre zutreffend, wenn es sich um tatsächliche physikalische Messungen handelt.
Zur Beurteilung der Qualität eines numerischen Lösers führt die nachträgliche Datenmanipulation in die Irre.
Warum bin ich der Meinung, Smokeview ist „retro“? Man schaue sich unvoreingenomen das Postprozessing kommerzieller Programme an und bilde sich selbst ein Urteil.
Was ist nun meine Motivation, mich pointiert so zu FDS zu äußern?
„15 minutes of fame“, wie „Boris“ vermutet? Ach du liebes Herrgottchen – Ruhm brauche ich so nötig wie eine Lungenentzündung.
Aber wenn ich am Rande einer Fachveranstaltung Bemerkungen höre wie „die anderen Programme (gemeint sind die kommerziellen) müssten erst nachweisen, dass sie das können, was FDS kann“, dann ist das nicht nur der Witz des Monats.
Vielmehr könnte sich daraus die Tendenz ergeben, FDS für Brandsimulationen zu einer Art Standard zu erklären. Dagegen habe ich etwas.
FDS ist eben nicht der Stand der Technik 2013, sondern in Bezug auf Löser, Vernetzung, Pre- und Postprozessing Stand der Technik von vielleicht 1985.
Das ist Fakt!
Der „Motor“ ist veraltet, wie beim Trabi. Solange dieses grundlegende Problem nicht anders gelöst ist, sind auch all die netten Sub-Modelle (Pyrolyse, Sprinkler…) nur von begrenztem Wert.
Deswegen werden wir den Teufel tun, uns an der Weiterentwicklung von FDS zu beteiligen. DAS würde ich als Vergeudung unseres Potential empfinden.
Dabei ist mir natürlich klar, dass wir an der Uni uns in einer komfortablen Situation befinden, weil wir für Forschungszwecke recht großzügige Rabatte auf die kommerziellen Programme bekommen.
Die Preispolitik der kommerziellen Anbieter trägt auch nicht unbedingt zur Verbreitung dieser Programme bei.
Natürlich haben viele Ingenieurbüros deshalb zunächst keine andere Option als FDS zu benutzen, zumindest solange nicht bis OpenFOAM (!) alltagstauglich ist.
Das ist ja alles in Ordnung, nur darf man halt nicht glauben, man hätte da etwas ganz besonders Tolles in der Hand.
So, es ist jetzt 02:20 Uhr.
Bei weiterem Diskussionsbedarf kann „Boris“ ja mal seine Identität lüften.
Meine Kontaktdaten gibt es hier:
http://www.iaut.ovgu.de/Lehrst%C3%BChle/Anlagentechnik+und+Anlagensicherheit/Mitarbeiter/Prof_+U_+Krause.html
Gute Nacht!
Ulrich Krause
PS: Hier noch Lesestoff:
Knaust c, Schneider U, Krause U, Hofmann-Böllinghaus A
Modellierung von Brandszenarien mit CFD
vfdb-Zeitschrift, 1/2010, Jg. 59, S. 20 – 30
Krause U, Rabe F, Knaust C
Modelling fire scenarios and smoke migration in structures
In: J. Schmidt (ed) Process and plant safety – Applying Computational Fluid Dynamics. – Weinheim : Wiley-VCH, 2012
Löhnert A, Knaust C, Rabe F, Krause U
Numerical and Experimental Investigation of Fire Smoke Toxicity
Fire Computer Modeling 2012 , Santander, 2012-10-18/19
Knaust C
Modellierung von Brandszenarien in Gebäuden
Diss. TU Wien, 2010
Pfister S
Grundlagen für die Anwendung numerischer Strömungssimulation auf Brandszenarien in Industrieanlagen
Diss., TU Berlin, 2012