---

Case.zip

Hallo an alle,

das ist mein erster Post. Ich hoffe, ich mach auf Anhieb alles richtig. :-)

Im Rahmen meiner Abschlussarbeit fertige ich eine Simulation der Strömung (inkompressibel, stationär) in einem Staubsauger an. Den Hersteller und die Geometrie muss ich aufgrund der Verschwiegenheitsklausel leider für mich behalten.

Da die Geometrie relativ komplex ist, habe ich schon sehr lange für die Erstellung eines relativ "guten" Gitters gebraucht. Die Geometrie wurde mit Snappy vernetzt. Dabei bin ich so vorgegangen wie der User "Shorty" das oft vorschlägt:

1. Import der STEP in Salome
2. Vernetzen in Salome (NETGEN 1D-2D, Mefisto ging irgendwie nicht)
3. Export der STL
4. Vernetzen mit Snappy

Ich teile die Geometrie in mehrere Stücke auf. (Siehe Anhang) Die einzelnen STL sind (bis auf die nicht geschlossene Oberfläche -> klar!) fehlerfrei. Wenn ich sie jedoch zusammenfüge, ist die Oberfläche an einigen wenigen Flächen immer noch offen. Kann es daran liegen, dass die Geometrie an manchen Stellen spitz zulaufende Kanten hat, sodass manche Flächen an der Spitze nur eine Fläche berühren?

Nach Vernetzung mit der angehängten SnappyHexMeshDict bekomme ich den angehängten CheckMesh Output.

Da es sich um einen stationären, inkompressiblen (zunächst einphasigen) Case handeln soll, rechne ich mit SimpleFoam. Dabei Verwende ich das kOmegaSST als Turbulenzmodell. Die Werte für k und Omega habe ich mit Ferziger / Fluent abgeschätzt. Außerdem rechne ich auf dem Universitätscluster.

Im Anhang findet ihr den ResiduenPlot, die Log-Datei von SimpleFoam (Slurm) und hoffentlich alles andere, was benötigt wird. Wie man auf dem Plot sieht, zeigt der Residuen Plot ein ganz seltsames Verhalten. Leider kann ich mir das nicht erklären.

Ich habe die Rechnung schon früher etwas länger laufen lassen, sie wird sich leider nicht großartig ändern. Es werden diese Peaks von k und Omega weiterhin auftreten und keine konvergente Lösung erreicht. Ich habe auch schon mal mit LowReynolds-Wandfunktionen gerechnet, da ist der Case aber noch schneller divergiert.

Ich sitze da jetzt schon gefühlt viel zu lange dran. Und langsam macht sich die Verzweiflung breit. Was mache ich falsch?

Vielen Dank für eure Unterstützung!!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Grüß dich Q.E.D und willkommen im Forum,

du kannst mich auch gerne "Tobi" nennen wenn du hier im Forum schon etwas umgeschaut hast (löblich).

Deine Herangehensweise ist korrekt allerdings  24.000.000 Zellen für einen Staubsauger bei 94 Kernen. Böse Simulation und vllt auch etwas sehr übertrieben? Gut ich kann jetzt nicht beurteilen wie komplex die Sache ist aber Hut ab. Denke das man das auch mit wesentlich weniger zustande bringt  Da du den Schlauch mitsimulierst hoffe ich nicht das du da dieses 2m lange gewellte Kunstoffrohr mitsimulieren musst. Das würde man entweder separat machen oder anders via periodic lösen.

Nun etwas konkreter, da du ja bereits einige Infos vorlegen kannst:

• Netgen 1D-2D kann nicht gehen weil du ein 2D Oberflächennetz generierst, somit also Triangle (Mifesto) oder Netgen 2D
  
• Wieso benötigst du ein neues LaplaceScheme für p? Hast du am Solver auch was geändert? Für omega ist es klar zwecks deinem anderen Turbulenzmodell.
  
• relTol für U, k, esplion, omega, würde ich persönlich auf 0.1 setzen
  
