[fxzf]

Hello Experts,

I want to ask question and discuss how to make a fast convergence conjugate heat transfer solver.

I am currently using OpenFOAM chtMultiRegionSimpleFoam which is steady state cht solver. The problem is it reaches convergence state very slow compare with commercial software, it could be slow down like 20 times. I believe the reason is OpenFOAM chtMultiRegionSimpleFoam is doing loosely coupled cht, so it solves fluid and solid separately.

I know there are two things to affect the convergence,
one is interface boundary condition, so both fluid and solid side should satisfy temperature Ts=Tf and heat flux Qs=-Qf

The other one how you solve it either you put fluid energy equation and solid energy equation in same matrix like in foam-ext conjugateHeatSimpleFoam, or your solve them separately.
By checking the OpenFOAM coupled boundary condition, it seems satisfy the Qs = -Qf condition, but I think there must be other way to define interface to improve the heat convergence.

So my question is could any expert give me some suggestion to improve the interface bc.

The second question is OF is solved fluid and solid in different matrix and iteratively. Does it a matter to put fluid and solid in same matrix? For me if we have a very good interface bc, how you solve it in same matrix or different matrix should only affect the parallel efficiency, not much on convergence speed?

Looking forward your answers.

[dlahaye]

Thank you for raising this well-thought issue.

Here are some arguments that might be valuable to consider.

1/ You compare OpenFoam with a commercial software. Is the commercial software 20 times faster in iterations, in CPU time or both? One can replace in a first instance the solid domain by a boundary conditions that allows heat to escape to the solid. For this situation, one could compare OpenFoam and the commercial implementation again. I wonder how the factor 20 would change is this case. That is, is the factor of 20 only related to the conjugate heat transfer or are other factors involved as well?

2/ You mention foam-ext conjugateHeatSimpleFoam. How does it compare with chtMultiRegionSimpleFoam on your test case?

3/ concerning the use of interface conditions that you raise: there is literature on interface conditions in the context of linear solvers (see e.g. ddm.org). I do not know how results carry over to conjugate heat transfer. Possibly the book by Dorfman on conjugate heat transfer is a place to start looking.

Hope this helps.

[fxzf]

Originally Posted by dlahaye

Thank you for raising this well-thought issue.

Here are some arguments that might be valuable to consider.

1/ You compare OpenFoam with a commercial software. Is the commercial software 20 times faster in iterations, in CPU time or both? One can replace in a first instance the solid domain by a boundary conditions that allows heat to escape to the solid. For this situation, one could compare OpenFoam and the commercial implementation again. I wonder how the factor 20 would change is this case. That is, is the factor of 20 only related to the conjugate heat transfer or are other factors involved as well?

2/ You mention foam-ext conjugateHeatSimpleFoam. How does it compare with chtMultiRegionSimpleFoam on your test case?

3/ concerning the use of interface conditions that you raise: there is literature on interface conditions in the context of linear solvers (see e.g. ddm.org). I do not know how results carry over to conjugate heat transfer. Possibly the book by Dorfman on conjugate heat transfer is a place to start looking.

Hope this helps.

Dear Domenico,

Thanks very much for your kind reply. I really would like to discuss with my questions with community to get a better idea to improve OF cht.

1. I am not consider the solver time since different solver has different way to store mesh, setup matrix and memory etc. But in my case, OF chtMultiRegionSimpleFoam took around 4000-5000 times to get heat converge in solid and fluid regions. In the same mesh, in starCCM, or Flotherm, it only takes about 100-200 iterations. And this is even a steady state case, the problem is in each iteration, it seems temperature in solid region varies very slow, like within 0.5C, then it took 1000s iterations to get corrected temperature.

2. I haven't tested my case in foam-ext conjugateHeatSimpleFoam, since my case a bit complicated. But I tested it on a simpler case, conjugateHeatSimpleFoam seems much faster, but still not reach convergence like Fluent or StarCCM.

3. I think this is area we need to check in OF. Thanks very much for your recommendation .

Cheers,

[arjun]

Based on my experience of implementing CHT in Wildkatze solver, the major factor is under-relaxation strategy. In solids the urf shall be close to 1.

I am attaching an image for calculation for a shell heat exchanger comparison of Wildkatze with Starccm. You can see that IN THIS comparison Wildkatze converged to outlet temperatures much faster than Starccm.

