[Zeppo]

Problem Formulation
I am about to model a complex problem of conjugate heat transfer in a set of fluids/solids coupled to each other through shared boundaries (interfaces). Thermal conduction defines heat transfer in solid regions. Thermal conduction, thermal radiation and convection govern heat transfer in fluid regions. chtMultiRegionSimpleFoam solver seems to be an adequate choice to solve such a problem.

Before I go into the world of real engineering problems I consider a rather simple test case. A sketch of my geometry is here.



Yes, the mesh is quite coarse and not optimal (an external mesher was utilized to construct polyhedral cells). Anyway, I guess I can live with it.

We have 3 concentric spherical layers: inner (cellZone_1), central (cellZone_2) and outer (cellZone_3) regions. The inner surface of cellZone_1 is at constant temperature 300°K; the outer surface of cellZone_3 is at constant temperature 2000°K; cellZone_2 is thermally coupled with cellZone_1 and cellZone_3 at its surfaces.

А sample line to plot some results along is shown below.



Part 1
To start off I narrowed a complex general case to a simple problem avoiding all the heat transfer options except thermal conduction in solid regions (with thermal conductivity “kappa” = 10 W/(m K)). OpenFOAM handled its job quite well! A graph in which the values of temperature are plotted along the sample line is shown here. OpenFOAM solution is compared with proprietary software solution. Perfect coincidence!



Part 2
Then I added some complexity to the simulation problem – now the central region is considered to be transparent for gray thermal radiation to transfer between region boundaries (surface-to-surface radiation with non-participating medium). Here comes the problem. All 3 regions remain solid as in the simplest case mentioned before:

//“constant/regionProperties”
regions
(
    fluid       ()
    solid       (cellZone_1 cellZone_2 cellZone_3)

Here is the "constant/cellZone_2/radiationProperties" file for the central region:

//“constant/cellZone_2/radiationProperties”
radiation       on;
radiationModel  viewFactor;
viewFactorCoeffs
{
    smoothing true;
    constantEmissivity true;
}
solverFreq 3;
absorptionEmissionModel none;
scatterModel    none;
sootModel       none;

As I said before I want to simulate thermal radiation exchange between diffuse surfaces forming a closed region (cellZone_2). The medium that fills the space between the surfaces is non-participating, that is it neither absorbs, emits, or scatters radiation. Under these circumstances, the amount of radiation received and emitted by each surface should be uniquely defined by the surface’s radiation properties and the thermal boundary conditions imposed on it. That’s why I turned off absorptionEmissionModel, scatterModel and sootModel.

For inner and outer regions I have "constant/cellZone_1/radiationProperties" and "constant/cellZone_3/radiationProperties":

//“constant/cellZone_1/radiationProperties”, “constant/cellZone_3/radiationProperties”
radiation				on;
radiationModel			opaqueSolid;
absorptionEmissionModel	none; 
scatterModel			none;
sootModel				none;

Should I set “radiation off;” and “radiationModel none;” instead?

Initial and boundary conditions are defined in a strange way. First of all why should we ever need pressure “p” file for our solid regions? Doesn’t we solve only for energy? When I remove this pressure file the solver starts to complain about it.

[2] --> FOAM FATAL IO ERROR:
[2] cannot find file
[2]
[2] file: /home/geeko/OpenFOAM/geeko-2.4.0/run/my_cases/radiation_sphere/processor2/0/cellZone_1/p at line 0.
[2]
[2]     From function regIOobject::readStream()
[2] /home/geeko/OpenFOAM/geeko-2.4.0/run/my_cases/radiation_sphere/processor1/0/cellZone_1/p at line 0.
[1]
[1]     From function regIOobject::readStream()
[1]     in file db/regIOobject/regIOobjectRead.C at line 73.

Next question is how to define temperature boundary conditions on the interfaces. For regions cellZone_1 and cellZone_3 they are:

//"0/cellZone_1/T", "0/cellZone_3/T"
".*_to_.*"
{
    type            compressible:: turbulentTemperatureRadCoupledMixed; 
    value           uniform 300;
    Tnbr            T;
    kappa           solidThermo;
    kappaName       none;
    QrNbr           Qr;
    Qr              none;
}

For region cellZone_2 we define:

//"0/cellZone_2/T"
".*_to_.*"
{
    type            compressible::turbulentTemperatureRadCoupledMixed;
    value           uniform 300;
    Tnbr            T;
    kappa           solidThermo;
    kappaName       none;
    QrNbr           none;
    Qr              Qr;
}

Basically the difference is how “Qr” and “QrNbr” are specified. Instead of “turbulentTemperatureRadCoupledMixed” I could probably have used “turbulentTemperatureCoupledBaffleMixed” as a type of this bc. What’s the difference between them? When should I use one and when another?

The way we specify radiation heat flux “Qr” on boundaries leaves no alternative. Note radiation "emissivity uniform 1".

// "0/cellZone_2/Qr"
".*_to_.*"
{
    type              greyDiffusiveRadiationViewFactor;
    value             uniform 0;
    emissivityMode    solidRadiation;
    Qro               uniform 0;
    emissivity        uniform 1;
}

Btw, “emissivityMode” can either be “solidRadiation” or “lookup” and I haven’t figured out yet how to make use of them. Have you?

With all this set-up I can say it didn't do me any good. I didn’t manage to obtain correct solution in OpenFOAM. It turned out that thermal radiation cannot be solved in solid regions. The temperature profile along my sample line is the same as in the no-radiation case. Correct solution obtained with proprietary software is shown in the picture above (it is marked as “proprietary, radOn”) as a reference. OpenFoam “Qr” field is zero everywhere at the end of simulation. No radiation transfer is observed:



Part 3
Well, what if I made my central region (cellZone_2) fluid, not solid? Let’s see if we could benefit from it.

//“constant/regionProperties”
regions
(
    fluid       (cellZone_2)
    solid       (cellZone_1 cellZone_3)
);

And I don’t want OpenFOAM to solve for fluid flow variables. Fluid should be stationary, permanent. It is the energy equation that is only solved. We can achieve this in chtMultiRegionSimpleFoam with a special option “frozenFlow on” in “system/cellZone_2/fvSolution”.

//“system/cellZone_2/fvSolution”
SIMPLE
{
    …
    frozenFlow	    on;
}

Thermophysical properties for my fluid region now look like this

// “constant/cellZone_2/thermophysicalProperties”
thermoType
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState rhoConst;
    specie          specie;
    energy          sensibleEnthalpy;
}
pRef            100000;
mixture
{
    specie
    {
        nMoles          1;
        molWeight       28.9;
    }
    thermodynamics
    {
        Cp              1000;
        Hf              0;
    }
    transport
    {
        mu              1.8e-05;
        Pr              0.0018; //Pr=mu*Cp/kappa
    }
    equationOfState
    {
        rho		1e-2;
    }
}

