---

Hallo!

Ich versuche mich seit einigen Wochen an OpenFoam und möchte ein Simulationsmodell aufbauen, das die (stationäre) Temperatur an einem Rippenkühlkörper und den Luftstrom abbildet. Dazu habe ich das Tutorial snappyMultiRegionHeater (chtMultiRegionFoam) umgeändert, so dass es nur noch aus zwei regions besteht, meinem Kühlkörper ("heater") und die umgebene Luft ("domain0"). Den Case-Ordner habe ich mal beigefügt:
kuehlkoerper_OFcase.zip

Das Netz von diesem Modell wird zwar erstellt, allerdings wird nichts berechnet. Die log.chtMultiRegionFoam liefert folgende Fehlermeldung, aus der ich nicht schlau werde:

Code:

---

Create time

Create fluid mesh for region domain0 for time = 0

Create solid mesh for region heater for time = 0

*** Reading fluid mesh thermophysical properties for region domain0

Adding to thermoFluid

Selecting thermodynamics package
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState perfectGas;
specie specie;
energy sensibleEnthalpy;
}

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::heRhoThermo<Foam::rhoThermo, Foam::pureMixture<Foam::constTransport<Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleEnthalpy> > > >::calculate() at ??:?
#4 Foam::rhoThermo::addfvMeshConstructorToTable<Foam::heRhoThermo<Foam::rhoThermo, Foam::pureMixture<Foam::constTransport<Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleEnthalpy> > > > >::New(Foam::fvMesh const&, Foam::word const&) at ??:?
#5 Foam::autoPtr<Foam::rhoThermo> Foam::basicThermo::New<Foam::rhoThermo>(Foam::fvMesh const&, Foam::word const&) at ??:?
#6 Foam::rhoThermo::New(Foam::fvMesh const&, Foam::word const&) at ??:?
#7
at ??:?
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9
at ??:?
Floating point exception (core dumped)

---

Ich wüsste auch gerne, wie ich meine Wärmequelle (50 W Leistung) an die Unterseite des Kühlkörpers anbringe. Die Wärmequelle im angeänderten Tutorial habe ich bisher auch noch nicht gefunden.

Ich bin dankbar für jede Hilfe, die mich meiner Lösung etwas näher bringt.

Gruß

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

---

Hallo und Willkommen im Forum,

Student/Ingenieur - beides  - Bachelor Ing. + Masterstudent?

Hab mal eben über deinen Case geschaut.
Bezüglich  Netz wirst du ja selber Bescheid wissen. Ich verweise einfach mal auf Literatur und/oder

Code:

---

checkMesh -region

---

bzw. einfach mal visuell betrachten. Dein Heater sieht eher aus wie eine sehr schlechte Freihandskizze :) (nicht böse gemeint).

Was komplett falsch ist, ist die Initialisierung deiner Randbedingungen. Jede Variable = calculated :)

Da du dich sehr an das Allrun Skript hältst fehlt dir ein entscheidender Schritt:

Code:

---

changeDictionary

---

Viel Erfolg.

------------------
Grüße Tobias Holzmann

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

---

Zitat:

---

Student/Ingenieur - beides  - Bachelor Ing. + Masterstudent?

---

Genau so ist es. Ich bin im vorletzten Mastersemester (Maschinenbau).

Ich weiß, dass das Netz (und damit auch der Kühlkörper) nicht ganz so hübsch ist. Dafür aber schnell erstellt. Damit wollte ich auch nur erstmal bewirken, dass irgendwas durchrechnet. Egal wie fein das Netz ist, der Fehler oben kommt trotzdem.

Was "checkMesh -region", "Jede Variable = calculated" und "changeDictionary" bedeutet, versuche ich morgen früh herauszufinden, wenn ich wieder am Rechner sitze.

Danke schonmal!

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

---

Hi,

