Adding heat source to chtMultiRegionFoam
 

Dear FOAMers,
in order to simulate a conduction + convection problem with openFoam, I added a heat source to the standard chtMultiRegionFoam release. This was straightforward: in solveSolid.H I added the heat source H [W m-3] contribution to the general conduction equation:
This formulation runs fine if I use a single region, but fails when using two or more regions. In that case, the temperature inside every region raises to unacceptable values, and the theoretical solution known for the easiest problems is not reached (see also here)
After some more investigations, I noticed that the problem may be due to the coupling between interfaces. Indeed, the solidWallMixedTemperatureCoupled formulation calculates Twall as:
I am guessing that this equation implements formula 3.15, pag 32 of this book: given three grid points W, P, and E and being dxw and dxe the distance between WP and PE respectively, than a_P*T_P = a_E*T_E+a_W*T_W + H*deltaX , where a_P = a_E+a_W, a_E = k_E/dxe, a_W = k_W/dxw. (T temperature, k conducibility). Therefore, in the case of heat source I should have something like
The last term represents the heat source*DeltaX contribution. However, this is valid for a Temperature inside the grid and not at the boundary. Indeed, the heat source contribution in this case is applied to the neighbor cell as well.
I am thinking that I need a more general review of solidWallMixedTemperatureCoupled.C, but I am asking for suggestions and hints before going further:

1. Has anyone have any kind of experience in adding heat source to chtMultiRegionFoam? I do not think I am the first to try it, and I know for sure that somewhere else had similar problem with OF (see here) ... How did you solved that?
2. In the case I am the pioneer in this sense :eek:, is my approach correct? Is there anyone that can comment on that?
3. Beside this book, is there any reference that gives a numerical formulation for chtt?

Thanks for any help I may get.

Regards,

mad

coupling conditions
 

Following a presentation of the coupling made by HRV, I ended up with the following.
In the case of coupling between two regions A and B, both of them with a heat source H, the coupling condition should be something like:

• T_A = T_B
• K_A*grad(T_A) +H_A*x = K_B*grad(T_B) +H_B*x

This will help to keep the continuity between the two regions & take into consideration the changing slopes of the two "x vs T" curves.
I was thinking to implement this as:
but without success.
Is there anyone that can comment on that? Is this the right approach or am I on the wrong path?
thank you

mad.

comments? hints? ideas?
 

Ok, the ideas presented above were unsuccessful, probably due to my poor C++ and / or something on the math formulation of the problem that I am missing.
Someone else agrees with me that the solidWallMixedTemperatureCoupled is not general enough to allow a heat source inside one or more regions. Unfortunately, it seems like that everybody facing this problem has given up and turned to a fixedValue approach. That is what I probably will do as well, at least for the moment.
On the other hand, I am really interested on a new coupling formulation, and I'd like to spend some of my time on it. However, I need some general ideas on how to approach the problem, since I am still not completely into it. The first step, for example, can be some comments on the ideas described above... :rolleyes:

regards,

mad

Hi,
first I would suggest you to check if the problem is really the boundary condition, did you try to compute the continuity error?
For "engineering" porpoise the coupling mixed condition gives good result, but maybe the source term is giving troubles, did you try to solve implicitly, using SuSp()?

If the power source is generated also along the boundary, which maybe is unphysical, you should add it in the balancing eq. otherwise the original should do the trick.

Andrea

Hi Andrea and thank you for replying!
What I have done up to now is to create a sort of matrix (see attached picture) with one or two regions, and applying energy using a temperature fixed value or a heat source. As you can see, the only simulation that fails is the 2 region + heat source, thus I concluded that:

1. How can I check continuity? If I use two solids as I did, it does not appear on the standard output.
2. How can I switch to implicitly? where using SuSp()?

The power is generated on every cell in the domain, thus on the boundary cell as well. The solidWallMixedTemperatureCoupled does not take into account the T gradient between the last cell center and the boundary, as you have if applying a heat source, and the Twall does not include the heat source as well. This is what I was trying to do on the previous posts: adding the heat source contribution on the boundary balancing equation. Is this what you mean?