The key point here is that we cannot define thermal conductivity coefficient “kappa” explicitly in the transport dictionary the way we do for solid regions. That means the solver derive it implicitly. The question is how? I thought it was “Pr=mu*Cp/kappa” -> “kappa=mu*Cp/Pr” = 1.8e-05*1000/0.0018=10. It turned out that I was wrong, somehow “kappa” depends on density “rho”. A set of simulations were carried out with different values for “rho”, other thermophysical properties being identical throughout the simulations. Thermal radiation was deactivated. Here are my results for “rho” = 1e-02, 1e-01, 1e-00, 1e+02 kg/m^3. The reference dashed line is for the case where all the regions are solid.



Can anyone comment on this? What is the relation between “kappa” and “rho”?

Then I switched radiation on (“viewFactorsModel”). “radiationProperties” file for fluid region remained the same as it was in the all-solids case. “radiationProperties” files for inner and outer solid regions had to be altered. Specifically “absorptionEmissionModel” cannot be “none” anymore. I had to set “absorptionEmissionModel constantAbsorptionEmission” otherwise the solver blows up and shows this message:

Time = 1

Solving for fluid region cellZone_2
DILUPBiCG:  Solving for h, Initial residual = 0.5466406, Final residual = 0.02687252, No Iterations 2
[0] #0  Foam::error::printStack(Foam::Ostream&) at ??:?
[0] #1  Foam::sigFpe::sigHandler(int) at ??:?
[0] #2  ? in "/lib64/libc.so.6"
[0] #3  Foam::radiation::viewFactor::calculate() at ??:?
[0] #4  Foam::radiation::radiationModel::correct() at ??:?
[0] #5  ? at ??:?
[0] #6  __libc_start_main in "/lib64/libc.so.6"
[0] #7  ? at /home/abuild/rpmbuild/BUILD/glibc-2.17/csu/../sysdeps/x86_64/start.S:126
[linux:06114] *** Process received signal ***
[linux:06114] Signal: Floating point exception (8)
[linux:06114] Signal code:  (-6)
[linux:06114] Failing at address: 0x3e8000017e2
[linux:06114] [ 0] /lib64/libc.so.6(+0x35450) [0x7f42d69d6450]
[linux:06114] [ 1] /lib64/libc.so.6(gsignal+0x35) [0x7f42d69d63d5]
[linux:06114] [ 2] /lib64/libc.so.6(+0x35450) [0x7f42d69d6450]
[linux:06114] [ 3] /opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libradiationModels.so(_ZN4Foam9radiation10viewFactor9calculateEv+0xd83) [0x7f42d8cfd273]
[linux:06114] [ 4] /opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libradiationModels.so(_ZN4Foam9radiation14radiationModel7correctEv+0x1f) [0x7f42d8cbf55f]
[linux:06114] [ 5] chtMultiRegionSimpleFoam() [0x441202]
[linux:06114] [ 6] /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f42d69c2a15]
[linux:06114] [ 7] chtMultiRegionSimpleFoam() [0x44a08d]
[linux:06114] *** End of error message ***

So I ended up having radiation absorption and emission (participating media) in solid regions:

“constant/cellZone_1/radiationProperties”, “constant/cellZone_3/radiationProperties”
Radiation               on;
radiationModel          opaqueSolid; 
absorptionEmissionModel constantAbsorptionEmission;
constantAbsorptionEmissionCoeffs
{
    absorptivity    absorptivity [ 0 -1 0 0 0 0 0 ] 0;
    emissivity      emissivity [ 0 -1 0 0 0 0 0 ] 1;
    E               E [ 1 -1 -3 0 0 0 0 ] 0;
}

“emissivity emissivity [ 0 -1 0 0 0 0 0 ]” parameter heavily affects solution. Take a look at the next plot, please.



As I said before I am not interested in having radiation within inner and outer regions. All I want is surface-to-surface radiation in central region. Moreover, no matter what emissivity defined on the boundaries (in “0/Qr” file) is, it seems to have no effect on the solution. This is totally opposed to my goal.

Conclusion
To sum everything up I can say that I failed to get chtMultiRegionSimpleFoam working the way I need. Should anyone have positive experience working with the solver please share your thoughts on the subject. You can download my OpenFOAM cases from this links:
radiation_sphere_solid: http://s000.tinyupload.com/?file_id=...00567809681193
radiation_sphere_fluid: http://s000.tinyupload.com/?file_id=...41445147881545

[zfaraday]

Hi Zeppo!
Interesting post yours! As I developed my Final Thesis using this solver and working with radiation I think I can help you with most of your doubts in this post. Geometry is quite simple, wich is good when you first try to model a system with the intention to understand how physical phenomena is modelled with OF. Now I will try to respond to your main hesitations with the most accurate information I can give you. Take into account that I developed my Final Thesis with OF 2.3.x, so my explanations are referred to this version's code, some aspects may have changed from this version on (the newst verision launched is 3.0.x).

Originally Posted by Zeppo

Part 1

...

Simple case. No comment about it.

Originally Posted by Zeppo

Part 2
Then I added some complexity to the simulation problem – now the central region is considered to be transparent for gray thermal radiation to transfer between region boundaries (surface-to-surface radiation with non-participating medium). Here comes the problem. All 3 regions remain solid as in the simplest case mentioned before:

