[maddalena]

Hello,
these are my first steps inside cht, thus please be patient...

I would like to simulate the convective heat transfer on a slice (cutted from an axialsymmetric model) made of different materials. I have two interfaces between solid and air, plus some interfaces between solid and solid.

For the fluid solid interface, I am going to use a solidWallMixedTemperatureCoupled, as usual.
But for the solid-solid interface I have some doubts since, among the other, I have two elements both of them producing heat. In this case, I would say that need a solidWallHeatFluxTemperature on both the boundaries: one with the heat flux of the first element and one with the heat flux of the second element. Is it possible to use it in this way? I read somewhere that, if imposing a solidWallHeatFluxTemperature in one element of the coupling, I must apply a solidWallMixedTemperatureCoupled on the other. Thus, it seems like I cannot model the interface between the two...

What you suggest? Anybody with some experience on the subject?
Thanks for any kind of advice!
Cheers,

mad

[psosnows]

Hello Maddalena,

first, forget about the solidWallHeatFluxTemperatureCoupled, and solidWallTemperatureCoupled. They were used in OF-1.5.

Now in OF-1.6, there is just one type: solidWallMixedTemepratureCoupled.
This condition works as both old ones together. The user does not have to worry about which direction the heat is flux going- the coupling condition figures it by itself. It automatically sets to be fixedValue or fixedGradient depending on the direction of the hf. Even better, it does it face-by-face, so if you have different sign of heat flux along the patch, it will become "half- fixedGrad, half-fixedValue".

I am not discussing here, if this approach is correct, since I could not find reference to theory.

In the end, I know (since I tested it), that this connection method gives reasonable and accurate results. At least for the test cases that I considered.

Last thing- you can use it to couple solid-fluid interfaces as well as solid-solid ones (take a look in the tutorial case ).

Hope it helps you a bit.

Best,
Pawel

[maddalena]

Hi Pawel, and thanks for your answer.

Originally Posted by psosnows

Now in OF-1.6, there is just one type: solidWallMixedTemepratureCoupled.
This condition works as both old ones together. The user does not have to worry about which direction the heat is flux going- the coupling condition figures it by itself. It automatically sets to be fixedValue or fixedGradient depending on the direction of the hf. Even better, it does it face-by-face, so if you have different sign of heat flux along the patch, it will become "half- fixedGrad, half-fixedValue".

That sounds good, although I cannot understand why solidWallHeatFluxTemperature is still on OF derived BC type...
In any case... how can I set the heat flux then? I do not want to set the solid regions temperature, since they should be calculated by the solver.
Thanks for any suggestion,
mas

[maddalena]

Ok Pawel, have not seen your answer:

Originally Posted by psosnows

Hi,

I just ment using solidWallHeatFluxTemperature of course you should be able to get similar results, if you impose fixedGratient such that:
FG = Qtot / Area
where FG is the FixedGradient value, Qtot is the constant total Heat flux, and Area is the area of the patch that we apply the HF to.
It all goes to using Neumann boundary condition types (fixed gradients).

And once again I state- the coupling patches do not have anything to do with other boundaries.

It also does not matter if you have solid-solid or solid-fluid connection.

In fact, I would not even use the term "boundary condition" but "coupling condition", since they are inside the whole system.

Maybe I am talking the thing a bit over, but consider an example: two connected square solid boxes. We create a system by coupling the connection face for each of the boxes (by using "special BC" called solidWallMixedTemperatureCoupled). From that moment, this connection becomes part of the "temperature interior" of the system. All the other patches that are pointing "outside" of the system should be considered as "boundary patches". We can apply any possible and allowed boundary condition types to them. So fixedGradient, fixedValue, solidWallHeatFlux, zeroGradient, bulkBody, you name it (I am not sure about "calculated" type).

Hope I did not shade the general idea too much and that this helps you a bit

Best,
Pawel

that you posted on http://www.cfd-online.com/Forums/ope...al-15-a-5.html

Your explanation is perfectly clear to me. So I can use the solidWallMixedTemperature in any case, and if I wanted to insert a heat flux, I can either add a fixedGradient for temperature, or to use solidWallHeatFluxTemperature. Right?
But what if I have two physically connected solid regions that both have a heat flux? What about their "inner" BC, or they coupling interface? In that case, the solidWallMixedTemperature will select which heatFlux (assigned as gradient) is higher, and it will use that one, is it right?
And, will it account for adding heatFlux? Let us say that we have three region of equal thickness: A, B and C. A has a 100W/m^2 heat flux, B has a 5 W/m^2 heat flux. Will C be influenced by the heat flux of both or, since I fix the heat Flux (gradient) to 5W/m^2 at the B-C interface, than C will be affected only by B?

