Kennt jemand einen FDTD solver, welcher mit tetraedischen meshes arbeiten kann? Der sollte open source sein. Bisher nutze ich openems, aber das meshing ist eine qual. Wenn ich komplexere Strukturen habe werden die meshlinien nach dem smoothing immer zu klein und der Zeitschritt dadurch extrem klein. Ich habe schon diverse tools ausprobiert. Pyems war bisher am besten, hat aber keine komplexen Strukturen das gleiche Problem.
Lars M. schrieb: > Kennt jemand einen FDTD solver, welcher mit tetraedischen meshes > arbeiten kann? Tetraeder sind typisches FEM-Mesh, also Finite-Elemente-Solver im Frequenzbereich wie HFSS oder CST. Bei FDTD gibt's das Würfel-Mesh das du bereits kennst. Hochfrequenz-FEM-Solver als Freeware sind mir keine bekannt, aber von Ansys oder CST gibt es kostenlose Studentenversionen die in der Projektgröße limitiert sind. Einige Hersteller bzw. Hochschulgruppen haben mit FDTD Subgrid experimentiert, also lokal verfeinertem FDTD-Mesh, aber soweit mir bekannt ist hat es das nie zur Produktreife geschafft.
Simulant schrieb: > also Finite-Elemente-Solver im Frequenzbereich wie HFSS oder CST. Ergänzung: die Tools dieser Hersteller haben viele unterschiedliche Solvermethoden, unter anderem eben auch FEM-Solver. Bei den Freeware-Solvern findet man ganz überwiegend FDTD, das ist relativ einfach zu implementieren vom Meshing und vom Solvercode. Die Herausforderung ist dann, dass es auch SCHNELL wird.
Simulant schrieb: > Hochfrequenz-FEM-Solver als Freeware sind mir keine bekannt, aber von > Ansys oder CST gibt es kostenlose Studentenversionen die in der > Projektgröße limitiert sind. Doch die gibt es. Alexandre Halbach hat sparselizard programmiert. Ich habe da aufgrund Zeitmangel nicht mehr weiter reingeschaut. Da muss man allerdings die Formulierung selber machen. Insgesamt scheint das eine tolle Arbeit zu sein. Openems kenne ich schon und Thorsten Liebig hat das ziemlich nutzbar gemacht auch wenn das Prinzip einem eben manchmal in die Karten spielt. Insgesamt finde ich es ganz toll, dass die beiden das auch unter einer freien Lizenz weiterpflegen. Das ist scheinbar nach deren Promotion komplett Freizeit, die draufgeht. Ich hatte ja irgendwann mal die Idee, dass man für numerical engineering mal eine Open Source foundation oder Allianz bildet, die fundraising betreibt und Kommunikation zwischen den tools erleichtert. Das ist ja ein Flickenteppich. Mit anderen gebieten hat das bisher auch funktioniert und kleine unternehmen können oder wollen such CST und Konsorten eben nicht leisten. Schon gar nicht diese dummen abo Modelle.
Niemand. Will. Tetraedernetze. Lerne die blockstrukturierten Netze zu lieben oder lass es. Netze und Solver müssen übrigens nicht aus dem gleichen Programmpaket kommen. Das sind sehr einfache Datenstrukturen, für die sich leicht Konvertierer schreiben lassen.
Walter T. schrieb: > Niemand. Will. Tetraedernetze. Du redest jetzt aber nur von FDTD, oder? Die Tetraeder bei FEM sind schon hilfreich, je nach Aufgabenstellung. Es gibt für beides (FDTD und FEM) gute Gründe, wo die jeweilige Methode besonders vorteilhaft und effizient ist. Und dann gibt's noch einen ganzen Strauß anderer Methoden wie MoM mit Oberflächenmesh der Leiter. FDTD ist bei Freeware beliebt, weil die mathematischen Grundlagen an einem Vormittag in der Vorlesung angehandelt werden können, und am nächsten Tag in der Übung wird's gleich in Matlab ausprobiert. Das ist einfach und enstprechend starten viele Leute daraus ein Projekt. Lars M. schrieb: > Mit anderen gebieten hat das bisher auch funktioniert und kleine > unternehmen können oder wollen such CST und Konsorten eben nicht > leisten. Schon gar nicht diese dummen abo Modelle. Als Anwender zahlt man mit Arbeitszeit beim Benutzen der freien Solver, weil alles länger dauert sofern es überhaupt möglich ist. Ich verfolge die Entwicklung eines kommerziellen FDTD Solvers (Empire XPU) und da stecken zwei Jahrzehnte Entwicklung eines ganzen Teams drin. Allein das Meshing (was dich bei der Freeware ärgert) sind dort einige Mannjahre an Entwicklungsarbeit und dafür findet es nun automatisch einen sehr guten Kompromiss aus Auflösung und Zeitschritt auch bei komplexen Geometrien mit 100 Millionen Zellen.
Simulant schrieb: > Allein das Meshing (was dich bei der Freeware ärgert) sind dort einige > Mannjahre an Entwicklungsarbeit und dafür findet es nun automatisch > einen sehr guten Kompromiss Woher hast du die information. Die Firma hat auch keine Mitarbeiterzahl wie US unternehmen und ist eher Mittelstand.
Simulant schrieb: > Du redest jetzt aber nur von FDTD, oder? Nö, das zieht sich quer durch die Disziplinen. Bei FEM ist es auch eine Katastrophe, bei BEM auch (bei letzterem sind es dann Dreiecke).
:
Bearbeitet durch User
Lars M. schrieb: > Woher hast du die information. Die Firma hat auch keine Mitarbeiterzahl > wie US unternehmen und ist eher Mittelstand. Ich kenne die Entwickler gut, weil ich seit 20 Jahren mit diversen Anbietern im Bereich der HF-EM Simulation zusammenarbeite. Da bekommt man den Entwicklungsaufwand mit, der bei manchen vermeintlich trivalen Details nötig wird.
Hat denn einer der simulationsgurus hier vielleicht Hinweise, wie das meshing gut automatisiert werden kann um den kommerziellen solvern im nichts nachstehen?
Aus meiner Perspektive als Nutzer kann ich was zum Ergebnis beschreiben: es werden zuerst alle Kanten erkannt und in eine Liste gepackt. Dabei wird unterschieden nach Objekttypen (gerade Kante vs. runde Objekte), deren Auflösungen können unterschiedlich gewichtet werden. Über die Liste der potentiellen Meshlinien läuft dann ein iterativer Optimierer, der Kompromisse aushandelt wo mit begrenzter Anzahl an Meshlinien nur geringe Abweichungen zu den exakten Werten aus der Liste entstehen und dabei die kleinen Abstände (kleine Zeitschritte) möglichst vermieden werden. Das löst u.a. das Problem von zufällig sehr eng benachbarten Kanten von Strukturen, die unkritisch sind und die man zu einer ausgemittelten Meshlinie zusammenfassen kann. Als Nutzer kann man dann noch harte oder weiche Limits in jede Raumrichtung angeben, welcher Abstand der Meshlinien nicht unter/überschritten werden soll. Das nutze ich zB bei Simulation von PCB wo bestimmte Bereiche nicht HF-relevant sind aber trotzdem mit moderater Auflösung im Modell enthalten sein sollen. Oder umgekehrt hohe Auflösung in Bereichen erzwingen wo das automatische Mesh zu grob war. Zeig mal ein Beispiel der Struktur, wo dein Mesh Probleme macht, dann kann man vielleicht konkretere Vorschläge machen.
Nachtrag: was ich für komplexe Modell auch sehr intensiv nutze sind individuelle Mesh-Steuerungen für einzelne Gruppen (z.B. Layer). Das ist eigentlich unverzichtbar bei komplexen FDTD-Modellen, damit man als Anwender dem Mesher helfen kann welche Strukturen abweichend von den Defaults besonders grob oder fein gemesht werden sollen.
Nochmal ganz anders gefragt. Könnte man die zu kleinen meshzellen nicht so lange löschen, bis die kleinste metallauflösung erreicht ist?
Lars M. schrieb: > Nochmal ganz anders gefragt. Könnte man die zu kleinen meshzellen > nicht > so lange löschen, bis die kleinste metallauflösung erreicht ist? Deinen Vorschlag verstehe ich nicht. Zeig bitte mal ein konkretes Beispiel.
Lars M. schrieb: > Könnte man die zu kleinen meshzellen nicht > so lange löschen, bis die kleinste metallauflösung erreicht ist? Nein. Ein Element pro Strukturbreite reicht nicht.
Walter T. schrieb: > Lars M. schrieb: > >> Könnte man die zu kleinen meshzellen nicht >> so lange löschen, bis die kleinste metallauflösung erreicht ist? > > Nein. Ein Element pro Strukturbreite reicht nicht. Mit kleinster metallauflösung meine ich sowas wie kleinste Wellenlänge / 20, so wie es von vielen solvern empfohlen wird.
Lars M. schrieb: > Mit kleinster metallauflösung meine ich sowas wie kleinste Wellenlänge / > 20, so wie es von vielen solvern empfohlen wird. Das ist ja nur die OBERGRENZE für den Meshabstand. Durch die Geometrie kann es notwendig sein, auch sehr viel kleinere Abstände aufzulösen. Beispiel Leitungsbreiten, da würde ein falsches Setzen der Meshlinien zu einer anderen wirksamen Leitungsbreite führend und entsprechend ungenau wäre das Ergebnis. Also nochmals, zeig mal die konkrete Aufgabenstellung um die es DIR aktuell geht.
Gutes Vernetzen braucht Erfahrung. Einen guten Netzgenerator zu schreiben noch mehr. Lars M. schrieb: > Mit kleinster metallauflösung meine ich sowas wie kleinste Wellenlänge / > 20, so wie es von vielen solvern empfohlen wird. Wenn die Strukturbreiten der Komponenten kleiner sind, als die Netzgüte es aufgrund der Wellenlänge erfordert, passt das aber auch wieder nicht. Dann braucht man Spezialelemente oder Netzverfeinerung. (Ich nutze mal den Begriff "Elemente" für die programmierte räumlichen Differenzialgleichungen, egal ob FEM, FDM, BEM oder FDH.) Außerdem ist die Wellenlänge oder die Frequenz ja oft erst das Ergebnis der Simulation. Da beisst sich die Katze in den Schwanz. Edit: Hoppla, hatte vergessen, dass es um time domain geht. Da trifft der letzte Satz ja nicht zu. Da ist die Wellenlänge ja eine Frage der initial gewählten Auflösung.
:
Bearbeitet durch User
Walter T. schrieb: > Außerdem ist die Wellenlänge oder die Frequenz ja oft erst das Ergebnis > der Simulation. Da beisst sich die Katze in den Schwanz. Nein, bei der hier diskutierten FDTD-Simulation für Hochfrequenz zumindest DIESER Aspekt einfach. Man setzt man für das Meshing die höchste Frequenz an im Frequenzbereich, den man simuliert. Dabei kann man für große Auflösung durchaus auf lambda/10 runtergehen. Beim von mir verwendeten Solver ist der Default bei 15 Zellen/Lamda. Die geometrieabhängige Auflösung ist per Default auf 4 Zellen pro Leiterbreite gesetzt, die Dicke der Leiter wird mit 0 oder 1 Zelle aufgelöst.
Angehängte Dateien:
-
rillenhorn_mesh_zu_grob.png
480 KB -
kanten2.png
470 KB
Simulant schrieb: > Lars M. schrieb: >> Mit kleinster metallauflösung meine ich sowas wie kleinste Wellenlänge / >> 20, so wie es von vielen solvern empfohlen wird. > > Das ist ja nur die OBERGRENZE für den Meshabstand. Durch die Geometrie > kann es notwendig sein, auch sehr viel kleinere Abstände aufzulösen. Um das nochmal zu verdeutlichen als Beispiel ein Rillenhorn (Hohlleiterantenne) mit grobem Mesh. Da ist zwar die Anzahl der Zellen pro Wellenlänge eingehalten, aber es kommt trotzdem zu Geometriefehlern im Form ungewollter Metallbrücken. Es ist deshalb wichtig, beide Kriterien zu erfüllen: Geometrie und Wellenlänge müssen BEIDE ausreichend fein aufgelöst werden. Als Beispiel für planare Strukturen habe ich noch das Mesh einer PCB-Antenne dargestellt. Man erkennt blauen Meshlinien, das sind Geometriekanten die erkannt wurden. Und dazwischen sind die roten Meshlinien die der Bauregel "4 Zellen pro Leiterbreite" folgen. Man erkennt dort auch eine unerwünschte Stelle, wo zwei Geometriekanten von Antenne und Via zufällig eng benachbart liegen, siehe roter Pfeil. Das würde zu einem kleinen Zeitschritt führen, solche eng benachbarten Meshlinien würde man ggf zusammenfassen wollen.
Ui. Das sind ja üble Netze. Womit wurden die erzeugt? (Gefühlt würde ich behaupten: Bis auf Strukturoptimierung habe ich solche Minecraft-Netze die letzten 20 Jahre nicht mehr gesehen.)
Walter T. schrieb: > Ui. Das sind ja üble Netze. Womit wurden die erzeugt? Empire XPU, das ist der aktuell schnellste FDTD EM-Solver weltweit. Mir scheint, auch wegen deiner Kommentare zum Tetraedermesh, dass du mit den EM-Solvern in der Hochfrequenztechnik nicht vertraut bist. Ich arbeite seit über 20 Jahren auf dem Gebiet und kenne den Stand der Technik ganz gut. Es geht hier nicht um Mechanik, dort mögen ganz andere Meshes sinnvoll sein.
Simulant schrieb: > Mir scheint, auch wegen deiner Kommentare zum Tetraedermesh, dass du mit > den EM-Solvern in der Hochfrequenztechnik nicht vertraut bist. Bin ich auch nicht. Als ich das letzte Mal etwas mit HF simuliert habe, war FDM noch viel zu langsam und BEM das Maß aller Dinge. Ansonsten eben viel FEM und etwas CFD über FDM. Simulant schrieb: > Walter T. schrieb: >> Ui. Das sind ja üble Netze. Womit wurden die erzeugt? > > Empire XPU, das ist der aktuell schnellste FDTD EM-Solver weltweit. Klassisch unterscheidet man zwischen Präprozessor, Solver und Postprozessor, wobei die meisten Programmpakete alles drei beinhalten. Schon immer war es so, dass die Programmpakete mit den besten Solvern die übelsten Netzgeneratoren (Teil des Preprocessors) hatten. Ich gehe davon aus, dass sich das bei Open Source eher noch verschärft hat, weil die Doktoranden für neue Solver-"Elemente" belohnt werden und nicht für bessere Netzgeneratoren. Die Postdocs hätten wohl die Erfahrung, bessere Netzgeneratoren zu entwickeln, aber da gehen die Anreize auch in komplett andere Richtungen. Wie das bei kommerziellen Paketen momentan aussieht, weiß ich nicht. Man bleibt ja schon allein wegen der riesigen Kosten immer in seiner Filterblase.
:
Bearbeitet durch User
Walter T. schrieb: > Schon immer war es so, dass die Programmpakete mit den besten > Solvern die übelsten Netzgeneratoren (Teil des Preprocessors) hatten. Kann man in der HF-Feldsimulation nicht trennen, weil jeder Solver eine sehr spezielle Meshkonfiguration benötigt. Bei FEM sind das Tetraeder, beim hier diskutierten FDTD ein Rechteckmesh. Das ist hochoptimiert, das schlechte Mesh am Beispiel des Rillenhorns war von mir bewusst so gewählt um Lars zu zeigen wo die Grenzen des groben Mesh zu falschen Ergebnissen führen. > Wie das bei kommerziellen Paketen momentan aussieht, weiß ich nicht. Stimmt :-) Da dominiert für 3D-Meshing FEM mit dem Tetraeder-Mesh, das du nicht magst. Das hier diskutierte FDTD mit dem dafür erforderlichen Rechteckgitter ist in kommerziellen Tools vor allem für Antennensimulationen gebräuchlich. Bei elektrisch großen Modellen (viele Wellenlängen in alle Raumrichtigen) explodiert bei FEM der Speicherbedarf während er bei FDTD linear mit der Anzahl der Meshzellen skaliert.
Simulant schrieb: > FDTD mit dem dafür erforderlichen Rechteckgitter Verstehe ich das richtig: "Rechteck" = Rechteck? "Rechteck" ist kein Slang für eine x-beliebige bilineare Abbildung?
:
Bearbeitet durch User
Simulant schrieb: > Empire XPU, das ist der aktuell schnellste FDTD EM-Solver weltweit. Der scheinbar auch einen Klasse netzgenerator hat. Kann ich mir trotzdem nicht leisten. Was macht Empire denn im Gegensatz zu openems so schnell? Also was machen die so super innovatives, was alle anderen nicht machen?
Walter T. schrieb: > Simulant schrieb: >> FDTD mit dem dafür erforderlichen Rechteckgitter > > Verstehe ich das richtig: "Rechteck" = Rechteck? > "Rechteck" ist kein Slang für eine x-beliebige bilineare Abbildung? Bei den kommerziellen Solver sind's tatsächlich Würfel in einem karthesischen Koordinatensystem. https://de.wikipedia.org/wiki/Finite_Difference_Time_Domain Wer sich eine spezielle Lösung für ein spezielles Problem selbst baut mag abweichende Koordinatensysteme nutzen ... da stecke ich nicht drin. Mein Thema sind die "universellen" Solver. Lars M. schrieb: > Was macht Empire denn im Gegensatz zu openems so > schnell? Also was machen die so super innovatives, was alle anderen > nicht machen? Die erzeugen "on the fly" einen optimerten Solver für das jeweilige Problem für die jeweilige CPU und rechnen viele Zeitschritte im Cache der CPU, bevor sie wieder Daten aus dem RAM nachladen müssen. Das alternative Verfahren was Konkurrent CST zur Beschleunigung der Zeitbereichssimulationen verwendet wäre die Berechnung auf einer GPU (Nvidia).
Lothar schrieb: > Für umsonst: > https://gmsh.info/ Schönes Mesh, aber taugt leider für FDTD-Berechnungen nicht.
Simulant schrieb: > Die erzeugen "on the fly" einen optimerten Solver für das jeweilige > Problem für die jeweilige CPU und rechnen viele Zeitschritte im Cache > der CPU, bevor sie wieder Daten aus dem RAM nachladen müssen. Soll der solver nicht immer gleich sein? Die zeitschritte müssten doch für jede CPU gleich sein, nur rechnet jede CPU andere Zellen.
Die CPU haben unterschiedliche Features zur Beschleunigung von Vektorberechnungen (zB AVX 512) und unterschiedliche Cachegrössen. Da wird je nach CPU anderer Code genutzt, zB auf meiner Hardware unterschiedlich zwischen Intel Core i9 und AMD Ryzen 5xxx. Und wenn ein Modell zB keine Metallverluste hat so wird DAFÜR ein Solver compiliert der die FDTD Berechnung ohne Metallverluste macht und damit etwas schneller ist. Das gilt für viele Berechnungsdetails: der Solver berechnet genau das, was DIESES Modell an Komplexität der FDTD Berechnung benötigt. Ansonsten müsste der Solver alle Features mitschleppen egal ob sie benötigt werden und jeder Zeitschritt wäre dann wegen der universellen Berechnung komplexer. Ich hoffe das Konzept ist verständlich? Der Solver kann damit sehr spezielle Dinge anbieten ohne für ALLE Berechnungen fett und langsam zu werden. Die erscheinen am Ende nur im Solvercode wo sie auch benötigt werden vom konkreten Simulationsmodell. Nachteil ist, dass der Bau des Solvers erstmal einige Sekunden braucht bevor irgendwas berechnet wird.
Simulant schrieb: > Bei den kommerziellen Solver sind's tatsächlich Würfel in einem > karthesischen Koordinatensystem. Jetzt kommt ich mir wirklich wie in einem Steampunk-Paralleluniversum vor, in dem mein kompletter Erfahrungsschatz nutzlos ist. Ich verabschiede mich hiermit und wünsche dem TO bei seinem Vorhaben viel Erfolg.
Walter T. schrieb: > Jetzt kommt ich mir wirklich wie in einem Steampunk-Paralleluniversum > vor, in dem mein kompletter Erfahrungsschatz nutzlos ist. > > Ich verabschiede mich hiermit und wünsche dem TO bei seinem Vorhaben > viel Erfolg. Was ist denn daran so schwer zu verstehen. Kommerzielle FDTD Solver arbeiten mit Würfelmesh. Es gibt mehr als eine Solvermethode. Andere arbeiten eben mit Tetraedermesh.
Dennis E. schrieb: > Was ist denn daran so schwer zu verstehen. Stell Dir einfach einen modernen Stahlbauer vor, der in ein Universum katapultiert wird, in dem Bronze als Standardmaterial gilt. Prinzipiell wird der schon ganz gut beurteilen können, was vorgeht, aber alle Feinheiten, die er mal über Stahlbau gelernt hat, sind nutzlos.
:
Bearbeitet durch User
Andere Aufgabestellung! Im Gegensatz zum Stahlbauer muss der Hochfrequenztechniker den gesamten Raum meshen und berechnen, weil die elektrischen und magnetischen Felder sich auch in Luft und anderen Isolatoren ausbreiten. Es gibt den Sonderfall der Momentenmethode-Solver, die meshen nur die Oberflächen der Leiter. Die Methode skaliert aber ungünstig wenn man sehr viele Meshzellen hat.
Walter T. schrieb: > Stell Dir einfach einen modernen Stahlbauer vor, der in ein Universum > katapultiert wird, in dem Bronze als Standardmaterial gilt. Es geht hier nicht um Stahlbau. Das sind Feldgleichungen, die es hier zu lösen gilt und da interessieren keine Kräfte wie du in deiner Stahlberechnung hast.
Ich habe es nun hin bekommen und entferne extrem kleine Abstände iterativ mit einem kleinen Algorithmus. Der Zeitschritt ist dann zwar immer noch klein weil die Struktur ja erhalten bleiben muss. Soweit sogut. Ich merke das meshen ist die wahre Kunst. Es müsste einen freien mesher geben, der das schön automatisiert wie gmsh macht. Außerdem wäre es klasse, wenn openems submeshes unterstützen würde. Hat jemand zufällig Kontakt zum Autor? Ich würde vielleicht ein paar Leute fragen, die Lust darauf haben openems zu erweitern.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.