OpenFOAM® v2606 新リリース

OpenFOAM Teamは、2026年6月リリースのOpenFOAM® v2606を発表します。

今回のリリースでは、OpenFOAM-v2512の機能が、コードのさまざまな領域にわたって拡張されています。

新機能には、Keysightの顧客がスポンサーとなった開発、社内資金による開発、およびOpenFOAM Communityから提供された機能や変更の統合が含まれています。

OpenFOAMはKeysightによってGPL Licenseの下で配布されています。

さまざまなLinuxおよびその他のPOSIX system上でcompile可能なsource code packageに加え、今回のリリースでは複数のpre-compiled binary packageも提供されています。

Ubuntu Linux: Ubuntu 24.04（LTS）、22.04（LTS）など向けのpackage installation
openSUSE Linux: Leap 16.0、15.7、15.6向けのpackage installation
Red Hat Linux variants: EPEL 9、Fedora 41、42向けのpackage installation
apptainer images: Docker Hubから`openfoam-dev:2606-apptainer`および`openfoam-dev:apptainer`として利用可能

Windowsユーザーには、pre-compiled packageを利用するための3つの選択肢があります（詳細情報）。

Windows Subsystem for Linux（Ubuntu、openSUSEなどをベースとした環境）を使用
Cross-compilationによるnative executableを使用
Docker installationを使用

OpenFOAMのApptainer supportは、事前に構築されたimageではなくdescription fileによって提供されます。

packaging/containersを参照してください。

macOSユーザーは、sourceからcompileするか、pre-compiled package用のDocker containerを使用できます（詳細情報）。

Pre-processing

distributedTriSurfaceMeshの更新

今回のリリースでは、`snappyHexMesh`のgeometry typeである`distributedTriSurfaceMesh`に、2つの有用な機能強化が加えられました。

最初の変更では、exclusion bounding boxが導入されました。

このutilityは、保持しているすべてのtriangleを包含するbounding box（`exclusionBb`）を計算するようになりました。このbounding box内に完全に含まれるqueryについては、geometryをlocalで解決できるため、過剰なremote testを回避できます。

この最適化はdefaultで有効になっていますが、必要に応じて無効にできます。

box
{
    file "box.obj";
    type distributedTriSurfaceMesh;

    // Do not calculate exclusion bounding box
    exclusionBb         false;
}

2つ目の変更では、geometryを選択したprocessorのみに読み込みながら、`distributedTriSurfaceMesh`を`triSurfaceMesh`とまったく同じように動作させることが可能になりました。

box
{
    file "box.obj";
    type distributedTriSurfaceMesh;

    // Send whole surface to master of each node
    distributionType    nodeMaster;
}

この設定では、追加の通信が必要になり、geometryを保持するprocessorがbottleneckとなる可能性がある代わりに、nodeごとのmemory使用量を削減できます。

Defaultでは、hostnameに基づいて各nodeに1つのmaster processorが指定されます。

必要に応じて、`nProcessorsPerMaster`設定を使用することで、1つのmasterを共有するprocessor数を調整できます。

チュートリアル

`$FOAM_TUTORIALS/mesh/snappyHexMesh/distributedTriSurfaceMesh`

ソースコード

`$FOAM_SRC/parallel/distributed/distributedTriSurfaceMesh/distributedTriSurfaceMesh.H`

Merge request

MR!844

splitMeshRegions utilityの改良

`splitMeshRegions` utilityに2つの新しいoptionが追加されました。

customRegionNames

`splitMeshRegions`で`combineZones` optionを使用すると、複数のcell zoneをまとめて1つのregionにできます。

例えば、`zoneA`、`zoneB`、`zoneC`、`zoneD`というzoneがある場合、`combineZones` optionを使用して、`zoneA`と`zoneB`を1つのregionに、`zoneC`と`zoneD`を別のregionにまとめることができます。

しかし、結合後のregion名はcell zone名を連結して生成されるため、例えば以下のようになります。

zoneA_zoneB
zoneC_zoneD

1つのregionに含まれるcell zoneの数が増えるにつれて、これらの名前は扱いにくくなる可能性があります。新しい`customRegionNames` optionを使用すると、`combineZones`使用時にcell zoneのclusterへ明示的な名前を割り当てることができます。

splitMeshRegions -cellZonesOnly -combineZones '((zoneA zoneB)(zoneC zoneD))' -customRegionNames '(regionX regionY)'

useSelectedFaceZones

既存の`useFaceZones` optionでは、region間のinterfaceを、すべてのface zoneに対応する複数のpatchへ分割します。

新しい`useSelectedFaceZones` optionでは、指定した一部のface zoneだけに対応するpatchへregion間interfaceを分割できるため、より細かな制御が可能になります。

ソースコード

`$FOAM_UTILITIES/mesh/manipulation/splitMeshRegions`

Merge request

Merge request #795

新しいpatchDistanceToCell cell source

OpenFOAMには、指定したpatchに直接隣接するcellを選択する`patchToCell`や、形状に基づいて領域を選択する`boxToCell`、`sphereToCell`などのgeometric sourceが用意されています。

しかしこれまでは、turbulenceのwall-distance計算と同じgeometric distance algorithmを使用して、1つまたは複数のpatchから一定の距離範囲内にあるcellを選択する方法はありませんでした。

この機能を補うため、`topoSet`のcell sourceとして`patchDistanceToCell`が追加されました。

`patchDistanceToCell`は、以下のような用途で使用できます。

mesh setup
refinement zone
source term
post-processing用cell set

Near-wallおよびannular-bandのcell setは、以下のように設定できます。

actions
(
    {
        name    nearWall;
        type    cellSet;
        action  new;
        source  patchDistanceToCell;
        patch   movingWall;
        distance 0.02;
    }

    {
        name    wallBand;
        type    cellSet;
        action  new;
        source  patchDistanceToCell;
        patches (movingWall fixedWalls);
        minDistance 0.01;
        distance 0.04;
    }
);

最初の`nearWall`では、`movingWall`から`0.02`以内にあるcellを選択します。

2つ目の`wallBand`では、`movingWall`および`fixedWalls`からの距離が`0.01`から`0.04`の範囲にあるcellを選択します。

ソースコード

`$FOAM_SRC/meshTools/topoSet/cellSources/patchDistanceToCell`

Merge request

Merge request #831

チュートリアル

`$FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity`

Issue

Issue #3503

Numerics

Overset gridにおけるinverseDistance methodの改良

Overset meshに使用されるinverse-distance weighted cell-cell stencilについて、主に2つの点でrobustnessが向上しました。

Fringe-to-fringe cascadeの防止

OVERSET fringe cellは、donor search phaseの前にあらかじめ`INTERPOLATED`へ昇格されるようになりました。

これにより、fringe cellが他のOVERSET acceptorのdonorとして選択されることを防止します。

従来は、このような選択によって安全ではないdonor chainが形成され、interpolationがcrashする可能性がありました。

`allowInterpolatedDonors`が`true`に設定されている場合でも、この保護処理が優先されます。これは、fringe-to-fringeのdonationが常に安全ではないためです。

Empty-stencilの保護

Donor-marking phaseの後、例えば`markPatchesAsHoles`によってdonor cellが`HOLE`になった場合、従来はacceptor cellが空のstencilを持った`INTERPOLATED`の状態で残されていました。

これにより、interpolationがcrashする可能性がありました。

今回、複数のdefensive checkが追加され、このようなcellを検出して`HOLE`へ降格させることで、stencilの整合性が維持されるようになりました。

また、compactionやmap redistributionの際にstencilが失われるような、まれなedge caseにも対応しています。