Thanks for your help.
Cheers,

mad

[psosnows]

Hello,

Originally Posted by maddalena

I cannot understand why solidWallHeatFluxTemperature is still on OF derived BC type...

It is just my guess, but I think it is in "derivedFvPatchFields" just because nobody moved it to general BC folder. And in addition, consider that solidWallHeatFluxTemperature is derived from fixedValueFvPatchScalarField (line 60-62 in .H file). So in facet it is a fixedValue BC. It uses the following formula:
Tw = Tint + q / ( L * K )
where Tw is the fixed temperature at the wall,
Tint is the temp. of the cell next to the boundary,
q is the provided heat flux,
L is the distance between wall and the nearest cell center,
K is the thermal conductivity.

Originally Posted by maddalena

how can I set the heat flux then? I do not want to set the solid regions temperature, since they should be calculated by the solver.

Lets just clear things out. I imagine your geometry like on the picture I attached.
c- are the couplings, done on both sides by solidWallMiexedTemperatureCoupled,
1,2,3,4 are some zeroGradient boundaries,
5 is fixedTemperature,
and on 6 and 7 you want to impose constant heat flux.
If this is the case, just set 6 and 7 as solidWallHeatFluxTemperature or by fixedGratient (withgrad valueproperly chosen).

I think I might misunderstood your problem (especially the geometry). A similar picture would be of great help

Best,
Pawel

[psosnows]

heh, talking about timing

Originally Posted by maddalena

So I can use the solidWallMixedTemperature in any case, and if I wanted to insert a heat flux, I can either add a fixedGradient for temperature, or to use solidWallHeatFluxTemperature. Right?

Exactly!

Originally Posted by maddalena

But what if I have two physically connected solid regions that both have a heat flux? What about their "inner" BC, or they coupling interface? In that case, the solidWallMixedTemperature will select which heatFlux (assigned as gradient) is higher, and it will use that one, is it right?
And, will it account for adding heatFlux? Let us say that we have three region of equal thickness: A, B and C. A has a 100W/m^2 heat flux, B has a 5 W/m^2 heat flux. Will C be influenced by the heat flux of both or, since I fix the heat Flux (gradient) to 5W/m^2 at the B-C interface, than C will be affected only by B?

Once again lets refer to a new picture (I really like those ).
If I correctly understood the geometry, the arrows should show the way energy will be transfered in this system. In the end, right solid will "borrow" some energy from the left one, and heat flux between the solids and the fluid near the 3-region connection will be non-uniform (some two-connected-gradients-like I guess).

I hope this thing becomes clearer

Best,
Pawel

[maddalena]

Ok, let us go with pictures!
Here is an example of the case I would like to study. I know the volume heat generation of the solids A and B, but since I cannot impose the volume generation, I will use the heat flux between their surfaces. C does not have any heat flux and its temperature depends from A, B and fluids. What I want to know is the heat flux to C and the temperature of the whole system...
If I understood right, OF will manage the A-B coupling, if I impose a solidWallHeatFluxTemperature with a properly chosen q (gradient 0 as suggested in another post). But what about the B-C interface?
Cheers,

mad

[psosnows]

First of all, putting "gradient 0;" into boundary in the temperature file will give no effect. Your boundary can look like:

    heater_to_rightSolid
    {
        type            solidWallMixedTemperatureCoupled;
        neighbourFieldName T;
        K               K;
        value           uniform 0;

        colorOfTheSky blue;
        numberOfStairSteps uniform 33;
        gradient uniform 0;
    }

only the first 4 entries are considered by the BC. This you can find by studying the code, or looking at the proposed way of usage at the beginning of .H file.

In your case I would drop the idea of imposing fixedGradients. I would make a backup of the solver and add heat generation rate to it.

Pawel

[maddalena]

I see...
thus the only choice I have is to use the solidWallHeatFluxTemperatureCoupled BC, which should work as solidWallMixedTemperatureCoupled+fixedGradient. But in this case we are not sure if the solver take into account the different direction of the flow.
I am going to run a simulation with the test case proposed above... Let's see what the results will be.
Cheers.

mad

[marval]

Hello Pawel and Maddalena,

