[julieng]

Hello,


I am new to Openfoam and I am interested in conjugate heat transfer.
I try to reproduce a 2D case p.81

"https://upcommons.upc.edu/bitstream/handle/2117/98893/REPORT_260.pdf?sequence=2&isAllowed=y"

It is one of the best step by step study that I found on the web concerning ChtMultiRegion preprocessing.



I have an error with the command changeDictionary:

--> FOAM FATAL ERROR:
cannot find file "C:/PROGRA~1/BLUECF~1/ofuser-of5/run/CHT/0/botWall/dictionaryReplacement"


It seems that I cannot generate the file dictionaryReplacement ...


Some help will be very much appreciated, can someone have a quick look on my case, I have add an Allrun file to manage the case.


Best regards


Julien

[julieng]

Ok I solve myself my problem.
I use blue-cfd-core 2017 so there is some difference with the refernce document.


Best regards

[wyldckat]

Quick note: The thesis you are following mentions that they used OpenFOAM 2.4 and blueCFD-Core 2017 provides OpenFOAM 5, therefore it's not as much as a limitation on blueCFD-Core as it is the changes in OpenFOAM itself since then.

At most, I expect that you might have some issues regarding the field names "K" colliding with "k", but that should not occur in blueCFD-Core, given that the "K" files are addressed to as "K_"... or at least they should be...


edit: I forgot to mention that when it doubt, please compare the tutorial cases that OpenFOAM provides in each version. For example:

• 2.4.x: https://github.com/OpenFOAM/OpenFOAM...ultiRegionFoam
• 5.x: https://github.com/OpenFOAM/OpenFOAM...ultiRegionFoam

[julieng]

Hello,


Thank you for your answer. I try now to modify the case. I simplify it with only 1 solid domain and region properties constant (not dependant of temperature).
I follow the same way the thesis and integrate some modifications in fvscheme and fvsolution according to "http://www.wolfdynamics.com/wiki/OFtipsandtricks.pdf".


Whitout these changes the simulation is stopped and I can't cleary see the ERROR message in the log:

Solving for fluid region botAir
Generating stack trace...


Backtrace:
        ZN10StackTraceC1Ev [0x705c1465+0x25]
                 module: C:\PROGRA~1\BLUECF~1\ThirdParty-5.x\platforms\mingw_w64GccDPInt32\lib\libstack_trace.dll
        ZN4Foam5error10printStackERNS_7OstreamE [0xff1c88+0x218]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\lib\libOpenFOAM.dll
        ZN4Foam6sigFpe13sigFpeHandlerEi [0xff2af3+0x33]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\lib\libOpenFOAM.dll
        (No symbol) [0x40468d]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\bin\chtMultiRegionSimpleFoam.exe
        _C_specific_handler [0x7ffdd1487c58+0x98]
                 module: C:\WINDOWS\System32\msvcrt.dll
        0_chkstk [0x7ffdd1e9f7dd+0x11d]
                 module: C:\WINDOWS\SYSTEM32\ntdll.dll
        RtlWalkFrameChain [0x7ffdd1e0d856+0x13f6]
                 module: C:\WINDOWS\SYSTEM32\ntdll.dll
        KiUserExceptionDispatcher [0x7ffdd1e9e70e+0x2e]
                 module: C:\WINDOWS\SYSTEM32\ntdll.dll
        ZN4Foam6divideERNS_5FieldIdEERKNS_5UListIdEES6_ [0xf97f65+0x25]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\lib\libOpenFOAM.dll
        ZN4Foam6divideINS_12fvPatchFieldENS_7volMeshEEEvRNS_14GeometricFieldIdT_T0_EERKS6_S9_ [0x6b6c57f0+0xb0]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\lib\libcompressibleTurbulenceModels.dll
        ZN4FoamdvINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldIdT_T0_EEEERKS8_RKS7_ [0x6b7190cf+0x26f]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\lib\libcompressibleTurbulenceModels.dll
        ZNK4Foam27CompressibleTurbulenceModelINS_11fluidThermoEE2nuEv [0x6b759aa7+0x37]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\lib\libcompressibleTurbulenceModels.dll
        ZNK4Foam13laminarModels6StokesINS_18ThermalDiffusivityINS_27CompressibleTurbulenceModelINS_11fluidThermoEEEEEE5nuEffEv [0x6b743e2f+0x4f]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\lib\libcompressibleTurbulenceModels.dll
        ZNK4Foam19linearViscousStressINS_12laminarModelINS_18ThermalDiffusivityINS_27CompressibleTurbulenceModelINS_11fluidThermoEEEEEEEE13divDevRhoReffERNS_14GeometricFieldINS_6VectorIdEENS_12fvPatchFieldENS_7volMeshEEE [0x6b756e5d+0x3d]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\lib\libcompressibleTurbulenceModels.dll
        (No symbol) [0x48638d]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\bin\chtMultiRegionSimpleFoam.exe
        (No symbol) [0x4013f7]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\bin\chtMultiRegionSimpleFoam.exe
        (No symbol) [0x40152b]
                 module: C:\PROGRA~1\BLUECF~1\OpenFOAM-5.x\platforms\mingw_w64GccDPInt32Opt\bin\chtMultiRegionSimpleFoam.exe
        BaseThreadInitThunk [0x7ffdcf453034+0x14]
                 module: C:\WINDOWS\System32\KERNEL32.DLL
        RtlUserThreadStart [0x7ffdd1e73691+0x21]
                 module: C:\WINDOWS\SYSTEM32\ntdll.dll