cheers,

mad

Hi,
about source term read this:
http://www.cfd-online.com/Forums/ope...r-details.html

If you don't want source at boundary create a vol Field with 0 fixed value boundary condition and add it to the equation to be solved, maybe this is worth a try.

To compute errors you should write your own little code... not too difficult.

yes I meant that, but I think it's not physical, my guess.
Hope it helps
Andrea

Hello,
this was easy: I defined H in my domain in the same way I declare K or cp, thus I simply had to vary the boundary field as follow:
well, it did not work. :rolleyes:
I will try the SuSp() as soon as I understand where I should change the code..

cheers,

mad

Hi,
ok then, I'm curious, how much this heat source is large?
Have you tried to lower H's value and see if there's any hope to get
convergence?

if I remember correctly it should be as simple as

or

into the solve function or the fvMatrix inizialization.

Hi Andrea,
The heat source is 500 W/m^3, but I tried to lower till 0.5 W/m^3. The most weird thing is that the time vs T tendency is linear, and I have this even if I let the simulation run longer or decrease H or change the material properties.

Some thoughts about that... Let us for a moment drop the heat source contribution and consider the (working) case if I impose a fixedValue temperature. From what I can understand, the solidWallMixedTemperatureValue copies the temperature value from the neighbour region, thus from the "cold" region, on my cell in the "warm" region. On the "cold" region, a zeroGradient BC is applied. In different (and easier) words the temperature of the "cold" region is diffused on the "warm" region and viceversa. This works fine if I do not have any heat source.
When I add H, the contribution of the "cold" region on the "warm" region is not enough, since the temperature gradient obtained on the boundary cell by coping "cold" cell value onto the "warm" cell value is lower than the heat source contribution. In other words, the temperature diffusion in the "cold" region works fine, but not in the "warm" region. Therefore, the "warm" region is somewhat isolated from the outside, and its temperature increases until the simulation ends. This is, at least, the explanation I am giving to the weird results I am getting.

Indeed, I should have written:
on my solveSolid.H, to let the solver consider only the constant part of the source term linearization. In that case, I get a "Unknow matrix combination" error before starting the solver, and the LU or something operator complaining. (sorry, I am not at the office now, I will report the complete error message as soon as I will go back there). As for using a SuSp(), should not I have a sort of linear equation for the heat source term to use it? Something like H = H0 + H1*T? At the moment I only know the H0, that is why I wrote the solveSolid.H equation as in the first post. I am going to google a bit to see if I can find a sort of relation that is applicable in my case, and than update solveSolid.H as you suggested.

In the meanwhile, another question come into my mind. chtMultiRegionFoam is a compressible solver, while I want to consider my simulation as incompressible. May I get problems if I use it in my case? I would say no, but maybe there is something that I am missing.

Thanks for your time,
regards,

mad

Hi again,
maybe you know about that but there was a sort of "bug" in the coupling patch in previous releases of OF, in 1.5 was fixed.

No, the coupling works fine since you are trying to force T and Heat Flux matching between two regions what ever the eq. to be solved on both sides . Actually, we used this thing for an incompressible case.

I still would like to see the coupling error between the two patches, can you try something as
this should gives you how bad is the coupling working.

you're welcome,
Andrea

Hi Andrea,
I am using 1.6.x coupling, and modified version of setInitialMultiRegionDeltaT.H to take into account the time step selection on the base of maxDi or maxCo.
That sounds nice. This is something I expected.
In place of changing the code, I looked at the lastTimeStep/../T file for both regions. In my simulation, H is 500 W/m^3 and placed inside cube1. The coupling is based on the 1.6.x unmodified version of solidWallMixedTemperatureCoupled.H. So... At time 0 the temperature is 300 K everywhere. This is 100000/cube1/T:
and this is 100000/cube2/T
As you can see, cube1 has a valueFraction close to 0: a fixedValue BC is applied, and the 520.5101 value is the innerField value of the cube2 first cell. cube2 has a valueFraction close to 1: a fixedGradient value is applied, and the refValue is the boundary value. Comparing the temperature value at the interface (value entry), I can see the temperatures are (almost) the same, thus the coupling is working fine.