これらの変更によりoverset interpolationのrobustnessが向上し、複雑なtopological transitionを伴う場合でもcrashしにくくなりました。

特に、hole-cuttingとdonor searchが密接に相互作用するoverlapping regionを含むcaseで効果があります。

ソースコード

`$FOAM_SRC/overset/cellCellStencil/inverseDistance`

Finite Areaの改良

今回のリリースでは、OpenFOAM-v2512で開始された開発を引き継ぎ、複数のareaを扱うためのfinite-area supportの拡張が完了しました。

Multiple area supportにより、volumeの異なる部分に対して、それぞれ異なるfinite-area physicsを定義できます。

例えば、同じvolumeに対して、一部のboundary areaには異なる2次元thermal shellを適用し、別のboundaryにはfilm shellを適用できます。

これは、thermal shellなどのfinite-area physics solverをvolume boundary conditionの一部として直接組み込めるため、特に有用です。

Setupに関する変更にはbackward compatibilityがあります。

Defaultのregionが1つだけの場合、setup方法は従来と同じです。

複数のarea regionを使用する場合、setupはmulti-region caseと同様になります。ただし、それぞれのvolume regionに対して複数のfinite-area definitionを設定できます。

Tutorialの`hotRoomWithThermalShell.multi-area`では、このsetup方法を分かりやすく紹介しています。

今回のリリースではedge fieldの処理も更新され、parallel計算においてflux orientationとedge flippingが正しく維持されるようになりました。

この処理は、以下の各種toolで一貫して適用されるようになっています。

decomposition
reconstruction
redistribution

既存のparallel caseは引き続き実行できます。Tool側で既存のedge flipping addressingの有無を自動的に検出するためです。

ただし、新しく作成された`edgeProcAddressing`は、一般的には古いバージョンのOpenFOAMでは使用できません。

前回のリリースでは、decompositionおよびreconstructionに対するmulti-area supportに加えて、複数のpost-processing toolへの対応がすでに追加されていました。

今回のリリースでは、そのsupportがparallel redistributionにも拡張されました。

Diagnosticsについては、`foamToVTK` utilityがedge fieldの出力にも対応しました。

さらに、`checkFaMesh`および`makeFaMesh`の両方について、VTK diagnostics outputが拡張されています。

AMI cacheの改良: restart

AMI cachingはv2512で導入され、rotating mesh caseのperformanceを向上できる機能として提供されました。

この機能では、interpolation weightとaddressingをcacheし、複数回のrotationにわたって再利用します。

これにより、本来であれば複数回のparallel reductionを含むassembly costを削減でき、scaling performanceの低下を抑えることができます。

一部のworkflowでは、例えば異なるtime-step strategyへ変更する場合などに、cacheをclearすることが望ましい場合があります。

今回、この操作をsingle-shot controlとしてAMI patchの設定に指定できるようになりました。

AMI1
{
    cacheSize        <size>;
    cacheRestartTime <time>;
}

以下の条件を満たすと、

time >= cacheRestartTime

cacheがclearされ、その後のevaluationで再構築されます。

将来のリリースでは、要件に応じて複数のrestart optionが追加される可能性があります。

ソースコード

`$FOAM_SRC/meshTools/AMIInterpolation`

Solvers and physics

新しい2方程式RANS乱流モデル: GEKO

OpenFOAMでは現在、`SpalartAllmaras`、各種`kEpsilon`、`kOmegaSST`など、広く使用されている複数のRANS乱流closure modelが提供されています。

各modelにはそれぞれ長所と短所があり、対象とするapplicationに最適なmodelを選択するため、想定されるflow configurationの一部に対して複数のmodelを実行・比較することが一般的です。

しかし、modelを切り替える場合、例えばboundary layerとfree-shear flowの間でaccuracyのtrade-offが発生することがあり、workflowが複雑になります。

このworkflowの柔軟性を向上するため、汎用的なRANS closureとして有望なGeneralised k-omega Two-Equation Turbulence Model（GEKO）が、Menter & Matyushenko（2025）の研究に基づいて実装されました。

Incompressibleおよびcompressibleの両applicationに対応しています。

GEKOのcalibration coefficient

GEKOでは、2方程式乱流modelを単一のframeworkに統合し、異なるphysicsを対象とする4つの独立したfree coefficientを提供します。

係数	対象とする現象
`CSEP`	Boundary layerなど、smooth surfaceからのflow separationを最適化
`CNW`	Heat transferやskin frictionなど、non-equilibrium near-wall regionのflowを最適化
`CMIX`	Free flowにおけるspreading rateを最適化
`CJET`	Round jet flowを最適化

実装されている主な機能

Wall distanceを必要としないvariant: `wallDistanceFree`
kに対するproduction limiter: `productionLimiter`（defaultで有効）
Kato-Launder stagnation correction: `katoLaunder`
Reynolds stress tensorに対するdilatation correction: `dilatationCorrection`
4つのcalibration coefficient field: `CSEP`、`CNW`、`CMIX`、`CJET`
- Uniform scalarまたはspatial fieldとして読み込み可能
- `writeCalibrationFields`によるdiagnostic outputに対応
Machine-learning augmentation: `machineLearning`
- Optionalな`Ck`および`Comega` source termを使用可能
`nut`に対するrealizability limiter

Verification

GEKO modelは、以下のcanonical flowに対してverificationされています。

Strong adverse pressure gradientを伴うsmooth-wall flat plate上のequilibrium boundary layer（Skare & Krogstad, 1994）
Free-shear mixing-layer flow（Bell & Mehta, 1990）
Zero-pressure-gradient smooth-wall flat plate（Wieghardt & Tillmann, 1951）
Backward-facing step flow（Driver & Seegmiller, 1985）
CS0 Diffuser flow（Driver, 1991）
Axisymmetric transonic bump flow（Bachalo & Johnson, 1986）

Release pageでは、mixing-layer flowについて`CMIX`を変化させた場合のself-similar velocity profileおよびturbulent kinetic energy profileへの影響が示されています。

ソースコード

`$FOAM_SRC/TurbulenceModels/turbulenceModels/RAS/GEKO/GEKO.H`

Merge request

MR !819

参考文献

Menter, F. R., & Matyushenko, A. (2025). Generalized k−omega (GEKO) Two-Equation Turbulence Model. AIAA Journal, 63(11), 4590-4606. DOI: 10.2514/1.J065678

新しいLagrangian patch interaction model: BaiGosman

OpenFOAMでは従来から、`kinematicSurfaceFilm` surface-film modelの`splashBai` interactionを通して、Bai系のspray impingement physicsを利用できます。

この方法では、droplet-wall interactionを、wall上のresolvedまたはmodelled liquid filmとcouplingします。

Film dynamicsが重要な場合には適切ですが、parcel-wall impingementのみを直接扱いたい場合には、surface filmを使用するためのmodelingおよびcase setupが追加で必要になります。

今回、Bai & Gosman（1996）のspray impingement frameworkに基づく`BaiGosman` interaction typeが、`localInteraction` patch-interaction modelに追加されました。

これにより、`surfaceFilmModel`を有効にしなくても、thermo、reactingおよびspray Lagrangian cloudに対して、patchごとにadhesion、rebound、splashを扱うことができます。

主な機能

`localInteractionCoeffs`内でpatchごとに`BaiGosman` typeを指定可能
Parcel typeには`T()`および`rho()`が必要
Cloud databaseには、少なくとも1つのliquid componentを含む`SLGThermo`の登録が必要
Temperature-dependentなimpingement regimeに対応
- `Tmelt`未満: viscoelastic reboundまたはadhesion
- `Tmelt`以上: Weber numberおよびOhnesorge numberに基づくsplash判定
- `dry` switchによりdry-wall / wet-wall treatmentを選択
Secondary splash parcelを生成可能
- Stochastic diameter distribution
- Splash directionのsampling
- Owner cloudへの即時inject