My file is attached if someone has some time to have a look.



Best regards

[wyldckat]

Quick answer: So, with a bit of experience it's possible to spot the following error blobs:

1. "ZN4Foam6sigFpe13sigFpeHandlerEi" -> sigFpe is mentioned in there. This means that an illegal mathematical operation occurred, usually a division by zero.
2. A bit below we can see:

   ZN4Foam6divideERNS_5FieldIdEERKNS_5UListIdEES6_

   so it was a division that went wrong...
3. Further below:

   ZNK4Foam27CompressibleTurbulenceModelINS_11fluidThermoEE2nuEv

   Compressible turbulence model went wrong... so something went wrong with the turbulence fields...
4. Uh... it's running as laminar, not as turbulent? I'm not familiar with the laminar implementation... so it is likely one of the other fields...
5. After unpacking the case and running Allrun, I got a similar error message on Linux and went looking at the field fields... and sure enough, there is a zero in the file "0/botAir/p":
   

       botAir_to_plate
       {
           type            calculated;
           value           uniform 0;
       }

   should be not zero:
   
   

       botAir_to_plate
       {
           type            calculated;
           value           uniform 1e5;
       }

6. After that I got an error on "system/botAir/fvSchemes", where this:
   

   laplacianSchemes
   {
           default Gauss linear limited;
   }

   is incomplete and should have a number next to "limited", e.g.:
   

   laplacianSchemes
   {
           default Gauss linear limited 1;
   }

7. After that I got yet another error in the set-up of the case... which I will leave it up to you, given that you are the one who needs the practice

[julieng]

Hello,

Thank you for your support. Yes you are right I need to pratice a lot.

point 4:I will modify my case for a turbulent flow in a future case test.

point 5: In the initial (Allrun is not execute) 0/botAir folder and other 0/folders, it is normal that I have no coherent values.
I use changeDictionary to update correctly the 0/folders (like it is done in the thesis).

point 6: You are right I have missed the numerical value

point 7: I will check again the BC

Why I need to calculate both "p" and "p_rhogh"? I have a look in some of the other tutorials and it seems that it is the only case where I found "p_rhogh" calculated. And in the solver files of the thesis and of the chtMultiRegion tutorials, only "p_rhogh" is calculated not "p"!
It is also srange for me that the unit dimensions of "p" and "p_rhogh" ([1 -1 -2 0 0 0] -> N/m2 or Pa) are not the same that "p" in other tutorials [0 2 -2 0 0 0] corresponding to "p/rho").


Best regards

[wyldckat]

Quick answers:

Originally Posted by julieng

Why I need to calculate both "p" and "p_rhogh"? I have a look in some of the other tutorials and it seems that it is the only case where I found "p_rhogh" calculated. And in the solver files of the thesis and of the chtMultiRegion tutorials, only "p_rhogh" is calculated not "p"!

To maintain consistency and ensuring the correct boundary conditions are used on both fields.