//“constant/regionProperties”
regions
(
    fluid       ()
    solid       (cellZone_1 cellZone_2 cellZone_3)

Here is the "constant/cellZone_2/radiationProperties" file for the central region:

//“constant/cellZone_2/radiationProperties”
radiation       on;
radiationModel  viewFactor;
viewFactorCoeffs
{
    smoothing true;
    constantEmissivity true;
}
solverFreq 3;
absorptionEmissionModel none;
scatterModel    none;
sootModel       none;

As I said before I want to simulate thermal radiation exchange between diffuse surfaces forming a closed region (cellZone_2). The medium that fills the space between the surfaces is non-participating, that is it neither absorbs, emits, or scatters radiation. Under these circumstances, the amount of radiation received and emitted by each surface should be uniquely defined by the surface’s radiation properties and the thermal boundary conditions imposed on it. That’s why I turned off absorptionEmissionModel, scatterModel and sootModel.

Well, sadly I have to tell you that OpenFOAM doesn't support radiative transport within a solid media. This is an important aspect I had to figure out during the development of my thesis, I couldn't find a way to define a (semi) transparent solid. As far as I know, radiation can only be defined within a fluid region. Maybe things have changed during the last OF versions launched...

Besides that, I think that view factors method can't handle participating media, just surface to surface radiation...

Originally Posted by Zeppo

For inner and outer regions I have "constant/cellZone_1/radiationProperties" and "constant/cellZone_3/radiationProperties":

//“constant/cellZone_1/radiationProperties”, “constant/cellZone_3/radiationProperties”
radiation				on;
radiationModel			opaqueSolid;
absorptionEmissionModel	none; 
scatterModel			none;
sootModel				none;

Should I set “radiation off;” and “radiationModel none;” instead?

I think it makes no difference...

Originally Posted by Zeppo

Initial and boundary conditions are defined in a strange way. First of all why should we ever need pressure “p” file for our solid regions? Doesn’t we solve only for energy? When I remove this pressure file the solver starts to complain about it.

[2] --> FOAM FATAL IO ERROR:
[2] cannot find file
[2]
[2] file: /home/geeko/OpenFOAM/geeko-2.4.0/run/my_cases/radiation_sphere/processor2/0/cellZone_1/p at line 0.
[2]
[2]     From function regIOobject::readStream()
[2] /home/geeko/OpenFOAM/geeko-2.4.0/run/my_cases/radiation_sphere/processor1/0/cellZone_1/p at line 0.
[1]
[1]     From function regIOobject::readStream()
[1]     in file db/regIOobject/regIOobjectRead.C at line 73.

I'm not quite sure about the reason that explains this fact, but the point is that, as you point out, p MUST be defined!

Originally Posted by Zeppo

Next question is how to define temperature boundary conditions on the interfaces. For regions cellZone_1 and cellZone_3 they are:

//"0/cellZone_1/T", "0/cellZone_3/T"
".*_to_.*"
{
    type            compressible:: turbulentTemperatureRadCoupledMixed; 
    value           uniform 300;
    Tnbr            T;
    kappa           solidThermo;
    kappaName       none;
    QrNbr           Qr;
    Qr              none;
}

For region cellZone_2 we define:

//"0/cellZone_2/T"
".*_to_.*"
{
    type            compressible::turbulentTemperatureRadCoupledMixed;
    value           uniform 300;
    Tnbr            T;
    kappa           solidThermo;
    kappaName       none;
    QrNbr           none;
    Qr              Qr;
}

Basically the difference is how “Qr” and “QrNbr” are specified. Instead of “turbulentTemperatureRadCoupledMixed” I could probably have used “turbulentTemperatureCoupledBaffleMixed” as a type of this bc. What’s the difference between them? When should I use one and when another?

Qr and QrNbr fields are used to tell OF which radiative heat fluxes are to be taken into account in the patch's thermal balance, that is to say, if radiative flux in the patch comes from the neighbour region or from the region itself (or even if both regions have radiation travelling within, I never used this option...). If both are set to "none", then “turbulentTemperatureRadCoupledMixed” does exactly the same as “turbulentTemperatureCoupledBaffleMixed”.

Originally Posted by Zeppo

The way we specify radiation heat flux “Qr” on boundaries leaves no alternative. Note radiation "emissivity uniform 1".

// "0/cellZone_2/Qr"
".*_to_.*"
{
    type              greyDiffusiveRadiationViewFactor;
    value             uniform 0;
    emissivityMode    solidRadiation;
    Qro               uniform 0;
    emissivity        uniform 1;
}

Btw, “emissivityMode” can either be “solidRadiation” or “lookup” and I haven’t figured out yet how to make use of them. Have you?

Well, "solidRadiation" retrieves the value of emissivity from the radiationProperties file of the solid region itself, while "lookup" uses the value specified in the "emissivity" field (uniform 1, in this case). (Marked in red for a future purpose!!)

Originally Posted by Zeppo

With all this set-up I can say it didn't do me any good. I didn’t manage to obtain correct solution in OpenFOAM. It turned out that thermal radiation cannot be solved in solid regions. The temperature profile along my sample line is the same as in the no-radiation case. Correct solution obtained with proprietary software is shown in the picture above (it is marked as “proprietary, radOn”) as a reference. OpenFoam “Qr” field is zero everywhere at the end of simulation. No radiation transfer is observed:

Your set up seems to be OK, but I haven't tested it, maybe nowadays it is possible to define a (semi) transparent solid, but you haven't found the proper way... However, as I mentioned above, I could find the way to do so with OF 2.3.x.

Originally Posted by Zeppo

Part 3
Well, what if I made my central region (cellZone_2) fluid, not solid? Let’s see if we could benefit from it.

//“constant/regionProperties”
regions
(
    fluid       (cellZone_2)
    solid       (cellZone_1 cellZone_3)
);

And I don’t want OpenFOAM to solve for fluid flow variables. Fluid should be stationary, permanent. It is the energy equation that is only solved. We can achieve this in chtMultiRegionSimpleFoam with a special option “frozenFlow on” in “system/cellZone_2/fvSolution”.

//“system/cellZone_2/fvSolution”
SIMPLE
{
    …
    frozenFlow	    on;
}

Maybe this is a naïve solution, but it is something I haven't think about before and maybe it can be a first step to solve the problem!!!

Originally Posted by Zeppo

Thermophysical properties for my fluid region now look like this

// “constant/cellZone_2/thermophysicalProperties”
thermoType
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState rhoConst;
    specie          specie;
    energy          sensibleEnthalpy;
}
pRef            100000;
mixture
{
    specie
    {
        nMoles          1;
        molWeight       28.9;
    }
    thermodynamics
    {
        Cp              1000;
        Hf              0;
    }
    transport
    {
        mu              1.8e-05;
        Pr              0.0018; //Pr=mu*Cp/kappa
    }
    equationOfState
    {
        rho		1e-2;
    }
}

The key point here is that we cannot define thermal conductivity coefficient “kappa” explicitly in the transport dictionary the way we do for solid regions. That means the solver derive it implicitly. The question is how? I thought it was “Pr=mu*Cp/kappa” -> “kappa=mu*Cp/Pr” = 1.8e-05*1000/0.0018=10. It turned out that I was wrong, somehow “kappa” depends on density “rho”. A set of simulations were carried out with different values for “rho”, other thermophysical properties being identical throughout the simulations. Thermal radiation was deactivated. Here are my results for “rho” = 1e-02, 1e-01, 1e-00, 1e+02 kg/m^3. The reference dashed line is for the case where all the regions are solid.



Can anyone comment on this? What is the relation between “kappa” and “rho”?

Well, at first sight, it seems that there's a relation between "kappa" and "rho" although we know that it shouldn't be like that... However, despite "rho" shouldn't affect the final results, I geuss it has an impact on the convergence velocity of the solution! Are you sure that all the results posted above have converged properly? I bet that some of the cases haven't run till the solution has converged...

Originally Posted by Zeppo

Then I switched radiation on (“viewFactorsModel”). “radiationProperties” file for fluid region remained the same as it was in the all-solids case. “radiationProperties” files for inner and outer solid regions had to be altered. Specifically “absorptionEmissionModel” cannot be “none” anymore. I had to set “absorptionEmissionModel constantAbsorptionEmission” otherwise the solver blows up and shows this message:

Time = 1

