solidWallHeatFluxTemperature at the solid solid interface in chtMultiRegionSimpleFoam
 

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

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

Hi Pawel, and thanks for your answer.
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

Ok Pawel, have not seen your answer:
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

Hello,
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.

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

heh, talking about timing :)
Exactly!

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

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

First of all, putting "gradient 0;" into boundary in the temperature file will give no effect. Your boundary can look like:
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

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

chtMultiRegionSimpleFoam
 

Hello Pawel and Maddalena,

The attached picture shows (hopefully :p) 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

Hi Marco!
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

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

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

Hello Marco,
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
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

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

Ok... look at this:
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

Thanks Maddalena :)!

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

Regards
Marco

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

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

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

Hello Michael,

as you pointed out, with the geometry that you have shown, it will be veeery hard (or even impossible) to acquire constant heat flux on the solidBottom-fluid interface. Its just the matter of geometry and heat transfer properties. The "hole" is closer to the heating surface, so it will faster start giving heat to the fluid, ergo it will have different heat flux from the rest of the interface. And it will change further in time... With your proposed setup it is unavoidable.

In my opinion what you should do is simply... drop the bottomSolid :)
Then at the fluidBottom-patch you just impose solidWallHeatFlux and voilà.

Best,
Pawel

ps
In the 4th post in this thread Maddalena cited my talk regarding general idea of temperature coupled systems. I am sure you already read it, but just want to point it out once again ;)

Heat flux
 

Hi everyone!

It turns out that I didn't fully understand the changeDictionaryDict files since I get the following:

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

As I undestand it, the problem lies in the coupling between fluid and solid for the temperature. I post my two changeDictionaryDict-files and a picture of the geometry.

This is for the fluid:
************************************************** ************
dictionaryReplacement
{
U
{
internalField uniform (0.001 0 0);

boundaryField
{
".*"
{
type fixedValue;
value uniform (0 0 0);
}
inlet
{
type fixedValue;
value uniform ( 0.145 0 0 );
}
outlet
{
type zeroGradient;
}

}
}

T
{
internalField uniform 293;

boundaryField
{
".*"
{
type zeroGradient;
}

inlet
{
type fixedValue;
value uniform 293;
}
outlet
{
type zeroGradient;
}

"fluid_to_.*"
{
type solidWallMixedTemperatureCoupled;
neighbourFieldName T;
K K;
value uniform 293;
}
}
}

epsilon
{
internalField uniform 1.33e-7;

boundaryField
{
".*"
{
type epsilonWallFunction;
value uniform 1.33e-7;
}

inlet
{
type fixedValue;
value uniform 1.33e-7;
}
outlet
{
type zeroGradient;
}
}
}

k
{
internalField uniform 1.08e-4;

boundaryField
{
".*"
{
type kqRWallFunction;
value uniform 1.08e-4;
}

inlet
{
type fixedValue;
value uniform 1.08e-4;
}
maxX
{
type zeroGradient;
}
}
}

p
{
internalField uniform 1e-9;

boundaryField
{
".*"
{
type zeroGradient;
}

outlet
{
type fixedValue;
value uniform 0;
}
}
}
}
************************************************** ************

And this is for the solid, I do not really understand how it works at the beginning under "boundary". I think there might be errors there as well:
************************************************** ************
dictionaryReplacement
{
boundary
{
minX
{
type patch;
}
maxX
{
type patch;
}
minY
{
type patch;
}
minZ
{
type patch;
}
maxZ
{
type patch;
}
}

T
{
internalField uniform 293;

boundaryField
{
".*"
{
type zeroGradient;
value uniform 293;
}
"heater_to_.*"
{
type solidWallHeatFluxTemperatureCoupled;
neighbourFieldName T;
K K;
value uniform 293;
}
cellWall
{
type fixedGradient;
value uniform 4860;
}
}
}

rho
{
internalField uniform 8000;

boundaryField
{
".*"
{
type calculated;
value uniform 8000;
}
}
}

K
{
internalField uniform 16;

boundaryField
{
".*"
{
type zeroGradient;
value uniform 16;
}
}
}

cp
{
internalField uniform 450;

boundaryField
{
".*"
{
type zeroGradient;
value uniform 450;
}
}
}
}
************************************************** ************