But it depends on the solver, so the sort-of simplest way is to check the source code... quoting from here: https://github.com/OpenFOAM/OpenFOAM...dFields.H#L171

    p_rghFluid.set
    (
        i,
        new volScalarField
        (
            IOobject
            (
                "p_rgh",
                runTime.timeName(),
                fluidRegions[i],
                IOobject::MUST_READ,
                IOobject::AUTO_WRITE
            ),
            fluidRegions[i]
        )
    );

    // Force p_rgh to be consistent with p
p_rghFluid[i] = thermoFluid[i].p() - rhoFluid[i]*ghFluid[i];

"p_rgh" is defined as "MUST_READ" and "p" is loaded by the thermodynamic model, which needs absolute pressure and absolute temperature to calculate the properties of the fluid...

This is something that there are plans to simplify this and only have one field that is truly necessary, so that sort of explains why you can find some solvers that only need one of the fields to start things with... but in other situations, the solvers simply don't use "p_rgh", e.g. simpleFoam.

Originally Posted by julieng

It is also srange for me that the unit dimensions of "p" and "p_rhogh" ([1 -1 -2 0 0 0] -> N/m2 or Pa) are not the same that "p" in other tutorials [0 2 -2 0 0 0] corresponding to "p/rho").

Search online with the following search string:

site:www.cfd-online.com/forums/openfoam pressure units

and it will give you several similar answers explaining why that is... unfortunately I didn't quickly find the best one...

Well, there is this FAQ entry: https://openfoamwiki.net/index.php/F...ble_solvers.3F - which essentially sums it up

[julieng]

Thank you for your support. It is a little bit clearer for me.



I have check my BC and there was a lot of errors in the thesis and mine also.
I don't understand all nuances for BC particularly for pressure BC but I think that now it is consistent.


My new problem is with kappaMethod in the T coupled BC compressible::turbulentTemperatureCoupledBaffleMix ed definition. I leave all the T coupled fluid and solid BC to :kappaMethod fluidThermo; and I have the following ERROR:

*** Reading solid mesh thermophysical properties for region plate

    Adding to thermos

Selecting thermodynamics package
{
    type            heSolidThermo;
    mixture         pureMixture;
    transport       constIso;
    thermo          hConst;
    equationOfState rhoConst;
    specie          specie;
    energy          sensibleEnthalpy;
}

    Adding to radiations

Radiation model not active: radiationProperties not found
Selecting radiationModel none
    Adding fvOptions

No finite volume options present

Time = 1


Solving for fluid region botAir
DILUPBiCG:  Solving for Ux, Initial residual = 1, Final residual = 0.000200286601, No Iterations 3
DILUPBiCG:  Solving for Uy, Initial residual = 1, Final residual = 0.000114932439, No Iterations 3


--> FOAM FATAL ERROR:
kappaMethod defined to employ fluidThermo method, but thermo package not available

    From function Foam::tmp<Foam::Field<double> > Foam::temperatureCoupledBase::kappa(const scalarField&) const
    in file turbulentFluidThermoModels/derivedFvPatchFields/temperatureCoupledBase/temperatureCoupledBase.C at line 171.

FOAM exiting

I change the T solid coupled BC for kappaMethod solidThermo and the simulation runs for 8 or 10 iterations and crashes. I think that I am close to a correct case, maybe I have to modify fvScheme and fvSolution, what do you think?


Best regards

[julieng]

Hello,


I modify a little bit the fvSolution and fvScheme according to tutorials and now the case runs well in single and parallel.
I am quite surprise when I see the results. I was thinking that the values that I fixe for T on BC "zeroGradient + value uniform 200" was only for initial values but it seems to fixe some Dirichlet constraints.




Do I have to withdraw all the values put in the Bondaryfield file? Where the initial condition on the whole domain is writed?

