---

Oberflachenstruktur.png

Moin zusammen,

seit einigen Wochen beschäftige ich mich in einem Projekt mit der Simulation eines Wärmeübertragers. Zu Anfang stand eine Strömungssimulation an, welche problemlos lief und auch plausible Ergebnisse lieferte. Nun möchte ich es um die Wärmeübertragung erweitern. Dazu verwende ich dem chtMultiRegionSimpleFoam-Solver.
Mein eigentliches Problem liegt jedoch in der Netzerstellung. Da es keine ganz einfach Struktur ist (siehe Grafik Anhang), möchte ich auf eine Nachbildung via blockMesh verzichten, weshalb bisher snappyHexMesh zu Einsatz gekommen ist. Ich bekomme auch problemlos ein Netz generiert, allerdings sind abgesehen von meinem Ein- und Austritt sämtliche anderen boundary's ohne Faces, sodass ein ansprechen auch nicht funktioniert. Allerdings muss ich bei dem Solver angeben welche Flächen aufeinanderliegen.
Daher die Frage:
Gibt es eine Möglichkeit, dass zuvor gesetzte boundary's in der blockMesh sich anpassen?

Um genauer zu werden. Die Struktur die auf der Grafik zu erkennen ist, ist meine Wärmeübertragerfläche mit positiver und negativer Prägung. Meine ursprüngliche blockMesh liegt außen herum. Die Meisten Faces die ich nach sHM erhalte werden unter dem in der sHMDict definiertem Namen abgelegt. Kann ich das beeinflussen, dass er es in Regionen aufteilt? (Bspw. vorne, hinten, rest)

Vielen Dank schon mal 

Beste Grüße
Nico

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

---

Hallo Nico und willkommen,

ja du kannst alles mit sHM machen. Gibt hier im Forum genügend Themen über sHM und chtMulti + Vernetzung.

Viel Glück.

------------------
Grüße Tobias H.

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

---

Hi Thomas,

danke für die Begrüßung (du bist ja in einigen Fällen das Komitee    )

Ich hatte schon versucht ob ich im Forum eine Lösung für das Problem finde, allerdings (ich kann auch Tomaten auf den Augen haben) habe ich nicht für mich anwendbares gefunden.
Die Kenntnisse über cMRSF und sHM reichen mir zur Zeit für mein Problem und dessen Lösung aus. Allerdings weiß ich nicht wie ich boundary's setzen muss, sodass ich darauf nach sHM zugreifen kann. Eine Mehrfachvernetzung bzw ein getrennter Export der STL kommt für mich nicht in Frage, weil die negative Prägung auf der Gegenseite schon wieder zum Vorschein kommt, wo das andere Netz anschließen soll. Somit tue ich mich schwer die STL vorher zu unterteilen oder mittels blockMesh verschieden anzusprechen.
Aber vielleicht stehe ich auch einfach nur auf dem Schlauch und mir muss jmd. einen Schubs geben 
Ich hänge noch einmal die STL an. Vielleicht steigt dann das Verständnis.

Der Plan:
in zwei Kanälen soll Luft strömen und die Wärme durch eine Wand übertragen werden (ich weiß, dass ich zu viele Wände habe)

Danke schon mal.

Grüße
Nico

Dateianhang:
http://ubuntuone.com/4KIbSHnaVlF8vmLCAxl23u (9MB)

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

---

Hi Nico,

mein Name ist Tobi und nicht Thomas 
Verwechselst mich wohl mit TTB. Er war auch die Muse meines Eigen. Aber leider ist er im Forum nicht mehr sehr aktiv.

Zu deinem Problem:
- Das wird mit einer STL nicht funktionieren!
- Du musst deine STL in Regionen splitten damit du die einzelnen Wände einzeln bekommst. Zudem würde ich mit cellZones arbeiten, damit kannst du alles Vernetzen - Fluid1 + Fluid2 + WT-Wand und danach die CellZonen einzeln herausschreiben. Die Interfaceflächen werden dann automatisch generiert (siehe tutorials/mesh/sHM/chtMulti/Allrun).

Es gibt viele Wege die zum Ziel führen.
Also viel Glück.

PS: Stellt deine STL einen Plattenwärmetauscher dar?

------------------
Grüße Tobias H.

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

---

Hi Tobi,

entschuldige den Namensdreher. Ich weiß ja auch nicht was da mit mir los war.