• Eine Konvergenz von 1e-12 ist ein wahrhaftiges Traumziel. Sehe ich nur bei meinen 2D Testfällen. Für U vllt noch schaffbar aber für p wahrscheinlich nicht
  
• Gibts einen Grund wieso du nicht simplecFoam nimmst?
  
• Wenn deine STL's zusammen eine geschlossene Geometrie ergeben, dann sollte das bei surfaceCheck auch dranstehen. Anderenfalls gibst du keine Acht auf die Interfaces zweier STL's (häufiger Fehler). Dann bekommst du Lücken und deine STL ist nicht waterproof. Desewgen arbeite ich am liebsten mit regionalen STLs. Wäre für dich vllt auch der bessere Weg. Aber viele Wege führen nach Rom.
  
• Wieso nNonOrthoCorrectors so hoch?
  
• Noch was, wenn du U nur bis zu einer Tolerance von 1e-8 löst, wie willst du dann jemals 1e-12 erreichen 
  

Deine Residuen sind interessant und kommt wahrscheinlich von deinem Netz. Du müsstest dir mal die Ergebnisse von bspw. Iteration 300 und 320 anschauen. Da ist sicherlich dein Omega irgendwo jenseits gut und böse; bekommst du denn ein bounding? Auch würde ich erstmal ohne Layer rechnen und vllt das Netz auf 5.000.000 herunterzwingen. Du verwendest laut sHMDict sogar schon Symmetrie. Kann mir wirklich nich vorstellen wieso du so viele Zellen hast außer du modellierst wirklich den Trölfmeter Schlauch.

Surface + Mesh
In deiner sHM Datei macht folgende Ausgabe dich darauf aufmerksam, dass du irgendwo ne Oberfläche hast aber keine numerischen Punkte in der Nähe. Ist kein Fehler aber wenn man quasi nur die Begrenzung des Fluidraums macht, dann sollte diese Fehlermeldung nicht kommen.

Code:

---

--> FOAM Warning : Displacement (-1.30130128e-06 -1.094969872e-06 -4.040821705e-07) at mesh point 14267 coord (-0.01635197861 0.1969721254 0.2654636728) points through the surrounding patch faces

---

Ist nur eine Warnung und muss nichts heißen. Dann bei deinem Snappen, das sieht nicht so gut aus. Viele Zellen die deine Qualitätskriterien nicht einhalten (naja viele ist in deinem Netz etwas übertrieben):

Code:

---

Checking faces in error :
    non-orthogonality > 65  degrees                        : 39
    faces with face pyramid volume < 5e-15                : 720
    faces with face-decomposition tet quality < 1e-15      : 3863
    faces with concavity > 80  degrees                    : 226
    faces with skewness > 4  (internal) or 20  (boundary) : 0
    faces with interpolation weights (0..1)  < 0.02        : 0
    faces with volume ratio of neighbour cells < 0.01      : 0
    faces with face twist < 0.02                          : 36
    faces on cells with determinant < 0.001                : 0

---

Schon mal versucht deine Geometrie um Faktor 1000 zu vergrößeren, vernetzen und dann zurückzuskalieren? Am Schluss kommen noch ein paar Errors die ich ungern sehe --> es nich möglich dein Netz ordentlich zu snappen. Die Layergenerierung sieht noch etwas schlimmer aus:

Code:

---

    non-orthogonality > 65  degrees                        : 11057
    faces with face pyramid volume < 5e-15                : 1396
    faces with face-decomposition tet quality < 1e-15      : 9293
    faces with concavity > 80  degrees                    : 89
    faces with skewness > 4  (internal) or 20  (boundary) : 1
    faces with interpolation weights (0..1)  < 0.02        : 0
    faces with volume ratio of neighbour cells < 0.01      : 2
    faces with face twist < 0.02                          : 186
    faces on cells with determinant < 0.001                : 854

---