Since the heater splits the fluid, do I have a similar scenario as Michael with the dimple?
Should I maybe do a separate region that splits the fluid in the middle?

Regards
Marco

Hi Marco,

regarding splitting solid region into "heater part" and "fluid wall" part. This is only a good idea if you want to drop the bottom heater part, leaving only the fluid and the wall, and imposing constant heat flux from the bottom.
If you want on the other hand to have the temperature distribution also in the bottom solid part, I would strongly recommend to leave the solid as one, single region (of course if the solid has constant heat transport properties).

I do not know whether you read some of my earlier post, but I have some doubts regarding the coupling condition- that is why I think the less solidWallMixedtemperautreCoupled conditions in the simulation- the better.

And also, I do not want to discourage you, for sure learning how changeDictionaryDict works is a nice thing, but... don't you think it would be much easier and faster to write your boundaries manually? And then, when your simulation is running, you can try to dig through changeDictionaryDict on a dummy case.

Best,
Pawel

Hi Pawel and thank you for the quick reply!

Yes, I want to have the distribution in the bottom part of the "heater"(it's just a solid part and I didn't mind changing the names of the tutorial case :)). Fortunately, I created the solid region as one to start with so there is no problem.

I read through them, I just think that I confused them (similar names). I still get the same error when I change to solidWallMixedtemperautreCoupled though. Maybe related to the following:

Hehe, it's ok. :) But I don't really understand what you mean by writing my own boundaries, didn't I do it in a way by (trying to) modify the tutorial case?

Regards
Marco

Hi,
as Pawel told you, you can leave changeDictionary out... In any case, I noticed the following:
This has absolutely no meaning! There are two BC: solidWallMixedTemperatureCoupled and solidWallHeatFluxTemperature. I think you are going to use the latter, so the right syntax is, for example:
At the beginning it works on constant/polyMesh/boundary file, applying a "patch" type boundary on all the minX, maxX, minY, minZ and maxZ boundaries.
This may be not the solution to your problem, but hope it helps.
I agree with Pawel about the solidWallMixedTemperatureCoupled precision. I experienced some difficulties on making chtMultiRegionFoam works if applying a volume heat source, and I doubt of its precision on other kind of applications. And Pawel for sure has more experience on that than me... ;)
Regards,

mad

Hi Marco,

by writing BC by yourself, I mean setting up the case from scratch, without using changeDictionary utility.

Lets look at it from the top-
what does chengeDict do? It is an utility which allows to prepare the case automatically. It helps to create p, rho, T, U, K (all necessary fields) in "0" folder.

My point is that you can do it manually, just writing those files by yourself.
And that way changeDict becomes unimportant, and can not generate errors because you know what are the boundaries (in the end you wrote them).

Best,
Pawel

Hi!

That sounds like a good idea actually, I will try to create the files in the 0-directory myself. I did never realize that you could get around it in that way since I thought the cht-solver worked that way (with changeDict) and it was the whole point using them.
Should I create two folders inside named "fluid" and "heater" for the respective region?

Now my question is how to define the coupling between fluid and solid in the 0-directory since it will have some "internal faces" (fluid to solid-coupling inside the geometry). Don't know if it can be defined in blockMeshDict, if it's ever needed to.

I suppose the makeCellSets is still needed to split the geometry.

Regards
Marco

Hi Marco,

if you want to have a quite clear understanding how to couple two regions, I strongly recommend to read this thread. It is very long, true, but has all the info you need. If you do not want to read all of it, start from the end ;)

best,
Pawel

Thank you Pawel!

I read through the entire thread and it was very informative.
This was not clear to me though:

Did you create two folders with those names ("tmp" and "runCase"), what for?
And what do you mean with decomposition?

Regards
Marco

Hi Marco,

next time please give me some link to the post that you are mentioning- it was half a year ago ;)

This post was about preparing a "case" for work. The idea in cht-tutorial was: create one big mesh, then use splitMesh tool to decompose it into regions.

splitMesh writes the decomposed big mesh in "constant" folders in newly created time folder 0.001. I did not like this way, so I proposed to create a tmp case, where one plays with the mesh, and when everything is ready- copies the tmp to runCase folder and runs the simulation.

Thats it.

Best,
Pawel

Ooops, sorry! Didn't pay attention to that. ;)

That part I don't get, about the creation of folder 0.001. It doesn't do that in the tutorial case.
I suppose I create the mesh with blockMeshDict as ususal but how do I define which parts that are solid/fluid?

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

About the different regions:

Do I only need one blockMeshDict in polyMesh-directory and just copy the above mentioned files to their resective region-directories?

Thanks for your patience and your replies!

Regards
Marco

OK, lets do it from the top.

First thing to know is how OF stores data. It requires folders: system, constant, <time>. Data are stored in time folders and do not contain any mesh information. Mesh is stored in polyMesh folder. It can be put in two places. First, most common is inside constant folder. Second place is the time folder. The 2nd approach is usually used for time-varying mesh. In one of previous chtMRFoam tutorials one also used this approach while running splitMesh.

In multi region case, in each of folders: system, constant, <time>, one requires to put "domain" folders. Each of those folders contains data which correspond to a specific region. The regions themselves are defied in constant/regionProperties file.

Going back to case organization regarding mesh. I do not like the 2nd approach, that is why I recommended the pre-processing procedure "tmp- run_case". First we create mesh in "tmp" which is saved using the 1st approach, and then manually we move it to constant/domainNames/polyMesh folders to acquire 2nd way of organizing files. After that we create "run_case" and use it to run the case.

Regarding "blockMeshDict"- this file is used only during pre-processing to create the mesh. After that, when you want to run the solver it is no longer needed (and even can be deleted).

I really do not know how to put this topic in other way :p


For the last words, I want to show completely different way of pre-processing.

Create empty multi-region case "runCASE" (without files, just right folder structure). Create a "TMP" case. In it, create a blockMeshDict for only one region. Run blockMesh. Copy acquired mesh from TMP to respective "runCASE" constant/region/polyMesh. Repeat procedure for all reigons.
After mesh is created, one has to organize "boundary" files in the right way, create initial fields, etc. This procedure is slower, requires more work but it works. And after one succeeds, he finally knows how it all works.

Best,
Pawel

It's clear to me now, thank you!

Now I know exactly what the boundaries are by defining everything myself (like you proposed) and editing the files for example:

Had to figure out that you also needed the following in TMP-folder to be able to run blockMesh:

* controlDict file in TMP/system
* blockMeshDict had to be in TMP/constant/polyMesh

I guess these are basic and obvious things you need to know in OpenFOAM that I didn't know, but now anyone that didn't know can read this and learn :p.

Anyhow, I still get the following error when I try to run chtMRSimpleFoam:

Don't understand what the error means (I got the same error in an earlier post in this thread). Probably coupling problem(s).

If anyone wan't to look at the files your welcome to do so (only the more relevant files are included). :)

The reason I have two solid regions are for visualization purpose mostly since the channel -region will be a more complex geometry later on (running some testcase now to get it working). Just in case someone was wondering. ;)

Regards
Marco

Hi Marco,
usually that error means that you mispelled the boundary definition (in constant\polyMesh\boundary) or the BC assignation (in 0\...). Indeed:
is not right. You should use type directMapped and not directMappedWall. Try to correct this and let me know if it worked. You got the same error some posta ago because you used a non existant BC, as I pointed out here.

Have fun!

mad