Solving for fluid region cellZone_2
DILUPBiCG:  Solving for h, Initial residual = 0.5466406, Final residual = 0.02687252, No Iterations 2
[0] #0  Foam::error::printStack(Foam::Ostream&) at ??:?
[0] #1  Foam::sigFpe::sigHandler(int) at ??:?
[0] #2  ? in "/lib64/libc.so.6"
[0] #3  Foam::radiation::viewFactor::calculate() at ??:?
[0] #4  Foam::radiation::radiationModel::correct() at ??:?
[0] #5  ? at ??:?
[0] #6  __libc_start_main in "/lib64/libc.so.6"
[0] #7  ? at /home/abuild/rpmbuild/BUILD/glibc-2.17/csu/../sysdeps/x86_64/start.S:126
[linux:06114] *** Process received signal ***
[linux:06114] Signal: Floating point exception (8)
[linux:06114] Signal code:  (-6)
[linux:06114] Failing at address: 0x3e8000017e2
[linux:06114] [ 0] /lib64/libc.so.6(+0x35450) [0x7f42d69d6450]
[linux:06114] [ 1] /lib64/libc.so.6(gsignal+0x35) [0x7f42d69d63d5]
[linux:06114] [ 2] /lib64/libc.so.6(+0x35450) [0x7f42d69d6450]
[linux:06114] [ 3] /opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libradiationModels.so(_ZN4Foam9radiation10viewFactor9calculateEv+0xd83) [0x7f42d8cfd273]
[linux:06114] [ 4] /opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libradiationModels.so(_ZN4Foam9radiation14radiationModel7correctEv+0x1f) [0x7f42d8cbf55f]
[linux:06114] [ 5] chtMultiRegionSimpleFoam() [0x441202]
[linux:06114] [ 6] /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f42d69c2a15]
[linux:06114] [ 7] chtMultiRegionSimpleFoam() [0x44a08d]
[linux:06114] *** End of error message ***

So I ended up having radiation absorption and emission (participating media) in solid regions:

“constant/cellZone_1/radiationProperties”, “constant/cellZone_3/radiationProperties”
Radiation               on;
radiationModel          opaqueSolid; 
absorptionEmissionModel constantAbsorptionEmission;
constantAbsorptionEmissionCoeffs
{
    absorptivity    absorptivity [ 0 -1 0 0 0 0 0 ] 0;
    emissivity      emissivity [ 0 -1 0 0 0 0 0 ] 1;
    E               E [ 1 -1 -3 0 0 0 0 ] 0;
}

“emissivity emissivity [ 0 -1 0 0 0 0 0 ]” parameter heavily affects solution. Take a look at the next plot, please.

Of cours it has an effect on the solution! However, this effect is not related to the radiation within the solid region itself, since it is defined as "opaqueSolid" so no radiation travels through it. Remember what I said before in the sentence coloured in red, the parameter "emissivity" defines the patch's emissivity to be taken into account in the thermal balance!

Originally Posted by Zeppo

As I said before I am not interested in having radiation within inner and outer regions. All I want is surface-to-surface radiation in central region. Moreover, no matter what emissivity defined on the boundaries (in “0/Qr” file) is, it seems to have no effect on the solution. This is totally opposed to my goal.

Conclusion
To sum everything up I can say that I failed to get chtMultiRegionSimpleFoam working the way I need. Should anyone have positive experience working with the solver please share your thoughts on the subject. You can download my OpenFOAM cases from this links:
radiation_sphere_solid: http://s000.tinyupload.com/?file_id=...00567809681193
radiation_sphere_fluid: http://s000.tinyupload.com/?file_id=...41445147881545

To conclude, radiation within a solid media is a tricky matter I'm really interested in and it has no easy solution as per what I have studied... However, I think that using the "frozenFlow trick" that you pointed out might be a good starting point in order to find a work-around to define transparent solid media...

I hope that my words have come in handy for your purpose and may help you with your future simulations!

Best regards,

Alex

[Zeppo]

Hello Alex.

Originally Posted by zfaraday

Hi Zeppo!
Take into account that I developed my Final Thesis with OF 2.3.x, so my explanations are referred to this version's code, some aspects may have changed from this version on (the newst verision launched is 3.0.x).

I am experimenting with OF v.2.4.x. All the things I said are referred to this version.

Originally Posted by zfaraday

Well, sadly I have to tell you that OpenFOAM doesn't support radiative transport within a solid media. This is an important aspect I had to figure out during the development of my thesis, I couldn't find a way to define a (semi) transparent solid. As far as I know, radiation can only be defined within a fluid region. Maybe things have changed during the last OF versions launched...

I read release notes on OF-3.0 and haven't seen a word about any new features they added to model thermal radiation. Anyway I have to check it out by myself.

Originally Posted by zfaraday

Besides that, I think that view factors method can't handle participating media, just surface to surface radiation...

You are right, turning on "absorptionEmissionModel" in a region with "radiationModel viewFactor" doesn't change a thing. It can't handle it. And it is just what I expect from "viewFactor" (surface-to-surface) method.

Originally Posted by zfaraday

Qr and QrNbr fields are used to tell OF which radiative heat fluxes are to be taken into account in the patch's thermal balance, that is to say, if radiative flux in the patch comes from the neighbour region or from the region itself (or even if both regions have radiation travelling within, I never used this option...). If both are set to "none", then “turbulentTemperatureRadCoupledMixed” does exactly the same as “turbulentTemperatureCoupledBaffleMixed”.

When I set "QrNbr none; Qr none;" on some boundaries it should mean that these patches don't participate in radiation energy exchange, right?

//"0/cellZone_2/T"
".*_to_.*"
{
     type                 compressible::turbulentTemperatureRadCoupledMixed;
     value               uniform 300;
     Tnbr                T;
     kappa             fluidThermo;
     QrNbr            none;
      Qr                   none
     kappaName  none; 
}

Plots indicate the opposite!



Kind of strange and suspicious, isn't it? Then how can I exclude some boundaries from RTE when I don't want them to take part in radiation exchange? Is it ever possible?

Originally Posted by zfaraday

Well, "solidRadiation" retrieves the value of emissivity from the radiationProperties file of the solid region itself, while "lookup" uses the value specified in the "emissivity" field (uniform 1, in this case). (Marked in red for a future purpose!!)

You mean when I have "emissivityMode solidRadiation" on a boundary in my central fluid region then emissivity is obtained from the adjacent solid region? But I can't see where emissivity is specified in the solid region to be used as emissivity for the adjacent fluid region.

//"constant/cellZone_1/radiationProperties", "constant/cellZone_3/radiationProperties"
radiation       off;
radiationModel  opaqueSolid;
absorptionEmissionModel none;
constantAbsorptionEmissionCoeffs
{
    absorptivity    absorptivity [ 0 -1 0 0 0 0 0 ] 0.0;  //opaque
    emissivity      emissivity [ 0 -1 0 0 0 0 0 ] 0.0;
    E               E [ 1 -1 -3 0 0 0 0 ] 0;
}
scatterModel    none;
sootModel none;

Originally Posted by zfaraday

Maybe this is a naïve solution, but it is something I haven't think about before and maybe it can be a first step to solve the problem!!!

Is far as I remember I found this trick on the forum while searching for any information regarding chtMultiRegionSimpleFoam solver. It was maybe even somewhere in your threads.

Originally Posted by zfaraday

Well, at first sight, it seems that there's a relation between "kappa" and "rho" although we know that it shouldn't be like that... However, despite "rho" shouldn't affect the final results, I geuss it has an impact on the convergence velocity of the solution! Are you sure that all the results posted above have converged properly? I bet that some of the cases haven't run till the solution has converged...