設定例

localInteractionCoeffs
{
    patches
    (
        walls
        {
            type              BaiGosman;
            dry               true;
            Tmelt             400;
            Wec               200;
            parcelsPerSplash  5;
            Adry              2630;
            Awet              1320;
            Cf                0.7;
        }

        outlet
        {
            type escape;
        }
    );

    ...
}

このmodelでは、Bai-Gosman impingement modelのadhesion、rebound、splash regimeが再現されます。

Secondary splash dropletのenergeticsにはwall-normal方向のincident kinetic energyが使用され、`ThermoSurfaceFilm`で使用されるformulationと整合しています。

ソースコード

`$FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/PatchInteractionModel/LocalInteraction/BaiGosman.H`
`$FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/PatchInteractionModel/LocalInteraction/LocalInteraction.H`

Merge request

Merge request #838

参考文献

Bai, C. & Gosman, A. (1996). Mathematical Modelling of Wall Films Formed by Impinging Sprays. International Congress & Exposition, Detroit, Michigan, United States.

turbulentDigitalFilterInlet境界条件のconvolution改良

`turbulentDigitalFilterInlet` boundary conditionは、LESおよびDESのinletに対して、synthetic turbulence-likeなtime seriesを生成するboundary conditionです。

Digital-filter method（DFM）またはforward-stepwise method（FSM）を使用します。

Two-point correlationを組み込むconvolution処理は`IntegralScaleBox`内部で実行されます。

従来の実装では、random-field generationとconvolutionがmaster MPI rank上だけで実行されていたため、parallel計算時にこの処理がserial bottleneckとなっていました。

Convolutionのparallel化

今回、`IntegralScaleBox`のconvolution処理がparallel化され、generation-planeに対する処理が複数のMPI rankへ分散されるようになりました。

既存のdictionary syntaxに変更はありません。

また、simulation outputについても従来のserial implementationとの整合性が維持されています。

Optionalな`seed` entryを使用することで、restartやmesh redistributionを行った場合のreproducibilityを制御できます。

Performance

この変更により、single-processorで実行されていたconvolution bottleneckが解消されました。

`turbulentInflow` tutorial simulationでは、およそ15～35%のspeedupが確認されています。

ソースコード

`$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/turbulentDigitalFilterInlet/IntegralScaleBox`
`$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/turbulentDigitalFilterInlet`

Merge request

Merge request #840

Heat diffusionの改良

`thermophysicalProperties`の`pureZoneMixture` modelでは、cell zoneごとに異なるthermal propertyを設定できます。

今回のリリースでは、solid solverである`solidFoam`およびconjugate heat transfer solverにおけるheat flux formulationの不具合が修正されました。

Isotropic thermal conductivity

Isotropic thermal conductivityを持つsolidでは、異なるmaterial propertyを持つ2つのcell zone間のinterfaceでconsistentなheat fluxを得るため、`alpha`および`kappa`のlaplacian schemeにharmonic interpolationを使用する必要があります。

例えば、以下のように設定します。

laplacianSchemes
{
    laplacian(alpha,h)      Gauss harmonic limited corrected 0.5;
    laplacian(kappa,h)      Gauss harmonic limited corrected 0.5;
}

Anisotropic thermal conductivity

Anisotropic thermal conductivityの場合、`alpha`および`kappa`はtensorとなるため、harmonic interpolation schemeを直接使用できません。

この場合はlinear interpolationを使用します。

laplacianSchemes
{
    laplacian(alpha,h)      Gauss linear limited corrected 0.5;
    laplacian(kappa,h)      Gauss linear limited corrected 0.5;
}

ただし、異なる2つのcell zone間のinterfaceでconsistentなheat fluxを確保するため、solver内部ではtensorのface-normal componentに対して自動的にharmonic interpolationが適用されます。

これは、`laplacianSchemes`で`linear`を指定した場合でも適用されます。

一方、`alpha`および`kappa` tensorのoff-diagonal componentについてはlinear interpolationが使用されます。

ソースコード

`$FOAM_SRC/thermophysicalModels/solidThermo/solidThermo`

Merge request

Merge request #842

Tutorial

`$FOAM_TUTORIALS/heatTransfer/solidFoam/multiSolidWithAnisoConduction`

Post-processing

新しいrelativeVelocity function object

新しい`relativeVelocity` function objectは、rotating caseにおけるrelative velocity fieldを計算します。

3種類のrotation modeがサポートされています。

specified mode

`specified`では、1つまたは複数のrotation zoneを直接定義できます。

rotationMode    specified;

specified
{
    origin  (0 0 0);    // Rotation around centre line
    axis    (1 0 0);
    n       -25;        // [rev/sec] (-ve: left-hand propeller)

    zone    innerCylinderSmall;
}

`origin`、`axis`、rotation speed `n`および対象となるcell zoneを指定してrelative velocityを計算します。

MRF mode

`MRF`では、case内に定義済みのmoving reference frameを参照してrelative velocityを計算します。

rotationMode    MRF;

既存のMRF設定をそのまま利用できるため、MRFを使用したrotating machinery caseのpost-processingに適しています。

solidBodyRotation mode

`solidBodyRotation`では、`rotatingMotion`の定義を使用してsolid body rotationを適用します。

rotationMode    solidBodyRotation;

このmodeはcell zoneを対象として使用します。

Background cellの扱い

Relative motionは複数のcell zoneから構成できるため、いずれのrotation zoneにも属さないbackground cellをどのように扱うかを制御できます。

通常はbackground cellのvelocityをzeroとしますが、以下のような設定も可能です。

Original velocity fieldのcopyを初期値として使用
Rotation zoneに含まれないcellへcustom mask valueを設定

これにより、複数のrotating regionを含むcaseでもrelative velocity fieldを柔軟に構築できます。

ソースコード

`$FOAM_SRC/functionObjects/field/relativeVelocity`

Tutorials

`$FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/propeller1/system/relativeVelocity`
`$FOAM_TUTORIALS/incompressible/simpleFoam/mixerVessel2D/system/relativeVelocity`
`$FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/propeller/system/relativeVelocity`

Polyhedral cell conversionの新しいoption

`cellDecomposer` function objectは、cellを基本的な形状へdecomposeし、選択したfieldを生成されたmeshへmapする機能です。

`mapFields`と類似したfield mapping機能も提供します。

今回のreleaseでは、この機能が拡張され、cell自体を分割せずにfaceだけを分割できるようになりました。

Faceのみのdecomposition

この機能は、外部で定義されたtriangle meshとAMIを介してinterfaceを構築する場合に特に有効です。

Faceをtriangleへ分割することで、OpenFOAM側のface geometryを外部triangle meshと正確に一致させることができます。

Faceをface-centre triangleへ変換する典型的な設定は以下です。

functions
{
    cellDecomposer
    {
        type            cellDecomposer;
        libs            (fieldFunctionObjects);
        fields          ();
        mapRegion       tetMesh;

        // How to decompose faces
        decomposeType   faceCentre;

        // Cell set to decompose
        selectionMode   cellSet;
        cellSet         dummy;  // empty set

        // Face set to decompose
        faceSelectionMode faceSet;
        faceSet         facesToDecompose;
    }
}

この例では、

`dummy`: decomposition対象となるcell set
`facesToDecompose`: decomposition対象となるface set

を読み込みます。

topoSetによるselectionの作成

Cell setおよびface setは`topoSet` applicationを使用して生成できます。

例えば、cellを分割せず、`missingCorner` patchのfaceのみを対象とする場合は以下のように設定できます。

{
    name    dummy;
    type    cellSet;
    action  clear;
}
{
    name    facesToDecompose;
    type    faceSet;
    action  patchToFace;
    patch   missingCorner;
}

この場合、`dummy`はempty cell setとなり、`facesToDecompose`には`missingCorner` patchのすべてのfaceが格納されます。

`missingCorner` tutorialでは、この方法によってpatch上のquadrilateral faceがtriangleへ変換されます。

ソースコード

`$FOAM_SRC/functionObjects/field/cellDecomposer`

Tutorial

`$FOAM_TUTORIALS/mesh/polyDualMesh/missingCorner`

Issue

Issue #3529

Conversion toolの改良

OpenFOAM v2606では、VTKおよびEnsightへのconversion機能にも複数の改善が加えられています。

Processor boundaryのartefact除去

`foamToVTK`や`vtkWrite` function objectなどによるVTK volume geometry outputで、processor boundaryに生じていたartefactが表示されなくなりました。

Ensight outputでは既に同様の処理が実装されていましたが、今回VTK volume infrastructureにも同等のtopological point merge処理が導入されました。

これにより、parallel計算結果をVTKへ変換した際のprocessor boundary由来の不要なgeometry artefactが除去されます。

Output fileのbase name指定

EnsightおよびVTK conversionで、新しく`base-name`を指定できるようになりました。

Utilityとして実行する場合は、

-base-name <name>

を使用できます。 Function objectとして使用する場合は、

baseName    <name>;

を指定できます。

これにより、case nameとは独立したbase nameまたはstem nameをoutput fileへ設定できます。

Absolute output pathへの対応

`foamToEnsight`および`foamToVTK` utilityがabsolute output pathを正しく扱えるようになりました。

これはdistributed rootsを使用するparallel環境で特に有用です。

例えば、各processorのfilesystemが分散している環境でも、NFS mountされた共通directoryなどへoutputを集約できます。

Surface noiseの改良

`surfaceNoise` utilityが拡張され、geometric surface informationを持たないsurface dataも処理できるようになりました。

Geometryを持たないsampling dataへの対応

外部でsampleされたdataでは、pressure valueがface centre位置の値としてのみ提供され、対応するsurface geometryが存在しない場合があります。

今回、このようなdataについて、

Ensightではpoint element
VTKではvertex element

に相当するzero-dimensional elementとしてinputを指定できるようになりました。

`surfaceNoise`は、この形式のdataに対してもnoise processingを実行できます。

Underlying surface reader/writerにも変更が加えられていますが、現時点では通常のsurface samplingからこの機能を利用することはできません。

将来的には需要に応じて通常のsurface samplingへの展開も検討されています。

Ensight collatedTimeの修正

Robert Perryによるcommunity contributionとして、`surfaceNoise`のEnsight `collatedTime` writing modeも修正されています。

従来はloop間でwriterが適切に保持されない問題がありましたが、writerをloop間で保持するよう変更され、正しいcollating behaviourが得られるようになりました。

新しいagglomeration visualisation

Field agglomerationのqualityは、GAMG solverのperformanceに大きな影響を与えます。

GAMGは特にpressure equationのsolutionで高い効果を発揮します。Steady-state simulationではpressure equationの計算時間が全体のrun timeの大きな割合を占めることがあるため、agglomeration structureの確認はsolver performanceの分析に有用です。

agglomerationInfo function object

新しい`agglomerationInfo` function objectを使用すると、agglomeration regionごとに異なる値を持つvolume fieldを生成できます。

これにより、一般に「blobs」と呼ばれるGAMGのagglomeration structureをParaViewなどで直接visualiseできます。

典型的な設定は以下です。

agglom1
{
    type            agglomerationInfo;
    libs            (utilityFunctionObjects);
    writeControl    writeTime;
}

生成されたvolume fieldを可視化することで、

Agglomeration regionの大きさ
Regionの空間分布
不自然に細かい、または大きなagglomeration
Mesh構造とcoarse levelの関係

などを確認しやすくなります。

Agglomeration table

Visualisation用のvolume fieldに加えて、agglomeration tableもfileへ出力されます。

そのため、GAMGのconvergenceやperformanceに問題がある場合に、agglomeration構造を定性的・定量的に確認するdiagnostic toolとして利用できます。

ソースコード

`$FOAM_SRC/functionObjects/utilities/agglomerationInfo`

Infrastructure

Community contribution: GPU

OpenFOAM v2606は、GPU offloadingを初めてサポートするreleaseです。

C++17/20の`std::execution` policyを利用し、loop処理を複数のexecution unit上で自動的にparallel実行します。Execution unitとしてはGPU deviceだけでなく、memoryを共有する複数のCPU coreも想定されています。

Background

Modern computer architectureでは、performanceは単純な演算性能だけではなく、memoryからcompute unitへdataを転送する速度によって制限される傾向が強くなっています。

今回のGPU対応は、これまで行われてきたGPU portingの成果を基礎としています。

最新の開発では、Keysight/OpenCFDが以下の組織と協力しています。

UK Science and Technology Facility Council（STFC）
Exeter University
AMD
Nvidia

Modern C++の機能を利用し、OpenFOAMの中でも特にperformanceへの影響が大きい部分をGPU offloadingに対応させています。

GPU対応の基本方針

主に以下の領域が対象となっています。

Order-dependentではなくrace conditionを発生させないalgorithmの利用
- 例えばface-based loopではなくcell-based loopを使用
C++17 execution policyを使用し、可能なloopをoffload
Umpireをbackendとするmemory poolを使用し、必要な場所へmemoryをallocate
User-facing APIへの影響を抑えるため、変更を可能な限りlow-levelに実装
- Field algebra
- Linear solver
- Boundary evaluation
Intermediate fieldのallocationを可能な限り回避
- Intermediate interpolated fieldを生成せずon-the-flyでinterpolation
- Expression templatingの利用

開発協力

今回のGPU対応には以下の組織・開発者が協力しています。

STFC
- Jony Castagna
- Mayank Kumar
Exeter University
- Gavin Tabor
- Liam Berrisford
AMD
- Leopold Grinsberg
- Kumar Saurabh
Nvidia
- Filippo Spiga
- Matthew Martineau
- Stan Posey
- Hardwareの提供

Performance

初期実装の段階ですが、有望なperformance improvementが確認されています。

Release pageでは、high-end 32-core CPUであるIntel Xeon Gold 6448Yを基準としてGPU実行時のspeed-upが比較されています。

Memory management

GPU performanceではmemory managementが非常に重要です。

OpenFOAMでは`UMPIRE`を使用し、memory chunkをどこに配置するかを管理します。

これにより、CPUおよびGPUの双方から効率的にmemoryへaccessできるようにします。

GH100やMI300Aなどのunified memory architectureにおいても、このmemory managementは重要とされています。

GAMGによるperformance

より複雑なlinear solver configurationとして、GAMGと専用smootherを組み合わせることで、大規模caseでは良好なspeed-upが得られています。

MI300Aについても同程度のspeed-upが期待されていますが、performance tuningは現在も継続されています。

Patch数によるperformanceへの影響

現在のimplementationではpatch fusingが実装されておらず、それぞれのpatchが個別に処理されます。

そのため、patch数が多いcaseではperformanceが明確に低下することがあります。

今後は以下の改善が進められています。

Patch merging
- OpenFOAM内部でのmerge
- Pre-processingによるmerge
Operation mergingの拡大
- Kernel内でよりcomplexなoperationをまとめて実行
Intermediate fieldのさらなる削減

現状のperformanceはhardwareのtheoretical maximumにはまだ達しておらず、今後の最適化余地が大きいとされています。

使用上の注意

GPU版では、明示的にserialなlinear solver routineを使用しないことが推奨されています。

以下のsolver / smootherは避ける必要があります。

`DIC`
`DILU`
`GaussSeidel`
`symGaussSeidel`

代わりに、例えば以下の組み合わせが推奨されています。

solver      GAMG;
smoother    twoStageGaussSeidel;

CPU版との数値結果の違い

GPU版で使用されるparallelisationでは、operationの実行順序がrunごとに変化する可能性があります。

また、CPU版とGPU版ではloop structure自体が異なる場合があります。

例えば、

CPU版: face-based loop
GPU版: cell-based loop

となる場合があります。

この違いはtruncation errorに影響するため、GPUとCPUでsimulation結果がわずかに異なる可能性があります。

したがって、bitwise identicalな結果が保証されるわけではありません。

Compile-time option

GPU parallelisationおよびoffloadingはcompile-time optionです。

新しいarchitectureとしてpackage化されており、同じsource treeからCPU版またはGPU版をcompileできます。

GPU用にcompileしない限り、GPU対応によって通常のCPU版のbehaviorが変化しないよう配慮されています。

現時点での制約

現在のGPU implementationには以下の制約があります。

GPU developmentはmain development lineとは別のdevelopment trackで進められている
Main development lineより若干遅れている可能性がある
CPU threadingの`-stdpar=multicore`は現時点では正式にはサポートされていない
- Work-in-progress

Test case

TestingにはHPC Committeeのbenchmark caseから選択したcaseが使用されています。

Source code

GPU対応codeはdevelopment repositoryのbranchとして公開されています。

Repositoryのwikiおよび関連guideに導入方法がまとめられています。

Communityによる追加testingとfeedbackを経て、OpenFOAM v2612へのcode integrationが予定されています。

Coding

OpenFOAM codebaseのmodernisationの一環として、modern C++への対応がさらに進められています。

constexprとnoexceptの拡大

より多くのmethodが、

`constexpr`
`noexcept`

に対応しました。

これにより、compilerがoffloading architectureをtargetとする場合のoptimizationを支援します。

C++17 structured bindings

OpenFOAMの基本typeの一部がC++17 structured bindingsに対応しました。

対象には以下が含まれます。

`FixedList`
`Pair`
`Tuple2`
`edge`
その他の基本type

例えば、以下のような記述が可能です。

auto [minId, maxId] = findMinMax_locations(fld);

従来よりも自然で簡潔なcodeを記述できます。

List type detection traits

Template programmingを支援するため、各種list typeを判定するtraitが追加されています。

例として、

`is_dynamiclist_v`
`is_fixedlist_v`
`is_indirectlist_v`

などがあります。

C++20 type traitsのbackport

Complexなtemplate codeを簡略化するため、一部のC++20 type traitがbackportされています。

例として、

`remove_cvref`
`type_identity`

などがあります。

また、

stdFoam::is_template_base_of_v

が追加されています。

これはtemplated classを扱える`std::is_base_of`相当の機能を提供します。

その他のtemplate programming支援

`vectorspace_data()`なども追加され、templated code内でのcomponent-wiseなdata処理が簡略化されています。

Debugging supportの改良

OpenFOAM v2606では、programmingおよびdebuggingを支援する機能も強化されています。

macOSでのstack trace

macOSにおける`error::printStack`の内部処理が更新され、新しく`atos` utilityを使用するようになりました。

従来使用していた`addr2line`の代替処理は、新しいmacOS versionで正しく動作しなくなっていました。

今回の変更により、macOS上でのstack traceを利用したdebuggingが容易になります。

Symbol nameのdemangle

新しく、

error::demangle()

functionが追加されました。

このfunctionは、compilerによってmangleされたsymbol nameをhuman-readableな形式へ変換して返します。

Templateを多用するC++ codeなどのdebuggingで有用です。

Memory high-water mark

Memory usageのhotspotを調査するため、node単位でmemory high-water markを取得するhigh-level methodが追加されました。

`error::list_mem_hwm()`は、nodeごとに集計されたmemory high-water markのlistを返します。

Info<< "mem.hwm = "
    << flatOutput(error::list_mem_hwm())
    << nl;

Memory表示macro

以下のgeneral macroも利用できます。

`PrintMemoryIn(functionName)`
`PrintMemoryInFunction`

これらを使用すると、現在のnodeごとのmemory high-water markをdecorated stringとして表示できます。

出力例は以下です。

[node0][mem.hwm=<digits>](file.cxx:123)

これにより、どの処理やsource code位置でmemory usageが増加しているかを追跡しやすくなります。

Profilingとの連携

Profilingを有効にした場合、そのoutputにもmemory high-water markが含まれるようになりました。

Performance profilingとmemory consumptionの分析を同時に行いやすくなっています。

Porting

Compilation ruleが拡張され、Windows ARM64 targetへのcross-compilationがサポートされました。

Windows ARM64

Windows ARM64向けのcross-compilationには`llvm-mingw` infrastructureを使用します。

Example setupとして、

build_llvm-mingwARM64.Dockerfile

が提供されています。

MPIの制約

現時点ではWindows ARM64環境におけるMPI supportは限定的です。

そのため、Windows ARM64へのporting自体は可能になったものの、parallel OpenFOAM applicationを本格的に利用する場合にはMPI implementationの対応状況に注意が必要です。

Parallel

GAMG processor agglomeration: communication-aware multiple masters

今回のリリースでは、`procFaces`がoptionalな`nMasters`（または`nProcessorsPerMaster`）設定を受け付けるように拡張されました。

これにより、coarsest levelでprocessorをagglomerateし、`nMasters`以下になるまでまとめることで、`masterCoarsest`と同様の動作が可能になります。

`nMasters 1`とした場合は、processor間boundaryが残らないため、`masterCoarsest`と同じ動作になります。

効果

`simpleFoam`の`pitzDaily` tutorialを、以下の設定で実行します。

p
{
    solver                  GAMG;
    ..
    processorAgglomerator   procFaces;
    nMasters                4;
}

Debug switchを有効にします。

DebugSwitches
{
    GAMGAgglomeration 1;
}

出力例は以下の通りです。

                              nCells       nFaces/nCells         nInterfaces    nIntFaces/nCells     profile
   Level  nProcs         avg     max         avg     max         avg     max         avg     max         avg
   -----  ------         ---     ---         ---     ---         ---     ---         ---     ---         ---
       0      16         764     770       1.926   1.927         3.5       5      0.1025  0.1299   2.044e+04
       1      16         381     385       1.964   2.143         3.5       5      0.1686  0.2158        8367
       2      16         189     192       2.292   2.774         3.5       5      0.2689   0.349        3062
       3      16          93      96       2.321   2.645         3.5       5      0.4439  0.5532        1028
       4      16          45      47        2.33   2.489         3.5       5      0.6251  0.8043         362
       5       4          89      90       2.497   2.596         1.5       2      0.2982  0.4432       902.5
       6       4          41      43       2.298   2.429         1.5       2      0.4132    0.65       272.2

Master-coarsestでcompact masterを使用

今回のリリースでは、新しい`compactMasters` optionを使用して、master processorをcompactに割り当てることもできます。

p
{
    solver                  GAMG;
    ..
    processorAgglomerator   masterCoarsest;
    nMasters                4;
    compactMasters          true;
}

16 processor、4 masterのcaseでは、defaultのmaster allocationは以下のようになります。

master  nProcs  procIDs
0       4       (1 2 3)
4       4       (5 6 7)
8       4       (9 10 11)
12      4       (13 14 15)

`compactMasters`を有効にすると、masterは番号の小さいprocessorから順に割り当てられます。

master  nProcs  procIDs
0       4       (4 5 6)
1       4       (7 8 9)
2       4       (10 11 12)
3       4       (13 14 15)

効果

Compact masterを使用しない場合の出力例です。

                              nCells       nFaces/nCells         nInterfaces    nIntFaces/nCells     profile
   Level  nProcs         avg     max         avg     max         avg     max         avg     max         avg
   -----  ------         ---     ---         ---     ---         ---     ---         ---     ---         ---
       0      16         764     770       1.926   1.927         3.5       5      0.1025  0.1299   2.044e+04
       1      16         381     385       1.964   2.143         3.5       5      0.1686  0.2158        8367
       2      16         189     192       2.292   2.774         3.5       5      0.2689   0.349        3062
       3      16          93      96       2.321   2.645         3.5       5      0.4439  0.5532        1028
       4      16          45      47        2.33   2.489         3.5       5      0.6251  0.8043         362
       5       4          89      90       2.536   2.596         1.5       2      0.2191  0.2889       949.5
       6       4          41      43        2.36   2.429         1.5       2      0.2897     0.4       291.2

Compact masterを使用した場合の出力例です。

                              nCells       nFaces/nCells         nInterfaces    nIntFaces/nCells     profile
   Level  nProcs         avg     max         avg     max         avg     max         avg     max         avg
   -----  ------         ---     ---         ---     ---         ---     ---         ---     ---         ---
       0      16         764     770       1.926   1.927         3.5       5      0.1025  0.1299   2.044e+04
       1      16         381     385       1.964   2.143         3.5       5      0.1686  0.2158        8367
       2      16         189     192       2.292   2.774         3.5       5      0.2689   0.349        3062
       3      16          93      96       2.321   2.645         3.5       5      0.4439  0.5532        1028
       4      16          45      47        2.33   2.489         3.5       5      0.6251  0.8043         362
       5       4          89      90       2.319   2.433           3       3       0.653  0.8621       599.8
       6       4          41      43       2.029   2.116           3       3      0.9538   1.268       172.5

Compact master configurationでは、processor間boundaryが増加し、profileも高くなります。

より大規模なagglomeration、例えば64 coreでは、この影響は小さくなります。

ただし、必ずしも同じ大きさのclusterが生成される保証はありません。大規模なdecompositionでは、不均等な大きさのclusterによってbottleneckが発生する可能性があります。

Parallel

今回のリリースでは、MPIへのinterfaceである`Pstream`に複数の改良が加えられています。

probeMessage()

通常の`MPI_Probe`を使用するためのparameterが簡略化されました。

probeMessages()

複数のsourceを同時にprobeし、それぞれのmessage sizeを取得できるようになりました。

IPstreamの拡張

`IPstream`（input/receive stream）は、新しく「receive from any」modeで呼び出せるようになりました。

また、receive bufferを解放することもできます。

これによりalgorithm側では、`IPstream`を使用して以下の処理を行えるようになります。

Probe
Receive
Bufferの回収
Forwarding
Delayed deserialisationを伴うstorage

Pstreamの追加method

Inputおよびoutput `Pstream`に、以下のmethodが追加されました。

`align`
`tell`
`seek`
その他の補助method

これにより、rewritingを伴うcomposite outputにも使用できるようになり、aggregated data handlingの柔軟性が向上しました。

Field function objectにおけるMPI overheadの削減

以下のfunction objectについて、MPI operationの総数およびmemory overheadが大幅に削減されました。

`fieldExtent`
`fieldMinMax`
`fieldStatistics`

これらはcritical code pathではありませんが、OpenFOAM内部に残るhidden overheadを評価するための初期対象として選ばれました。

主な改善点は以下の通りです。

`mag()`演算に必要だったintermediate volume fieldを、ほとんどの場合で生成しないように変更
Bounding box reductionをまとめて実行
- 従来の`2*(nPatches+1)`回のMPI reductionから、正確に2回へ削減
`fieldMinMax`と`fieldStatistics`では、6回の個別MPI operationの代わりに1回の`MPI_AllGather`を使用

Core数が増えるにつれて、このようなhidden overheadの影響はより顕著になるため、今後も同様の改善が進められる予定です。

Specialised reduction

`MinMax`と`sumOp`の組み合わせに対して、specialisedな`Foam::reduce`が追加されました。

この処理は、intermediateなtree communicationやserialisation／deserialisationを介さず、対応するMPI reductionへ直接渡されます。

これにより、通信処理のoverheadを削減できます。

Plugins

Community contribution: pybFoam

今回のリリースでは、Henning Scheuflerによって開発されたOpenFOAM向けPython bindingである`pybFoam`が導入されました。この貢献に感謝いたします。

Pythonは、scientific computing、data analysis、machine learning、およびworkflowをつなぐgeneral-purposeな言語として、ますます重要になっています。

CFDにおいて重要性が高まっている多くの手法もPython ecosystem上で開発されています。例えば、以下のようなものがあります。

Data-driven turbulence closure
Surrogate model
Reduced-order model
Physics-informed neural network

`pybFoam` projectは、これらの手法をOpenFOAMからより利用しやすくし、Python ecosystemへのentry pointとして機能します。

このbindingを導入することで、PythonとOpenFOAMを連携させた利用を促進し、統一されたPython/OpenFOAM interfaceを提供することが期待されています。

pybFoamの構成

`pybFoam`は`nanobind`を基盤として構築されており、OpenFOAMのclassをPythonから利用できるようにします。

現在、以下の機能がbindingされています。

Core type
- `Time`
- `fvMesh`
- `dictionary`
- `volField` family
- `surfaceField` family
- Field dataはNumPyへ直接公開可能

Field operation
- Fieldに対する算術演算
- `cos`
- `sin`
- その他のelement-wise function

Finite-volume operator
- `fvc`
- `fvm`
- `grad`
- `div`
- `laplacian`
- `ddt`
- その他のOpenFOAM実装operator

Sampling
- Surface sampling
- Line sampling
- Interpolation

Model
- Turbulence model binding
- Thermophysical model binding

Meshing
- `blockMesh`
- `snappyHexMesh`
- `checkMesh`

Embedded solver
- Solverまたはlibraryへ組み込むことができるinterpreter

使用例

以下はpressure fieldを読み込み、そのgradientを計算し、field dataのNumPy viewを作成する例です。

import pybFoam as pyb
import numpy as np

runTime = pyb.Time(".", ".")
mesh = pyb.fvMesh(runTime)
p = pyb.volScalarField.read_field(mesh, "p")

grad_p = pyb.fvc.grad(p)
np_p = np.asarray(p["internalField"])

この例では、OpenFOAMの`p` fieldをPythonから直接読み込み、OpenFOAMの`fvc::grad`に相当する演算を実行した後、internal fieldをNumPy arrayとして参照しています。

追加のdocumentationはexternal repositoryで提供されています。

Repository

https://github.com/HenningScheufler/pybFoam

Documentation

https://henningscheufler.github.io/pybFoam/index.html

Community contribution: pyOFTools

`pyOFTools`もHenning Scheuflerによって開発されており、`pybFoam`によって提供されるinfrastructureを基盤として、OpenFOAMと連携するための基本的なPython method群を提供します。

Simulationの両端、すなわち、

Initial fieldを準備するpre-processing
計算結果を抽出するpost-processing

の両方でPythonを使用することで、workflowをより簡潔に記述し、容易に拡張できるようになります。

目的