Now this is 1.7 million polyhedrals so it is moderate sized case. For starccm, the person who ran this case for me, he only ran it to 180 iterations. You can see that at 180 iteration starccm just started to converge to proper temperature, while Wildkatze went towards that temperature much quicker.

I believe that this is because Wildkatze is using better URF since starccm and wildkatze are similar in algo.

Originally Posted by fxzf

Dear Domenico,

Thanks very much for your kind reply. I really would like to discuss with my questions with community to get a better idea to improve OF cht.

1. I am not consider the solver time since different solver has different way to store mesh, setup matrix and memory etc. But in my case, OF chtMultiRegionSimpleFoam took around 4000-5000 times to get heat converge in solid and fluid regions. In the same mesh, in starCCM, or Flotherm, it only takes about 100-200 iterations. And this is even a steady state case, the problem is in each iteration, it seems temperature in solid region varies very slow, like within 0.5C, then it took 1000s iterations to get corrected temperature.

2. I haven't tested my case in foam-ext conjugateHeatSimpleFoam, since my case a bit complicated. But I tested it on a simpler case, conjugateHeatSimpleFoam seems much faster, but still not reach convergence like Fluent or StarCCM.

3. I think this is area we need to check in OF. Thanks very much for your recommendation .

Cheers,

[dlahaye]

OpenFoam might be slow in various applications for various reasons. The use of over-relaxation factors might indeed one as Arjun suggest.

It is our role as users community to discuss these applications, reasons, solutions and fixes.

My humble suggestion is that you provide more details on what exactly you are observing, i.e., details on the application of the commercial code and OpenFoam.
I am sure that the exercise of being more explicit will be valuable to make. I will be happy to provide input on drafts on your notes.

We have attributed the slow change of the solid domain in COMSOL Multiphysics to thermal stiffness of the solid. This implies that slow changes in the solid domain are independent of any implementation (commercial code or otherwise).

Cheers, D.

[fxzf]

Originally Posted by arjun

Based on my experience of implementing CHT in Wildkatze solver, the major factor is under-relaxation strategy. In solids the urf shall be close to 1.

I am attaching an image for calculation for a shell heat exchanger comparison of Wildkatze with Starccm. You can see that IN THIS comparison Wildkatze converged to outlet temperatures much faster than Starccm.

Now this is 1.7 million polyhedrals so it is moderate sized case. For starccm, the person who ran this case for me, he only ran it to 180 iterations. You can see that at 180 iteration starccm just started to converge to proper temperature, while Wildkatze went towards that temperature much quicker.

I believe that this is because Wildkatze is using better URF since starccm and wildkatze are similar in algo.

Hi Arjun,

Thanks very much for your reply. I actually already use under-relaxation factor 0.99999 in solid region, but in fluid region I still keep as 0.7, I can try to push under-relaxation factor in fluid region a bit more, but as my experience, it some times lead unstable in fluid region.

Wow, this is very interesting. But I never use Wildkatze, is it open-source? As I don't have budget to buy software.

Thanks very much.

Cheers

[fxzf]

Originally Posted by dlahaye

OpenFoam might be slow in various applications for various reasons. The use of over-relaxation factors might indeed one as Arjun suggest.

It is our role as users community to discuss these applications, reasons, solutions and fixes.

My humble suggestion is that you provide more details on what exactly you are observing, i.e., details on the application of the commercial code and OpenFoam.
I am sure that the exercise of being more explicit will be valuable to make. I will be happy to provide input on drafts on your notes.

We have attributed the slow change of the solid domain in COMSOL Multiphysics to thermal stiffness of the solid. This implies that slow changes in the solid domain are independent of any implementation (commercial code or otherwise).

Cheers, D.

Dear Domenico,

Thanks very much for your reply and support. Much appreciates.

As Arjun suggested, I have already used Under-relaxation factor in solid region as 0.9999 but still keep 0.7 in fluid region since the fear of unstable, but I can try to push it a bit higher.

I can simply describe my problem. I am simulating the natural convection case. It is will be for electronical device heating cooling issue. So geometry is simple, just a few cubes for solid, and some cubes has volume heat source. I want to get the steady state temperature for each solid regions and temperature distribution in fluid region. Because big commercial using Siemens Flotherm for this problem, we tried to use Flotherm to calibrate OF. In same test case, Flotherm is very faster to get steady state result but OpenFOAM chtMultiregionSimpleFoam is just too slow to use. I wonder how we can improve it.

