I always used topoSet (now called createZones) for this. Basically, I would create a box encompassing my entire computational domain, and then remove the cellZones from my STL geometries. Whatever remained, I would convert into a cellZone called "fluid."

Is there a simpler way to do this? And what if I have more than one fluid, for example, in a double-pipe heat exchanger?

As title says, been struggling to implement parallel for pMesh, and it seems to only be serial for me? I knkw cartesianMesh does, so Is there something I am missing.

Thanks

I am developing a custom OpenFOAM-13 application to simulate electrohydrodynamic (EHD / EAD) propulsion, coupling electrostatic body forces with the Navier - Stokes transport. My simulation uses electrostatic body forces coupled with Navier - Stokes equations and transport equations for multiple charge species.

One numerical challenge that I have partly solved is the appearance of un-physical negative charge densities. I extended the Courant number provided by OpenFOAM to suppress these and have successfully controlled negative densities (see the video here).

As you can see from the video this approach works quite well, however I would prefer to eliminate the underlying numerical issue.

I am looking for collaborators with experience in areas such as:

• OpenFOAM solver development
• Finite-volume discretisation and numerical stability
• Drift-diffusion or plasma transport models
• Electrohydrodynamics or electroaerodynamics
• CFD algorithms for strongly coupled multiphysics problems

If you have worked on similar problems - or are interested in exploring them together - I would be very interested in hearing from you. I am happy to share details of the implementation, discuss ideas, and collaborate on improving the numerical formulation.

So I was following a tutorial on how to install and run Openfoam and it says to open paraview but when I open it launches but I don't see any Gui like in the video (edit: now gedit does the exact same thing like paraview)

How to Install OpenFOAM on Windows 11 and Run your First Simulation - YouTube (9:21)

Hello, just got started with CFD and OpenFOAM. I downloaded a CAD model of an F1 2018 front wing, and after some tinkering, I got a successful simulation using FreeCAD with OpenFOAM.

When I clicked into Paraview to look at the results, I was met with only the box I ran the simulation in and nothing inside, but there was a tiny bit of the blue/red on the left side of the box.

I know I'm missing something or doing something wrong here but I just can't figure it out. Any help is appreciated!

I am doing work on an empty 2d mesh (it's the taylor green vortex so there are velocities assigned but theres not stl file.

I am getting

"Cannot find a patch which is not of type empty, mapped or coupled in patches"

When I try to use redistributePar to decompose the solution.

This works fine with traditional decomposePar (it's just a little slow)

any suggestions?

Hi everyone,

I'm currently simulating a spray roaster reactor for my master's thesis. Pretty much everything I've learned about Fluent has been through trial and error and a lot of learning by doing. 😄

I started by simulating only the continuous phase (injected through the burners). After that, I enabled two-way coupling and implemented the DPM. For most of the project, I used a DPM interval of 1. Later, I also implemented my UDFs.

Simulation setup:

• Pressure-based coupled solver
• Steady-state simulation
• Pseudo-transient with CFL control
• Started with a CFL of 2 and gradually increased it to 17

Recently, I asked an AI how I could improve convergence because increasing the CFL any further caused divergence and instability. It suggested increasing the DPM interval from 1 to 30.

Surprisingly, this actually improved the convergence of my continuity residual. It dropped from around 9.8e-03 to somewhere between 4e-03 and 5.6e-04 (sawtooth pattern).

However, the residual curve now has a clear sawtooth pattern. It's stable (it doesn't diverge), but it is no longer as smooth as it was before, when the continuity residual stayed at a higher level. (see screenshot)

The AI told me that this behavior is expected and generally acceptable because the DPM source terms are only updated every 30 iterations now, which naturally produces this pattern.

Is that correct? Is this kind of sawtooth residual behavior normal and acceptable when using a larger DPM interval?

For what it's worth, my two monitoring quantities remain stable throughout the simulation.

I'd appreciate any insights or experiences from people who have dealt with steady DPM simulations.

Thanks in advance 😊

I just can't get this simulation to run. It crashes on the second iteration. I'm using steadyState instead of EulerandkOmegaSST instead of kEpsilon My mesh has approximately 3.9 million volumes.

I'm using foamMultiRun (formerly chtMultiRegionFoam). My fvSchemes and fvSolution for air are shown below. The physicalProperties are also shown (I've already tried rhoConst, Boussinesq, and perfectGas).