also checkMesh ist ein Befehl, der dir dein Netz auf gewisse Qualitätskriterien prüft. Dein BlockMesh würd ich anpassen. Am Besten ist immer ein Würfelnetz zu haben. Außnahmen bestätigen natürlich die Regel.

Alle Variablen = calculated; damit meine ich folgendes:

- Alle Randbedingungen müssen im Ordner 0/variablen vorgegeben werden.
- Beim conjungated heat transfer (cht) eben in 0/region/variable
- Die Variablen (T, U, p, p_rgh, k, epsilon, omega, ...) müssen natürlich sinnvoll definiert werden bspw.

Geschwindigkeit an der Wand = (0 0 0)^T
Das gibst du dann in diesen Files vor und da ist bei dir überall die Randbedingung:

Code:

---

type  calculated;
value uniform xxx;

---

drin. Das ist natürlich falsch  (hier kannst du dann auch deinen Wärmestrom auf der Unterseite definieren).

Dein Netz hat nicht mal 50.000 Zellen  also kannst du da schon noch einiges rausholen. Da dein Kühlkörper eher mager ist (wenig Zellen) kann es sein, dass dein Interface nicht funktioniert. Also etwas mehr Zellen und du wirst sehen das das Ergebnis schon wesentlich besser (qualitativ und quantitativ) sein wird.

------------------
Grüße Tobias Holzmann

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

---

Guten Morgen,

Danke für die Hinweise! Das Netz habe ich jetzt viel feiner gemacht und im 0-Ordner eine Geschwindigkeit für den inlet von domain0 (minZ) und eine Temperatur für den heater (minY) gesetzt. Nach der erstellung des Netzes habe ich

Code:

---

changeDictionary -region heater

---

ausgeführt. Das ist ja auch die einzige region, für die es ein "changeDictionaryDict" gibt. Das scheint auch soweit gut funktioniert zu haben.

Code:

---

Create time

Create mesh heater for time = 0

Read dictionary changeDictionaryDict with replacements for dictionaries
2
(
boundary
T
)

Reading polyMesh/boundary file to extract patch names
Loaded dictionary boundary with entries
2
(
minY
heater_to_domain0
)

Replacing entries in dictionary boundary
Special handling of boundary as polyMesh/boundary file.
Merging entries from
3
(
minY
minZ
maxZ
)

fieldDict:
{
minY
{
type patch;
nFaces 21280;
startFace 3241830;
}
heater_to_domain0
{
type mappedWall;
nFaces 181460;
startFace 3263110;
sampleMode nearestPatchFace;
sampleRegion domain0;
samplePatch domain0_to_heater;
offsetMode uniform;
offset ( 0 0 0 );
}
minZ
{
type patch;
}
maxZ
{
type patch;
}
}

Writing modified boundary
Replacing entries in dictionary T
Loading dictionary T
Loaded dictionary T with entries
3
(
dimensions
internalField
boundaryField
)

Merging entries from
2
(
internalField
boundaryField
)

Writing modified fieldDict T

End

---

Danach wollte ich die Simulation starten:

Code:

---

mpirun -np 4 chtMultiRegionFoam

---

woraufhin ein neuer Fehler ausgeworfen wird:

Code:

---

--> FOAM FATAL IO ERROR:
keyword startFace is undefined in dictionary ".minZ"

file: .minZ from line 42 to line 42.

From function dictionary::lookupEntry(const word&, bool, bool) const
in file db/dictionary/dictionary.C at line 402.

FOAM exiting

---

Wo und wie kann ich denn jetzt "startFace" definieren?

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

---

Hallo,

du musst natürlich jede Region anpassen.
Über changeDictionary kann man sich viel Arbeit sparen, wenn man es öfter durchführen muss.

Ansonsten arbeite ich immer manuell über vim.

Entsprechend musst du auch

Code:

---

changeDictionary -Region domain0

---

ausführen oder du änderst die Dateien in 0/Domain0/ selber.