I am sure all the solutions are totally converged. The typical residuals are

Solver output shows no sign of progress in solution. It is obviously converged:

Time = 998


Solving for fluid region cellZone_2
DILUPBiCG:  Solving for h, Initial residual = 9.552542e-08, Final residual = 9.552542e-08, No Iterations 0
Min/max T:1738.045 1851.023

Solving for solid region cellZone_1
DICPCG:  Solving for h, Initial residual = 9.899032e-07, Final residual = 9.899032e-07, No Iterations 0
Min/max T:300 1789.063

Solving for solid region cellZone_3
DICPCG:  Solving for h, Initial residual = 9.094747e-07, Final residual = 9.094747e-07, No Iterations 0
Min/max T:1816.936 2000
ExecutionTime = 66.05 s  ClockTime = 78 s

Time = 999


Solving for fluid region cellZone_2
DILUPBiCG:  Solving for h, Initial residual = 9.552542e-08, Final residual = 9.552542e-08, No Iterations 0

LU Back substitute C matrix..
Min/max T:1738.045 1851.023

Solving for solid region cellZone_1
DICPCG:  Solving for h, Initial residual = 9.899032e-07, Final residual = 9.899032e-07, No Iterations 0
Min/max T:300 1789.063

Solving for solid region cellZone_3
DICPCG:  Solving for h, Initial residual = 9.094747e-07, Final residual = 9.094747e-07, No Iterations 0
Min/max T:1816.936 2000
ExecutionTime = 66.2 s  ClockTime = 78 s

Time = 1000


Solving for fluid region cellZone_2
DILUPBiCG:  Solving for h, Initial residual = 9.552542e-08, Final residual = 9.552542e-08, No Iterations 0
Min/max T:1738.045 1851.023

Solving for solid region cellZone_1
DICPCG:  Solving for h, Initial residual = 9.899032e-07, Final residual = 9.899032e-07, No Iterations 0
Min/max T:300 1789.063

Solving for solid region cellZone_3
DICPCG:  Solving for h, Initial residual = 9.094747e-07, Final residual = 9.094747e-07, No Iterations 0
Min/max T:1816.936 2000
ExecutionTime = 66.23 s  ClockTime = 78 s

Originally Posted by zfaraday

I hope that my words have come in handy for your purpose and may help you with your future simulations!

Thank you Alex. Your comments are quite valuable to me. Unfortunately there seems to be very little info on the forum about multi-region OpenFoam solvers.

I have to ask my question from the post #1 again. Can you (or anyone else) tell me why thermal conductivity (kappa) depends on density (rho) in the case of a fluid region? Shouldn’t the relation “Pr=mu*Cp/kappa” always hold?

//“constant/cellZone_2/thermophysicalProperties”
thermoType
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState rhoConst; //<perfectGas>;
    specie          specie;
    energy          sensibleEnthalpy;
}
pRef            100000;
mixture
{
    specie
    {
        nMoles          1;
        molWeight       28.9;
    }
    thermodynamics
    {
        Cp              1000;
        Hf              0;
    }
    transport
    {
        mu              1.8e-05;
        Pr              0.0018; // "Pr=mu*Cp/kappa"
    }
    equationOfState
    {
        rho            1e-02;
    }
}

When I change “rho” in the “thermophysicalProperties“ file the results (temperature distribution) change too. So I conclude that somehow “kappa” changes. But why? Let me duplicate a picture with temperature distribution along the sample line from my post #1. I gradually changed density in the central region (cellZone_2) starting from 1e-02 kg/m^3 to 1e+02 kg/m^3 and performed steady-state simulations. Everything else (properties, boundary conditions, solver parameters,…) was identical. Radiation was turned off.



It is easy to see that as density increases the temperature distribution in the central region gets more and more level, uniform as if thermal conductivity increased too. Obviously, there are 2 limit boundaries the plot line can stick to:
1) density is 0 (then we get the correct solution depicted by a dashed red line in the picture),
2) density is infinite (the solution is totally incorrect and corresponds to the case of infinite thermal conductivity).

It looks like we have something like this: “kappa = f *(mu*Cp/Pr)“, where f is a function of density. It goes to 1 when density goes to 0 and it goes to infinity when density goes to infinity. Can anybody confirm my assumption?

My a little bit updated case can be downloaded here: http://s000.tinyupload.com/?file_id=31692654334161942508

[zfaraday]

Hi Zeppo,

First of all, I apologize for my very late response, I've been busy lately. I will try to respond quickly to your questions...

Originally Posted by Zeppo

When I set "QrNbr none; Qr none;" on some boundaries it should mean that these patches don't participate in radiation energy exchange, right?

Well, it doesn't exactly mean that this boundary doesn't participate in the radiative exchange, it actually exchanges radiative energy, the fact is that a curious and totally unphysical calculation is done in the case you switch the corresponding field to "none". What occurs in this case is that radiative exchange at the surface is calculated, but this exchange does not have any effect on the temperature field, as if the surface reflectivity was 1, but being different from 1 at the same time. Imagine you were at the beach taking a sunbath, radiative exchange takes place in your skin, but simultaneously your body doesn't absorve this heat, so you don't experience any temperature increase. Something extremelly weird and senseless... Or at least that's how I see it...

Originally Posted by Zeppo

Plots indicate the opposite!



Kind of strange and suspicious, isn't it? Then how can I exclude some boundaries from RTE when I don't want them to take part in radiation exchange? Is it ever possible?

Regarding your plot, according to its legend, I assume that you turned off the effect of Qr at the boundary of the fluid region, right? But what about the boundaries of the solid regions? Did you also turned them off? I ask that because maybe you forgot about doing it and I don't know what effect can cause this fact, nor even if it is possible to do so...

I don't think this is so strange nor suspicious, radiation is taken into account in your calculations for the fluid region but something "weird" is happening at the boundaries when you set Qr/QrNbr to "none", that is to say, something "not very physical, but mathematically possible" occurs. Btw, the dotted blue line, corresponding to the proprietary software, represents the central region as a fluid or as a solid? And what about the segmented red line?

If you want some boundaries not to take part in the radiation exchange in the ViewFactors method you can exclude them in the ViewFactorsDict file. However, I never did it and I have no clue if it can lead to unphysical results... Maybe you could try it and find it out!

Originally Posted by Zeppo

You mean when I have "emissivityMode solidRadiation" on a boundary in my central fluid region then emissivity is obtained from the adjacent solid region? But I can't see where emissivity is specified in the solid region to be used as emissivity for the adjacent fluid region.

//"constant/cellZone_1/radiationProperties", "constant/cellZone_3/radiationProperties"
radiation       off;
radiationModel  opaqueSolid;
absorptionEmissionModel none;
constantAbsorptionEmissionCoeffs
{
    absorptivity    absorptivity [ 0 -1 0 0 0 0 0 ] 0.0;  //opaque
    emissivity      emissivity [ 0 -1 0 0 0 0 0 ] 0.0; 
    E               E [ 1 -1 -3 0 0 0 0 ] 0;
}
scatterModel    none;
sootModel none;