Thank you Maddalena, but I still get the same error.
When I check the boundary- file in the tutorial case (which runs changeDictionary) the created type is directMappedWall. Why the difference?

As I carefully read through some earlier posts, you guys didn't actually recommend solidWallMixedTemperatureCoupled (swMtc).
For instance:

Should I instead use solidWallTemperatureCoupled (swtc) for coupling the temperature?

Btw, is solidWallHeatFluxTemperature (swHFt) a suitable boundary condition for a system? Since the others (swtc, swMtc, swHFtc) are more like coupling conditions inside the system.

I will continue to look for misspelling errors for the moment, could be more more of them (if you have time I posted the relevant files in my earlier post so you can look at them :)).

Regards
Marco

Ops... :o My fault. directMappedWall is ok indeed...
Well... let us say that Pawel, I and some other guys worked a bit on the subject, and discovered that the coupling condition is not so fine for some kind of applications. You can find a discussion on the subject in this post. But maybe this is not your case...
Regards,

mad

Hmm, swMtc maybe don't work so well then.
I looked at the other alternatives, but the question is:

Do these even exist in OF-1.6.x?
* swtc (solidWallTemperatureCoupled)
* swHFtc (solidWallHeatFluxTemperatureCoupled)

I did try anyway to do as proposed by Pawel in another post by using swHFtc and swtc:

But with no sucess, also not sure which side should be swtc or swHFtc.

Could it be something with the thermophysical properties in fluid region? Wondering since the error is displayed in the following way.

I have changed from air to H2O in that file anyway (I attach it too), don't know if you're allowed to do that.

Regards
Marco

Hello everybody,

i did some cht-simulation but i´m still confused about the mixing BC. I use solidWallMixedTemperatureCoupled as it was mentioned in this thread. But how does this BC works?

That I found out is, that the valueFraction decides whether it is fixedValue ( valueFraction=0) or zeroGradient (valueFraction=1) or it could be something in between. The valueFraction is calulated by:

valueFraction()=nbrKDelta/(nbrKDelta+myKDelta)

with:

nbrKDelta = nbr.Field.K()*nbrPatch.deltaCoeffs();
myKDelta = K()*patch.deltaCoeffs();

so the valueFraction depends on the Kfield of the coupeld regions. What I don´t know is the meaning of the "deltaCoeffs()" and how does the BC work, when the valueFraction is between 0 and 1???

Thanks a lot!!

Michael

Hello Michael,

I suppose that you are working on OF-1.7.1 (please state if otherwise- there were some major changes in this BC).

You got quite deep into C++ jungle of boundary condition implementation.
As I mentioned, there were big changes since OF-1.6 and this BC became very abstract (this means- good knowledge of C++ is needed).

Regarding deltaCoeffs().
It is a member function called for "patch" object which is of "fvPatch" type.
Here is where the deltaCoeffs are calculated: makeDeltaCoeffs()
In general, they are distances from the face to the centre of the cell.

Regarding valueFraction(), etc.
In the newest swMixedTempCoupled one just sets valueFraction, rfValue and refGradient, then calls "mixedFvPatchScalarField::updateCoeffs();" and lets OF magic do the rest. In fact, during solving process, OF calls member functions of mixedFvPatchField, which define values, gradients and all the other needed stuff. And those functions take as parameters the ref-Data set by us in the updateCoeffs() of swMixedTempCoupled function. If you want to see exactly how the values are calculated- go to mixedFvPatchField above.

All above is just about the "mechanics" of the BC (and requires only jumping from tree to tree in the C++ jungle). I can not help with the theoretical background of this mechanics: I am simply not aware of it- my bad. Can anyone give some references please?

Hope it helps a bit,
best,
Pawel

Hello Pawel,

Thank you and yes it helps a lot! So this BC decides due to the K-value and the cellsize whether it is fixedGradient, fixedvalue or something in between. So this BC is the implementation of the third type of BC (other names I found for that are Robin-BC or Newton-BC). Am I right??

Thanks

Michael