[nakor]

Hey
I try to run chtMultiRegionSimpleFoam on a simple case (a tube, with a cube inside), but I have a error.

Here's what I did :
I used gambit to create my mesh with two regions, v_fluid and v_solid,
my boundary are quite simple, inlet, outlet, wall, symetry (it's a 2D case).

Then I used fluent3DToFoam,

Dimension of grid: 3
Number of points: 18170
PointGroup: 1 start: 0 end: 18169. Reading points...done.
Number of faces: 34860
FaceGroup: 4 start: 0 end: 19. Reading mixed faces...done.
FaceGroup: 5 start: 20 end: 17203. Reading mixed faces...done.
FaceGroup: 6 start: 17204 end: 17227. Reading mixed faces...done.
FaceGroup: 7 start: 17228 end: 17243. Reading mixed faces...done.
FaceGroup: 8 start: 17244 end: 18187. Reading mixed faces...done.
FaceGroup: 10 start: 18188 end: 34859. Reading mixed faces...done.
Number of cells: 8592
CellGroup: 2 start: 0 end: 8566 type: 1
CellGroup: 3 start: 8567 end: 8591 type: 1
Zone: 2 name: v_fluid type: fluid. Reading zone data...done.
Zone: 3 name: v_solid type: solid. Reading zone data...done.
Zone: 4 name: wall_internal type: wall. Reading zone data...done.
Zone: 5 name: sym type: symmetry. Reading zone data...done.
Zone: 6 name: outlet type: pressure-outlet. Reading zone data...done.
Zone: 7 name: inlet type: velocity-inlet. Reading zone data...done.
Zone: 8 name: wall type: wall. Reading zone data...done.
Zone: 10 name: default-interior type: interior. Reading zone data...done.

FINISHED LEXING

Creating patch 0 for zone: 4 name: wall_internal type: wall
Creating patch 1 for zone: 5 name: sym type: symmetry
Creating patch 2 for zone: 6 name: outlet type: pressure-outlet
Creating patch 3 for zone: 7 name: inlet type: velocity-inlet
Creating patch 4 for zone: 8 name: wall type: wall
Creating cellZone 0 name: v_fluid type: fluid
Creating cellZone 1 name: v_solid type: solid
Creating faceZone 0 name: default-interior type: interior
faceZone from Fluent indices: 18188 to: 34859 type: interior
patch 0 from Fluent indices: 0 to: 19 type: wall
patch 1 from Fluent indices: 20 to: 17203 type: symmetry
patch 2 from Fluent indices: 17204 to: 17227 type: pressure-outlet
patch 3 from Fluent indices: 17228 to: 17243 type: velocity-inlet
patch 4 from Fluent indices: 17244 to: 18187 type: wall

and after that, splitMeshRegons -cellZones,

Number of regions:2

Writing region per cell file (for manual decomposition) to "/home/users/romain/OpenFOAM/romain-1.7.x/run/backstep/V01-withcube/kw-SST-Groovy/constant/cellToRegion"

Writing region per cell as volScalarField to "/home/users/romain/OpenFOAM/romain-1.7.x/run/backstep/V01-withcube/kw-SST-Groovy/0/cellToRegion"

Region Cells
------ -----
0 8567
1 25

Region Zone Name
------ ---- ----
0 0 v_fluid
1 1 v_solid

Sizes inbetween regions:

Region Region Faces
------ ------ -----

Reading volScalarField cellToRegion
Reading volScalarField p
Reading volScalarField nut
Reading volScalarField k
Reading volScalarField omega
Reading volScalarField nuTilda
Reading volVectorField U
Reading volSymmTensorField R


Adding patches


Adding patches


Region 0
--------
Creating mesh for region 0 v_fluid
Testing:"/home/users/romain/OpenFOAM/romain-1.7.x/run/backstep/V01-withcube/kw-SST-Groovy/system/v_fluid/fvSchemes"
Writing dummy "v_fluid/fvSchemes"
Writing dummy "v_fluid/fvSolution"
Mapping fields
Mapping field cellToRegion
Mapping field k
Mapping field omega
Mapping field nuTilda
Mapping field nut
Mapping field p
Mapping field U
Mapping field R
Deleting empty patches
Writing new mesh
Writing addressing to base mesh
Writing map pointRegionAddressing from region0 points back to base mesh.
Writing map faceRegionAddressing from region0 faces back to base mesh.
Writing map cellRegionAddressing from region0 cells back to base mesh.

Region 1
--------
Creating mesh for region 1 v_solid
Testing:"/home/users/romain/OpenFOAM/romain-1.7.x/run/backstep/V01-withcube/kw-SST-Groovy/system/v_solid/fvSchemes"
Writing dummy "v_solid/fvSchemes"
Writing dummy "v_solid/fvSolution"
Mapping fields
Mapping field cellToRegion
Mapping field k
Mapping field omega
Mapping field nuTilda
Mapping field nut
Mapping field p
Mapping field U
Mapping field R
Deleting empty patches
Writing new mesh
Writing addressing to base mesh
Writing map pointRegionAddressing from region1 points back to base mesh.
Writing map faceRegionAddressing from region1 faces back to base mesh.
Writing map cellRegionAddressing from region1 cells back to base mesh.
End

After that I organise my case as psosnows explains in a previous post (domains folders with their respective datafield without polymesh in 0/, regions porperties + domains folders (with propertiesfikes and polymesh) in constant/ and controldict + domain folders (fv_files) in system)

But when I run chtMultiRegionSimpleFoam, I have the following error

Create time

Create fluid mesh for region v_fluid for time = 0

Create solid mesh for region v_solid for time = 0

*** Reading fluid mesh thermophysical properties for region v_fluid

Adding to thermoFluid

Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo <hConstThermo<perfectGas>>>>>
#0 Foam::error:: printStack(Foam::Ostream&) in "/usr/local/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/usr/local/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib/libc.so.6"
#3 Foam::hPsiThermo<Foam:: pureMixture<Foam::constTransport<Foam:: specieTherm o<Foam::hConstThermo<Foam:: perfectGas> > > > >::calculate() in "/usr/local/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#4 Foam::hPsiThermo<Foam:: pureMixture<Foam::constTransport<Foam::specieTherm o<Foam::hConstThermo<Foam:: perfectGas> > > > >::hPsiThermo(Foam::fvMesh const&) in "/usr/local/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#5 Foam::basicPsiThermo::addfvMeshConstructorToTable< Foam::hPsiThermo<Foam: : pureMixture<Foam::constTran sport<Foam::specieThermo<Foam::hConstThermo<Foam:: perfectGas> > > > > >::New(Foam::fvMesh const&) in "/usr/local/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#6 Foam::basicPsiThermo::New(Foam::fvMesh const&) in "/usr/local/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#7 main in "/usr/local/OpenFOAM/OpenFOAM-1.7.x/applications/bin/linux64GccDPOpt/chtMultiRegionSimpleFoam"
#8 __libc_start_main in "/lib/libc.so.6"
#9 _start at /build/buildd/glibc-2.9/csu/../sysdeps/x86_64/elf/start.S:116
Exception en point flottant

Can you help me ?

Thank you

[nuria87]

Hello nakor, i'm running a similar case of yours and i obtain the same error...
Did you arrived to solved it???

Thank u!

[marval]

Hello everyone!

I have a similar problem in chtMRSimpleFoam:

*** Reading fluid mesh thermophysical properties for region fluid

    Adding to thermoFluid

Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>


--> FOAM FATAL ERROR: 
Not Implemented
    Trying to construct an genericFvPatchField on patch fluid_to_solid of field h

And I think the problem lies in the thermophysicalProperties file because when I try with some other thermophysical models for example changing

thermoType      hPsiThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>;

to

thermoType      ePsiThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>;

I get the following (similar) error:

*** Reading fluid mesh thermophysical properties for region fluid

    Adding to thermoFluid

Selecting thermodynamics package ePsiThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>


--> FOAM FATAL ERROR: 
Not Implemented
    Trying to construct an genericFvPatchField on patch fluid_to_solid of field e

Notice field h vs field e (look in the UserGuide chapter 7 or http://www.openfoam.com/docs/user/thermophysical.php).
My case consists of a solid region (in two parts) and water.

I'll post my entire case with the most relevant files (since it gets too big otherwise) in case anyone wants to look at it.

How do you make it work for water as a fluid?

Regards
Marco

[Canesin]

Originally Posted by marval

My case consists of a solid region (in two parts) and water.

I'll post my entire case with the most relevant files (since it gets too big otherwise) in case anyone wants to look at it.

How do you make it work for water as a fluid?

Regards
Marco

You could use:

hRhoThermo<pureMixture<constTransport<specieThermo<hConstThermo<incompressible>>>>>;

mixture         water 1 18 1000 4181 0 959e-6 6.62;

That is in the new git version of 1.7.x tutorial multiRegionLiquidHeater

[marval]

Originally Posted by Canesin

You could use:

hRhoThermo<pureMixture<constTransport<specieThermo<hConstThermo<incompressible>>>>>;

mixture         water 1 18 1000 4181 0 959e-6 6.62;

That is in the new git version of 1.7.x tutorial multiRegionLiquidHeater

Thank you Fábio!

Didn't know that this option was available in 1.7.x. The strange thing is that the userGuide listed hRhoThermo as an option but when I tried it out it didn't work.
Couldn't make it work with air as fluid either (like in the tutorial case).

* Any ideas why it didn't work with air (as it should do it)?
* Is the new multiRegionLiquidHeater transient or steady state?
* What does git version mean (yes, I'm quite new to Linux/Ubuntu)?
* Is it complicated to upgrade from OF-1.6.x to 1.7.x?

Regards and thank you again!
Marco

[Canesin]

Originally Posted by marval

Thank you Fábio!

Didn't know that this option was available in 1.7.x. The strange thing is that the userGuide listed hRhoThermo as an option but when I tried it out it didn't work.
Couldn't make it work with air as fluid either (like in the tutorial case).

* Any ideas why it didn't work with air (as it should do it)?

Probably because the solver was using hPsiThermo and not hRhoThermo. Really don't have tested.. I have developed my own incompressible conjugated heat transfer solver (paper and code coming soon ...).

* Is the new multiRegionLiquidHeater transient or steady state?

chtMultiRegionFoam is transient, but it permits large time-steps, so the tutorial is transient

* What does git version mean (yes, I'm quite new to Linux/Ubuntu)?

Git is a version control software, OpenCFD use it to control OpenFOAM development, you can follow it in the github site, the hosting used to store they repository (the place where the files stay) www.github.com

* Is it complicated to upgrade from OF-1.6.x to 1.7.x?

Many factors here to complicate things, how did you installed OF-1.6.x ?? Myself, Bruno Santos and Anton Kidess have coded a installer for OF-1.6.x and has some initial work to port it to 1.7.x, I'm already working in it.. But the simplest way to do so is to follow the instructions on www.openfoam.com


Best regards,
Fabio C. Canesin

[mabinty]

hey marval!

had a brief look into your set up. it seems you have messed up your BCs; e.g. i cannot see any changeDictionaryDict in the systen/{region} directories prescribing the BCs of each region as well as their coupling. i d suggest to study the tutorial case again.

cheers,
aram

[marval]

Hello Fabio and Aram!

Originally Posted by Canesin

Probably because the solver was using hPsiThermo and not hRhoThermo. Really don't have tested.. I have developed my own incompressible conjugated heat transfer solver (paper and code coming soon ...).

That sounds nice, hope you like to share it with us later on.

chtMultiRegionFoam is transient, but it permits large time-steps, so the tutorial is transient

Hmm, I would prefer steady state. Large timesteps, could that maybe a solution to make it steady-state? Just thinking loud here...

Many factors here to complicate things, how did you installed OF-1.6.x ?? Myself, Bruno Santos and Anton Kidess have coded a installer for OF-1.6.x and has some initial work to port it to 1.7.x, I'm already working in it.. But the simplest way to do so is to follow the instructions on www.openfoam.com

Yepp, I used the exact same installer (which is great btw) to get started with my work.
I will maybe try to install it in an external device so I don't mess up anything.

Thanks again Fabio!

Regarding Arams post:

Originally Posted by mabinty

had a brief look into your set up. it seems you have messed up your BCs; e.g. i cannot see any changeDictionaryDict in the systen/{region} directories prescribing the BCs of each region as well as their coupling. i d suggest to study the tutorial case again.

Yes and thank you for looking at my case.
There is a reason I don't have changeDictionary, I followed the steps proposed by Pawel in another post:

Originally Posted by psosnows

This is how I do it in the approach I propose:

0-folder: contains domain folders with their respective data fields without polyMesh folders.

constant-folder: regionProperties file and domain folders. Each domain has properties files, AND polyMeshes folder.

system: in main folder controlDict and individual domain folders. In domain subfolers: fv-files.

(no changeDictionaryDict is required, it is used for automatic decomposition)

I also note, that the polyMesh folders require only standard files in them: boundary, owner, neighbour, points, faces. All other may be thrown out (repeating after Einstein: "make everything as simple as possible, but not simpler" )

I attach a picture showing "general idea" of multi region structure I use.

Hope it helps a bit

The attached picture:
http://www.cfd-online.com/Forums/att...iregfolder.jpg

There are similar posts by him:

Originally Posted by psosnows

If I were you, I would do this case like this (it works for my problems fine):
- treat the case that you have as a scrapyard from which you will build up a work case (I will call it TMP);
- create "raw" work case: standard 0, constant, system folders (call RUN);
- in each of standard folders in RUN create "region" subfolders;
Now we build up our case. Copy:
- controlDict to system;
- fvS* files to each subfolder in system;
- regionProperties to constant;
- any files in TMP's constant subfolders to corresponding subfolders in RUN's constant;
- polyMesh from TMP's 0.001 subfolders to corresponding subfolders in RUN's constant;
- all data files from TMP's 0.001 subfolders to corresponding subfolders in RUN's 0;
- worst part, check each boundary file in RUN if the names are different for coupled patches, and if they are the right type (directMappedPatch, explained earlier in the thread)
- check all data files if all boundaries are mentioned. If not, fix it

After doing that, you get a nice OF case: all constant things (like mesh, props) are in constant folder, all initial data are in 0, all simulation control are in system.
It should run smoothly like a summer breeze
For post processing use the "paraFoam -touch -region <X>" trick.

Hope it helps you a bit
Best,
Pawel

ps
Of course you can do things like in tutorial. In my case, after some time I simply got fed up and thought that it is better to do something slower and less automatic, but with understanding of everything, than to go with a ready code... But probably I am just strange

I tried to follow those steps but of course, I could have missed something.
changeDictionary is just an automatic way to define things, it's much faster if it works but I felt more safe defining everything by myself .
Anyway, thank you again for your time and if you have any more ideas please share them.

Regards
Marco

[marval]

Hello again everyone!

I'm soon running out of options with the solvers. I looked at the solver that handles liquids (chtMultiRegionSimpleFoam in OF-1.7.x) and have some questions.

Regarding the new multiRegionLiquidHeater, is it for INcompressible fluids?
The reason I'm asking is because when dealing with compressible cases the pressure (in 0/p-directory) the dimension is

N/m² = kg/(m*s²): [ 1 -1 -2 0 0 0 0 ]

And when it's INcompressible the pressure is divided by the density so the dimension would be (it's also a relative pressure: p_calculated=p-p_reference):

m²/s²: [ 0 2 -2 0 0 0 0 ]

And it looks like in the new multiRegionLiquidHeater the pressure is defined as in a compressible case, does this matter and is there a way around the problem?
As I understood chtMultiRegionSimpleFoam is for compressible fluids, right?

Any other ideas to simulate heat transfer between an INcompressible fluid and a solid?
Start to get a little frustrating...


Regards
Marco

[maddalena]

Originally Posted by marval

Start to get a little frustrating...

... as everyone when using cht in OpenFoam, I guess.

mad

[marval]

Haha, Mad!

"Welcome to the club!"

The UserGuide states quite clearly (after reading more carefully) that chtMultiRegionSimpleFoam is a combination of buoyantSimpleFoam and (the old ??) heatConductionFoam, thus it solves for compressble fluids.
Too bad!

Well, I think I'm gonna try using the new liquidSolver in OF-1.7.x anyway. For the moment I will do the best of the situation (before I install OF-1.7.x) and use air for the simulation in OF-1.6.x.

I was thinking of maybe starting to reach a steady state solution with only the buoyantSimpleFoam solver and use this as starting point in 0-directory for chtMultiRegionSimpleFoam.
Good or bad idea?
Any suggestions on how to set up the 0/U- and 0/p-files to avoid the solver blowing up? I'm more used to incompressible cases.
Should I still use patch -inlet/outlet when creating the mesh for example?
The fluid flows ~0,14 m/s, so I might need an inlet/outlet...or?

Thankful for any further hints!

Regards
Marco

[ksp1717]

Hi

I have the following questions

1. Did anyone from the above who inquired about doing CHT using incompressible fluid succeed in doing it ???
If yes how ???

2. My case involves both the solid and fluid moving. I am thinking of doing something like this

solid
{
boundary
}
U
{
internal field uniform (u v w)
boundaryfield
{
boundary
{
type fixedvalue
uniform (u v w)
}
}
}

Will this work ??? Or should I do something else or add something to the above ??

Thanks,
Shyam

[psosnows]

Hello Shyam,

regarding first question- chtMultiRegionFoam model is based on incompressibility assumption. In that case, I can confirm that I was able to run some simulation. I simply set up the case similarly to the tutorial one and run it

regarding second question-
remember that dividing into "solid" and "fluid" is just artificial. One can name them "plasma" and "strawberry_juice", providing that inside the solver you deal with them.
Now moving into your case. I believe that you want to have a moving element in your domain. I think that it would be sufficient just to set the "fluid_to_solid" boundary as some fixed value. But if you want to have for example a bullet going through a channel (with frame of reference connected to the channel walls), you will need to change the solver.

Best,
Pawel

[sebonator]

Hi there!

I use the cht-Solvers, too. After Marval's statement

"The UserGuide states quite clearly (after reading more carefully) that chtMultiRegionSimpleFoam is a combination of buoyantSimpleFoam and (the old ??) heatConductionFoam, thus it solves for compressble fluids."

I am a bit confused... Is there a bigger difference between chtMultiRegionFoam and chtMultiRegionSimpleFoam than the fact, that the first is a transient and the second is a steady state solver?

My second problem is:
Why is the usage of the coupling condition solidWallMixedtemperatureCoupled only in the chtMultiRegionFoam and not in the chtMultiRegionSimpleFoam possible? As I understood former posts, this coupling condition should be the preferred way to couple solid-solid and solid-fluid regions. But it is not selectable, as it is missing in the solver's derivedFvPatchFields directory (compare $WM_PROJECT_DIR/applications/solvers/heatTransfer/chtMultiRegionFoam/derivedFvPatchFields and $WM_PROJECT_DIR/applications/solvers/heatTransfer/chtMultiRegionSimpleFoam/derivedFvPatchFields). Is there a physical or numerical reason for this fact, that the coupling condition is not selectable in the steady state case?

The last question would be: Which coupling condition should I use for my steady state simulations with chtMultiRegionSimpleFoam? In the steady state tutorials for the solver I found a coupling condition compressible::turbulentTemperatureCoupledBaffleMix ed. From what I found out in the source codes, this coupling condition seems to do almost the same as the solidWallMixedtemperatureCoupled, but I am a bit confused about the "compressible::" at the beginning of the name, because I want to simulate incompressible flow! Or does the "compressible::" not mean anything at all, because it seems as this coupling condition is able to work at solid-solid interfaces, too, and there of course is nothing that needs a compressible treatment...

By the way: I am using the newest 1.7.x-Version, downloaded yesterday from the git-repository

Thanks a lot for your replies!
Greetings Sebastian

[ksp1717]

Hi Pawel

Thanks for your reply. After I posted the question yesterday, I took a look at the solver, tutorials and figured out the answer for question 2. But I was not sure if I am right.

But for question 1, I need to simulate an incompressible flow in steady state. So I am using the solver chtIcoMultiRegionFoam (which is transient) with large time steps. Would this suffice for my problem ?
But since you said I can use the original solver as they are may be i will set up a case with chtMultiRegionSimpleFoam.

Shyam

[psosnows]

Greetings,

Regarding Sebastian's post:

Originally Posted by sebonator

Is there a bigger difference between chtMultiRegionFoam and chtMultiRegionSimpleFoam than the fact, that the first is a transient and the second is a steady state solver?

The chtMultiRegionFoam solver also can work as a steady state one- you just set in the fvScheme file the ddtScheme to be "steadyState". From my brief look the "simple" solver is just free of all time-related features (like time step control, etc.), so it should be working faster if you want just to run steady state case.

Regarding second problem:
This is C++ code related You need to include/link/recompile the boundary condition to work within a specific solver. I mentioned it quite long ago- boundary conditions should be solver-independent. And from what I remember, solidWallTemperatureMixed was.

Regarding last question- unfortunately I can not help... I did not go deeply enough into recent versions of chtMultiRegionFoam.

Regarding Shyam's post:

Originally Posted by ksp1717

So I am using the solver chtIcoMultiRegionFoam (which is transient) with large time steps. Would this suffice for my problem ?
But since you said I can use the original solver as they are may be i will set up a case with chtMultiRegionSimpleFoam.

Sorry, but I can not find chtIcoMultiRegionFoam in my OF-1.7.1 distribution On the other hand, for steady state case chtMultiRegionSimpleFoam should work fine.

Best,
Pawel

[ksp1717]

Hi

The chtIcoMultiRegionFoam is a seperate which i downloaded and compiled from here.

About the chtMultiRegionSimpleFoam, I used that in my case and when I run it, I am not getting anyout put and at the same time I am not getting any error messages.

Here is my output when I run that,

shyam@sujatha:~/Desktop/Oven$ ./Allrun
Running blockMesh on /home/shyam/Desktop/Oven
Running setSet on /home/shyam/Desktop/Oven
Running setsToZones on /home/shyam/Desktop/Oven
Running splitMeshRegions on /home/shyam/Desktop/Oven
Running chtMultiRegionSimpleFoam on /home/shyam/Desktop/Oven

creating files for paraview post-processing

created 'Oven{web}.OpenFOAM'
created 'Oven{air}.OpenFOAM'

I did not get any output files.

I have lefteverything as it is from the tutorial case except ofcourse the blockMesh and changeDictionaryDict files.

Can you tell me whats wrong ???

Shyam


UPDATE:

I ran one command after another and found out that I entered a keyword incorrect. After I corrected it, the solver started running.

Shyam

[sebonator]

Hi Pawel,

First of all: Thanks for your reply!

Unfortunately I don't get how to use the chtMultiRegionFoam-Solver for my steadyState case. The calculation always crashes with a floating point exception when the solver tries to solve the fluid field for the first time. The fluid regions are generally solved first, so I don't know if the problem is related to the fluid field. When I use the solver in a transient way, it works as it should...

Can you please explain a bit more in detail, what I have to change in order to use the transient solver for steadyState calculations? I only changed the ddtScheme from Euler to steadyState as you told me in your former post, but this seems not to be all... I was a bit confused about the PIMPLE-Algorithm in fvSolution because I thought this is a algorithm for transient cases. Unfortunately, a switch to SIMPLE is not accepted by the solver, so it seems as if PIMPLE has to be used for the steadyState case, too.

If you don't really know the answers to my questions, then I would prefer to return to the chtMultiRegionSimpleFoam-Solver for my steadyState problems and recompile it to make the usage of the coupling condition solidWallMixedtemperatureCoupled possible. Could you please explain a bit more in detail what I have to do for that? Or is it as easy as: Copy the directory for this coupling condition from the chtMultiRegionFoam-Solver to the chtMultiRegionSimpleFoam-Solver, include some .H-files and then use wmake? If it is that easy, than where do I have to include which .H-files? From a first look to chtMultiRegionSimpleFoam.C, I wasn't able even to find the "#include "solidWallHeatFluxTemperature.H"" statement, so I definetely don't know where to include that.

Hope you can help me again...

thanks in advance,
Greetings Sebastian

[psosnows]

Hello Sebastian,

Originally Posted by sebonator

Unfortunately I don't get how to use the chtMultiRegionFoam-Solver for my steadyState case. The calculation always crashes with a floating point exception when the solver tries to solve the fluid field for the first time.

This means you have something wrong with the case- you perform some division by zero or similar. Go step by step checking all fields, dimensions, values, parameters, schemes, well... everything in the case. My bet is that there is problem with density or/and specific heat.

Originally Posted by sebonator

(...) what I have to change in order to use the transient solver for steadyState calculations? I only changed the ddtScheme from Euler to steadyState

That is (should be) enough. When you set ddt scheme to steadyState, the solver does not work with the fvc::ddt( ) expression. The solver becomes steady state. But! usually transient solvers have some time/convergence controls. They are still calculated but not used- thus the solver is "fat" and a bit slower than the "slim" designed-for-steady-state version.

Originally Posted by sebonator

(...) I would prefer to return to the chtMultiRegionSimpleFoam-Solver for my steadyState problems

This may be the best and most efficient way

Originally Posted by sebonator

Could you please explain a bit more in detail what I have to do for that? Or is it as easy as: Copy the directory for this coupling condition from the chtMultiRegionFoam-Solver to the chtMultiRegionSimpleFoam-Solver, include some .H-files and then use wmake? If it is that easy, than where do I have to include which .H-files? From a first look to chtMultiRegionSimpleFoam.C, I wasn't able even to find the "#include "solidWallHeatFluxTemperature.H"" statement, so I definetely don't know where to include that.

We have to slow down for a moment. First I will try to explain how it works (in my humble opinion), and later you will find a detail "recipe" how to do that

We get into C++ structure of OF solvers and BC's. Each- the solver code and the BC code are (should be) separate beings, which can be compiled separately into objects. Those objects are later on linked together to create a working program- a "Solver". Using "wmake" is just a fancy and easy way of writing "g++ -c ..." for each created source code and then linking the results. Take a look at the "Make/files" file. Each line (except the one starting with EXE or LIB) contains name and path to a file that is to be compiled. The objects are stored in "Make/linuxBBGccDpOpt" folder (the *.o fiels). Then they are linked and create an executable program which is saved into EXE=PATH_TO_EXE_FOLDER.

Now, why we do not have the "#include BC" in the code and it still works?
The answer is once again the brilliant object oriented structure of OF. The solver code wants to have some boundary. During the compilation of the solver code, we do not provide it exactly. We just say- it will have this standard structure, take these standard parameters, allow some standard functionality and give some standard output. And now, ANY boundary condition object, that matches the solvers expectations can be used! The only thing is that you need to link the object while creating executable Solver and then specify it when you run the case.

Sorry but I can not put it out simpler :P If you have doubts, you may need to contact someone that works with object-oriented programming.

And finally, the "recipe"
- copy the original chtMultiRegionSimpleFoam solver to your /user-1.7.x/applications/ folder (always work on a copy ) ;
- go there and run wclean ;
- rename the directory and the main .C file to something like MYchtMultiRegionSimpleFoam ;
- copy the chtMultiRegion/derivedFvPatchFields/solidWallMixedTemperatureCoupled to your derivedFvPatchFields/ folder ;
- edit the Make/files file:
- - add as first line derivedFvPatchFields/solidWallMixedTemperatureCoupled/solidWallMixedTemperatureCoupledFvPatchScalarField .C ;
- - change chtMultiRegionSimpleFoam.C to MYchtMultiRegionSimpleFoam.C ;
- - change EXE = (...) to EXE = $(FOAM_USER_APPBIN)/MYchtMultiRegionSimpleFoam ;
- make sure that you have folder /user-1.7.x/applications/bin/linux64GccDPOpt (if you use 32bit change 64 to 32) ;
- run wmake ;
- set the case properly. Take special care about patches coupled by solidWallMixedTemperatureCoupled ;
- you are ready to go use MYchtMultiRegionSimpleFoam solver.

Hope you will make it- this procedure worked for me today for using solidWallMixedTemperatureCoupled in chtSimple tutorial case.

Best,
Pawel

[sebonator]

Hi Pawel,

WOW... thank you so much for your detailed explanation! Your instructions were absolutely correct, the modified solver worked on the first try and accepted the solidWallMixedTemperatureCoupled BC!

And especially thank you for your general words at the beginning of your post! This was something I was looking for since I began to work with OpenFOAM two months ago! I was able to write procedural c-code when I started up, learned the object-orientated stuff of c++ in order to understand the OpenFOAM codes, but this thing concerning the linking between different source codes during compilation was the piece that was missing in my puzzle to understand OpenFOAM's codes... Thank you so much, I hope I am now able to modify utilities on my own.

Well, at least the steadyState simulations with my MODchtMultiRegionSimpleFoam run for about 180 steps. After that the solver stops because it exceeds the maximum number of iterations. It seems as if my temperature field diverges... I get temperatures ranging from -1000 to 770 K but i don't know why...(The 'physical' temperature range is 300 to 600 K) I think my initial conditions are not inside the convergence radius, but as the setFields-utility for example doesn't accept the -region option, I don't know an easy way to set up proper initial conditions... This is another gap to be closed in OpenFOAM's codes, because several other utilities like foamCalc of wallHeatFlux do not accept this option, too, and are not usable in such a splitted mesh calculations therefore.

Does anybody know how to modify for example the setFields utility in order to use it for regions? Or is it my fault and those utilities can be used in splitted mesh cases? How do I have to use them then?

Pawel, you advised me to check the internal boundaries. What could be done wrong on the internal boundaries? The only thing I could think of are different initial values for temperature on these patches, but I am not even sure if that would make the calculation crash...

Thanks in advance, and as I said above, special thanks to Pawel for his detailed instructions!

Greetings Sebastian