Can you see it now?

Naaaah... Just kidding! I know it is quite confusing, mainly because of the units, everyone knows that emissivity in a surface is a dimensionless factor. However, in a solid region here is where you can store the value of the emissivity. Another confusing point in this file is the definition of an opaque solid, there it says that as the solid is opaque its absorptivity has a value of 0!!! Someone was drunk when writing this file because what defines the opacity of a surface is its transmitance not its absorptivity! Anyway, I hope that someday someone will change the format file for solid regions so that people don't get confused!

Originally Posted by Zeppo

Is far as I remember I found this trick on the forum while searching for any information regarding chtMultiRegionSimpleFoam solver. It was maybe even somewhere in your threads.

Really?! Can you please refresh my mind and copy the links where you found it out!?

Originally Posted by Zeppo

I have to ask my question from the post #1 again. Can you (or anyone else) tell me why thermal conductivity (kappa) depends on density (rho) in the case of a fluid region? Shouldn’t the relation “Pr=mu*Cp/kappa” always hold?

Honestly, I have no clue about this issue, I agree with you that kappa sholudn't be related to density according to the theory I studied in the university, however, here it seems that something goes different... Perhaps it has something to do with the fact that you used frozenFlow option, it might be a bug with this option maybe... I saw, also, you are using RASModel in turbulenceProperties file, why don't you try laminar model? Just in case...

Let's see if someone else more skilled and clever than us can find the solution of this problem...

So far my little contribution for today. I hope it can help you a bit on your multiRegionRadiative adventure! And again, I'm sorry for my late response!

Best regards,

Alex

[Zeppo]

Originally Posted by zfaraday

Regarding your plot, according to its legend, I assume that you turned off the effect of Qr at the boundary of the fluid region, right? But what about the boundaries of the solid regions? Did you also turned them off? I ask that because maybe you forgot about doing it and I don't know what effect can cause this fact, nor even if it is possible to do so...

Radiation was deactivated in both solids.

//“constant/cellZone_1/radiationProperties”, “constant/cellZone_3/radiationProperties”
radiation       off;
radiationModel  opaqueSolid;

And radiation heat flux boundary conditions Qr in the fluid region was the following:

// "0/cellZone_2/Qr"
".*"
{
    type                      greyDiffusiveRadiationViewFactor;
    value                    uniform 0;
    emissivityMode  lookup;
    Qro                       uniform 0;
    emissivity             uniform 1;
}

So I guess (and hope) computation of radiation in the fluid region got completely independent on any radiation propertied specified in the solid regions.

Originally Posted by zfaraday

Btw, the dotted blue line, corresponding to the proprietary software, represents the central region as a fluid or as a solid? And what about the segmented red line?