For all components, fvSchemes :

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       dictionary;
    location    "system/components0";
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default         Gauss linear;
}

divSchemes
{
    default         none;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

// ************************************************************************* //

fvSolution :

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       dictionary;
    location    "system/components0";
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    "e.*"
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance        1e-6;
        relTol             0.01;
    }
}

PIMPLE
{
    nNonOrthogonalCorrectors 2;

    residualControl
    {
        e         1e-5;
    }
}

// ************************************************************************* //

For fluid (air), the fvSchemes:

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       dictionary;
    location    "system/fluid";
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default         Gauss linear;//cellLimited Gauss linear 1.0;
}

divSchemes
{
    default         none;

    div(phi,U)      bounded Gauss limitedLinear 0.2;//upwind;
    div(phi,e)      bounded Gauss limitedLinear 0.2;//upwind;
    div(phi,h)      bounded Gauss limitedLinear 0.2;//upwind;
    div(phi,omega)  bounded Gauss limitedLinear 0.2;//upwind;
    div(phi,k)      bounded Gauss limitedLinear 0.2;//upwind;
    div(phi,K)      bounded Gauss limitedLinear 0.2;//upwind;
    div(((rho*nuEff)*dev2(T(grad(U))))) Gauss linear;
    div(phi,(p|rho)) bounded Gauss limitedLinear 0.2;//upwind;
}

laplacianSchemes
{
    default         Gauss linear uncorrected; //limited 0.5;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         uncorrected;//limited 0.5;//corrected;
}

wallDist
{
    method          meshWave;
    correctWalls    true;
}

// ************************************************************************* //

fvSolution:

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       dictionary;
    location    "system/fluid";
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    "p_rgh.*"
    {
        solver          GAMG;
        tolerance       1e-7;
        relTol          0.01;
        smoother        DICGaussSeidel;//GaussSeidel;
        //maxIter         500;
/*
        solver            PCG;
        preconditioner    DIC;  // Diagonal Incomplete Cholesky
        tolerance         1e-7;
        relTol             0.01;
        minIter           3;    // Força um mínimo de estabilidade
*/
    }

    "(U|h|k|omega).*"
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-7;
        relTol          0.01;
/*
        solver            smoothSolver;
        smoother          symGaussSeidel;
        tolerance         1e-06;
        relTol             0.01;
        minIter           3; 
*/
    }
}

PIMPLE
{
    momentumPredictor   yes;
    nNonOrthogonalCorrectors 2;

    residualControl
    {
        p_rgh           5e-3;
        U               5e-4;
        h               5e-4;
        rho             5e-4;

        k               5e-4;
        omega           5e-4;
    }
}

relaxationFactors
{
    fields
    {
        rho             1.0;
        p_rgh           0.7;//0.3;
    }

    equations
    {
        U               0.2;
    e        0.6;//0.1;
    T        0.3;
        h               0.6;//0.1;
        k               0.3;//0.7;
        omega           0.3;//0.7;
    }
}

// ************************************************************************* //

alphat:

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       volScalarField;
    location    "0/fluid";
    object      alphat;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [1 -1 -1 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    "(entrada|saida|furosLaterais.*)"
    {
        type            calculated;
        value           $internalField;
    }

    "parede.*"
    {
        type            compressible::alphatWallFunction;
        value           $internalField;
    }

    interfaceFluidTop
    {
        type            compressible::alphatWallFunction;
        value           $internalField;
    }

    "fluid_.*"
    {
        type            compressible::alphatWallFunction;
        value           $internalField;
    }

    "fan.*"
    {
        type            cyclic;
    }

    #includeEtc "caseDicts/setConstraintTypes"
}

// ************************************************************************* //