One thing I read in many papers where CHT researchers complain the loosely coupled cht solver has trouble in the heat flux inbalance between fluid-solid, solid-solid will lead slow convergence since they can only be reach heat balance at converged state. Therefore, I am thinking many we can do something on courrent chtMultiRegaionSimpleFoam interface bc, before we go to more complicated option to develop coupled CHT solver like conjugateHeatSimpleFoam. (The other CHT classic issue like multi-scale issue, I believe it should be in unsteady CHT problem. That is one thing haunting me, why OF steady state chtMultiRegionSimpleFoam is too slow)

Hope community can give more ideas and support on the CHT issue.

Cheers,

FF

[dlahaye]

Any idea what this more complex coupling bc should be?

[Yann]

Hi all,

I'm interested in this topic and I just came into the new implicit handling of coupled patches while reading the release notes of OpenFOAM-v2112.

I did not try the cpuCabinet tutorial yet nor did I dig into the math and code, but it seems worth sharing here.

Yann

[arjun]

Originally Posted by fxzf

Hi Arjun,

Thanks very much for your reply. I actually already use under-relaxation factor 0.99999 in solid region, but in fluid region I still keep as 0.7, I can try to push under-relaxation factor in fluid region a bit more, but as my experience, it some times lead unstable in fluid region.

Wow, this is very interesting. But I never use Wildkatze, is it open-source? As I don't have budget to buy software.

Thanks very much.

Cheers

I tried to run the same case with 0.7 urf in fluid regions but it did not make much difference. Solver converged more or less the same way.

So it seems it is the coupling of the regions that is making the difference. In Wildkatze, one single matrix is constructed for all the regions (solids plus fluids) and the equation for engery is solved. (Pretty much how starccm and fluent too do).

I believe there is a version of openfoam that does this (tightly coupled regions) so may be your best bet is to use that one.

(If nothing works out and you feel stuck then just dm me, I can provide you license to run Wildkatze. )

[fxzf]

Originally Posted by Yann

Hi all,

I'm interested in this topic and I just came into the new implicit handling of coupled patches while reading the release notes of OpenFOAM-v2112.

I did not try the cpuCabinet tutorial yet nor did I dig into the math and code, but it seems worth sharing here.

Yann

Dear Yann,

Thanks very much for your reply. This is very interesting, I will definitely test this.

It mentioned that "An example usage for the new option is to solve for a single temperature field in multi-region conjugate heat transfer (CHT) cases. This produces a closer coupling between disconnected regions, yielding an energy equation that is easier to converge compared to using mapped patches. Applying this approach is particularly beneficial for quasi-steady flow conditions and the temperature field requires inner loops across multiple solid/fluid regions."

It is very interesting since, I only thought the AMI is only a interpolation scheme to help you get information between two different patches. I didn't know this could help to improve CHT convergence. In my case, my fluid-solid has conform mesh, but I will still test this if it makes different.

Cheers,
FF

[fxzf]

Originally Posted by arjun

I tried to run the same case with 0.7 urf in fluid regions but it did not make much difference. Solver converged more or less the same way.

So it seems it is the coupling of the regions that is making the difference. In Wildkatze, one single matrix is constructed for all the regions (solids plus fluids) and the equation for engery is solved. (Pretty much how starccm and fluent too do).

I believe there is a version of openfoam that does this (tightly coupled regions) so may be your best bet is to use that one.

(If nothing works out and you feel stuck then just dm me, I can provide you license to run Wildkatze. )

Well, this is what I thought as well. Most commercial softwares solve CHT in tight coupled, and solve solid-fluid, solid-solid in one matrix. I know in foam-ext it has conjugateHeatSimpleFoam does this way, but that one is very simple, it only support one fluid and one solid region, and it based on Boussenesiq approximation, so it not suit for natural convection yet. Need a lots of improvement. Furthermore, transfer it to work in current Openfoam foundation is not easy....

[arjun]

Originally Posted by fxzf

Well, this is what I thought as well. Most commercial softwares solve CHT in tight coupled, and solve solid-fluid, solid-solid in one matrix. I know in foam-ext it has conjugateHeatSimpleFoam does this way, but that one is very simple, it only support one fluid and one solid region, and it based on Boussenesiq approximation, so it not suit for natural convection yet. Need a lots of improvement. Furthermore, transfer it to work in current Openfoam foundation is not easy....