In the proprietary software the central region was modeled as a solid region with constant density. The red line is for the case with all the regions specified as solids, with radiation being turned off (the case which wasn't a problem neither for OpenFOAM nor for the proprietary software).

Originally Posted by zfaraday

If you want some boundaries not to take part in the radiation exchange in the ViewFactors method you can exclude them in the ViewFactorsDict file.

I don't think so. Here is a snippet from my viewFactorsDict file:

// "constant/cellZone_2/viewFactorsDict"
".*_to_.*"
{
    nFacesInCoarsestLevel 0;
    featureAngle                 0;
}
maxDynListLength        100000000;

As far as I can see, nFacesInCoarsestLevel and featureAngle control how faces of a boundary patch agglomerate into coarse faces. With "nFacesInCoarsestLevel 0; featureAngle 0;" faceAgglomerate utility does not do any agglomeration at all, and one "regular" face corresponds to one coarse face (in other words, the number of faces of a patch is the same as the number of coarse faces of the patch). maxDynListLength determines how many (the upper limit) radiation rays is to shoot from a coarse face when viewFactorsGen utility computes view factors matrix. Log file generated by viewFactorsGen:

// "log.viewFactorsGen.cellZone_2"
Total number of coarse faces: 2760
View factor patches included in the calculation : 2(0 1)
Calculating view factors...
Writing view factor matrix...
F00: 2.042893e-08
F01: 1.00178
F10: 0.2369856
F11: 0.5562016

2760 is a total number of faces of 2 boundaries in the fluid region. Interestingly enough, the sum of F10 and F11 is 0.793 but it should make up 1 ideally (a conservation energy law). You may think that increasing maxDynListLength can increase accuracy? Not my case! Playing around with maxDynListLength didn't changed anything.
On the other hand the least number of coarse faces I can get is 4. So you can't exclude a patch from radiation exchange as you say. Or maybe I am going the wrong way and I can do so in any other way?

// "constant/cellZone_2/viewFactorsDict"
".*_to_.*"
{
    nFacesInCoarsestLevel 0;
    featureAngle                 1000000;
}

// "log.viewFactorsGen.cellZone_2"
Total number of coarse faces: 4
View factor patches included in the calculation : 2(0 1)
Calculating view factors...
Writing view factor matrix...
F00: 0
F01: 0.8841754
F10: 0
F11: 1.059796

The reason why OF's solution doesn't exactly match proprietary software's solution may lie in the very fact that viewFactorsGen doesn't produce a good enough radiation factor matrix. Agree?

Originally Posted by zfaraday

Really?! Can you please refresh my mind and copy the links where you found it out!?

Sorry, I can't remember any links!

Originally Posted by zfaraday

I saw, also, you are using RASModel in turbulenceProperties file, why don't you try laminar model? Just in case...

I tried and it was of no effect. Turbulence seems to have nothing to do with this "bug".

All in all I don't want to give up and will continue my "experiments" with the solver.

[zfaraday]

Hi Zeppo,

Again, I apologise for my late response!

Originally Posted by Zeppo

Radiation was deactivated in both solids.

//“constant/cellZone_1/radiationProperties”, “constant/cellZone_3/radiationProperties”
radiation       off;
radiationModel  opaqueSolid;

And radiation heat flux boundary conditions Qr in the fluid region was the following:

// "0/cellZone_2/Qr"
".*"
{
    type                      greyDiffusiveRadiationViewFactor;
    value                    uniform 0;
    emissivityMode  lookup;
    Qro                       uniform 0;
    emissivity             uniform 1;
}

So I guess (and hope) computation of radiation in the fluid region got completely independent on any radiation propertied specified in the solid regions.

Sorry, when I asked for the radiation to be deactivated in the solids I didn't mean in the radiationProperties file. I meant wether the boundary condition for T was taking into account the effect of Qr (QrNbr Qr) or not (QrNbr none). Maybe I express myself wrong, my fault.

Originally Posted by Zeppo

I don't think so. Here is a snippet from my viewFactorsDict file:

// "constant/cellZone_2/viewFactorsDict"
".*_to_.*"
{
    nFacesInCoarsestLevel 0;
    featureAngle                 0;
}
maxDynListLength        100000000;

You didn't understand what I was talking about... As you can see (".*_to_.*") you are taking into account all the interregion patches for the radiation exchange. If you want one patch no to be taken into account just delete it from the viewFactorsDict file! However, it wouldn't make any sense in your case, but you can do it!

Originally Posted by Zeppo

As far as I can see, nFacesInCoarsestLevel and featureAngle control how faces of a boundary patch agglomerate into coarse faces. With "nFacesInCoarsestLevel 0; featureAngle 0;" faceAgglomerate utility does not do any agglomeration at all, and one "regular" face corresponds to one coarse face (in other words, the number of faces of a patch is the same as the number of coarse faces of the patch). maxDynListLength determines how many (the upper limit) radiation rays is to shoot from a coarse face when viewFactorsGen utility computes view factors matrix. Log file generated by viewFactorsGen:

// "log.viewFactorsGen.cellZone_2"
Total number of coarse faces: 2760
View factor patches included in the calculation : 2(0 1)
Calculating view factors...
Writing view factor matrix...
F00: 2.042893e-08
F01: 1.00178
F10: 0.2369856
F11: 0.5562016

2760 is a total number of faces of 2 boundaries in the fluid region. Interestingly enough, the sum of F10 and F11 is 0.793 but it should make up 1 ideally (a conservation energy law). You may think that increasing maxDynListLength can increase accuracy? Not my case! Playing around with maxDynListLength didn't changed anything.

You are right, MaxDynListLenght doesn't play any role when it comes to improve the view factors accuracy. However, accuracy of the matrix can be imporved by playing with the nFacesInCoarsestLevel and featureAngle paramaters. If you want to take a further look into the matrix accuracy you can set the parameter writePatchViewFactors in the viewFactorsDict file to true. This will create a new scalar field named viewFactorField for every coarse face with the value of the view factors sum in itself (ideally should be 1 for each face).

writeViewFactorMatrix     true;
// Write agglomeration as a volScalarField with calculated boundary values
writeFacesAgglomeration   true;
writePatchViewFactors     false;

By doing so you will be able to check in paraFoam which patch is causing trouble and you wil be able to readjust the parameters in viewFactorsDict accordingly.

Originally Posted by Zeppo

On the other hand the least number of coarse faces I can get is 4. So you can't exclude a patch from radiation exchange as you say. Or maybe I am going the wrong way and I can do so in any other way?

// "constant/cellZone_2/viewFactorsDict"
".*_to_.*"
{
    nFacesInCoarsestLevel 0;
    featureAngle                 1000000;
}

// "log.viewFactorsGen.cellZone_2"
Total number of coarse faces: 
View factor patches included in the calculation : 2(0 1)
Calculating view factors...
Writing view factor matrix...
F00: 0
F01: 0.8841754
F10: 0
F11: 1.059796

Read again what I wrote above to understand how can you exclude a pach from being computed in the view factors matrix! I must tell you that I never did it so I have no idea what can happen...

Originally Posted by Zeppo

The reason why OF's solution doesn't exactly match proprietary software's solution may lie in the very fact that viewFactorsGen doesn't produce a good enough radiation factor matrix. Agree?

Totally agree with you! You must play with the parameters in the viewFactorsDict file in order to find the most accurate solution. I hope you can find it and that the solution will be close to the one obtained with the proprietary software!

Originally Posted by Zeppo

Sorry, I can't remember any links!

I tried and it was of no effect. Turbulence seems to have nothing to do with this "bug".

All in all I don't want to give up and will continue my "experiments" with the solver.

Keep the experiments up! And regarding the problemof the dependency of kappa with rho, have you found anything else? I strongy recomend you to report this behaviour to the bug tracker and share the answer here in your thread!

Best regards,

Alex

[olivierG]

Hello, Zeppo,

I would just correct you about kappa and rho effect. Your solutions are NOT converged at all.
In thermal stationary simulation, convergence check should be done with some probes, not with residual at 1e-6.
In your convergence plot, you see a flat line at 1e-7 after 700 iter, and if you look at the log, you have "No Iteration 0". This mean you don NOT calculate T Field anymore ...

What you should do is: set Tolerance to a far lower value 1e-12,, or add "minIter 1;" in you FvSolution File, for the h solver. Thermal simulation have usually a convergence at very low residual value.

regards,
olivier

[coccone]

Originally Posted by Zeppo

Problem Formulation
Thermophysical properties for my fluid region now look like this

// “constant/cellZone_2/thermophysicalProperties”
thermoType
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState rhoConst;
    specie          specie;
    energy          sensibleEnthalpy;
}
pRef            100000;
mixture
{
    specie
    {
        nMoles          1;
        molWeight       28.9;
    }
    thermodynamics
    {
        Cp              1000;
        Hf              0;
    }
    transport
    {
        mu              1.8e-05;
        Pr              0.0018; //Pr=mu*Cp/kappa
    }
    equationOfState
    {
        rho        1e-2;
    }
}

The key point here is that we cannot define thermal conductivity coefficient “kappa” explicitly in the transport dictionary the way we do for solid regions. That means the solver derive it implicitly. The question is how? I thought it was “Pr=mu*Cp/kappa” -> “kappa=mu*Cp/Pr” = 1.8e-05*1000/0.0018=10. It turned out that I was wrong, somehow “kappa” depends on density “rho”. A set of simulations were carried out with different values for “rho”, other thermophysical properties being identical throughout the simulations. Thermal radiation was deactivated. Here are my results for “rho” = 1e-02, 1e-01, 1e-00, 1e+02 kg/m^3. The reference dashed line is for the case where all the regions are solid.



Can anyone comment on this? What is the relation between “kappa” and “rho”?

Silly answer out of the blue, I'll let you consider whether it is a smart or idiot answer...

Since it is an incompressible solver all the equations are divided by rho, even the viscosity value to be used should be cinematic rather than dynamic. I don't recall the energy equation in this solver right now, it could be written in terms of kappa or making Pr appear or whatever... anyway if Pr is divided by rho in the equation, the actual kappa would be obtained from cinematic viscosity rather than dynamic.

This leads me to the point: when you tried simulating with different rho values did you vary viscosity accordingly? Does this make any sense or sounds just like BS?

ps: in my property file I don't even have the equationOfState-rho part, i just change viscosity values for different densities

[visheshkapoor06]

Hello All,

I am trying to run a case of chtMultiRegionSimpleFoam based on the multiRegionHeaterRadiation example. My case has 8 solid blocks inside air. The air and blocks are inside a metal cabinet, and also touch the cabinet. The cabinet is in the atmosphere.
When i run the case, the temperature diverges and an error comes up. I am not able to diagnose the error. Please help!

Time = 1


Solving for fluid region domain0
DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 0.0156926, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 1, Final residual = 0.0130481, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 1, Final residual = 0.0180424, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 1, Final residual = 0.0671467, No Iterations 1
Min/max T:300 7709.26
GAMG: Solving for p_rgh, Initial residual = 0.88219, Final residual = 0.00738372, No Iterations 6
time step continuity errors : sum local = 21.78, global = -18.8129, cumulative = -18.8129
Min/max rho:0.2 1.15862