FoamFile
{
    version     2.0;
    format      ascii;
    class       volScalarField;
    location    "0/plate";
    object      T;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [ 0 0 0 1 0 0 0 ];

internalField   uniform 200;

boundaryField
{
    minX
    {
        type            zeroGradient;
        value           uniform 200;
    }
    maxX
    {
        type            zeroGradient;
        value           uniform 200;
    }
    defaultFaces
    {
        type            empty;
    }
    plate_to_botAir
    {
        type            compressible::turbulentTemperatureCoupledBaffleMixed;
        value           uniform 200;
        Tnbr            T;
        kappaMethod     solidThermo;
    }
    plate_to_topAir
    {
        type            compressible::turbulentTemperatureCoupledBaffleMixed;
        value           uniform 200;
        Tnbr            T;
        kappaMethod     solidThermo;
    }
}

[wyldckat]

Quick answer: Sorry, I won't have enough time in the next week or so to answer to the previous 2 posts you've made, so the my best suggestion is to take a side step and study a simpler example and work from there: https://openfoamwiki.net/index.php/G..._-_planeWall2D

Then do one step at a time towards the case you are trying to work on.

[julieng]

Hello,


Yes i have to do a new simpler example.


I understood that it is well initial BC no Dirichlet, for T on BC "zeroGradient + value uniform 200". It was my mistake.


I have plotted the convergence curves of my case with a command file I found on the forum:



set logscale y
set title "Residuals"
set ylabel 'Residual'
set xlabel 'Iteration'
plot "< cat log | grep 'Solving for Ux' | cut -d' ' -f9 | tr -d ','" title 'Ux' with lines,\
"< cat log | grep 'Solving for Uy' | cut -d' ' -f9 | tr -d ','" title 'Uy' with lines,\
"< cat log | grep 'Solving for h' | cut -d' ' -f9 | tr -d ','" title 'h' with lines,\
"< cat log | grep 'Solving for p_rgh' | cut -d' ' -f9 | tr -d ','" title 'p_rgh' with lines
pause 1






It seems very perturbated and my case is not fully converged. Results are also not smooth close to the coupled interface between solid and fluid.

Why the curves of Ux, Uy (2000 iterations) and later h (5000 iterations) are stopped ? It means that Ux,Uy and h are converged? I don't reach my tolerance 10-9... strange



My fvSolution file for U and h for the fluid domains



"(U|h)" -> What does it means U and h are solved in a coupling way?
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-9;
relTol 0.1;
minIter 3;
}


p_rgh
{
solver PCG;
preconditioner DIC;
tolerance 1e-9;
relTol 0.01;
}
SIMPLE
{
momentumPredictor yes;
nNonOrthogonalCorrectors 2;
pRefCell 0;
pRefValue 100000;
rhoMin rhoMin [1 -3 0 0 0] 0.2;
rhoMax rhoMax [1 -3 0 0 0] 2;




Maybe I need to use a more stable solver. Any advise on this point?


Best regards

[wyldckat]

Quick questions/answers:

1. Which specific solver are you using? chtMultiRegionFoam or chtMultiRegionSimpleFoam?
2. I don't trust that script code for getting the residual values. I suspect that it's either showing the values for all regions or showing the initial and final residuals in a single go. Please attach the log file of the solver that you ran, so that we can inspect what actually is going on.
3. I was intrigued that there were no tutorial examples, so here are a few quick steps:
   1. I used the tutorial case "heatTransfer/chtMultiRegionSimpleFoam/heatExchanger" on OpenFOAM 5.x.
   2. Added the following to the end of the file "system/controlDict":
      

      functions
      {
        region1
        {
          #includeEtc "caseDicts/postProcessing/numerical/residuals.cfg"
      
          fields (p_rgh U k epsilon);
      
          region air;
        }
      
        region2
        {
          #includeEtc "caseDicts/postProcessing/numerical/residuals.cfg"
      
          fields (p_rgh U k epsilon);
      
          region porous;
        }
      
      }

   3. Then I ran the script "Allrun-parallel".
   4. In a new terminal, I ran the following command, once the simulation started (I looked into the log file "log.chtMultiRegionSimpleFoam" to see when it actually started, because it takes a bit to start):
      

      foamMonitor -l postProcessing/air/region1/0/residuals.dat

   5. And in another terminal:
      

      foamMonitor -l postProcessing/air/region2/0/residuals.dat

   6. that way I could see both residuals evolving.
4. Since (I think) you are using blueCFD-Core, there is a fix for foamMonitor here: https://github.com/blueCFD/Core/issues/97
5. Convergence for stopping the simulation in a region is defined in the "fvSolution" for each region, within the "SIMPLE" or "PIMPLE" blocks.

6. Originally Posted by julieng

   "(U|h)" -> What does it means U and h are solved in a coupling way?

   that is not coupling, that is just a regular expression for assigning the same block settings to both "U" and "h". See the user guide: https://cfd.direct/openfoam/user-gui...7-1340004.2.11

[julieng]

It works perfectly,


Thank you very much!


Julien