Danke für den Richtungsweiser, besonders auch das Tutorial. Schau ich mir gerade an, ist nur wieder ein Stück Neuland was ich betrete. Werde mal versuchen es zu übertragen.

Allerdings habe ich immer noch eine kleine Denksperre im Kopf:
In dem Tutorial und auch in anderen sind das alles rechteckige Körper mit "klaren" Kanten. Die Flächen meiner Geometrie ist, ganz vereinfacht gesagt, wellenförmig. Wie kann ich da anhand von einfachen Koordinaten meine Flächen trennen - reicht da ein rechteckiger Kasten, da sHM die Konturen der STL eh übernimmt?
Ich hoffe, dass sich diese Sperre schnell bei löst.

Ja Tobi, du liegst richtig. Näherungsweise kann es als Plattenwärmeübertrager angesehen werden - so ja auch in der STL.

Grüße
Nico

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

---

Hi

also mein Vorschlag ist folgender:

-> schließe den Plattenwärmetauscher vorne und hinten.
-> diese Flächen exportierst du dann als inlet1, inlet2, outlet1, outlet2
-> Exportiere deine Begrenzungsflächen (also quasi deinen Wärmetauscher)
-> jede STL erhält einen Boundaryeintrag nachdem sHM durchgelaufen ist.
-> Entsprechend brauchst du nur ein block als Hintergrundnetz.

Was mir noch nicht klar ist. Die Begrenzung nach links und rechts. Wird das ne Symmetrie RB oder mit welcher arbeitest du da?

Würds dir gern zeigen aber ich aknn die STL nicht in SALOME einlesen, deswegen kann ichs dir nicht zeigen wie ich das meine.

------------------
Grüße Tobias H.

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

---

Struktur.png

Ich bin jetzt davon ausgegangen, dass ich 3 STL / 3 Netze Brache.
- Fluid 1
- Wand/Übertragung
- Fluid 2

Zudem enthält die STL auch ein zu langes Profil - Tatsächlich wird etwa nur 1/4 verwendet (48mm). Des Weiteren strömt es nicht einfach von links nach rechts sondern:
- Vorderer Kanal (Fluid 1): Einströmung unten rechts, Ausströmungs unten links, Restliche Flächen geschlossen
   (habe ich jedoch bisher über die bM und RB definiert)
- Wand: eben eine Wand
- hinterer Kanal: Einströmung links oben, Ausströmung rechts oben, restliche Flächen ebenfalls geschlossen.
(siehe auch Grafik Anhang)

Für die Strömungssimulation habe ich bisher sämtliche Wände auf 0 (uniform (0 0 0)) gesetzt und den Eintritt mit 1 vorgegeben. Für die Temperatur habe ich noch keine RB.

Das Modell wurde mittels AudoCAD Inventor erstellt und dann als ASCII-STL exportiert. Was liest SALOME denn für STL? Könnte ich ja notfalls einfach nochmals exportieren.

EDIT:
Bei der Strömungssimulation hat es mit den Ein- und Auslässen sehr gut funktioniert (die boundarys war noch ansprechbar).

Grüße
Nico

[Diese Nachricht wurde von -nc- am 17. Jan. 2013 editiert.]

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

---

Hi,

ach jetzt versteh ich wie du das machen willst.
Joa das kann man größtenteils mit dem BlockMesh machen.

STEP, IGES, kann ich einlesen.

Dann könnt ich mal schnell was bauen (insofern du die Daten weitergeben darfst).

------------------
Grüße Tobias H.

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

---

Vielen Dank für die Hilfe und Unterstützung Tobi!

Die Files liegen hier.

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

---

Hi,

also ich hab deine Geoemtrie mal etwas vereinfacht.
Anbei der Case: www.holzmann-cfd.de/

-> chmod +x Run.sh
-> ./Run.sh

danach paraview und die einzelnen Files laden, fertig.

Ach ja - sehr kleine Gemoetrie! Da musst du dann schon einige Tricks mit sHM verwenden, sonst erhältst du solche Kanten wie in meinem Fall!

Wie ich gerade gesehen habe gehts glaub noch etwas einfacher aber das ist mal so der gängige Fall den ich immer verwende. Unter constant/ findest dann deine Regionen.

In dessen PolyMesh/boundary Files siehst du auch gleich, dass sHM dir die Interfaces bereits herausgeschrieben hat und alles selber angepasst hat.

Viel Spaß & Glück + Ausdauer   
Nette Geometrie...

PS: Wenn es recht ist, würde ich meine vereinfachte Geometrie gerne als Tutorial zur Verfügung stellen.