Solving for fluid region domain2
DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 0.0184007, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 1, Final residual = 0.0246227, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 1, Final residual = 0.0227786, No Iterations 1
[3]
[3]
[3] --> FOAM FATAL ERROR:
[3] Attempt to cast type compressible::turbulentTemperatureCoupledBaffleMix ed to type compressible::turbulentTemperatureRadCoupledMixed[0]
[3]
[3] From function refCast<To>(From&)
[3] in file /home/kav9kor/OpenFOAM/OpenFOAM-3.0.1/src/OpenFOAM/lnInclude/typeInfo.H at line 114.
[3]

[coccone]

Originally Posted by visheshkapoor06

Solving for fluid region domain2
...
[3] --> FOAM FATAL ERROR:
[3] Attempt to cast type compressible::turbulentTemperatureCoupledBaffleMix ed to type compressible::turbulentTemperatureRadCoupledMixed[0]

I just recall by heart: this basically means that you are trying to use a CoupledBaffle bc with some boundary which was already assigned a RadCoupled one so it just stops running for incongruence...

So, since you're trying to run a case of chtMultiRegionSimpleFoam based on the multiRegionHeaterRadiation example you probably forgot to adapt some part of one case to the other. Check the bc type in T field of /0/domain2 and /system/domain2/changeDictionaryDict (especially after running changeDictionary).
Something else you could do is to see if you have the same issues with similar regions, like domains that have more or less the same bc types. Modify constant/regionProperties and put the similar region before your domain2, eg: solids(domain0 domain1 domain3 domain2) assuming 3 is similar to 2. Now the order of solving has been changed: if it runs until domain2 then domain 3 should be correctly set up. So copy and paste files from domain 3 folder to 2 and adapt it back with the correct values for domain 2.

It's actually easier to do than to explain ... Hope it helps,
Have fun!

[MBttR]

Hi,

I'm trying to do something based on chtMultiRegionSimpleFoam/planeWall2D. I want to make a solid cylinder suspended in a body of air. To prevent errors I kept as many names as possible, deleting the bottomAir variable from the picture, using topAir as my air volume and wall as my cylinder.

splitMeshRegions works okay and split my mesh correctly, but when running chtMultiRegionSimpleFoam I get the following error:

Create time

Create fluid mesh for region topAir for time = 0

Create solid mesh for region wall for time = 0

*** Reading fluid mesh thermophysical properties for region topAir

    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)

I think this has got to do something with the boundary conditions but I have no clue where to start looking. They're the same as in the tutorial case so I don't know why they would fail now. Anyone? Cheers!

[visheshkapoor06]

Thank you coccone, I checked my boundary conditions and i found the problem. he issue has been resolved.

Hi Bruno,

I had the exact same problem and the issue is in boundary conditions only. I believe you are using changeDictionary to write your BC files. In my case, i found that after running changeDict, all the boundaries were not coming in the boundary conditions file due to some error from my side. I would recommend you to compare your changeDict to the boundary conditions files in 0/topAir and other folders and check if any boundaries are not getting BC's.

[visheshkapoor06]

Hi,

I am trying to run a case of chtMultiRegionSimpleFoam based on the multiRegionHeaterRadiation example. My case has 8 solid blocks inside air. The air and blocks are inside a metal cabinet, and also touch the cabinet. The cabinet is in the atmosphere.
When i run the case, the temperature diverges and an error "Maximum number of iterations exceeded". Looking at the geometry, the spot where the temperature is diverging lies on the cell where 3 Boundary conditions intersect. I am not able to diagnose the error. Please help!


Time = 4

Solving for fluid region domain0
DILUPBiCG: Solving for Ux, Initial residual = 0.494337, Final residual = 0.0365276, No Iterations 2
DILUPBiCG: Solving for Uy, Initial residual = 0.410604, Final residual = 0.00511476, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 0.533649, Final residual = 0.00156498, No Iterations 2
DILUPBiCG: Solving for h, Initial residual = 1, Final residual = 4.10453e-05, No Iterations 1
Min/max T:-6.25267e+07 1.94969e+11
GAMG: Solving for p_rgh, Initial residual = 0.677243, Final residual = 0.00620046, No Iterations 556
time step continuity errors : sum local = 8649.74, global = -8438.73, cumulative = -8436.92
Min/max rho:0.663714 0.717282

Solving for fluid region domain2
DILUPBiCG: Solving for Ux, Initial residual = 0.363923, Final residual = 0.0297, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.300749, Final residual = 0.0230535, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.440358, Final residual = 0.0310553, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 0.0544437, Final residual = 0.00419095, No Iterations 1
Min/max T:294.252 349.985
GAMG: Solving for p_rgh, Initial residual = 0.796012, Final residual = 0.00544866, No Iterations 6
time step continuity errors : sum local = 2.17657, global = 8.83195e-16, cumulative = -8436.92
Min/max rho:0.470228 1.34124

Time = 5


Solving for fluid region domain0
DILUPBiCG: Solving for Ux, Initial residual = 0.563651, Final residual = 0.00134662, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.554814, Final residual = 0.00039006, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.555083, Final residual = 0.000398982, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 0.405382, Final residual = 0.00225312, No Iterations 1


--> FOAM FATAL ERROR:
Maximum number of iterations exceeded

From function Foam::scalar Foam::species::thermo<Thermo, Type>::T(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar)const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar)const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar)const) const [with Thermo = Foam::hConstThermo<Foam:erfectGas<Foam::specie> >; Type = Foam::sensibleEnthalpy; Foam::scalar = double; Foam::species::thermo<Thermo, Type> = Foam::species::thermo<Foam::hConstThermo<Foam:er fectGas<Foam::specie> >, Foam::sensibleEnthalpy>]
in file /home/kav9kor/OpenFOAM/OpenFOAM-3.0.1/src/thermophysicalModels/specie/lnInclude/thermoI.H at line 66.

[MBttR]

Thanks Vishesh, it indeed had to do with a missing entry for one of my BCs in the ChangeDict. I hit the next problem though (regarding temperatures reaching negative values and then the simulation crashing) but I feel that's more relevant in another topic so I'll post it there.

[visheshkapoor06]

Hi Bruno,

you are welcome.
I am also facing the negative temperature problem. I have figured that it is because velocity is diverging. You ll notice that velocity diverges in the 1st iteration and then temperature diverges. But i havent figured out the solution yet. Please send me the link of the thread where you will post your problem.

[ignacio.12]

Hello, I want to simulate a similar case to this one. It is a solid box with a hole in the center containing air. Two faces have fixed temperature wall and others are adiabatics. I tried to download the case of this post but I couldn't. It will help me with my case, I am new with OF and I am a little lost. Thanks a lot!!

[dewey]

Hi i want to simulate flow through one pipe, with two obstacles, this obstacles are inmersed like in the figure.

1.- I export with .msh

2.- splitMeshRegions -cellZones -overwrite (fluid, porosity, solid)

This separate my three domains, but the interior faces of my porosity became into wall. I want the fluid flow through the porous media. how can i fix this?