CheckMesh sagt erstmal nix wildes, somit ist das Netz erstmal "okay" muss aber nichts heißen. Die Skewness kann man meistens außer Acht lassen. Ggf. kann man was am LaplacianScheme deswegen drehen, muss man aber normalerweise nicht. Beim detaillierteren Check bekommst du noch weitere Fehler. Angesichts deiner Fülle an Zellen ist das natürlich auch wenig. Kann aber durchaus dein Problem darstellen. Numerische Probleme gehen immer von einer oder wenigen Zelle aus -> Numerische Probleme Video ganz unten; Du nimmst allerdings das Upwind-Verfahren, dass deine Numerik stark stabilisiert. Wahrscheinlich würdest du mit 2ter Ordnung ziemlich schnell den Crash bekommen. Die Diffusion (hier numerische Diffusion) verschmiert dir deine Gradienten und macht die Lösung "smooth". Ist also gut fürs überleben aber die Genauigkeit leidet da schon sehr; allerdings immer zu Empfehlen mit dem anzufangen, dannach auf höhere Ordnungen zu wechseln. Aber das ist alles eine philosophie Sache. Änderst du deine Schemen --> neues & anderes Ergebnis, änderst du dein Kochrezept "Turbulenzmodell" -> neues & anderes Ergebnis... usw.

Boundarys

U kann ich nicht beurteilen (also die Groovy). Wird aber schon passen. p sollt auch passen. Für omega und k nimmst du am Besten andere BC für deine Inlets und zwar turbulentKinetic...Inlet und mixingLengthDissipation...Inlet. Damit fährst du wesentlich besser.

Decomposing

Interessant wäre (für mich) dein decomposePar Logfile zu sehen. Sicherlich machst du dir keine Gedanken wie viele Faces deine Prozessoren teilen. Macht an der Simulation nichts aber an der Geschwindigkeit.

Außerdem machst du sicher auch keine Matrixoptimierung (renumberMesh). Speedup bis 20%.

Zusammenfassend