Still working on the heat source definition. This is the error I am getting when using fvm::Su(H, T):
Stay tuned for update. ;)
regards,

mad

Hi,
to check the coupling properly you should also check the heat flux, and for this you have to add two code lines :eek:, don't be too scared... If the heat is not flowing to the next regions of course the temperature will rise whatever the source implementation, I think you had a feeling about this too.
I wait for some new updates, good luck!
Andrea

:o I am not scared... I only do not want to loose time in implementing things that I already knows... For example, the heat flux can be obtained activating the debug flag. This is the last simulated time:
The two flux are (almost) the same, so the flow seems to be modeled accurately.
In any case, where should I add the lines you suggested? In solidWallTemperatureCoupled.H or in chtMultiRegionFoam.H? Is Ts the solid temperature at the boundary and Tf the fluid temperature? If so, what does change if I add the lines or check the T value at the coupling region?

mad

Ok then,
from what I see it seems fine except for a little heat flux error, maybe not enough for a totally wrong simulation, is this error so little in the first time steps?
The problem is that you get unrealistic too high values inside the source domain, right?
I noticed that the coupling gives slower temperature rising than it should, maybe you "accumulate" too much heat in the beginning (I'm just thinking aloud now)

Andrea

Hi andrea, and thank you to keep replying.
yes, that small error is always there. After 5000 s simulating time, the output is as follows:
At 5000 s the steady state is not reached: for cube1, the time constant should be around 40000s. Note that the delta T is chosen by OF automatically, but it matches the max admissible delta T, calculated as suggested in other threads, which is 100 s.
This is one of the problems... summarizing:

1. the temperature is too high inside the source region. As a consequence, the temperature is too high inside the "cold" region as well.
2. The time vs temperature has not the theoretical tendency: in my simulation, I have a linear time vs temperature!

How did you noticed that? The final 100000 seconds simulation should be already on a steady state condition....
What do you mean? Should I increase the heat source little by little, as one usually does with turbulence on simpleFoam simulation? I have already done that, using three steps:
1. from 0 to 25000 s with H = 5 W/m^3
2. from 25000 to 50000 s with H = 50 W/m^3
3. from 50000 to 100000 s with H = 500 W/m^3
no success. The only things that changes is the time vs temperature line angular coefficient. The theoretical curve rising is not matched.

mad

Hi,
so the coupling seems to work, even if with the "small" enough error in heat flow that unlikely it is the problem.
So what about the others boundary conditions? It seems that you possibly have a zeroGradient somewhere in the colder domain. Let me know.

Bye
Andrea

Hello Andrea,

find attached a simple figure of my domain. I have zeroGradient BC on K, cp and H (heat source) both at the interface between cube1 and cube2 and on the other vertical patch. As you can see, the grid is rough: should this be a problem? I guess that the solution may be wrong to the poor grid quality, but not SO wrong...

In the meanwhile, I found a working case. If I add the heat source to the multiRegionHeater tutorial, everything works as it should: time vs temperature is not linear but it has the well known curved tendency. Note that the grid is really really rough on the tutorial.
I do not now if I should be happy with that (OF does not betray us) or not happy (there is something wrong with my model). In any case... In order to find what is wrong with it, I cross checked what changes between the two models (tutorial and my own model):

• time step: my time step is much higher than the tutorial time step. Decrease it bring no improvements.
• mesh size: a rough mesh cannot be capable of describing what is happening. I am going to increase the mesh resolution close to the interface.
• cyclic: I am using cyclic, the tutorial is not. May this be cause of the problem?
• Material properties: I "created" a new material for cube1, with some properties I like in order to reduce the computational time, while using air properties for the cube2 (which is calculated as solid). I am going to change them. However, this will not explain the linear time vs temperature...

What do you think?
cheers,

mad

Well,
I agree with your analysis, and then the obviously thing to do is drop the cyclic patch type... then we can re-think on "why you cyclic?"

fingers crossed
Andrea

So...

• mesh size: Increased mesh resolution at the interface --> No changes on the solution.
• cyclic: run with zeroGradient in place of cyclic --> No changes on the solution.
• material properties: adjusted with tutorial values --> solution changes, but not the time vs temperature.
• time step: tried to reduce time step, well below the prescribed limit of Dt < rho*cp*Dx^2/2/K --> no changes.
• 2D vs 3D: tutorial uses a 3D mesh, while I have a 2D case, maybe patch defined as empty is the problem? -> no, the time vs temperature keeps to be linear.

what should I do now? I am really out of ideas! It seems unbelievable that the only running case is the modified tutorial!

cheers,

mad

ok,
don't loose your temper, the thing is weird but maybe we're still missing something. Can you post the case, along with the solution? I will take a look at it

cheers
Andrea

This "WE" implies that there is someone else loosing sleeping hours for this as me??? ;)
Do you also need the solver? I will email them as soon as possible.

