[macRC]

Hello Forum,

I want to simulate an electronics cooling problem. You can find a sketch of the domain attached. 3 LEDs (which are in a thermal view just a heat source) are mounted on a board (PCB - Printed Circuit Board). Between the LEDs and the board are two thin layers, one copper layer and one dielectric layer. These two layers are thermally important.
The PCB "floats" in an air region.

Thus lends itself to the chtMultiRegionSolver.

I have already pre-processed this simulation using OpenFOAM 4.1 on a Suse-Linux machine. The case file can be found on the link below and is ready for simulation.
Mesh was created in Starccm and imported to OpenFOAM via ccm26ToFoam (to run the simulation on your machine, you don´t have to install this utility as I already did). So you should be able to run this simulation just by activating the Allrun-script as usual.

Unfortunately - of course - I have problems with poor convergence. Even if the simulation runs for several days, I can only reach residuals ~ 0,02 for some parameters, like pressure. Depending on the geometry, sometimes the convergence is even worse (with very low relaxation factors).

I played around with several parameters, but without success in improving the convergence.



So my question is, how can I improve this simulation in order to get better convergence?

Thanks a lot in advance for your help.
With pleasure I can give you more information.

Best regards




Here you can download the zipped case-file:
https://1drv.ms/u/s!AsWYOz7IwhuKja9F11GrSlylwCk-Tg

[student666]

Hi, have you checked your mesh? have you already run checkMesh -allTopology -allGeometry? Maybe it can gives you hints where to start to look for a solution. Is your solution mesh dependent? Have you refined? Have you tried different bc's?have you set a probe to check if some physical variable (temperature) reaches a steady value? Roughly speaking, residuals give an idea how much your calculation converge, but some times even if you have very low residuals it does not mean that your simulation has a physical meaning...

Further, let's say you want to keep a value for the T field on some boundary not over a limit, what is your tollerance 0,0001℃ or 5℃? Is it really important?how much?

These are questions I always ask myself when I have to run a case...

Hope it can helps.

Regards.

Sent from my ASUS_X008D using CFD Online Forum mobile app

[student666]

This is a partial output from checkMesh command:

Checking geometry...
    Overall domain bounding box (-0.13500001 0 -0.125) (0.115 0.2 0.125)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (-5.6675828e-17 -2.0275043e-16 6.1828176e-17) OK.
    Max cell openness = 2.2154147e-16 OK.
    Max aspect ratio = 16.911564 OK.
    Minimum face area = 3.0243927e-11. Maximum face area = 9.4663958e-05.  Face area magnitudes OK.
    Min volume = 4.9860945e-15. Max volume = 1.6854708e-06.  Total volume = 0.012500001.  Cell volumes OK.
    Mesh non-orthogonality Max: 78.606195 average: 14.151239
   *Number of severely non-orthogonal (> 70 degrees) faces: 30.
    Non-orthogonality check OK.
  <<Writing 30 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 3.1169794 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

This is a partial output from

checkMEsh -allTopology -allGeometry

Checking geometry...
    Overall domain bounding box (-0.13500001 0 -0.125) (0.115 0.2 0.125)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (-5.6675828e-17 -2.0275043e-16 6.1828176e-17) OK.
    Max cell openness = 2.2154147e-16 OK.
    Max aspect ratio = 16.911564 OK.
    Minimum face area = 3.0243927e-11. Maximum face area = 9.4663958e-05.  Face area magnitudes OK.
    Min volume = 4.9860945e-15. Max volume = 1.6854708e-06.  Total volume = 0.012500001.  Cell volumes OK.
    Mesh non-orthogonality Max: 78.606195 average: 14.151239
   *Number of severely non-orthogonal (> 70 degrees) faces: 30.
    Non-orthogonality check OK.
  <<Writing 30 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 3.1169794 OK.
    Coupled point location match (average 0) OK.
 ***Error in face tets: 736 faces with low quality or negative volume decomposition tets.
  <<Writing 730 faces with low quality or negative volume decomposition tets to set lowQualityTetFaces
   *Edges too small, min/max edge length = 1.1601697e-07 0.0084498897, number too small: 2
  <<Writing 2 points on short edges to set shortEdges
  <<Writing 303340 near (closer than 4.0620193e-07 apart) points to set nearPoints
   *There are 1397 faces with concave angles between consecutive edges. Max concave angle = 89.744921 degrees.
  <<Writing 1397 faces with concave angles to set concaveFaces
    Face flatness (1 = flat, 0 = butterfly) : min = 0.71591694  average = 0.98842403
   *There are 80 faces with ratio between projected and actual area < 0.8
    Minimum ratio (minimum flatness, maximum warpage) = 0.71591694
  <<Writing 80 warped faces to set warpedFaces
    Cell determinant (wellposedness) : minimum: 0.012127452 average: 184.26317
    Cell determinant check OK.
 ***Concave cells (using face planes) found, number of cells: 368763
  <<Writing 368763 concave cells to set concaveCells
    Face interpolation weight : minimum: 0.01432908 average: 0.45251457
 ***Faces with small interpolation weight (< 0.05) found, number of faces: 6
  <<Writing 6 faces with low interpolation weights to set lowWeightFaces
    Face volume ratio : minimum: 0.0018523896 average: 0.68625844
 ***Faces with small volume ratio (< 0.01) found, number of faces: 54
  <<Writing 54 faces with low volume ratio cells to set lowVolRatioFaces

Failed 4 mesh checks.

End

Next comes from my experience with OF, truly speaking I'm still a beginner, so these are my personal thoughts, ok?!? I don't want to insult anybody!!!
If you work with not open-source software...you generate the mesh with tools that are native for each solver; It means that SW houses always adapt their routines solver to work with their own mesh generators: they know where they have problems, they know where to improve, how to get convergence...so at the end, you can "easly" get to an output, that seems correct.
OF gives you the possibility to reuse other meshes geneated by other tools, but it does not means that this will surely works!
Infact, OF works well with structured (blockMesh) and hexahedral (SHM). If you take a look to cases where meshes are imported in some tutorials, you will see that generated meshes are (most of the cases) made of perfect hexahedral, so they work as they respect OF rules!
I suggest you to switch from other friendly user interface mesh generators and move to native OF tools for mesh generation; it will makes you spit blood! But what a pleasure when it works as you wish...

Regards.

[Tobi]

Dear student666,

I cannot agree with your sentence that FOAM works best with hexaedral meshes. Of course it is true but for each FVM solver based on the numerics and that is all you have to consider. By the way, snappyHexMesh never produces pure hexaedral meshes. It would be too good if that would be true. You ever meshed complex geometries with snappyHexMesh? Yes? If so, you should realize that sHM generates the following cells:

• hexaedrals
• prisms
• wedges
• polygones
• tetraedra
• tet wedges
• pyramids

Furthermore, if the thread starter did everything correct and set up the case for CHT, you should not check the mesh with your command. Here, the important attribute is missing:

checkMesh -region xyz

You might be correct with your hypothesis of closed or black box software package which have their own mesher. However, I think it is more about understanding the numerics and the mathematical system and apply the knowledge correctly. I agree that the mesh has first priority but even with a good mesh and no knowledge about the numerics, the simulation can blow up based on wrong set-up in FOAM.



By the way I also checked your case. The mesh seems to be okay but I prefer the hex-dominant meshes from snappyHexMesh. However, modeling such small parts is not a good choice (in my opinion). It is like macroscopic - microscopic mixture. Personally, I would suggest you to think about that again but if you want to keep it, you should definitely improve your numerical system and rethink your boundary conditions (e.g. your T BC does not make sense if you have backflow; or you relax p in fields and equations - funny! especially because you use ".*").

My first suggestion is: use my laserConvectionBC and remove the whole air part. Done. It is just heat transfer between the solids + appropriate BC. I even added polynomial approximation for HTC-eff which could include radiation. The implementation of the radiation term is not so difficult but I have not time for that.

My second suggestion: use sHM to create your mesh or reduce the air-domain cells dramatically. 1205657 cells for what? In addition, if you really want to have a good resolution of your problem, you should refine the interfaces (Fluid - Solid) in a way that the thermal boundary layer is resolved. This influences the heat-transfer extremely. So be aware of all that. Therefore, it might be better to approximate / model the HT from the solid to the fluid. Of course you do not have radiation included but hey - you ever calculated the radiation part? The heat flux is soooo small: . Of course it depend on the emissivity factor but if it is like 0.1 and T is not really high. You really could neglect that or put it into a effective heat-transfer coefficient.


Good luck.

[macRC]

Hello student666 and Tobi,

thanks a lot for your replies and help. The next days I will try to implement your suggestions.
I actually did rethink my plan to implement this simulation, but on the other hand, I already spent a lot of time for preparation and I´m still in hope for a better solution

As the emmissivity factor is 0.9 I do have to consider thermal radiation espacially for further case setups.

Any other hints are very welcome.

Best regards

[Tobi]

Hi Domi,

thanks for your PM. Based on the fact that it is just an estimation, you should change to sHM, especially for automation. However, if you still can include the radiation in the BC. But it is up to you how you want to model it. I also want to refer you to my topic about an open domain boundary condition for cooling phenomenon. Common setup for p_rgh in complete open domains

[derekm]

Read this
specifically for the chtmultiregionsimplefoam ,
1) residuals are not the criteria to look at but rather temperature changes
2) make sure you have a smooth transition between cells i.e. dont expand by more than a factor of two.
3) make sure you have >4 cells in any thin layer
4) As tobi says : small(normal to surface) cells close to any solid air boundary


to get faster resolution

solids
fvSolution

solvers
{
    h
    {
        solver           PCG;
        preconditioner   DIC;
        tolerance        1e-06;
        relTol           0.05;
    }
}

SIMPLE
{
    nNonOrthogonalCorrectors 3;
}

relaxationFactors
{
    fields
    {
    }
    equations
    {
        h               0.8;
    }
}

Air

solvers
{
    rho
    {
        solver          PCG
        preconditioner  DIC;
        tolerance       1e-6;
        relTol          0;
    }

    p_rgh
    {
        solver           GAMG;
        tolerance        1e-6;
        relTol           0.01;

        smoother         GaussSeidel;

        cacheAgglomeration true;
        nCellsInCoarsestLevel 1000;
        agglomerator     faceAreaPair;
        mergeLevels      1;
    }

    "(U|h|k|epsilon|G|Ii)"
    {
        solver           PBiCG;
        preconditioner   DILU;
        tolerance        1e-6;
        relTol           0.1;
    }
    omega
    {
        solver           PBiCG;
        preconditioner   DILU;
        tolerance        1e-5;
        relTol           0.1;
    }
    G
    {
        $p_rgh;
        tolerance       1e-05;
        relTol          0.1;
    }
    
}

SIMPLE
{
    momentumPredictor on;
    nNonOrthogonalCorrectors 0;
    pRefCell        0;
    pRefValue       100000;
    rhoMin          rhoMin [1 -3 0 0 0] 0.2;
    rhoMax          rhoMax [1 -3 0 0 0] 2;
}

relaxationFactors
{
    fields
    {
        rho             1.0;
        p_rgh           0.7;
    }
    equations
    {
        U               0.3;
        h               0.7;
        "(k|epsilon|omega)" 0.7;
        G               0.7;
        "ILambda.*"     0.7;
        Qr              0.7;
    }
}