[cfdhelp]

Hello,

I have a question about an Energy equation in the ANSYS Fluent.
I have a computational domain with combination of the forced flow and the natural circulation.
I am using a SIMPLE scheme for a pressure and a velocity coupling.
One fluid is a liquid metal and second is an air. In these regions are completely different velocities.
I want to know if there is one matrix for combination with fluid - solid - fluid for energy equation or is there some type of the coupling for the regions.
Maybe is there some type of the coupled matrix (some joined complex matrix from smaller matrixes ) fluid - solid - fluid regions ?
Can be this problem something like stiff equations ? (... matrix with a bad conditionality)
Is there any difference between the solution procedure in the Fluent and and in the OpenFOAM ?
If I checked the tutorial: chtMultiRegionFoam ... snappyMultiRegionHeater
...
Solution order
Solving for fluid region bottomAir ...
...
Solving for fluid region topAir
...
Solving for solid region heater
...
Solving for solid region leftSolid
...
Solving for solid region rightSolid
...

There is a first solutions for the fluid regions and than there are solutions for the solids.

Thank a lot for any comments,
Ivan

The chtMultiRegionFoam source C++ code bellow.
Is there first solved the fluid regions and than secondly the solid region ?
I think that yes. According to the C++ source code.

int main(int argc, char *argv[]) { #include "setRootCase.H" #include "createTime.H"
regionProperties rp(runTime);
#include "createFluidMeshes.H" #include "createSolidMeshes.H"
#include "createFluidFields.H" #include "createSolidFields.H"
#include "initContinuityErrs.H" #include "readTimeControls.H" #include "readSolidTimeControls.H"

#include "compressibleMultiRegionCourantNo.H" #include "solidRegionDiffusionNo.H" #include "setInitialMultiRegionDeltaT.H"
while (runTime.run()) { #include "readTimeControls.H" #include "readSolidTimeControls.H" #include "readPIMPLEControls.H"
#include "compressibleMultiRegionCourantNo.H" #include "solidRegionDiffusionNo.H" #include "setMultiRegionDeltaT.H"
runTime++;
Info<< "Time = " << runTime.timeName() << nl << endl;
if (nOuterCorr != 1) { forAll(fluidRegions, i) { #include "setRegionFluidFields.H" #include "storeOldFluidFields.H" } }

// --- PIMPLE loop for (int oCorr=0; oCorr<nOuterCorr; oCorr++) { bool finalIter = oCorr == nOuterCorr-1;
forAll(fluidRegions, i) { Info<< "\nSolving for fluid region " << fluidRegions[i].name() << endl; #include "setRegionFluidFields.H" #include "readFluidMultiRegionPIMPLEControls.H" #include "solveFluid.H" }
forAll(solidRegions, i) { Info<< "\nSolving for solid region " << solidRegions[i].name() << endl; #include "setRegionSolidFields.H" #include "readSolidMultiRegionPIMPLEControls.H" #include "solveSolid.H" }
}
runTime.write();
Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s" << " ClockTime = " << runTime.elapsedClockTime() << " s" << nl << endl; }
Info<< "End\n" << endl;
return 0; }

[arjun]

Unlike openFOAM , starccm, fluent (and my solver FVUS too) create single matrix and the interfaces are implicitly taken care.

As far as openfoam goes, I think there are some people who are working on removing this issue and creating a single matrix. More someone who is expert on openfoam can comment.

[LuckyTran]

As far as I know, Star-CCM and Fluent solves one big matrix. I was not aware that OF did not do this, that is interesting.

One big matrix is usually preferred since it keeps the fluid-solid coupling. But certainly the problem can become ill-conditioned at some conditions; it is always possible when you have a large matrix assembled from smaller matrices that each describe different physics. This is the same issue that coupled solvers have (i.e. segregated vs coupled in Star-CCM, pressure-based vs density based in Fluent, and rhopimplefoam vs rhocentralfoam in OF).

There is certainly some value in a segregated approach. One can imagine you do a coupled solver in one region, a simple sweep in another, a piso sweep in another. The advantage of this divide and conquer approach is you can tune your solver for each region to be optimum for that region. Solid conduction and natural convection usually has really small cells and needs small time-steps whereas forced advection problems tolerate large cells and large time-steps. Natural convection tends to be tough because the buoyancy is driven by coupling with the energy equation and heat transfer in natural convection is diffusion dominated and acts more like heat conduction than heat advection.

Single big matrices are nice when you have a simple system where it is easy to optimize the solver for the entire system. For multi-scale, multiphysics simulations there's usually some physics-based properties you can exploit in a segregated solver.

[arjun]

Originally Posted by LuckyTran

. I was not aware that OF did not do this, that is interesting.

In year 2015 I was about to add this into OF for one company in germany. But i moved from there so they might have hired someone to do it for them. I am not aware what happened in the end.

But they faced lots of problems because of this and they told me just because of this they were forced to use fluent.


This whole thing is not tough so i am not sure why it is not added into OF by now. May be someone will do it one day.

[cfdhelp]

Hello,

thanks a lot for your help and for the CFD software FVUS. I would like to try
this software.
Yes, I think too that there is only one huge matrix in the Fluent and for some type task it can be the cause of the problems "stiffens problem". Maybe for the combination of the forced flow in one domain and the natural flow in the second domain.
Again, thanks a lot for your comments.


Regards,
Ivan