------------------
Grüße Tobias H.

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

---

nAbend Tobi,

vielen Dank für deine Mühe!
Die Datei war allerdings noch ausführbar. Jedoch scheint er nicht zu machen, wozu du ihn angewiesen hast (bspw. gibt es unter constant/ auch keine Regionen). [log]
Ohnehin ist der Case für mich aufgebaut wie ich noch keinen hatte (blockMesh.unv etc.).
Immerhin habe ich schon einmal einen Anhaltspunkt.

Zur Ausprägung der "richtigen" Struktur der Wand, sowie der vollständigen korrekten Vernetzung der Fluidgeometrie (ebenfalls mit Prägung) muss wahrscheinlich noch ein großer Aufwand (für mich) betrieben werden. Sehe ich das richtig? Denn prinzipiell soll dies nur ein Modell von mehreren ähnlichen darstellen.

Ich hatte insgeheim gehofft, dass es  eine relativ einfache Lösung gibt, allerdings wurde mir schnell klar, dass das vermutlich nur wunschdenken ist.
Was gut werden soll braucht Zeit 

Grüße
Nico

PS: mit Tutorial geht klar - dann hast du jetzt noch eines mehr 

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

---

Hi,

was hast du für ein Linux? Ubuntu, Suse? Hab mit Suse und Ubuntu hin und wieder Probleme bei meinen Skripten festgestellt.

Wie die Log zeigt, werden viele Befehle nicht ausgeführt.

Einfach mal step by step das machen was in der Run.sh steht.

------------------
Grüße Tobias H.

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

---

Moin Tobi,