Das ist dir überlassen. Bei FOAM heißt es so schön. Viele Wege führen ans Ziel. Wie du das machst musst du entscheiden.

Soweit ich das gesehen habe arbeitest du nicht im Terminal sondern mit dem Texteditor gedit (liegt an deinen für dich nicht sichtbaren Backupdateien, die gedit erstellt. Entsprechend ist vllt der Aufwand (gefühlt) mit changeDictionary weniger als ständig diese Files zu öffnen.

Ich weiß nicht aber möglicherweise hat die Open Source GUI von Engys bereits eine Implementation für CHT Problemstellungen. Arbeite nicht mit diesem Tool deswegen auch die spärliche Information. Andere können dir hierzu sicherlich mehr sagen.

PS: zu deinem Fehler!
-------------------------------------------------------

Anscheinend ist bei dir irgendwas daneben gegangen. Möglicherweise hast du auch ein File namens ".minz" in deinem Case Ordner.
Diese Files siehst du natürlich NICHT mit den Standardeinstellungen im File-Browser.

------------------
Grüße Tobias Holzmann

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

---

Hi Shor-ty!

Wenn ich das richtig verstehe, überschreibt man mit dem changeDictionary seine Randbedingungen. Das brauche ich aber nur, wenn sich das öfter ändert bzw. überschrieben wird. (?)

Wenn ich mir alle versteckten Dateien anzeigen lasse, finde ich diese .minZ Datei nicht. Ich habe den Case-Ordner nochmal zusammengepackt und hochgeladen. Das Netz habe ich dafür wieder verschlechtert, damit die Datei klein bleibt.

kuehlkoerper_OFcase2.zip

Nach der Netzerstellung gibt es die Datei constant/heater/polyMesh/boundary. Das scheint die Datei zu sein, um die es in der Fehlermeldung geht. Wenn ich die Zeilen von "minZ { type patch; }" verändere, verändert sich auch die Zeile in der Fehlermeldung:

Code:

---

--> FOAM FATAL IO ERROR:
keyword startFace is undefined in dictionary ".minZ"

file: .minZ from line 43 to line 43.

From function dictionary::lookupEntry(const word&, bool, bool) const
in file db/dictionary/dictionary.C at line 402.

FOAM exiting

---

Vorher war es Zeile 42 (siehe Oben), jetzt Zeile 43.

Man sieht, dass eine startFace verlangt wird. hier steht zwar theoretisch, was eingetragen werden könnte, aber wie ich an die entsprechenden Werte für startFace und nFaces kommen soll ist mit völlig unklar.

Code:

---

movingWall
{
type patch;
nFaces 20;
startFace 760;
}

---

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

---

In den letzten Tagen habe ich nochmal von vorn angefangen und bin dabei etwas methodischer vorgegangen. Dazu habe ich mir erneut das Tutorial "snappyMultiRegionFoam" vorgenommen und es Schritt für Schritt verändert. D.h. ich habe alle Teile bis auf den "heater" entfernt und benutze "domain0" als fluid.

Jetzt bin ich dem Fehler von oben wieder auf der Spur. Ich habe herausgefunden, dass er nur auftritt, wenn domain0 in y-Richtung (+/-) und negativer z-Richtung größer wird als der heater.

Hier noch der aktuelle Case-Ordner:
02_snappyVersuchskuehler.zip

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

---

Zitat:

---

Original erstellt von svengineer:

Jetzt bin ich dem Fehler von oben wieder auf der Spur. Ich habe herausgefunden, dass er nur auftritt, wenn domain0 in y-Richtung (+/-) und negativer z-Richtung größer wird als der heater.

---

Ich schaue heute Abend einmal drüber.

------------------
Grüße Tobias Holzmann

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

---

Hallo - ich weiß jetzt nicht was du genau vorhast - ob du quasi den Heater und die Domain darum komplett als Fluid betrachtest oder ob du die topAir.stl auch noch miteinbinden willst.

Ich mach einfach mal was ich denke und poste dein Case hier.

------------------
Grüße Tobias Holzmann

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

---

Hallo,

tut mir leid, wenn ich damit Verwirrung stifte. Der Heater soll natürlich als solid definiert sein und domain0 als fluid. topAir sollte es eigentlich nicht mehr geben. Ich dachte so hätte ich das auch schon eingestellt.

Jedenfalls danke für deine Hilfe!

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

---

Okay wunderbar dann mach ich das so.
Sieht schon sehr gut aus.

!!! Wäre von Vorteil wenn ich den Case auf meine Homepage laden könnte!!!

Die Allrun Datei wird nämlich komplett überarbeitet und ein sauberer Case generiert.

------------------
Grüße Tobias Holzmann

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

---

Mit dem Case kannst du gerne machen, was du möchtest. Meine fertige Version würde ich hier auch hochladen. Die soll ja auch nicht den Heater aus dem Tutorial beinhalten, sondern den Kühlkörper, den ich untersuchen möchte.

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

---

snappyMultiRegionHeaterCase.tar.gz

Hallo,

anbei der gesäuberte und Step-by-Step aktualisierte Case.

http://www.holzmann-cfd.de/tutorials/chtMultiRegion/snappyMultiRegionHeaterCase.tar.gz

Code:

---

./Allrun

---

Fertig, hoff es hilft.

------------------
Grüße Tobias Holzmann

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

---

Danke! Ich werde es morgen ausprobieren.

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

---

Temperature.png

Sollte es nun funktionieren kannst du ja diesen Thread als gelöst markieren (oben der grüne Pfeil +10)

Im Anhang noch ein Bild des Temperaturverlaufs nach 25s.
Die Randbedingung müsste noch geändert werden  aber sieht ganz gut aus.

------------------
Grüße Tobias Holzmann

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

---

Danke, du hast mir sehr geholfen! Ich habe den Case jetzt auch soweit verändert, dass meine eigene Geometrie für den heater benutzt wird und im chtMultiRegionSimpleFoam gerechnet wird. Als nächstes knüpfe ich mir das Netz vor.

Das mit den Unities war mir nicht bewusst. Du hast sie jetzt aber erhalten.

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

---

Hi,

Unities sind mir eigentlich egal 
Mir gehts primär darum zu sehen ob ein Thread gelöst ist oder nicht.

------------------
Grüße Tobias Holzmann

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

---

Hallo zusammen,

hier die Nachricht (PM) von Sven:

Zitat:

---

Hallo Tobias,
ich habe nun wieder etwas mit dem Case gearbeitet, den du mir letzte Woche erstellt hast. Leider fällt mir jetzt erst auf, dass die Randbedingungen bei mir falsch sind. Seltsam ist ja, dass bei dir Temperaturunterschiede vorhanden sind. Bei mir bleibt der heater allerdings konstant bei 300K. Woran kann das jetzt liegen?

Im Allgemeinen habe ich noch ein paar Fragen zu den Randbedingungen. Ich bin bisher davon ausgegangen, dass wenn in der der changeDictionaryDict von dem heater im Eintrag minY die Temperatur auf 500K gesetzt wird, dass das dann die Wärmequelle darstellt. Ist das falsch?

Wie gehe ich vor, wenn meine Wärmequelle nicht zufällig auf min/max X/Y/Z liegt?

Ich war mir jetzt nicht sicher, ob ich das wieder unter den anderen Einträge schreiben soll, weil das ja schon "gelöst" ist  Wenn es besser ist, kann ich diese Nachricht auch noch darunter schreiben.

---

1. Du darfst natürlich hier noch weiter posten, kannst aber auch ein neues Problem mit "changeDictionary" machen etc. Wie dir es beliebt.

2. Dein Problem mit dem changeDictionary ist folgender (versuchs mal aus m Kopf):

Code:

---

T
{
      ".*"
      {
              type        calculated;
      }

      minX
      {
              type        zeroGradient;
      }

      maxX
      {
              type        fixedValue;  // Wärmequelle - konstante Temperatur
              value      uniform 350;
      }
     
      ...
}

---

Ich glaub einmal das das bei dir so ungefähr drin stand.
Damit schreibst du diese Werte in dein T-File was an und für sich richtig ist. Allerdings darfst du einen Fehler nicht machen.
Der reguläre Ausdruck ".*" sagt OpenFOAM das alle Oberflächen diese Randbedingung hat. Egal was danach kommt. Du hast es mit dem regulären Ausdruck bereits definiert.

Ergo. Was oben steht ist vom Prinzip richtig (auch wenn calculated falsch wäre) aber der Fehler liegt in der Reihenfolge. Das hier wäre möglich:

Code:

---

T
{
      minX
      {
              type        zeroGradient;
      }

      maxX
      {
              type        fixedValue;  // Wärmequelle - konstante Temperatur
              value      uniform 350;
      }
     
      ...

      ".*"
      {
              type        zeroGradient; // ausgebessert
      }

}

---

Während des Initialisierens wird OpenFOAM die ersten zwei so definieren wie sie explizit definiert sind. Alle anderen erhalten dann den "zeroGradient".

Noch ein Hinweis:

Bei mir gingen die regulären Ausdrücke nicht, deswegen habe ich alle Oberflächen einzeln in die changeDictionaryDict eingetragen (wie du vielleicht schon gemerkt hast).

------------------
Grüße Tobias Holzmann

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

---

Das Problem lag darin, dass ich das fluid über den Rand vom heater hinaus erweitert habe und damit durch die Bedingung durch heater_to_fluid überschrieben wurde.

Darum bleibt auch noch die Frage:

Zitat:

---

Wie gehe ich vor, wenn meine Wärmequelle nicht zufällig auf min/max X/Y/Z liegt?

---

Außerdem würde ich gerne meine Wärmequelle in einen konstanten "heat flux" (3000 W/m²) ändern.

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

---

Hallo,

konstanter HeatFlux - entsprechende Randbedingung setzen.

Das mit deinem Zitat - wo genau möchtest du den deine WQ haben?
Müsstest halt wahrscheinlich eine Quelle in dein internalField setzen.

------------------
Grüße Tobias Holzmann

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

---

konstanter HeatFlux - entsprechende Randbedingung setzen.

Wie sieht das dann aus? kann ich da einfach

Code:

---

T
{
      minY
      {
              type        heatFlux;
              value      uniform 3000;
      }
     
      ...

}

---

einsetzen?

Das ist ja nur geraten... Muss ich mich durch den Quellcode wühlen, um herauszufinden, welche Randbedingungen ich wie setzen kann oder ist das irgendwo aufgelistet?

An diesem Kühlkörper möchte ich die Wärmequelle nirgendwo sonst haben. Allerdings würde ich gerne wissen, wie ich das mit den Randbedingungen machen müsste, wenn die Geometrie des Kühlkörpers oder der Wärmequelle anders wäre. Z.B. wenn die Wärmequelle nicht auf der gesamten Grundfläche des Kühlkörpers wirken würde.

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

---

Hallo,

nein - gibt einfach sowas ein wie du jetzt und dann gibt dir OpenFOAM einen Fehler aus + alle zulässigen RB.

------------------
Grüße Tobias Holzmann

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

---

Zitat:

---

Original erstellt von svengineer:
[i]
     
An diesem Kühlkörper möchte ich die Wärmequelle nirgendwo sonst haben. Allerdings würde ich gerne wissen, wie ich das mit den Randbedingungen machen müsste, wenn die Geometrie des Kühlkörpers oder der Wärmequelle anders wäre. Z.B. wenn die Wärmequelle nicht auf der gesamten Grundfläche des Kühlkörpers wirken würde.

---

Groovy BC ermöglicht vieles.

------------------
Grüße Tobias Holzmann

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