Wahrscheinlich Netzprobleme. Ich würde mal ohne Layer rechnen und dann auch mal das k-Epsilon verwenden. Das ist nicht so anfällig.
Möglich wäre auch noch omega und k bei dir auf 0.1 zu relaxieren und zu hoffen das es was bringt. Zudem mal eine Analyse deiner Rechnung machen. Wo sind hohe Werte für omega die nicht ins Profil passen etc.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Jetz muss ich schmunzeln weil ich Q.E.D. in meinen Matheprüfungen immer hingeschrieben hatte (:

quod erat demonstrandum

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Tobi,

  ja genau! Man sucht ja immer ewig lang nach einem coolen Nick. Und irgendwann bin ich dann scheinbar im Matheskript gelandet. 

Boah, erstmal vielen vielen Dank für deine ausführliche Durchsicht meines Cases. Ich bin zwar doch recht unerfahren, was OpenFoam angeht, aber ich versuche mal alles zu beantworten.

Zitat:

---

Deine Herangehensweise ist korrekt allerdings   24.000.000 Zellen für einen Staubsauger bei 94 Kernen. Böse Simulation und vllt auch etwas sehr übertrieben? Gut ich kann jetzt nicht beurteilen wie komplex die Sache ist aber Hut ab. Denke das man das auch mit wesentlich weniger zustande bringt   Da du den Schlauch mitsimulierst hoffe ich nicht das du da dieses 2m lange gewellte Kunstoffrohr mitsimulieren musst. Das würde man entweder separat machen oder anders via periodic lösen.

---

Ja, so hat mein Betreuer auch erstmal reagiert.  Die Sache ist die, dass ich eine relativ ausgedehnte Geometrie bei gleichzeitig sehr vielen Details habe, die aufgelöst werden müssen. (Scharfe Kanten, etc.) Also da hängt wirklich ein großer Teil des Innenlebens des Staubsaugers dran. Und nach Durchsicht der Geometrie mit meinem Betreuer haben wir die Teile mit reingenommen, die unserer Meinung nach noch einen großen Einfluss auf die Strömung haben sollten.

Vom Schlauch habe ich nur ein kurzes Stück mit reingenommen, was auch ganz gut ist. Denn dieser hat so helixartige Rillen, die den Rechner schon krass beanspruchen. Eine Operation am Schlauch in SolidWorks legt meinen Rechner ca. 30 Minuten lahm. Der Schlauch verursacht leider auch einen großen Teil der Zellen. Ich muss den nur leider reinnehmen, weil ich speziell ein Bauteil betrachte, welches doch recht nah am Schlauch sitzt. Und es war angedacht, die Simulation mit einer Messung am realen Sauger zu vergleichen.

Zitat:

---

Netgen 1D-2D kann nicht gehen weil du ein 2D Oberflächennetz generierst, somit also Triangle (Mifesto) oder Netgen 2D

---

Das ist schon mal sehr gut zu wissen! Ich versuche die STLs nochmal zu erstellen. Vielleicht bringt das was.

Zitat:

---

Wieso benötigst du ein neues LaplaceScheme für p? Hast du am Solver auch was geändert? Für omega ist es klar zwecks deinem anderen Turbulenzmodell.

---

Wenn ich mich jetzt recht errinere, hatte ich das hinzugefügt, weil ich vorher noch PotentialFoam ausgeführt habe. Und dieser hat immer nach einem LaplaceScheme für p gefragt.

Zitat:

---

relTol für U, k, esplion, omega, würde ich persönlich auf 0.1 setzen

Wieso nNonOrthoCorrectors so hoch?

---

Ok, werde ich versuchen. Wie gesagt: Ich habe leider noch sehr wenig Erfahrung und schöpfe im Moment aus der Erfahrung meines Betreuers, der mir diese Werte erstmal empfohlen hat. Sonst habe ich vorher mit nNonOrthoCorrectors=10 gerechnet.

Zitat:

---

Gibts einen Grund wieso du nicht simplecFoam nimmst?

Noch was, wenn du U nur bis zu einer Tolerance von 1e-8 löst, wie willst du dann jemals 1e-12 erreichen 

---

SimplecFoam kannte ich gar nicht. Ich hatte mir erstmal einen Standard-Solver entsprechend meinen Annahmen gewählt. Guter Hinweis mit der Tolerance! 

Zitat:

---

Deine Residuen sind interessant und kommt wahrscheinlich von deinem Netz. Du müsstest dir mal die Ergebnisse von bspw. Iteration 300 und 320 anschauen. Da ist sicherlich dein Omega irgendwo jenseits gut und böse; bekommst du denn ein bounding?

---

Ok... ja das Bounding sieht auch sehr unschön aus. Für Omega treten auch Peaks von bis zu 1e+20 auf.

Zitat:

---

Auch würde ich erstmal ohne Layer rechnen und vllt das Netz auf 5.000.000 herunterzwingen.

---

Okay... ich versuchs mal.

Zitat:

---

Dann bei deinem Snappen, das sieht nicht so gut aus. Viele Zellen die deine Qualitätskriterien nicht einhalten (naja viele ist in deinem Netz etwas übertrieben):

Code:

---

Checking faces in error :
    non-orthogonality > 65  degrees                        : 39
    faces with face pyramid volume < 5e-15                 : 720
    faces with face-decomposition tet quality < 1e-15      : 3863
    faces with concavity > 80  degrees                     : 226
    faces with skewness > 4   (internal) or 20  (boundary) : 0
    faces with interpolation weights (0..1)  < 0.02        : 0
    faces with volume ratio of neighbour cells < 0.01      : 0
    faces with face twist < 0.02                           : 36
    faces on cells with determinant < 0.001                : 0

---

---

Okay... ich dachte, das wäre normal wenn zu Beginn noch viele fehlerhafte Zellen auftreten und das die so mit der Zeit ausgebügelt werden. Und das es eher wichtig ist, was am Ende dabei rumkommt. Gut zu wissen!

Zitat:

---

Schon mal versucht deine Geometrie um Faktor 1000 zu vergrößeren, vernetzen und dann zurückzuskalieren?

---

Ja, hatte leider auch keine wesentliche Verbesserung nach sich gezogen.

Zitat:

---

U kann ich nicht beurteilen (also die Groovy). Wird aber schon passen. p sollt auch passen. Für omega und k nimmst du am Besten andere BC für deine Inlets und zwar turbulentKinetic...Inlet und mixingLengthDissipation...Inlet. Damit fährst du wesentlich besser.

---

Okay... werde ich versuchen. Die decomposePar Log habe ich leider schon entfernt. Aber ich das decomposing mache ich mit der Methode scotch, wobei jeder Prozessor gleich gewichtet wird. Renumbering habe ich aber bisher immer gemacht.

Zitat:

---

Wahrscheinlich Netzprobleme. Ich würde mal ohne Layer rechnen und dann auch mal das k-Epsilon verwenden. Das ist nicht so anfällig.
Möglich wäre auch noch omega und k bei dir auf 0.1 zu relaxieren und zu hoffen das es was bringt. Zudem mal eine Analyse deiner Rechnung machen. Wo sind hohe Werte für omega die nicht ins Profil passen etc.

---

Okay, ich werds mal versuchen. Aber vielen vielen Dank für die hilfreichen Tips! Ich denke, ich werde jetzt erstmal etwas Zeit brauchen, um alles auszuprobieren. Wenn ich eine Lösung gefunden habe, werde ich mich nochmal melden. Und wenn nicht, dann werde ich mich wahrscheinlich auch melden. 

Danke dir! 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

das mit deinem zusätzlichen laplaceScheme is jetzt klar (potentialFoam). Bezüglich snappen liegst du schon richtig, allerdings musst du wissen wie das Snappen geht. Letztenendes ist deine Aussage schon wahr aber je mehr Iterationen du brauchst um zu snappen und je mehr fehlerhafte Zellen vorliegen, desto schlechter ist die ganze Sache.

Das mit der Geometrie ist so ne Sache aber wenn du mit deinem Betreuer schon darüber gesprochen hast, dann ist das ja gut. Ich möchte aufjedenfall keine Analyse der Ergebnisse machen 

SimplecFoam scheint gerade gar nich mehr in den Solver zu sein. Ich kann mich entsinnen das der mal da war. Ggf. wars auch in der extend Version von FOAM.

Zwecks den Tolerancen. Beim SIMPLE Algorithmus rechnest du die Gleichungen entweder zur relTol oder zur Toleranzegrenze aus. In deinem Fall rechnest du alle mit relTol 0; justierten Löser auf deine gegebene Toleranz runter. Heißt der größste Restfehler ist dann tolerance.

Beispiel

U initial 1e-2 und nach 2 Iterationen auf 1e-5

Wenn du jetzt relTol 0 hast und tolerance 1e-12, dann würdest du für eine "globale" Iteration, x Iterationen für die U - Matrix machen das sowas rauskommt:

U initial 1e-2 und nach x Iterationen auf < 1e-12

Wenn du jetzt relTol 0.1 hast und tolerance 1e-12, dann würdest du für eine "globale" Iteration, y Iterationen für die U - Matrix machen das sowas rauskommt:

U initial 1e-2 und nach y Iterationen auf < 0.1*1e-2

Ist also einfach nur ein Speedup. Natürlich können da auch Probleme auftreten aber normalerweise nur mit p. Deswegen ist hier relTol auch bei 0.01 oder 0.001.

Frohes schaffen und viel Erfolg.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Noch was zum Snappen,... also du hast da schon recht, da war ich etwas falsch gewickelt. Bei komplexeren Geometrien ist das eben so. Solang checkMesh okay ist, sollte das Netz "gut" sein, allerdings kannst du trotzdem Zellen haben die numerisch Probleme machen. Da wäre dann, wie schon erwähnt, eine Analyse der Rechnung interessant.

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Tobi,

vielen Dank für die Erklärung. Ich hoffe eine der Maßnahmen, die du vorgeschlagen hast, bringt mich etwas weiter. Da muss ich mich jetzt ranmachen.

Ich hänge und mache da jetzt einfach schon viel zu lange dran. Es wäre nur echt blöd, wenn dabei am Ende dann doch nichts Gescheites rauskommt. Das ist nun mal ein realer Fall, den man vielleicht nur mit sehr viel Erfahrung lösen muss.

Mal schauen... vielen Dank dir!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Grüße dich,

nach deinen Residuals kann es aber durchaus sein, dass du schon ne passable Lösung hast. Schau dir einfach mal deinen Case an (und mach am Schluss noch ne Rechnung wo du alle 50 Iterationen rausschreiben lässt. Wenn sich da nicht viel tut, ist alles konvergiert. Diese Peaks von Omega und k werden durch irgendwelche komischen Zellen hervorgerufen; muss aber nicht gleich bedeuten, dass alles falsch ist. Ich würde als erstes, die Layer weglassen, letztes Ergebnis auf das neue Netz mappen und dann mit k-epsilon simulieren.

Außerdem beachte,... Turbulenzmodellierung ist immer eine Art "kochen". Auf Grund der Tatsache, dass jedes Modell andere Ergebnisse liefert (manchmal auch komplett andere), fehlt wohl irgendein Term bei der Modellierung (irgendeine Relation zu irgendeinem Phänomen).

------------------
Viele Grüße,
Tobias Holzmann

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Residuals.png

Hallo Tobi,

habe deinen Tip beherzigt und ein neues Netz ohne Layers erstellt, die alte Lösung auf das neue Netz gemappt und dann versucht mit k-epsilon zu rechnen. Leider divergiert die Rechnung mit k-epsilon relativ schnell. Mit k-omega kommen folgende Residuen raus. (Anhang)

Weiter scheinen die nicht sinken zu wollen. Ist etwas unbefriedigend mit 1e-2 für p....

Beste Grüße
Arthur

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Tobi,

ich habe noch eine Frage wegen den BC für k und omega. Du hattest mir ja empfohlen für k den Typ turbulentIntensityKineticEnergyInlet und für omega den Typ turbulentMixingLengthFrequencyInlet zu nehmen.

Für k trifft man im Internet auf die Standardwerte für die Intensität von 0.02 bis 0.05. Ich habe jetzt 0.05 genommen.

Für Omega muss man ja eine mixingLength definieren. Auch hier trifft man oft auf einen Wert von 0.005. Lautet Ferziger ist eine gängige Abschätzung für L aber 1/20 des Durchmessers. Inwiefern hängen diese beiden Größen zusammen?

Noch eine Frage: Ich bekomme für alle Wände ein YPlus < 1. Wie müsste ich das in den BC (kOmegaSST) berücksichtigen?

Vielen Dank dir für deine Mühe!

[Diese Nachricht wurde von Q.E.D. am 29. Dez. 2015 editiert.]

[Diese Nachricht wurde von Q.E.D. am 29. Dez. 2015 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Res.png

Hallo an alle Mitlesenden:

Mit einem verbesserten Gitter, das ich entsprechend den Tipps von Tobi bekommen habe, erhalte ich auch ganz ansehnliche Residuen ohne diese seltsamen Peaks.

Aufgrund von y+<1 verfolge ich im Moment zwei Ansätze:

1. Das low-Re-Modell LaunderSharmaKE ohne Wandfunktionen. (epsilon: zeroGradient an Wänden; k: sehr kleiner fester Wert an Wänden; nut: nutUSpaldingWallFunction)

Update: Mit diesen Einstellungen divergiert die Rechnung. Vielleicht liegt das daran, dass der y+ Wert nur im Mittel überall kleiner 1 ist?

2. Das kwSST-Modell für low-Re. (k: sehr kleiner fester Wert an Wänden; nut: nutUSpaldingWallFunction entsprechend den Tipps von Henry auf http://www.cfd-online.com/Forums/openfoam-bugs/62339-compressible-komegasst-2.html; omega: omegaWallFunction)

Update: Erhalte die angehängten Residuen.

Beste Grüße
Arthur

Edit: Wenn ich auf höhere Ordnungen bei den schemes wechseln will, wie sollte ich dabei vorgehen? Welches Scheme sollte ich nehmen? (Hab leider gar keine Erfahrung auf dem Gebiet)

Herzlichen Dank für die Hilfe!

[Diese Nachricht wurde von Q.E.D. am 01. Jan. 2016 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP