A Load-balanced adaptive mesh refinement for OpenFOAM

Note

If you're using OpenFOAM v2112 or newer, please switch to the v2212 branch. The master branch is for OpenFOAM v2012 and earlier versions (v2106 is not supported). See #6. The Allwmake does this automatically for you now.

H2 injection case

H2Injection.mp4

Free-propagating flame case

freelyPropagatingFlame.mp4

This repository extracts library parts from blastFoam which are relevant to load-balanced adaptive mesh refinement for polyhedral meshes while retaining the original commit history; this is not intended as a full port! Only tested features are to be trusted. !!WIP!!

To get started, you can visit the one and only wiki page.

Objectives

• Have a reasonable Load-balanced AMR for 2D/3D OpenFOAM meshes in the ESI fork.
• Support load balancing of Lagrangian particle clouds (not yet implemented).
• Make it easy to include this lib in other projects through submodules/subtrees.

blastFoam is GPL licensed; see the included (original) COPYING.

Quick Notes

• Everything compiles to your $FOAM_USER_LIBBIN with a recent ESI (openfoam.com) version.
• Our favorite refinement cell selector is the coded. Although a wide range of selectors is provided, they are not well tested. So, use the coded refinement whenever possible.

Overset meshes

adaptiveOversetFvMesh is dynamicOversetFvMesh with AMR and load balancing on top, so mesh motion, refinement and balancing are all driven from a single constant/dynamicMeshDict:

dynamicFvMesh   adaptiveOversetFvMesh;

solvers
{}                              // or a motionSolver list, as for dynamicOversetFvMesh

adaptiveOversetFvMeshCoeffs
{
    // the usual blastAMR settings
}

Zone book-keeping across topology changes and redistribution is handled by a run-time selectable oversetHandler, picked up automatically for any mesh with an overset patch. Set oversetHandler none; to switch it off, or register your own type if you use custom cellCellStencil code:

class myHandler : public oversetHandler { ... };
addToRunTimeSelectionTable(oversetHandler, myHandler, mesh);

Cells carried by a motion solver must be kept out of adaptation:

    protectZones    ( movingZone );     // cell zones excluded from AMR

OpenFOAM places points introduced by refinement in the reference configuration by assuming the motion is a pure scaling (points0MotionSolver::updateMesh). That is wrong under rotation, and the mesh tangles as the body turns. Refine the background around the body instead, which is the useful case anyway.

See tutorials/oversetHeatTransfer (static zones, AMR + load balancing) and tutorials/oversetRotatingSquare (moving body, AMR).

Load balancing an overset mesh

The default cellCount load policy weights every cell the same, which misprices an overset mesh: a hole cell is masked out of the solution and carries no physics, yet counts as a full cell, so a rank owning much of the hole region reports as loaded while doing almost no work. cellCountWithOverset prices cells by overset type instead, with user-configurable factors:

    loadPolicy          cellCountWithOverset;

    holeWeight          0.01;   // masked out, no physics solved
    interpolatedWeight  1.5;    // extra matrix faces + donor comms
    porousWeight        1.0;    // no donors found
    specialWeight       1.0;    // hole acting as a donor

Only the hole discount is on by default; the rest default to 1, i.e. to plain cellCount. Calculated cells always keep their weight, particle contributions are never discounted, and a mesh with no overset patch falls back to cellCount untouched. Both overset tutorials use this policy.

Expect it to report larger imbalances than cellCount, because it can see imbalance that cell counting cannot. On tutorials/oversetRotatingSquare, where holes run 18-47% of the mesh, cellCount peaks at 2.8% imbalance while cellCountWithOverset peaks at 20.9%. A threshold tuned for cellCount is therefore far too aggressive: at allowableImbalance 0.01 that case rebalances 176 times instead of 12. Pick a threshold clear of the noise floor: on that case the overset-aware metric sits at a 1-2.6% mean, so the tutorial uses 0.05, which gives 24 balances. Raise allowableImbalance whenever you switch policy.

Known limitations:

• Refinement driven by the loadBalancedAMR function object needs adaptiveOversetFvMesh; the function object on a stock dynamicOversetFvMesh covers load balancing only.