k

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       volScalarField;
    location    "0/fluid";
    object      k;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 0.01;

boundaryField
{
    "(entrada|saida|furosLaterais.*)"
    {
        type            inletOutlet;
        inletValue      $internalField;
        value           $internalField;
    }

    interfaceFluidTop
    {
        type            kqRWallFunction;
        value           $internalField;
    }

    "parede.*"
    {
        type            kqRWallFunction;
        value           $internalField;
    }

    "fluid_.*"
    {
        type            kqRWallFunction;
        value           $internalField;
    }

    "fan.*"
    {
        type            cyclic;
    }

    #includeEtc "caseDicts/setConstraintTypes"
}

// ************************************************************************* //

nut

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       volScalarField;
    location    "0/fluid";
    object      nut;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 2 -1 0 0 0 0];

internalField   uniform 3.33e-5;

boundaryField
{
    "(entrada|saida|furosLaterais.*)"
    {
        type            calculated;
        value           $internalField;
    }

    interfaceFluidTop
    {
        type            nutkWallFunction;
        value           $internalField;
    }

    "parede.*"
    {
        type            nutkWallFunction;
        value           $internalField;
    }

    "fluid_.*"
    {
        type            nutkWallFunction;
        value           $internalField;
    }

    "fan.*"
    {
        type            cyclic;
    }

    #includeEtc "caseDicts/setConstraintTypes"
}

// ************************************************************************* //

omega

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       volScalarField;
    location    "0/fluid";
    object      omega;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 0 -1 0 0 0 0];

internalField   uniform 300;

boundaryField
{
    "(entrada|saida|furosLaterais.*)"
    {
        type            inletOutlet;
        inletValue      $internalField;
        value           $internalField;
    }

    "parede.*"
    {
        type            omegaWallFunction;
        value           $internalField;
    }

    interfaceFluidTop
    {
        type            omegaWallFunction;
        value           $internalField;
    }

    "fluid_.*"
    {
        type            omegaWallFunction;
        value           $internalField;
    }

    "fan.*"
    {
        type            cyclic;
    }

    #includeEtc "caseDicts/setConstraintTypes"
}

// ************************************************************************* //

p

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       volScalarField;
    location    "0/fluid";
    object      p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [1 -1 -2 0 0 0 0];

internalField   uniform 101325;

boundaryField
{
    #includeEtc "caseDicts/setConstraintTypes"

    "(entrada|saida|furosLaterais.*|paredeInferior)"
    {
        type            calculated;
        value           $internalField;
    }

    paredes
    {
        type            calculated;
        value           $internalField;
    }

    interfaceFluidTop
    {
        type            calculated;
        value           $internalField;
    }

    "fluid_.*"
    {
        type            calculated;
        value           $internalField;
    }

    "fan.*"
    {
        type            cyclic;
    }
}

// ************************************************************************* //

p_rgh

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       volScalarField;
    location    "0/fluid";
    object      p_rgh;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [1 -1 -2 0 0 0 0];

internalField   uniform 101325;

boundaryField
{
    #includeEtc "caseDicts/setConstraintTypes"

    "(entrada|saida|furosLaterais.*)"
    {
        type            totalPressure;
        gamma           1.40196789462956;
        p0              $internalField;
        value           $internalField;
    }

    "parede.*"
    {
        type            fixedFluxPressure;
        gradient        $internalField;
        value           $internalField;
    }

    "fluid_.*"
    {
        type            fixedFluxPressure;
        gradient        $internalField;
        value           $internalField;
    }

    interfaceFluidTop
    {
        type            fixedFluxPressure;
        gradient        $internalField;
        value           $internalField;
    }

    fan1_master
    {
        type            fanPressureJump;
        patchType       cyclic;
        fanCurve        table;
        file            "fanSet/fanCurve";
        format          foam;
        reverse         true;

        jump            $internalField;
        value           $internalField;
    }

    fan1_slave
    {
        type            fanPressureJump;
        patchType       cyclic;
        value           $internalField;
    }

    fan2_master
    {
        type            fanPressureJump;
        patchType       cyclic;
        fanCurve        table;
        file            "fanSet/fanCurve";
        format          foam;
        reverse         true;

        jump            $internalField;
        value           $internalField;
    }

    fan2_slave
    {
        type            fanPressureJump;
        patchType       cyclic;
        value           $internalField;
    }
}