The attached picture shows (hopefully ) what I'm trying to simulate. It's a cross-section of a channel flow with added heat transfer. I know the heat fluxes but not the temperatures and it's the temperature I'd like to calculate.

To start of I'm having problems with splitting the geometry.
As I understand, you define the entire boundary first in blockMeshDict, then run blockMesh.
After that, you have to run the setSet command, but I'm not sure how to edit the makeCellSets.setSet-flie. As seen in the figure I would only like to define a U-turn for a water flow.

Since I'm modifying the tutorial case, do I need to delete some previous things (leftSolid, bottomAir etc.) to make a geometry or do I approach the problem in a different way?

I hope it wasn't too confusing.

Regards
Marco

[maddalena]

Hi Marco!

Originally Posted by marval

do I need to delete some previous things (leftSolid, bottomAir etc.) to make a geometry or do I approach the problem in a different way?

yes, you should delete all the previous regions, since the setSet is used to define the new and different region of your geometry.
However, I cannot help you more than this on setSet, since I am used to create my geometry on specific software and than import it in openfoam, that will arrange sets automatically.
Regards,

mad

[psosnows]

Hello Marco,

I never got deep into those mesh manipulations presented in the tutorial, but repeating after rob3rt: http://www.cfd-online.com/Forums/ope...tml#post262547
try to look into:
/OF(...)/applications/utilities/mesh/manipulations/(...)
in each of the tools' dirs, there is a Dict file, which hopefully will make things a bit clearer.

Best,
Pawel

[marval]

Hi and thanks guys for the quick reply!

It sure helped, I think I got the basics now with setSet. The dict file was quite good and gave alot of understanding.

