OpenFOAM v2606 リリースノート

提供：オープンCAEWiki OpenCAE Wiki
2026年8月11日 (火) 08:56時点におけるMmer547 (トーク | 投稿記録)による版 (ページの作成:「=OpenFOAM® v2606 新リリース= OpenFOAM Teamは、2026年6月リリースのOpenFOAM® v2606を発表します。 今回のリリースでは、[https://www.openfoam.com/news/main-news/openfoam-v2512 OpenFOAM-v2512]の機能が、コードのさまざまな領域にわたって拡張されています。 新機能には、Keysightの顧客がスポンサーとなった開発、社内資金による開発、および[https://www.openfoam.com/governance/overview…」)
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
ナビゲーションに移動 検索に移動

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も提供されています。

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

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

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

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が発生する可能性があります。

ソースコード

Tutorial

Merge request

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

Documentation

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

Documentation

新しい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`を採用
  • 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

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

また、

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

「https://wiki.opencae.or.jp/index.php?title=OpenFOAM_v2606_リリースノート&oldid=884」から取得