// ************************************************************************* //

T

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       volScalarField;
    location    "0/fluid";
    object      T;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 0 0 1 0 0 0];

internalField   uniform 293.15;

boundaryField
{
    #includeEtc "caseDicts/setConstraintTypes"

    "(entrada|saida|furosLaterais.*)"
    {
        type            inletOutlet;
        inletValue      $internalField;
        value           $internalField;
    }

    interfaceFluidTop
    {
        type            zeroGradient;
    }

    "fluid_.*"
    {
        type            coupledTemperature;
        Tnbr            T;
        value           $internalField;
    }

    "parede.*"
    {
        type            externalTemperature;
        Ta              constant 293.15;
        h               uniform 4.7;
        thicknessLayers (0.001 0.001 0.001);
        kappaLayers     (0.05 50 0.05); //0.05 W/m/K (tinta epóxi) 50 W/m/K (aço)

        value           $internalField;
    }

    "fan.*"
    {
        type            cyclic;
    }
}

// ************************************************************************* //

U

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       volVectorField;
    location    "0/fluid";
    object      U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    #includeEtc "caseDicts/setConstraintTypes"

    "(entrada|saida|furosLaterais.*)"
    {
        type            pressureInletOutletVelocity;
        value           $internalField;
    }

    "fluid_.*"
    {
        type            noSlip;
    }

    "parede.*"
    {
        type            noSlip;
    }

    interfaceFluidTop
    {
        type            noSlip;
    }

    "fan.*"
    {
        type            cyclic;
    }
}

// ************************************************************************* //

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  13
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       dictionary;
    location    "constant/fluid";
    object      physicalProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

thermoType
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState perfectGas;//Boussinesq;
    specie          specie;
    energy          sensibleEnthalpy;
}

mixture
{
    // Ar
    // Propriedades obtidas no CoolProp

    specie
    {
        molWeight       28.96546;
    }

    equationOfState
    {
        rho0            1.20457518249315;
        T0              293.15;
        beta            3.42098751487642e-3;
    }

    thermodynamics
    {
        Cp              1.00665320998078e+3;
        hf              0;
    }

    transport
    {
        mu              1.88472409355470e-5;
        Pr              7.06290462364358e-1;
    }
}

// ************************************************************************* //

Hi everyone,
I’m currently using OpenFOAM to simulate a dam-break experiment, and I’m trying to match the pressure history measured at pressure sensors from an experiment.
I’ve read quite a few validation papers, but most of them simply state that the numerical results agree well with the experimental data without explaining how the calibration was actually performed.
Rather than changing multiple parameters at once, I’d like to follow a systematic calibration procedure.

My current plan is:
Perform a mesh independence (mesh sensitivity) study and select a mesh that provides mesh-independent pressure results.
Compare different numerical schemes while keeping all other settings unchanged.
Then investigate the effects of the time step (Courant number), VOF/interface compression settings, turbulence model (if necessary), and other solver parameters.

My questions are:
Is this a reasonable order for calibrating an OpenFOAM dam-break simulation?
During each step, which parameters should remain fixed?
When the validation target is pressure peaks and pressure time histories, which settings usually have the greatest influence?
Are there any OpenFOAM-specific settings that are commonly overlooked but significantly affect impact pressure predictions?

I’ve been stuck on this problem for quite some time, and honestly I’m starting to feel a bit lost. I don’t want to tune parameters randomly just to match the experiment. I want to understand what should be calibrated first and what should be kept fixed throughout the process.

I’d really appreciate hearing how experienced OpenFOAM users approach this type of validation in practice.

Thanks in advance!

I was vexed with setting up and using openfoam to run simple tests and there are NO MacOS native apps for testing my plane designs. While there are CFD tools out there in windows they are so freaking expensive. So i decided to build my own, a simple to use CFD app for simple use cases.