thanks

mad

Hi mad,
I've looked at it. The problem maybe the symmetry/zeroGradient condition on the left side of cube1, that makes T unbounded, while a fixedValue works. My advise will be to try a cube2-cube1-cube 2 configuration.

I opened this case and the tutorial, the cube case looks 10 times greater than it should be, but maybe is a paraview ocus-pocus.

let me know
Andrea

Hello Andrea,
Yes, that is true!!! :eek: It is unbelievable... The only things that I did not try yesterday... So, the solution seems to not use any symmetry BC...
And this is the logical conclusion... Ok, I will report it as soon as possible.
What does it mean? cube1 is a cube of 1 meter long. It seems to me that it is like that, no? Or did you compare it with the size of the tutorial? I have made them independently, so maybe I should scale my case to match the tutorial dimensions...
Thanks for your support, at least now I have a possible answer to the problem! :rolleyes:
ciao

mad

yes I mean that they should be of the same order but open them in paraview makes look the cube 1o times bigger, mah!

I'm still not understanding why symmetry is not working!
ok

Hello,
guess what??? It is not working! I have the same results as the cube1-cube2 + symmetry.

but...

If I use a condition like the one shown in the attached figure... well, everything works! It seems like the solver needs a fixedValue somewhere in the domain to limit the heat source contribution...

Indeed...

coming back to the modified tutorial example. If you modify the minY BC from fixedValue 500K (or 300K) to zeroGradient BC, (and set U 0 0 0 in the fluid regions) well... The time vs temperature is ok in the first 100 simulated seconds, but it becomes linear after on!

Thus

it is not the "symmetry" or the "cyclic" or some special condition that does not work, but it is a "heat source limitation" problems.

I am going to think to it. Does it has any physical meaning connected with the BC we are fixing or is it a computational problem? What is your opinion on that?

mad

Hi,
I agree, but maybe is more subtle than this. Of course source should be limited, but putting a fixedValue on the left side of cube1 and putting zeroGradient on the right of cube2 just works fine... hence, in my opinion, coupling condition misbehaves...

Andrea

Hi Andrea,
yes, it works fine because we are limiting in some way the heat source... ant this limit is the fixedValue temperature on the left side of cube1.

One step more... I created a new case, like the cube2-cube1-cube2 case of yesterday and added a very large solid surrounding domain, where I fixed the temperature. Something similar is shown in the attached figure. In this case, we have NO BC on cube1, and its solution depends only on what is happening there. In addition, there is no involving convection, that may represent an additional problem. Now, we have two hypothesis on why the modified version of chtMultiRegionFoam fails:

1. BC that are not representing what we think.
2. coupling does not works properly.

If 1 is true, than the new case should work, since we have no BC on the heating region. If 2 is true, the new case should fail.

After running as usual, I have result as usual: linear time vs temperature, hence 2 is true and, as you suggested yesterday,What I cannot explain is why Robertas has a similar case over here, and she claims to have it running... Unfortunately, the case needs some modifications to run.

Therefore, we are at the same point of the 20th of July, when I started this thread. How to improve the coupling condition? Or, is there a way to limit the heat source without fixing the temperature on one side of it?