Now to some more specific questions about changeDictionary (I hope I'm not in the wrong thread for this).

- What does "compressible::turbulentTemperatureCoupledBaff le;" mean?
Guessing it's some kind of coupling between regions and it says compressible since it's air.
- Can "compressible" just be changed to "incompressible" for e.g. water?
- What are these good for: ".*" and "topAir_to_.*"?

dictionaryReplacement
{
U
{
internalField uniform (0.01 0 0);

boundaryField
{
".*"
{
type fixedValue;
value uniform (0 0 0);
}
minX
{
type fixedValue;
value uniform ( 0.01 0 0 );
}
maxX
{
type inletOutlet;
inletValue uniform ( 0 0 0 );
value uniform ( 0 0 0 );
}
}
}

T
{
internalField uniform 300;

boundaryField
{
".*"
{
type zeroGradient;
}

minX
{
type fixedValue;
value uniform 300;
}
maxX
{
type inletOutlet;
inletValue uniform 300;
value uniform 300;
}

"topAir_to_.*"
{
type compressible::turbulentTemperatureCoupledBaffle;
neighbourFieldName T;
K K;
value uniform 300;
}
}
}

epsilon
{
internalField uniform 0.01;

boundaryField
{
".*"
{
type compressible::epsilonWallFunction;
value uniform 0.01;
}

minX
{
type fixedValue;
value uniform 0.01;
}
maxX
{
type inletOutlet;
inletValue uniform 0.01;
value uniform 0.01;
}
}
}

k
{
internalField uniform 0.1;

boundaryField
{
".*"
{
type compressible::kqRWallFunction;
value uniform 0.1;
}

minX
{
type fixedValue;
value uniform 0.1;
}
maxX
{
type inletOutlet;
inletValue uniform 0.1;
value uniform 0.1;
}
}
}

p
{
internalField uniform 100000;

boundaryField
{
".*"
{
type buoyantPressure;
value 1e5;
}

maxX
{
type fixedValue;
value uniform 100000;
}
}
}
}

Regards
Marco

[maddalena]

Hello Marco,

Originally Posted by marval

- What does "compressible::turbulentTemperatureCoupledBaff le;" mean?
Guessing it's some kind of coupling between regions and it says compressible since it's air.
- Can "compressible" just be changed to "incompressible" for e.g. water?

That is a specific boundary condition used for compressible case. If you want to use the incompressible try solidWallMixedTemperatureGradient. To say the truth, I never used compressible::turbulentTemperatureCoupledBaffle and only considered incompressible with air cases, where I applied solidWallMixedTemperatureGradient

Originally Posted by marval

- What are these good for: ".*" and "topAir_to_.*"?

The ".*" is a flag. If you say topAir_to_.* it means that changeDict will change any existing entry that starts with topAir_to_ and has any kind of suffix. i.e. it will change both topAir_to_blabla and topAir_to_albalb, but not bla_topAir_to_bla. As a consequence, the ".*" will change any entry you have in your file.
Hope this is clear.
cheers

mad

[marval]

Originally Posted by maddalena

The ".*" is a flag. If you say topAir_to_.* it means that changeDict will change any existing entry that starts with topAir_to_ and has any kind of suffix. i.e. it will change both topAir_to_blabla and topAir_to_albalb, but not bla_topAir_to_bla. As a consequence, the ".*" will change any entry you have in your file.
Hope this is clear.

Not really clear, can you apply it to my case (from the previos post) in any way?

[maddalena]

Ok... look at this:

Originally Posted by marval

T
{
internalField uniform 300;

boundaryField
{
".*"
{
type zeroGradient;
}

minX
{
type fixedValue;
value uniform 300;
}
maxX
{
type inletOutlet;
inletValue uniform 300;
value uniform 300;
}

"topAir_to_.*"
{
type compressible::turbulentTemperatureCoupledBaffle;
neighbourFieldName T;
K K;
value uniform 300;
}
}
}

It says that it will apply a fixedValue 300 K for the internal field + zeroGradient condition in every boundary except:

1. boundary named minX: if it exist, it will be updated as fixedValue, if not existing it will be added;
2. boundary named maxX: if it exist, it will be updated as inletOutlet, if not existing it will be added;
3. any boundary whose name start with topAir_to_: the exisitng boundaries will be updated as compressible::turbulentTemperatureCoupledBaffle.

better?
cheers

mad

[marval]

Thanks Maddalena !

I think I got it now, you've helped me alot.
Thanks again.

Regards
Marco

[miael]

Hallo everybody,

I´ve another problem with the cht-BC solidWallHeatFluxTemperature. I want to simulate a channel, therefore I have 3 regions: the upper solid, the fluid and the bottom solid. in order to couple the temperaturefield I use solidWallMixedTemperatureCoupled for the interface between the upper solid and the fluid and for the interface between bottom solid and fluid I want to use solidWallHeatFluxTemperatue, because I´ve a fixed heaflux. The definition of the interfaces seems to be right, because the calculation starts up, but then I get my problem. The temperature rises up to infinity and I don´t know why. At the following I post my BC:
for FLuid 0/fluid/T

fluid_to_solid1
{
type solidWallMixedTemperatureCoupled;
value uniform 300;
neighbourFieldName T;
K K;
}
fluid_to_solid2
{
type solidWallHeatFluxTemperature;
value uniform 300;
gradient uniform 0;
K K;
q uniform 1000;
}
and for Solid2 (o/Solid2/T)

solid2_to_fluid
{
type solidWallHeatFluxTemperature;
value uniform 300;
gradient uniform 0;
K K;
q uniform -1000;
}

So my question is: Is it possible to define a constant heatFlux and how to do this??I hope anybody can help me!

Thanks a lot

Michael

[psosnows]

Hello Michael,

from what I understood, your geometry is:

---------
solid1
---------
fluid
---------
solid2
----------

in this setup, the boundaries should be:

* solid1:
*** solid1_to_outWorld -> fixedValue / fixedGradient / solidWallHeatFlux
*** solid1_to_fluid -> solidWallMixedTemperatureCoupled (pointing to fluid)

*fluid:
*** fluid_to_solid1 -> solidWallMixedTemperatureCoupled (pointing to solid1)
*** fluid_to_solid2 -> solidWallMixedTemperatureCoupled (pointing to solid2)

*solid2:
*** solid2_to_outWorld -> fixedValue / fixedGradient / solidWallHeatFlux
*** solid2_to_fluid -> solidWallMixedTemperatureCoupled (pointing to fluid)

The boundaries on the left and right in both solids should be "zeroGradient"
Boundaries of the fluid- as you wish.

With this setup, the simulation should work.

Best,
Pawel

[miael]

Hello Pawel,

thank you for your quick reply. I think for these simple qeometry your setup works. But at the next step I want to simulate a channel with a dimple in it, it looks like these:
___________
solid1
___________
fluid

'''''''''''\__/'''''''''
solid2
___________
<heatflux>

Now I want to heat up the fluid with a constant heat flux. But when I take your setup, there is a constant heatflux on the lower wall of solid2 (see picture) and because of the geometry I don´t get my needed constant heatflux on the interface. Am I right? Is there any other opportunity to run these case with a defined heatflux on the interface??

Thank you

Michael