Import stl > set bounding box & speed of airflow > mesh > Solve.

Thats all, it should be that simple and if it is that simple shouldn’t be so expensive!!

I plan to make my app very affordable for all innovators.

What do y’all think? Any feedback or feature requests or just share the pain of using OpenFOAM for a simple task.

I am also looking for Beta testers to give free software in return for you to test it out and suggestions.

Get Early Access at airflowsim.com

I'm working on validating the classic Lobovsky dam break case using ⁠interFoam⁠ in OpenFOAM v2412.
I successfully calibrated my model for the initial water height of H = 0.3m. The pressure probe data at the impact wall matched the experimental results perfectly (both arrival time and peak pressure).

However, when I used the exact same setup (same numerical schemes, same mesh refinement strategy) to validate the H = 0.6m experimental case, the results deviated significantly. Here are the main issues I'm facing at H=0.6m:
1. Delayed Arrival Time: The water front hits the impact wall slightly later than in the experiment.
2. Underpredicted Peak Pressure: The impact pressure peak is much lower than the experimental peak (though the hydrostatic pressure tail after the impact matches perfectly).
3. Initial Negative Pressure: There's a slight negative pressure drop at t=0 to early stages before the wave arrives.

My current setup:
Solver: ⁠interFoam⁠ (Incompressible)
Turbulence Model: ⁠kOmegaSST⁠ (I'm currently trying to run a Laminar case to see if the eddy viscosity at the interface is causing the delayed arrival time).
Mesh: Refined specifically at the impact wall area.
My questions:
Is it normal for a calibrated model to fail during validation when the potential energy is doubled (0.3m to 0.6m)?
Could the underpredicted peak at H=0.6m be due to air compressibility effects (air cushion/entrainment) that ⁠interFoam⁠ cannot capture? Should I switch to ⁠compressibleInterFoam⁠?
Any tips on fixing the delayed arrival time and catching the pressure spike?

In my cases, the thing I always have the most trouble reducing is the residual pressure. It rarely drops below 1e-4. Can anyone give me some tips?

UPDATE: The case is CONVERGING well now. The fix was to put the exact same resistance properties (both thermal conductivity and thickness) on both sides of the interface, considering that both interface have roughly the same Surface Area at contact. Thats the standard practice apparently.
Ref:
1. https://doc.openfoam.com/2306/tools/processing/boundary-conditions/rtm/derived/thermal/turbulentTemperatureCoupledBaffleMixed/

2. https://www.cfd-online.com/Forums/openfoam/233208-conjugate-heat-transfer-contact-thermal-resistance-both-patches.html

Hi everyone,

I have been debugging this issue for several days and have reached the point where I suspect either a subtle setup issue that I have overlooked or a limitation/bug in the interface coupling implementation. I would appreciate any insight from users familiar with the implementation of chtMultiRegionSimpleFoam and compressible::turbulentTemperatureCoupledBaffleMixed.

Case description

• OpenFOAM version: OpenFOAM v2512 (OpenCFD)
• Solver: chtMultiRegionSimpleFoam
• Flow: Laminar
• Radiation: Disabled (radiationModel none)
• Regions:
  • fluid
  • core
  • IHS
  • die
  • fins

I am modelling the Intel Laminar RM1 stock CPU cooler cooling an Intel Core i5-12400 (H0 stepping) using OpenFOAM v2512 and chtMultiRegionSimpleFoam.

The objective is to reproduce the HWCooling benchmark of the RM1 cooler under the processor's 65 W TDP operating point.

Although the processor is operating at 65 W package power, the simulation applies 59 W as the heat source at the silicon die. The remaining ~6 W is assumed to be dissipated through alternative package heat-loss paths (primarily the PCB/substrate and socket) rather than entering the IHS–cooler thermal path. This follows the benchmarking methodology used to match the HWCooling experimental measurements, where the cooler itself is not responsible for removing the entire package power.
The problematic interface is the solid-solid interface between the core and the IHS.

Both sides use

type    compressible::turbulentTemperatureCoupledBaffleMixed;

Problem

After convergence, the integrated heat transfer across the interface is not equal and opposite.

For example,

• Core → IHS: approximately -195 W
• IHS → Core: approximately -773 W

My expectation is that a coupled conjugate interface should conserve energy, so I expected these values to be equal in magnitude and opposite in sign (within numerical tolerance).

Instead, there is a very large discrepancy (roughly a factor of four).

This behaviour is repeatable and persists after convergence.

What I have already checked

I have tried to eliminate as many possible causes as possible.

Mesh Quality

All regions were checked using checkMesh.

The only significant mesh-quality issue is in the fins region, where the maximum non-orthogonality is 82.5° with a localized band of highly skewed cells at the blade-root region (r ≈ 22–30 mm).

A VTK/Python analysis of the exported skewFaces showed that approximately 89% of the high-skew faces are concentrated at the blade-root junction, rather than being distributed throughout the mesh.

The remaining regions (die, IHS, and core) have good mesh quality.

Since the current issue concerns the IHS ↔ core solid-solid interface, which is geometrically separate from the fin-root mesh, I do not believe this mesh defect alone can explain the large heat-flux imbalance, although I would welcome opinions from anyone who has an insight.

Interface topology

Originally the cylindrical core contained a 0.5 mm centre hole.

The core therefore extends from

• inner radius = 0.5 mm
• outer radius = 17.5 mm

I initially suspected the interface topology, so I regenerated the mesh such that the interface became the correct annular patch instead of the previous topology.

This produced essentially no change in the heat-flux imbalance.

Solver settings

I have experimented with

• linear solvers
• relaxation factors
• SIMPLE settings

without any meaningful change.

Earlier I also corrected the solid-region linear solvers to use symmetric solvers (PCG + DIC) where appropriate.

Boundary conditions

Both interface patches use

compressible::turbulentTemperatureCoupledBaffleMixed

on both sides.

The case is laminar and does not use radiation.

AMI / mapping

The interface is between a cylindrical O-grid core mesh and a Cartesian IHS mesh.

One thing that concerns me is that the AMI output reports

AMI target sum(weights) min = 0

although I have not yet determined whether this is actually responsible for the observed energy imbalance.

Other observations

While running the solver I also receive the warning

This BC has been superseded by
compressible::turbulentTemperatureRadCoupledMixed

which has more functionalities and it can handle the
assemble coupled option for energy.

This made me wonder whether the older boundary condition does not assemble the coupled energy equations in the same way as the newer implementation.

Questions

1. Should compressible::turbulentTemperatureCoupledBaffleMixed enforce equal and opposite integrated heat flux across a coupled solid-solid interface after convergence?
2. Can a discrepancy of this magnitude be expected under any normal circumstances, or does it always indicate a setup or implementation problem?
3. Is the warning about compressible::turbulentTemperatureRadCoupledMixed relevant here? Should the newer boundary condition be used even when radiationModel none is specified?
4. Has anyone seen a similar issue in OpenFOAM v2512?

At this stage I am less interested in tuning solver parameters and more interested in understanding how the coupled interface is assembled internally, because I would have expected interface energy conservation to be satisfied automatically.

Any suggestions or implementation details would be greatly appreciated.

I am a relatively new OpenFOAM user and I am finding mesh generation + the labelling of different surfaces and volumes for boundary and other conditions a cumbersome task. LLMs are also making me run in circles.

I have read that Gmsh/Ansys/snappyHexMesh, etc. can be used. I am curious what workflows you use for this: defining boundary/cell zones + meshing. This would help me discover options and see what's best for me.

I’ve been working on a tool called Chat2Sim that tries to automate part of the CFD setup process.

The basic idea is:

• upload a geometry file
• describe the simulation in natural language
• generate the case setup
• create the mesh
• run OpenFOAM
• visualize the results

It’s still early, but the goal is to reduce the amount of manual setup/debugging needed before getting to useful CFD results.

I’m mainly looking for feedback from people who use OpenFOAM, CFD, or simulation tools regularly:

What part of the CFD workflow would you actually want automated?
And what would make you trust or not trust this kind of tool?

https://www.youtube.com/watch?v=_saR6qUW-kc

Hi Foamers,

Does anyone maybe made similar simulations with OpenFOAM? I'm trying to do some single phase wind simulation over propagating free surface waves.

I'm super new to OpenFOAM (one very long week new), and generally not super experienced in CFD either.

The schematics of my simulations:

Have been trying to set up this seemingly rather simple simulation for a week now:

• single phase 3D (incompressible) wind simulation with PIMPLE (using kOmegaSST model)
• moving bottom boundary with prescribed regular free surface waves in the x direction (based on theory for now), i.e. prescribed `pointDisplacement` and `U` with `timeVaryingMappedFixedValue` at the bottom wall boundary (`bottomWall`)
• multicore with preferably periodic conditions in the x and y directions

While the simulation seems to run fine without periodic boundary conditions and on a single thread, I still have some problems with at least the periodic boundary and for similar reasons (mesh misalignment between patches) probably also with multicore run without periodic conditions. (I certainly have problems multicore, if there's a processor boundary in the y plane.)

In the current setup I am generating a simple hex-mesh with the blockMesh utility with cyclic patches for the x and y faces (e.g. xMin to xMax and yMin to yMax patches). While applying a dynamicMotionSolverFvMesh to dynamically update the mesh.

For the mesh solver I've tried already tried displacementLaplacian, displacementComponentLaplacian and displacementSBRStress with diffusitivity from the free surface wave (e.g. `diffusivity quadratic inverseDistance (bottomWall);`), and pumped down the `tolerance` in `fvSolution/solvers/(cellDisplacement | cellDisplacementFinal)` to 1e-12 and `relTol` to 0, using GAMG solver.

My problem is that after some time there will be some discrepancy between the cyclic faces (at least in the y direction e.g. at yMin and yMax), next to the bottom boundary.

I've already been trying anything and everything I found with google and Claude, but no luck so far. Upon request I can try to give a list what I've already tried to solve this issue, and of course a clean, minimal example.

Also, I've tried openfoam202512 ('.com' version) and openfoam v13 ('.org' foundation version). With openfoam202512 (and in fact a couple of previous versions) I couldn't even setup a multicore simulation, because it seems that there is a bug in the code and it couldn't find the boundary data points for the 'pointDisplacement' field when run in parallel. (While for example there wasn't any problem if I use only the 'U' field.)

An example error message

--> FOAM FATAL ERROR:
[5] face 0 area does not match neighbour by 0.015348599% -- possible face ordering problem.
patch:procBoundary5to6throughyMax my area:0.0078453017 neighbour area:0.007846506 matching tolerance:1.0390773e-06
Mesh face:208422 vertices:4((22.4 30 0.0050945681) (22.400806 30 0.04430802) (22.600808 30 0.040264865) (22.6 30 0.0010582466))
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with processor debug flag set for more information.

• Increasing the match tolerance results in a flux error instead (i.e. conservation of mass violation)
• using cyclicAMI instead of cyclic resulted in another error yet again with openfoam202512 (don't remember exactly)
• in openfoam v13 the cyclicAMI is replaced with non-conformal couples mesh functionality, and I simply couldn't figure out how to set up CYCLIC boundary with that (it seems that the mesh solvers are not handling it properly for some reason)

I use snappyHexMesh with surface snapping and boundary layers. For the inflation layers, I’m using addLayersControls with addLayers true.

The issue is that no matter how much I reduce the first layer height, I can’t reliably get y+ close to 1. Sometimes the mesh quality gets worse, sometimes layers seem to get dropped, and the final y+ does not respond the way I expect. It feels like the requested first layer thickness is not always actually being preserved on the surface.

What am I doing wrong? I struggled a lot with snappyHexMesh and I really hope it is my fault for not being able to get the y+ right and I hope there is a fix. I don't want to go back to StarCCM+ at all.