ich bin unter Ubuntu zu Gange - meist 12.04. (siehe links  :zwinker
Auf die Idee mit dem manuellen Ausführen in der Reihenfolge von deiner Run hätte ich eigentlich ja auch kommen müssen/können.
Habe es heute Morgen noch einmal gestartet, lief auch gut durch, allerding schreibt er mir alle Faces als default aus:

Code:

---

Patch               Faces    Points   Surface topology                 
defaultFaces        80907    81666    ok (closed singly connected)
solidToFluidKalt    0        0        ok (empty)
solidToFluidWarm    0        0        ok (empty)     
wallSolid           0        0        ok (empty)
fluidWarmToSolid    0        0        ok (empty) 
inletWarm           0        0        ok (empty)
outletWarm          0        0        ok (empty)
wallWarm            0        0        ok (empty)
fluidKaltToSolid    0        0        ok (empty)
inletKalt           0        0        ok (empty)
outletKalt          0        0        ok (empty)
wallKalt            0        0        ok (empty)

---

Er legt mit zwar unter boundarys die einzelnen Patches an, allerdings jeweils mit nFaces=0.

Besteht die Möglichkeit, dass sHM nur eine Oberfläche mesht, bspw nur die Prägung auf der Wand von einer Seite, sodass man sich notfalls selber in Kleinsarbeit ein Großes Netz aufbaut von Hand? Oder könnte es sein, dass die Vernetzung mit SALOME, gMesh oder ähnlichen Mitstreitern besser (im Bezug auf die boundarys) von statten gehen könnte? Ich habe zwar schon von einige gehört und ein paar mal kurz angeschaut, jedoch nocht nicht weiter betrachtet.

Grüße
Nico

[Diese Nachricht wurde von -nc- am 18. Jan. 2013 editiert.]

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

---

Hi,

bei mir läuft alles einwandfrei!
Ohne Probleme und Fehler.

Schau mal ob die STL's richtig sind. Soll heißen in Paraview einladen. Oder mit surfaceCheck  prüfen. Müssen geschlossen sein. Aber wie gesagt bei mir funktioniert alles einwandfrei.

Ach ja - hast du splitMeshRegions -cellZones gemacht?

------------------
Grüße Tobias H.

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

---

Ach jetz weiß ich woher du die Ausgabe hast. Von checkMesh

Code:

---

    Patch              Faces    Points  Surface topology                 
    defaultFaces        81672    82424    ok (closed singly connected)     
    solidToFluidKalt    0        0        ok (empty)                       
    solidToFluidWarm    0        0        ok (empty)                       
    wallSolid          0        0        ok (empty)                       
    fluidWarmToSolid    0        0        ok (empty)                       
    inletWarm          0        0        ok (empty)                       
    outletWarm          0        0        ok (empty)                       
    wallWarm            0        0        ok (empty)                       
    fluidKaltToSolid    0        0        ok (empty)                       
    inletKalt          0        0        ok (empty)                       
    outletKalt          0        0        ok (empty)                       
    wallKalt            0        0        ok (empty) 

---

splitMeshRegions -cellZones und fertig!

------------------
Grüße Tobias H.

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

---

Hi,

ich war mir sicher, dass ich "splitMeshRegions -cellZones" ausgeführt habe - sogar zwei mal, aber ...
Jedenfalls vielen Dank!

Wenn du mir jedoch noch den Trick dahin kurz erläutern kannst, sprich wie du es geschafft hast über die blockMesh (mit SALOME erstellt?) die Flächen so definiert bekommen hast, dass sie nach sHM übernommen werden.
Von da ab könnte ich anschließend das Netz verbessern, besser an die "muss"-Geometrie anpassen und auch auf andere Fälle anwänden.

Was ich bisher rauslesen kann:
Du hast drei STL (kann ich nachvollziehen), hast dort jeweils mehrere boundarys definiert, sHM bastelt anschließend das Netz der Regionen und anschließend setzt du wieder die boundarys, wobei lediglich die Übertragerflächen als boundarys erhalten bleiben.
Ich denke der Schlüssel liegt in deiner generierten blockMesh. Kann ich die eigentlich bei SALOME importieren?

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

---

Hi,

nein die blockMesh Datei ist ein einfaches Netz.
Du kannst ja via ideasUnvToFoam blockMesh.unv das Hintergrundnetz erstellen lassen.
Dabei fällt dir dann auf, dass keine boundarys vorgegeben sind. Die sind nämlich alle in deinen STL`s

Grüße Tobi

------------------
Grüße Tobias H.

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

---

Moin Tobi,

vielen dank bis hier her. Dann werde ich mich mal mit SALOME auseinandersetzen um dort die Flächen definieren zu können.

Grüße

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

---

Hi,

wie gesagt das ist ein blockMesh ohne definierte Ränder. Sprich ein Block der alles einschließt und alle Wände sind "defaultFaces".

Deine Boundarys für deinen Case/Netz kommen von den STL NICHT vom Hintergrundnetz

------------------
Grüße Tobias H.

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

---

...das hatte ich mittlerweile verinnerlicht. Ich sehe ja auch die einzelnen boundarys wenn ich mir die STL mit Paraview anschaue.
Aber danke für den Hinweise 

Grüße
Nico

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

---

Hi,

ach ich habe etwas überlesen.
Du musst das nicht mit Salome machen. Das kann man auch mit jedem CAD Programm machen. Also mit Catia geht das  man muss einfach die Oberflächen einteilen und als Einzelne STL exportieren. Heißt: jedes Inlet oder Outlet bzw. jede Wand oder andere Fläche die du definieren möchtest wird als einzelne STL exportiert.

------------------
Grüße Tobias H.

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

---

Hi,

noch eine Anmerkung. Das mit den BC via STL geht doch nicht wie ich mir das gedacht habe.

Ich bin dabei es zu lösen.

------------------
Grüße Tobias H.

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

---

Hi Tobi,

ich habe deine Tipps und alles rund herum soweit umgesetzt, dass ich mich auf das Ziel zubewege.

1) Ich exportiere die Geometrien (Fluid, Wand, Fluid) aus Inventor als .iges,
2) importiere es in Salome,
3) gruppiere dort meine gewollten Flächen (Einlass, Auslass, Wärmeübertragung, Wand),
4) erstelle ein Netz in mit dem Meshing-Modul von Salome,
5) lege dort ebenfalls die Gruppen an,
6) exportiere es wiederum als .unv,
7) konvertiere es mit "ideasUnvToFoam" in ein openfoam-taugliches Format,
8) bearbeite ggf. die boundary unter "constant/polyMesh/"
9) und starte letzten Endes die Simulation.

Ist sicherlich von hinten durch die Brust ins Auge, aber es geht 

Jetzt versuche ich lediglich noch das Netz aus Salome so zu gestalten, dass ich es mit snappyHex weiter verfeinern kann. Denn eine erste Simulation (600k Zellen) mit einem NetGen-Algorithmus bringt stark abweichende Ergebnisse im Gegensatz zu einem 800k sHM-Netz, die so stark nicht auftreten sollten (unter gleichen Bedingungen). Er verdichtet die falschen Stellen.

Bisher habe ich es jedoch nur mit dem simpleFoam-Solver gerechnet und wollte heute Abend den cMRSF-Case aufsetzen

Grüße

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

---

...bzw. kannst du mir einen guten Meshing-Algorithmus in Salome vorschlagen?

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

---

Dein Vorgehen ist nicht schlecht. Gehts?
Problem ist halt das du ein Tetnetz machst (so nehm ich an).
Ich persönlich mag Tetraedernetze nicht so gern. Verwende dann doch lieber ein Hexadominant mit sHM.

Zudem:

Die Interfaces!!! Wie definierst du die in deiner boundary Datei?

------------------
Grüße Tobias H.

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

---

Im Großen und Ganzen geht es - zur Zeit nur ein paar Definitionsprobleme, wie ich denke bei den RB.

zu den Interfaces:
Nachdem ich das Netz als UNV exportiert habe und openfoam-konform umgewandelt habe bearbeite ich die boundary-Datei noch einmal manuell. Zum einen verzichte ich auf die Definition all meiner Flächen bei Salome. Demnach bekomme ich default-Flächen welche ich noch vom Namen umdefiniere.
Die Übertragerflächen mappe ich ebenfalls manuell.

Code:

---

WandToWarm
    {
        type            mappedWall;
        nFaces          28262;
        startFace      158179;
        sampleMode      nearestPatchFace;
        sampleRegion    warm;
        samplePatch    WarmToWand;
        offsetMode      uniform;
        offset          (0 0 0);
    }

---

Zum Ändern sind:
- type von patch in mappesWall
- die Faces sind schon hinterlegt
- den Rest ebenfalls einfügen und manuell anpassen
- sampleRegion: die angrenzende Region
- samplePatch: angrenzender Patch

Und so läuft der Test-Case bei mir und der echte auch Fast.
Diese Methode wird wahrscheinlich nur etwas für "kleinere" Cases sein, sonst wird die Handarbeit zu groß.

Grüße
Nico

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

---

Ach ja, stimmt. Ich hab da was durcheinander gebracht. 

Ich bin immer noch dabei es mit sHM zu machen. Bislang hab ich aber noch keinen Erfolg, da ich jedesmal meine Patches verliere.
Werds schon noch rausfinden 

------------------
Grüße Tobias H.

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

---

Wenn du bspw. einen Würfel hast, dessen Flächen du in der blockMeshDict definierst, und ihn anschließend von sHM vernetzen lässt (und die Flächen erhalten bleiben), bleiben auch die Patches erhalten.

Wie es in einem anderen Fall aussieht, weiß ich auch noch nicht.
Wenn du da was gefunden hast, musst du unbedigt Bescheid geben 

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

---

Also ich hab die letzten zwei Tage auch versucht via dem Hintergrundnetz die Patches zu erhalten, aber da gab mir sHM beim snappen immer Fehler.
Ich hab es jedoch gelöst. Step by Step von einer leichten Geometrie angefangen.

Muss das nochmals nachschaun und werde es als Tutorial auf meine HP setzen.
Ich geb bescheid wenn es fertig ist!

------------------
Grüße Tobias H.

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

---

Top.png

Hallo zusammen,

es funktioniert nun alles einwandfrei!

Aber für heute ist ende 

------------------
Grüße Tobias H.

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

---

Hi Tobi,

das ist ja eine super Nachricht!
Sowas brauche ich auch 

Ich warte gespannt 

Grüße
Nico

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

---

Hallo zusammen,

hier mein Fallbeispiel: Plattenwärmetauscher

+ Skript zum Meshen
+ Skript zum Ausführen
+ Skript zum Rekonstruieren

Also alles was man braucht.
Ich simuliere gerade den Fall und werde weitere Infos einstellen.
Layer wurden keine generiert, sollte aber bei Wärmeübertragung definitiv passieren.

Soll allerdings nur ein Beispiel sein.

------------------
Grüße Tobias H.

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

---

Hi Tobi,

vielen Dank, dass du dich so intensiv mit dem Problem beschäftigst.

Ich werde mir deine Lösung im Laufe des Wochenendes anschauen und versuchen zu erweitern  

Grüße
Nico

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

---

Der Link funktioniert nicht mehr. Gibts das Tutorial noch?

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

---

Hey,

ja das liegt daran, dass ich meine Homepage erneuert hab und einiges rausgeschmissen habe. Das Tutorial habe ich noch, muss ich aber erst auf v2.3.x anpassen (ggf. heute Abend).

------------------
Best regards,
Tobias Holzmann

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