cannot get chtMultiRegion case to work
 

Hi community,


My interest in CFD is as a vehicle designer; to do my work I need 2 tools: simpleFoam to calculate lift and drag, and chtMultiRegionFoam to analyze heat exchanger integration. Regarding the first tool, I have a good handle on it - for the second, not so much.


Since November (!) I have been struggling with chtMultiRegionFoam as applied to a porous zone heat exchanger in a lofted body case, and have received a lot of advice, suggestions and actual time-spent-aid from generous people on this forum. I have gone through the tutorials, and carried over applicable material. Still no luck.
The big problem is failure accompanied by the "...exceeded maximum number of iterations..." message. It occurs immediately at time step 2. This could be a BC problem, or something more fundamental. I hate to ask yet again for help, but if anyone has time on their hands, my case can be found in this dropbox link:


https://www.dropbox.com/sh/fdbqckqdb...tC0oXhYMa?dl=0


As a sanity check to see if the mesh was at fault, I removed the heat exchanger and ran the case as a just a body with an empty duct, and it ran successfully. For reference, this case can be found in this dropbox link:


https://www.dropbox.com/sh/ukpv6cl3m...j7Thd3RPa?dl=0


All this notwithstanding, I will keep trying to make my case run, and will always be grateful for the help I have received.


boffin5

some clues for chtMultiRegion detectives
 

Today's attempt at resolving the mystery consisted of removing the body (fuselage), and running the case with the just the heat exchanger (porous zone) alone. And it ran!

And, the converse, running the body alone without the heat exchanger, also successfully ran.

Images of these situations are attached.

But, when I run them together, the chtMultiRegionFoam case fails. I checked, and the location of the radiator in the duct is precise; there are no heat exchanger cells pushing into a non-meshed area.

So what to make of this?

I am now wondering if my computer itself is to blame. It is an old laptop, whose processor has 2 cores. As I speak, I have a pile of parts waiting to coalesce into a relatively powerful desktop computer, that I configured for CFD. Computer to blame or not, I might as well proceed!

It seems you are struggling for some days.
Have you uploaded your solver in GitHub or GitLab? If then, share the link.

Let me look into it.
Thank you

Thank You, Kummi!!
 

Not just struggling for some days, but rather, months!


It would mean the world to me if you could help me sort out this case.
Regarding Github, I created an account, and went through the steps to upload my files. Then I tried to implement Github desktop, but it repeatedly failed on my Mac.

(btw, all my OpenFOAM work is done on a windows machine, but I transfer the files to my Mac for dissemination)

So for my Github account, the link is here:

https://github.com/boffin5/chtMultiRegion-rv6


But I am not sure if my files actually were uploaded.
However, if this didn't work, the files should be available in a Dropbox site as indicted in my previous post.


I am looking forward to your help, and if there is anything I need to do, by all means, please let me know.


Regards,
Alan w

Hello Alan,
Let's forget what we discussed in the past. Starting fresh !!
I have looked your case files in GITHUB. Irrespective of errors you are facing, I have some queries to ask you.
In regionProperties,
Why did you declared solid zone inside fluid zone ?

Anywhere in OpenFOAM, under constant/solid/thermophysicalProperties, the thermoType for solid is heSolidThermo, not heRhoThermo
Check the links:

https://github.com/OpenFOAM/OpenFOAM...icalProperties
https://github.com/OpenFOAM/OpenFOAM...icalProperties
So somewhere the basic understanding about the problem is lagging. The flow physics might look easy, but implementation in OpenFOAM requires some understanding.

Some homeworks to do:
1) What's your base solver ? I mean from which solver you built your customized solver ? Can you justify your choice about base solver and any references based on it.
2) Have you come across any references/journals related to your application in OpenFOAM ?
3) Create doxygen documentation. It's a good reference manual with source trees to easily understand the actual code.
4) If Steps 1 - 3 are clear, you need to copy necessary files/folders from OpenFOAM for your customized solver and resolve step by step. Use Debugger like gdb, nemiver to track your code and catch the flow. That's key !!

Honestly, it looks completely vague for now. More discussions will shape this work in a better way.
Thank you

Hi to both of you,

If I may interfere in the talk...

@Kumaresh: Alan doesn't use a customized solver, he uses the original chtMuliRegionFoam solver. His case is based on the heatExchanger tutorial (https://github.com/OpenFOAM/OpenFOAM.../heatExchanger) where 2 fluid regions are coupled together through the constantHeatTransfer source in fvOptions. It's a bit different from the usual chtMultiRegion cases.