It seems the above provided link to implicit patches might work out. I quickly read and if you can set such a way that the patch lies on the same processor then it shall be okay to be used.

What surprises me though is that this issue is there for at least 5 to 6 years in the sense that people are asking for multiple coupled regions. Also openfoam is developed from year 1990 or so, and as open source from 2004. Still in 2022, there is no proper solution to this important thing.

This is very strange because so many people work on openfoam.

[fxzf]

Originally Posted by arjun

It seems the above provided link to implicit patches might work out. I quickly read and if you can set such a way that the patch lies on the same processor then it shall be okay to be used.

What surprises me though is that this issue is there for at least 5 to 6 years in the sense that people are asking for multiple coupled regions. Also openfoam is developed from year 1990 or so, and as open source from 2004. Still in 2022, there is no proper solution to this important thing.

This is very strange because so many people work on openfoam.

Hi Arjun,

Yes, I agree, I actually come across a few time for this issue. Each time, we want to do CHT, OpenFOAM has slow convergence issue.

I checked the detailed code of OF v2112 yesterday, it seems useImplicit on coupled Patch in CHT is more than a boundary condition. The solver will detect it and then put the matrix fluid, and all solids into one matrix system. It seems a tight coupled this time. I hope this is a big step forward. Although, there is still a few unknows, like how to perserve the coupled patch master and slave side into same processor in complicated case, does AMI still working in coupled CHT interface. But hope this could provide us some advantage.

[fxzf]

Originally Posted by Yann

Hi all,

I'm interested in this topic and I just came into the new implicit handling of coupled patches while reading the release notes of OpenFOAM-v2112.

I did not try the cpuCabinet tutorial yet nor did I dig into the math and code, but it seems worth sharing here.

Yann

Hi Yann,

I quickly checked the code yesterday, so it seems useImplicit coupled patch is more than a boundary condition. The CHT solver will detect it, once it found there is implicit coupled patch, it will switch solver to build a big matrix with all fluid and solid regions together. I hope this is a big step forward for OF cht community.

[Yann]

Hi FF,


Thank you for your feedback on the code, this is quite an interesting news!
Let us know how it performs if you try this on your case.


I'm installing v2112 right now, I plan to look into the cpuCabinet tutorial and to apply this change to one of my own CHT cases but I'm not sure when I will have time to do it.


Yann

[arjun]

Originally Posted by fxzf

Hi Arjun,

Yes, I agree, I actually come across a few time for this issue. Each time, we want to do CHT, OpenFOAM has slow convergence issue.

I checked the detailed code of OF v2112 yesterday, it seems useImplicit on coupled Patch in CHT is more than a boundary condition. The solver will detect it and then put the matrix fluid, and all solids into one matrix system. It seems a tight coupled this time. I hope this is a big step forward. Although, there is still a few unknows, like how to perserve the coupled patch master and slave side into same processor in complicated case, does AMI still working in coupled CHT interface. But hope this could provide us some advantage.

Check that if you get faster solution single process than using multiple processes. At least in case of single process the patch definitely lies on 1 processor.

[Krapf]

Maybe the options described in this commit are interesting for you: https://github.com/OpenFOAM/OpenFOAM...75c64c5b3c6cf5
(I have no experience with this.)

[fxzf]

Originally Posted by arjun

Check that if you get faster solution single process than using multiple processes. At least in case of single process the patch definitely lies on 1 processor.

Hi Arjun,

For multi-processor, it looks like ok as long as you perserve the coupled patch front and back at same processor. Not sure if for complicated case, it would work.

Although the convergence is good, but the temperature result is less than segregated solver and also same case with other commercial software. I think there maybe a bug somewhere.

[arjun]

Originally Posted by fxzf

Hi Arjun,

For multi-processor, it looks like ok as long as you perserve the coupled patch front and back at same processor. Not sure if for complicated case, it would work.

Although the convergence is good, but the temperature result is less than segregated solver and also same case with other commercial software. I think there maybe a bug somewhere.

Yes industrial cases could be tough. In fact this was the reason we wrote new software and not just used openfoam. For example the heat exchanger that i posted earlier had 6 regions and 11 interfaces. And this is first 3 calculations i did once the CHT model was added to the solver.