Talk:BA Emilio Schmidt
Hier auf der Talk-Seite können wir Diskussionen führen und dabei natürlich auch Links verwenden. Hochgradig sinnvoll ist es, seine Beiträge zu signieren, was einfach durch das Anhängen von ~~~~ geschieht (oder auch im Edit-Feld oben der Knopf zwischen dem I-Knopf und dem Link-Knopf). Zur Strukturierung von Threads kann man noch mit Doppelpunkten einrücken. --Lothar (talk) 10:23, 16 April 2024 (CEST)
Ableitungen des v-Feldes an der Kugeloberfläche
Möchte man die Scherung im Gas wissen oder die Scherung zwischen dem Gas und der Null-Geschwindigkeit an der Kugeloberfläche? --Rolf
- Ich sehe da analytisch keinen Unterschied. Das v-Feld ist bis an die Kugel heran definiert, dort sind eigentlich die Ableitungen auszuwerten. Wenn wir im Post-Processing die Werte in den Geisterzellen nicht haben, müssen wir passende, d.h. extrapolierende Diskretisierungsformeln verwenden. --Lothar (talk) 10:48, 16 April 2024 (CEST)
- Ich meine damit sowas wie
oder . --Lothar (talk) 11:57, 16 April 2024 (CEST)- Du hattest gestern gesagt, dass es zu Problemen mit der Funktion np.gradient() kommen könnte, wegen der nicht äquidistanten Zellen. Ich habe nochmal auf der Webseite von numpy nachgeschaut (numpy.gradient). Dort steht, dass die Funktion auch für nicht äqudistante Schrittweiten verwendbar ist, solange die Liste angegeben wird, nach der abgeleitet werden soll. Aufgrund dessen, dass beide Geschwindigkeitskomponenten auf der Kugel gleich Null werden müssen, können wir diese manuell in die Geschwindigkeitsfelder hinzufügen. Dann müsste man nur noch schauen, wie man den fehlenden Teil bei
extrapoliert. --Emilio.S (talk) 10:10, 23 April 2024 (CEST)- Ja, verstehe
np.gradient()
bietet den Vorteil, dass Du mit einem Aufruf die -Ableitung für alle (außer 0) berechnen lassen kannst. Bei der Ableitung nach haben wir eh noch das "Problem", dass wir zwar alle -Werte (außer 0) haben, aber auswerten wollen wir ja auch die bei . Erst aber sollten wir die Ordnung festlegen. Ich schlage vor, sich zunächst auf die 1. Ordnung zu beschränken. --Lothar (talk) 13:01, 23 April 2024 (CEST)- Meinst du mit "Problem", dass alle
bzw. für gleich Null sind? Würden sich dann nicht die Ableitungsterme nach einfach wegfallen? Falls dies nicht der Fall ist soll ich die Ableitungen nach nicht mitnp.gradient()
bestimmen, da diese Funktion einen Fehler 2. Ordnung hat (s.numpy.gradient).--Emilio.S (talk) 16:50, 23 April 2024 (CEST)- Äh, ja, stimmt, die Ableitungen nach
fallen in der Tat bei weg, da und dort konstant Null sind. Super, das macht noch einfacher. --Lothar (talk) 18:13, 23 April 2024 (CEST)
- Äh, ja, stimmt, die Ableitungen nach
- Meinst du mit "Problem", dass alle
- Ja, verstehe
- Du hattest gestern gesagt, dass es zu Problemen mit der Funktion np.gradient() kommen könnte, wegen der nicht äquidistanten Zellen. Ich habe nochmal auf der Webseite von numpy nachgeschaut (numpy.gradient). Dort steht, dass die Funktion auch für nicht äqudistante Schrittweiten verwendbar ist, solange die Liste angegeben wird, nach der abgeleitet werden soll. Aufgrund dessen, dass beide Geschwindigkeitskomponenten auf der Kugel gleich Null werden müssen, können wir diese manuell in die Geschwindigkeitsfelder hinzufügen. Dann müsste man nur noch schauen, wie man den fehlenden Teil bei
Dann noch mal zu
- Genau der Wert für
und für fällt zusätzlich auch wegen dem Flächenelement weg, da der ist.--Emilio.S (talk) 11:31, 26 April 2024 (CEST)
Falls doch noch mal jemand sowas braucht, für den äquidistanten Fall
Dimensionslose Kenngröße
Von den 4 das Szenario beschreibenden Parametern,
Die Wahl von
Eine alternative Krafteinheit wäre
Auch wenn die Krafteinheit
- Ich wollte nochmals sicher gehen, ob ich das ganze mit den natürlichen Einheiten verstanden habe. Wir wählen also aus irgendeinem Grund bestimmte charakteristische Größen des Systems aus, welche dann gleich
gesetzt werden und drücken dann weitere Größen in Bezug zu diesen natürlichen Einheiten aus? Im Moment sind bei mir in der Datei user-defined.parameters.h die Dichte, Länge und die Geschwindigkeit gleich gewählt. Damit lassen sich es, wie du es schon getan hast die, die Masse, Länge und Zeit in diesen natürlichen Einheiten ausdrücken. Die dynamische Viskosität $\mu$ lässt sich damit nun auch in natürlichen Einheiten ausdrücken. Aufgrund dessen, dass die dynamische Viskosität eine Dimension von hat, lässt sich die dynamische Viskositätseinheit folgendermaßen schreiben:
- Damit folgt für die dynamische Viskosität
in den natürlichen Einheiten:
- Du hattest da jedoch noch einen Faktor
zusätzlich gehabt. Liegt das an der Konvention, dass gewählt wird? - Analoges Vorgehen liefert dann für die Kraft in natürlichen Einheiten:
- Soll ich dann diese Formel für die Kraft in mein Notebook implementieren?--Emilio.S (talk) 12:01, 29 April 2024 (CEST)
- ● "aus irgendeinem Grund": Der Grund ist (u.A.) die Reduktion der Dimension des Parameterraums um 3.
- ● "gleich
gesetzt werden": Ihr Zahlenwert in den aus ihnen gebildeten Einheiten wird automatisch 1. - ● "lässt sich die dynamische Viskositätseinheit folgendermaßen schreiben": Richtig ist
. Im "Theoretiker-Alltag" ignoriert man meist den "Operator" und benutzt dasselbe Symbol für physikalische Größe und ihren Zahlenwert. Erst aus dieser "Schludrigkeit" resultiert dann ein Statement wie . - ● Deine Gleichung
gilt (modulo dem Faktor 2) in allen Einheitensystemen (auch z.B. SI oder cgs), die Form ist zur Verdeutlichung gewählt, da die gewählte natürliche Einheit explizit im Nenner steht. Im Code würde die Gleichung dann bzw. lauten. Und ja, der Faktor 2 kommt von . - ● "Analoges Vorgehen liefert dann für die Kraft in natürlichen Einheiten": Genauer gesagt, der Zahlenwert der Kraft in diesen Einheiten, den Du aus Deinen Simulationsdaten herausbekämest, sollte ungefähr gleich
sein. - ● "Soll ich dann diese Formel für die Kraft in mein Notebook implementieren?": Das geht nicht, die Kraft ist das Ergebnis. Als Einheitensystem favorisiere ich jedoch die "zähen Einheiten". --Lothar (talk) 08:16, 30 April 2024 (CEST)
- Ich glaube ich habe mich da falsch ausgedrückt. Ich meine, ob ich dann die Kraft, welche wir dann mit der Formel
- als Referenzwert nehmen und nicht
Kraftberechnung (Emilio)
Ich bin nicht d'accord mit Deiner Begründung hinsichtlich der z-Richtung. Klären wir aber vielleicht am besten IRL. --Lothar (talk) 18:35, 18 April 2024 (CEST)
- Alles klar, können wir machen --Emilio
- Mir ist noch ein etwas größerer Fehler bei meiner vorherigen Rechnung heute morgen aufgefallen, nachdem du weg warst. Ich habe nämlich auch den Divergenzterm in der
-Komponente mitgeschleppt, obwohl dieser im Tensor nur auf der Hauptdiagonalen steht, da der Divergenzterm mit dem Einheitstensor multipliziert wird. Dadurch wird die Endgleichung ein wenig schlanker. --Emilio.S (talk) 15:18, 19 April 2024 (CEST)
- Mir ist noch ein etwas größerer Fehler bei meiner vorherigen Rechnung heute morgen aufgefallen, nachdem du weg warst. Ich habe nämlich auch den Divergenzterm in der
Implementierung in Python
Ich habe jetzt auf der Wiki-Seite grob erklärt, wie ich bis jetzt die Kraftberechnung in Python implementiert habe. Ich kann Dir auch noch mein Notebook per Mail schicken. Ich werde mich jetzt mit dem Problem befassen, dass meine Kraft nach oben zeigt und nicht wie erwartet nach unten.--Emilio.S (talk) 11:27, 26 April 2024 (CEST)
- Ich glaube das Problem liegt an der radialen Ableitung. Ich bin der Meinung, dass die Ableitung entlang der Stromlinie ausgerechnet werden muss. Da wir jedoch in Kugelkoordinaten rechnen, berechnen wir ja oberhalb der Kugel die radiale Ableitung aus Sicht der Kugel aus, was zu einem Vorzeichenfehler meiner Meinung nach führt.--Emilio.S (talk) 13:28, 26 April 2024 (CEST)
Ich glaube ich habe den Fehler gefunden, der dafür sorgt, dass die Kraft für ein feineres Grid immer größer wird. Es liegt glaube ich daran, dass ich das
- Ich habe das jetzt auf der Main Paige geändert und erneut die Kräfte für die verschieden feinen Grids bestimmt. Dabei habe ich immer ganzzahlige Vielfache in der Zellaufteilung im Vergleich zu meinem Ausgangsgrid genommen. Es scheint hierbei so, als ob die Werte für immer feinere Grids gegen einen bestimmten Wert konvergieren. Um dies bestätigen zu können muss ich jedoch mehr Simulationen laufen lassen. Es fällt jedoch auf, dass die numerisch bestimmten Werte dann um einen Faktor 20 ungefaähr vom theoretisch erwarteten Wert abweichen.--Emilio.S (talk) 16:53, 3 May 2024 (CEST)
Fehler in der numerischen Kraftberechnung
Es stellt sich heraus, dass die relative Kraftabweichung, selbst für vergleichsweise hohe Auflösungen, trotz der Auflösung im Bereich von ungefähr
Dieser Fehler könnte jedoch viele Ursachen haben. Eine davon könnte die numerisch durchgeführte Integration sein, welche einer einfachen Summation entspricht. Um dies zu überprüfen, wird zunächst das Oberflächenintegral über die Kugel bestimmt. Dabei wird analytisch für eine Kugel mit Radius
Daher muss der Fehler entweder durch die Druckverteilung oder das Geschwindigkeitsfeld kommen. Um dies zu untersuchen wird zunächst die Druckverteilung für die ersten beiden Zellschalen um die Kugel untersucht. In In Abb.3 lässt sich erkennen, dass die analytischen Lösungen bzw. die numerischen Lösungen für die ersten beiden Zellschalen nahezu perfekt übereinander liegen. Auch weisen die numerischen Lösungen einen kosinusförmigen Verlauf auf, genau, wie analytisch erwartet. Jedoch ist die numerische Lösung für
Analog lässt sich die polare Geschwindigkeit
In Abb.5 ist selbige Untersuchung, wie in Abb.4, für die radiale Geschwindigkeitskomponente
Ich finde, der Abschnitt mit den Plots könnten eigentlich auf die Hauptseite. Aktuelle Fragen:
- Bleiben bei Halbierung der Reynoldszahl die relativen Abweichungen gleich?
- Wie wirkt sich ein größerer Außenradius aus? --Lothar (talk) 17:43, 16 May 2024 (CEST)
Viskosität, dynamisch vs. kinematisch
Von den beiden,
Die Viskosität wird in der Funktion Visc_nu()
in visc_nu.c berechnet, ein Aufruf pro Zelle. Trotz der Namen nu1
(Scherv.) und nu2
(Volumenv.) handelt es sich um die dynamischen Viskositäten. Beim Vorgeben von v[RHO]
) also gar nicht auftauchen. Verwendet man obige "zähe Einheiten", so wird die Funktion besonders einfach:
void Visc_nu(double *v, double x1, double x2, double x3, double *nu1, double *nu2)
/* ... */
{
*nu1 = 1.0; *nu2 = 0.0;
}