FDTD ungleichmäßiges mesh

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.

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.

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.

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.

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.

Das sollte „grobe Auflösung“ heissen

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.

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.

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:
> 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).

Für umsonst:

https://gmsh.info/

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.

Ja das ist verständlich und logisch. Das machen viele Lösungen so.

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.

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.