このlibraryは、以下の実装例を示すことも目的としています。

Python interpreterをOpenFOAMへembedし、`pybFoam`と組み合わせて使用する方法
Custom bindingによってlibraryを拡張する方法
`pybFoam`上に構築したPython libraryをPython ecosystem向けにpackage化する方法

Function Objectによるpost-processing

`pyOFTools`はFunction Objectを使用し、OpenFOAM solver内部でpost-processingを実行します。

設定例を以下に示します。

functions
{
    pyPostProcessing
    {
        libs            (embeddingPython);
        type            pyPostProcessing;
        writeControl    timeStep;
        writeInterval   1;
        pyFileName      postProcess;   // postProcess.py (no extension)
        pyClassName     postProcess;   // module-level PostProcessorBase instance
    }
}

この設定では、ユーザーが作成した`postProcess.py`を読み込み、`postProcess` classを呼び出します。 Python側の例は以下です。

from pyOFTools.postprocessor import PostProcessorBase
from pyOFTools.builders import field
from pyOFTools.aggregators import VolIntegrate

postProcess = PostProcessorBase()

@postProcess.Table("water_volume.csv")
def water_volume(mesh):
    return field(mesh, "alpha.water") | VolIntegrate()

Decorator、

@postProcess.Table("water_volume.csv")

は、output formatおよびfile nameを定義します。 Function bodyでは、

field(mesh, "alpha.water")

によってregistryからfieldを読み込み、operationを適用します。この例では、

| VolIntegrate()

によって`alpha.water`をdomain volume全体で積分します。

Additional Features

Surface dataset

以下のようなsurfaceを生成できます。

plane(mesh, point, normal)

または、

iso_surface(mesh, "alpha.water", 0.5)

さらに、`area()`や`sample(mesh, field)`、aggregatorへpipelineとして接続できます。例えば、

iso_surface(mesh, "alpha.water", 0.5) | area() | Sum()

のように記述できます。

Point dataset

`line()`を使用してfieldをline上でsamplingできます。

line(mesh, name, start, end, n_points, field)

例えば、

line(mesh, "centreline", (0,0,0), (1,0,0), 100, "p") | Mean()

のように、line上のpressureをsamplingしてmeanを計算できます。

Composable pipeline

Spatial selectorとして、

`Box`
`Sphere`

などを使用でき、

&
|
~

operatorによって組み合わせることができます。

また、以下のようなcomponentを`|` operatorでchainできます。

Binner: `Directional`
Aggregator:
- `Sum`
- `Mean`
- `VolIntegrate`
- `SurfIntegrate`

これらは異なるdataset type間でも組み合わせることができます。

PythonによるsetFields

Post-processingと同じgeometric selectorを使用し、initial `0/` fieldをPythonから準備できます。

これにより、`setFieldsDict`の代わりにPythonによるfield初期化が可能になります。

Command-line interface

`pyoftools` CLIが提供されています。

例えば、

pyoftools setFields <spec>

を使用すると、`.py`または`.json`形式のfield specificationをcaseに対して実行できます。また、

pyoftools version

も利用できます。

Sampling

Surfaceおよびline/set samplingに対応し、interpolationも利用できます。

Volume dataの場合と同じselectorおよびaggregatorを再利用できます。

Repository

https://github.com/HenningScheufler/pyOFTools

Documentation

https://henningscheufler.github.io/pyOFTools/index.html

新しいVTK-HDF support

今回のOpenFOAM releaseでは、新しいVTK-HDF data formatへのOpenFOAM data exportが初めてサポートされました。

VTK-HDFは、ParaView 6.1以降で正式にサポートされているnative VTK data formatであり、HDF5（Hierarchical Data Format）を基盤としています。

従来のlegacy VTK formatやXML-based VTK formatで発生していたparsing overheadおよびdata duplicationを削減できます。

また、true binary fileとして扱えるため、

Readingの高速化
最新のVTK data modelへの柔軟な対応
複雑なdata compositionへの対応

が可能になります。

将来的な利点

長期的な利点の1つとして、static mesh geometryの再利用が挙げられます。

これはEnsight formatではすでに可能ですが、VTK-HDFでは専用のparserを別途必要としません。

また、将来のreleaseでは、

Data compression
その他のformat enhancement

を追加できる可能性があります。

現在の対応範囲

初期implementationでは、最もdata量が大きく、頻繁に出力される以下のdataが対象です。

Volume geometry
Volume field

生成時のdata compressionにはまだ対応していません。

ただし、HDF5の`h5repack` commandを使用することで、出力後にcompressionを適用できます。

vtkhdfWrite function object

新しい`vtkhdfWrite` function objectは、既存の`vtkWrite` function objectをそのまま置き換えて使用できるように設計されています。

既存の`vtkWrite`と同じkeywordをサポートします。

`legacy`および`format` keywordも受け付けますが、VTK-HDF formatには適用されないため、指定されても無視されます。

基本的な設定は以下です。

{
    type    vtkhdfWrite;
    libs    (foam-vtkhdfWrite);
    ...
}

今回の初期提供に対して十分な需要が確認された場合、将来のreleaseで以下への対応が検討されます。

その他のOpenFOAM data generator
Time-series data
Static geometry

foamToVTKHDF utility

`foamToVTKHDF` utilityは、その名称が示す通り、`foamToVTK`のVTK-HDF版です。

基本機能は`foamToVTK`とほぼ同じですが、現時点では以下のみを扱います。

Volume geometry
Volume field

現在、以下には対応していません。

Finite-area
Lagrangian data
Special-purpose diagnostic dump

関連するtutorial exampleは提供されていません。

これは、`vtkhdfWrite`および`foamToVTKHDF`が既存の`vtkWrite`および`foamToVTK`をdrop-in replacementとして利用できることを想定しているためです。

Community

謝辞

OpenFOAMに貢献してくださった以下のCommunity memberの皆様に、心より感謝いたします。

貢献: Merge request

Robert Perry
- MR#823 - BUG: `Time::setControls`における`startTime`整合性checkのfalse-positiveを回避（#3544をclose）
- MR#810 - BUG: overflowを防ぐため、有効なpointのみを対象にsample statisticsを計算（#3526をclose）
- MR#808 - BUG: `nearWallFields`のcrashを防ぐ`invalidTetHandling` optionを追加（#3523をclose）
- MR#804 - ENH: `wallShearStress`で使用する`U` fieldを指定するoption
- MR#803 - BUG: `noise` utilityがEnsightの`collateTimes` writeOptionを無視する問題
- MR#801 - ENH: `createPatch -fields` optionによりfieldを保持可能
- MR#800 - ENH: `snappyHexMesh -no-intermediate-write` optionを追加
- MR#798 - ENH: `forces`／`forcesCoeffs`に含めるporous cellZoneを選択するoption
- MR#797 - ENH: `yPlus`のfield entryにより、使用する`U` fieldをユーザーが選択可能
- MR#786 - `fusedGauss`のTBB link問題を修正

tulasihazarath-mcw
- MR#829 - ENH: Windows on ARMのsupportを有効化

Sajad Khodadadi
- MR#815 - library、solver、tutorialおよびcore integration変更を含むImmersed Boundary frameworkを追加
- MR#814 - library、solver、tutorialおよび必要なcore integration変更を含むsolver-level Immersed Boundary frameworkを追加

Qizhe Wen
- MR#816 - Non-orthogonal mesh向けに`limitedCubic`を採用

Thorsten Zirwes
- MR#812 - https://bugs.openfoam.org/view.php?id=4279 で報告されたcubic schemeのbugfix