regards,

mad

Hi mad,

I asked the OF support team about the heat source issue.
They told me I should take a look at the porousExplicitSourceReactingParcelFoam solver in OF-1.7.x
There is a energy source term in createExplicitSources.H:
I run the tutorial but I don't understand yet.

Regards,
Toni

Ehi!
Well... thank you! It seems like you can receive support team help only by direct contact! Have they ever look at this thread??? mah... :rolleyes:
Of course, I will have a look to it during the next week or so.
And please report everything. The three of us can do a good job, I hope... :cool:

mad

Hi Toni,
I looked at the file you pointed out. It seems that the createExplicitSources.H, which recalls timeActivateExplicitSource.H, is used only to define a heat source that can be activated / deactivated whenever you need it. In my case, the heat source is on and does not change for all the time, so this approach seems useless. Indeed the explicit source can be defined as I posted above.
In any case, Andrea and I found out that is the coupling condition that does not work properly when defining a heat source and not fix at least one of the boundary values. If the temperature is fixed in one of the boundaries, the heat source defined as above gives reasonable results.
The problem sounds deeper than it looks like. Hope I can still get some sort of support from the community, but at the moment none has suggested improvement for the coupling yet.
Regards,

mad

Hi,

I will take a look at this also, can you send me the solver you have for now ??? You can send it to:
fc [at] canesin [dot] com

My problem is a little like yours, I have to add an heat source term that reads a variable cp and a variable value that both depends on another equation I solve in the domain.. (it is a triple coupled problem, magnetic+heat+fluid).

I will be back in here for the next developments of my solver... hope to work together.

Just send it.
Hope to work together too. I have been stuck to the same point for some weeks now.
Cheers,

maddalena

Hi Fabio, any news?

mad

I have run a preprocessor in it and at the moment I'm trying to understand better the solver.
I agree it seams to do the interface like Patankar book.

I have added the source term explicit to the solid equation.. I will reproduce from memory the steps here, so I maybe type wrong some code.. I have changed little the solid, but a lot the fluid.. I'm trying to setup some validation cases now.. as soon as I do that will be back here.

tmp<fvScalarMatrix> TEqn
(
fvm::ddt(rho*cp, T)
- fvm::laplacian(K, T)
- S
);

Then added a field to it:
PrtList<volScalarField> Ss(solidRegions.size());

Ss.set
(
i,
new volScalarField,
IOobject ...
)
... In fact have copied temperature T field and just changed to "S".

Then I have changed the flow solver to a incompressible one and removed the PIMPLE loop to a PISO one... now I'm trying to validate with Blasius and planewall.. but I'm having some problems with mesh =/ ...

Hi, Canesin,

I am interested in using incompressible solver for fluid in stead of the compressible solver in the current chtMultiRegionFoam solver. I am wondering if you can send me your solver so that I can learn from you?

What is your reason for using PISO instead of PIMPLE?

Pei

phsieh2005@yahoo.com

Dier Phsieh,

I`m really sorry for not being able to send my solver.. I have an confidentiality agreement with the sponsor of my project .. But as soon as I have submited an paper to some journal I can publish some code here..

I have used an PISO loop because my problem is not steady-state, it has no steady-state configuration, it can be only determined an periodic developed region... In that case I use an PISO loop since PIMPLE is only to permit the use of large time-step, with don't make sence for me.. removing the PIMPLE to a PISO loop I can remove the outer loop (the "nOuterCorr" for loop) and improve the speedy of the solver.

Thanks Canesin!

Pei

Hi Maddalena and Andrea,

Could you please show me how to compute the wall heat flux at every iteration when using the chtMultiRegionSimpleFoam (OF 1.7.0)?

I am a complete beginner with OpenFoam, and absolutely weak with C++.

Thank you very much.

Best Regards,
Stefano

Hi Stefano,
I commented the if selection while leaving uncommented the inner test in solidWallHeatFluxTemperature. Something like:
Then recompiled the solver. The heat flux is written in the log file.

mad