@Alan: have you tried changing the mesh refinement in the radiator vicinity? I did not have time to check your case but I remember something similar happened in your simplified case. Or is it my memory failing me?

Regards,
Yann

Hello Yann,
Glad you interfered, Happy to interact. That's cool. I'm not aware of it. May be the name 'solid' region in his case file confused here. But in previous thread, Alan posted that the case has porous solid zone. Link below. It's better to follow strict convention names for solid and fluid regions appropriately.
https://www.cfd-online.com/Forums/op...tml#post827141
Thank you

Thanks Kummi and Yann!
 

To set the stage, I'm a design engineer, specifically in air vehicle preliminary design (hence my interest in CFD). Skill level in computer programming: just enough to use the tools needed to do design work.


Attached is a Powerpoint file showing the basic setup of my case. In my current case, the physical geometry in the fluid region body is much more complex than the shown in the schematic, although for the solid (porous zone) region, it remains a cuboid. Some of the boundary conditions in the chart have been overtaken by the ones in the GitHub posting.


I have a simplified case, similar to the Powerpoint one, which ran successfully. But in the complex case in question, it only runs when either the body in the fluid zone, or the solid zone radiator, are deleted. But it fails when both are present.


Yann, yes I have tried to increase the mesh fineness for the radiator, to no effect. Today I will increase the mesh fineness in the body adjacent to the radiator. Fingers crossed, to complete this madness. But since the case fails immediately, I am wondering.


Kummi, in answer to questions 1 -3:
1 - Yann answered
2 - There are examples extant using a shell and tube heat exchanger. But for a real radiator, the complexity of the geometry would be out of scope. So I am approximating real radiator details via the use of a porous zone. The idea is that once I have a running case, I can tweak the parameters to yield the performance characteristics of a real radiator. In short, I have not found any cases in the technical world, which take this approach.
3 - For debugging, my skills only suffices for me to create various iterations, from which I try to draw clues.


In any event, my thanks go out to you both! I am lucky to have this forum, and moreover generous people like yourselves in it.

Yann, I forgot that I had already made the fuselage mesh finer in the area of the radiator. In fact, I have 6 different refinement zones for the fluid region/fuselage that I made with curves and/or volumes, used to make the mesh finer in key areas.


However, meshing could still be the problem. At this point, I have nearly run out of things to try, given my lack of debugging skills.

thought I found the problem - but alas, not so
 

After looking through articles on porous zone heat exchangers, I found one that showed a cylindrical duct with a square porous zone that extended well beyond the cylinder walls. Aha!!, I aha'd. My case had a radiator with a net, line to line fit in the duct. All I had to do was extend the radiator so that it extended past the duct, into the unmeshed part of the domain. See attached image.


But when I attempted to run it, once again the same failure, 'exceeded maximum number of iterations,' came staring back at me. Note that the case runs okay with just the fluid region, with its fuselage and duct, and also runs okay with just the radiator. But when they are both present, utter failure.


Furthermore, a template case of mine, having the same setup, but with a greatly simplified body in the fluid region, also runs successfully. This makes no sense.


I am hoping for guidance on how I can finally conquer this problem.


Also attached is a complete run log of the latest failure.

The cause of the chtMultiRegion problem was symmetry! - but how to fix?
 

FINALLY!! Not total success, but I was able to make my case run. I did this by removing all of the 'symmetry' provisions, and just running the case as half of a fuselage flying through the air.


So it seems that way I implemented symmetry is problematic. I could just give up on it and include both sides of the geometry, but obviously that would be expensive in time and computing resources, so I need to understand what I did wrong. Here is one of the '0' BC files as an example; it shows the symmetry provision commented out.
In the 'symmetry' version that failed, there was a blockMeshDict in system/fluid and system/solid. In both, I had the 'rightSide' face as 'symmetry'. In the version without symmetry that ran, I changed it to 'patch.'



Also, in the runlog, there was this warning:
What is causing that? The complete runlog is attached. Also, here is a Dropbox link to the folder of the complete case:


https://www.dropbox.com/sh/z9absepcn...SmPW0Mz7a?dl=0


If I can get help with my symmetry issue, and the above FOAM warning, I can get this bearcat solved! - and go on with my life.

Found the fix for the "source ..... never used" FOAM warning, but still working on the symmetry problem. The drivaer simulation has 'symmetry' in the boundary conditions, but for the symmetry plane in blockMeshDict, calls it out as 'wall'. I'll give that a shot.