Marine Lasbleis
- MR#827 - BUG: `interFoam`のalpha equationでoff-centered coefficientが正しく使用されない問題
- MR#793 - `inverseDistance`に`.correctBoundaryConditions()`を追加する修正

David Von Rüden
- MR#805 - Tutorial: `interFoam`の`sloshingTank2D`で`Allclean`から`CleanFunctions`をsourceするよう修正

Ilya Popov
- MR#790 - `wmakeLnInclude`における`ln` callをbatch化

Zhisong Li
- MR#785 - `BoussinesqWaveModel.C`、`GrimshawWaveModel.C`、`McCowanWaveModel.C`のbugを修正

貢献: Issue tracking

Gerasimos Chourdakis（MakisH）: v2512 — Ubuntu 24.04向けDebian packageが破損 GL#3480
Masashi Imano（masaz）: `ThirdParty-v2512.tgz`へのlink切れ（404 Not Found） GL#3482
Robert Perry（skoloCFD）: `pitzDaily_fused` tutorialが実行できない問題 GL#3485
franco otaola（otaola.franc）: `blockMesh`のprojectionに関する問題 GL#3490
Carsten Thorenz（cthorenz）: `fvOptions` — geometric selectionが反対方向へ移動する問題 GL#3491
Carsten Thorenz（cthorenz）: `fvOptions` — geometric selectionが誤ったconsole情報を生成する問題 GL#3492
xpqiu（xpqiu）: SPDP modeにおける`ensightSurfaceWriter`の予期しない動作 GL#3493
Frederic Simonis（fsimonis）: Ubuntu 25.10 Questingにおけるpackage mismatch GL#3496
Asahi Yoshimitsu（YAsahi）: `chtMultiRegionTwoPhaseEulerFoam`と`jouleHeatingSource`の組み合わせで存在しないtime directoryを読み込もうとする問題 GL#3499
xpqiu（xpqiu）: PIMPLE dictionary内の`residualControl`に関する可能性のあるbug GL#3500
Santiago Marquez Damian（santiagomarquezd）: `twoPhaseMixture`で作成後に`alpha2`が更新されなくなる問題 GL#3501
Marine Lasbleis（marinelasbleis）: `inverseDistance` diffusivity GL#3502
Mahi_848（MahishMohan）: `patchDistanceToCell`／`topoSet` GL#3503
yongsheng fu（fuys）: `wmakeFilesAndOptions: command not found` GL#3505
Masaru Sato（satorccm）: coded source termにおける`eqn.diag()`および`eqn.source()`の符号が逆 GL#3508
David Von Ruden（OpenFoe）: Third-Party-v2512のScotch 6.1.0がUbuntu 25.10でbuildに失敗 GL#3510
Yannick Eberhard（Yannick.Eberhard）: `propellerInfo` functionObjectが誤ったcylindrical velocityを計算 GL#3511
Anna Hochberger（hochbean）: Solar radiationを追加するとsurfaceが冷却される問題 GL#3512
GiuseppeGq20（GiuseppeGq20）: `snappyHexMesh` error — `wheelRotMesh`のstatic meshがv2106より新しいOpenFOAMで失敗 GL#3513
Robert Perry（skoloCFD）: `snappyHexMesh`で最終meshのみを書き出し、intermediate stepを書き出さないoption GL#3515
Robert Perry（skoloCFD）: `hostCollated`使用時にnode数を変更すると`redistributePar`が失敗する問題の修正 GL#3516
Robert Perry（skoloCFD）: `driveAer` test caseにおける`fusedGauss`の大きな差異 GL#3519
Robert Perry（skoloCFD）: `snappyHexMesh`およびutilityの高速化 — phaseごとのdecompositionと`foamMeshPipeline` GL#3520
Robert Perry（skoloCFD）: sampled wall faceを有効なtet decompositionに配置できない場合に`nearWallFields`がcrashする問題 GL#3523
Mark Olesen（olesenm）: Python binding supportの追加 GL#3524
Robert Perry（skoloCFD）: single precision solveで無効なpointが存在する場合に`sample` utilityがcrashする問題 GL#3526
Zhouping Li（bajfi）: `ISpanStream` bug GL#3530
Robert Perry（skoloCFD）: `applyBoundaryLayer`でslip wall、`movingWallVelocity` patchなどを除外すべき問題 GL#3534
Sajad Khodadadi（sajad.khodadadi）: library、solver、tutorialおよび必要なcore integration変更を含むsolver-level Immersed Boundary framework GL#3536
tulasihazarath-mcw（tulasihazarath-mcw）: OpenFOAMのWindows on ARM（ARM64）support GL#3538
Robert Perry（skoloCFD）: BUG — single precision DESがrestartに失敗。「Start time is not the same for all processors」 GL#3544
Zhouping Li（bajfi）: `objectRegistry` bug GL#3550
Alexey Matveichev（alexey.matveichev）: ENH — multi-region solver向けconvergence control GL#3555
Zhouping Li（bajfi）: symmetry patch向け`PatchInteraction` GL#3556
Zhouping Li（bajfi）: `StochasticCollision`のprobability comparison error GL#3559
Rbemi（Rbemi）: `regionFaMaxCo`が読み込まれなくなった問題 GL#3560

OpenFOAM Teamについて

OpenFOAMは、KeysightのOpenFOAM core teamによって開発されています。

Andrew Heather
Mattijs Janssens
Mark Olesen
Prashant Sonakar
Pawan Ghildiyal
Kutalmış Berçin
Matej Forman
Chiara Pesci
Martin Lichtmes
Jiri Polansky
Niloufar Bordbar
Vijaya Kumar G
Swapnil Salokhe
Matthieu Niess
Solange Lecat

より広範なサポートとして、

Keysight Technologiesのglobal team

からの支援を受けています。

また、

OpenFOAM Community

からの貢献を受けています。

OpenFOAM v2606 リリースノート

OpenFOAM® v2606 新リリース

Pre-processing

distributedTriSurfaceMeshの更新

チュートリアル

ソースコード

Merge request

splitMeshRegions utilityの改良

customRegionNames

useSelectedFaceZones

ソースコード

Merge request

新しいpatchDistanceToCell cell source

ソースコード

Merge request

チュートリアル

Issue

Numerics

Overset gridにおけるinverseDistance methodの改良

Fringe-to-fringe cascadeの防止

Empty-stencilの保護

ソースコード

Finite Areaの改良

AMI cacheの改良: restart

ソースコード

Solvers and physics

新しい2方程式RANS乱流モデル: GEKO

GEKOのcalibration coefficient

実装されている主な機能

Verification

ソースコード

Merge request

参考文献

新しいLagrangian patch interaction model: BaiGosman

主な機能

設定例

ソースコード

Merge request

参考文献

turbulentDigitalFilterInlet境界条件のconvolution改良

Convolutionのparallel化

Performance

ソースコード

Merge request

Heat diffusionの改良

Isotropic thermal conductivity

Anisotropic thermal conductivity

ソースコード

Merge request

Tutorial

Post-processing

新しいrelativeVelocity function object

specified mode

MRF mode

solidBodyRotation mode

Background cellの扱い

ソースコード

Tutorials

Polyhedral cell conversionの新しいoption

Faceのみのdecomposition

topoSetによるselectionの作成

ソースコード

Tutorial

Issue

Conversion toolの改良

Processor boundaryのartefact除去

Output fileのbase name指定

Absolute output pathへの対応

Surface noiseの改良

Geometryを持たないsampling dataへの対応

Ensight collatedTimeの修正

新しいagglomeration visualisation

agglomerationInfo function object

Agglomeration table

ソースコード

Infrastructure

Community contribution: GPU

Background

GPU対応の基本方針

開発協力