オープンCAEWiki OpenCAE Wiki - 利用者の投稿記録 [ja]

OpenLB

2026-03-19T23:14:19Z

Mmer547: /* GPUのみで計算実行 */

''OpenLBプロジェクトは、格子ボルツマン法を実装するためのC++パッケージを提供しています。このパッケージは、数値流体力学など、幅広いマルチフィジックス輸送問題に対応します。ソースコードは公開されており、読みやすく、モジュール化され、プラットフォームに依存しない方法で構築されています。これにより、学術アプリケーションと高度なエンジニアリングアプリケーションの両方で、迅速な実装が可能になります。また、新しい物理モデルを追加するための拡張も容易です。''

[https://www.openlb.net/ 公式ホームページ]

== インストール ==

=== Windows＋WSL ===
まずWSLをインストールする。<ref>https://learn.microsoft.com/ja-jp/windows/wsl/install</ref>

OpenLBをダウンロードする。<ref>https://www.openlb.net/download/</ref>ダウンロードしたら圧縮ファイルを解凍する。

WSLを起動する。

WSL内にmakeをインストールする。<syntaxhighlight lang="bash">
sudo apt update
sudo apt install make gcc g++ openmpi-bin libopenmpi-dev
</syntaxhighlight>WSL内で解答した圧縮ファイルのフォルダに移動する。

makeを実行します。<syntaxhighlight lang="bash">
make
</syntaxhighlight>これでOpenLBのコンパイルは完了です。

=== インストールの確認 ===
試しに簡単なソルバをコンパイルして計算してみます。<syntaxhighlight lang="bash">
cd examples/laminar/cavity2d
</syntaxhighlight>makeします。<syntaxhighlight lang="bash">
make
</syntaxhighlight>計算を実行してみます。<syntaxhighlight lang="bash">
./cavity2d
</syntaxhighlight>cavity2dフォルダ内にtmpフォルダが作成され、その中に計算結果が保存されています。

vtkDataフォルダの中にあるcavity2dvtk.pvdをParaViewで読み込み、計算が実行されていることを確認してください。

== GPUのみで計算実行 ==

=== WSL ===

==== CUDAのインストール ====
Windows側でNVIDIAのドライバーを入れておき、nvidia-smiコマンドが実行できることを確認する。

cudaをインストールする。<ref>https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&Distribution=WSL-Ubuntu&target_version=2.0&target_type=deb_local</ref><syntaxhighlight lang="bash">
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.2.0/local_installers/cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-13-2-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-2
</syntaxhighlight>インストール出来たら環境変数を追加する。<syntaxhighlight lang="bash">
echo 'export PATH="${PATH}:/usr/local/cuda-13.2/bin"' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/cuda-13.2/lib64"' >> ~/.bashrc
source ~/.bashrc
</syntaxhighlight>

==== OpenLBの再コンパイル ====
config.mkをconfig/gpu_only.mkを参考に書き換える。

GPUによってパラメータの変更は必要。

（RTX2060の場合）<syntaxhighlight lang="makefile">
# Example build config for OpenLB using CUDA on single GPU systems
#
# Tested using CUDA 11.4
#
# Usage:
# - Copy this file to OpenLB root as `config.mk`
# - Adjust CUDA_ARCH to match your specifc GPU
# - Run `make clean; make`
# - Switch to example directory, e.g. `examples/laminar/cavity3dBenchmark`
# - Run `make`
# - Start the simulation using `./cavity3d`

CXX := nvcc
CC := nvcc

CXXFLAGS := -O3
CXXFLAGS += -std=c++20 --forward-unknown-to-host-compiler

PARALLEL_MODE := NONE

PLATFORMS := CPU_SISD GPU_CUDA

# for e.g. RTX 30* (Ampere), see table in `rules.mk` for other options
CUDA_ARCH := 75

FLOATING_POINT_TYPE := float

USE_EMBEDDED_DEPENDENCIES := ON

</syntaxhighlight>再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== ソルバのコンパイル ====
ソルバも再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== 実行 ====
実行はCPU版と同じ。<syntaxhighlight lang="bash">
./<solver>
</syntaxhighlight>
----<references />

OpenLB

2026-03-19T23:03:16Z

Mmer547:

''OpenLBプロジェクトは、格子ボルツマン法を実装するためのC++パッケージを提供しています。このパッケージは、数値流体力学など、幅広いマルチフィジックス輸送問題に対応します。ソースコードは公開されており、読みやすく、モジュール化され、プラットフォームに依存しない方法で構築されています。これにより、学術アプリケーションと高度なエンジニアリングアプリケーションの両方で、迅速な実装が可能になります。また、新しい物理モデルを追加するための拡張も容易です。''

[https://www.openlb.net/ 公式ホームページ]

== インストール ==

=== Windows＋WSL ===
まずWSLをインストールする。<ref>https://learn.microsoft.com/ja-jp/windows/wsl/install</ref>

OpenLBをダウンロードする。<ref>https://www.openlb.net/download/</ref>ダウンロードしたら圧縮ファイルを解凍する。

WSLを起動する。

WSL内にmakeをインストールする。<syntaxhighlight lang="bash">
sudo apt update
sudo apt install make gcc g++ openmpi-bin libopenmpi-dev
</syntaxhighlight>WSL内で解答した圧縮ファイルのフォルダに移動する。

makeを実行します。<syntaxhighlight lang="bash">
make
</syntaxhighlight>これでOpenLBのコンパイルは完了です。

=== インストールの確認 ===
試しに簡単なソルバをコンパイルして計算してみます。<syntaxhighlight lang="bash">
cd examples/laminar/cavity2d
</syntaxhighlight>makeします。<syntaxhighlight lang="bash">
make
</syntaxhighlight>計算を実行してみます。<syntaxhighlight lang="bash">
./cavity2d
</syntaxhighlight>cavity2dフォルダ内にtmpフォルダが作成され、その中に計算結果が保存されています。

vtkDataフォルダの中にあるcavity2dvtk.pvdをParaViewで読み込み、計算が実行されていることを確認してください。

== GPUのみで計算実行 ==

=== WSL ===

==== CUDAのインストール ====
Windows側でNVIDIAのドライバーを入れておき、nvidia-smiコマンドが実行できることを確認する。

cudaをインストールする。<ref>https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&Distribution=WSL-Ubuntu&target_version=2.0&target_type=deb_local</ref><syntaxhighlight lang="bash">
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.2.0/local_installers/cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-13-2-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-2
</syntaxhighlight>インストール出来たら環境変数を追加する。<syntaxhighlight lang="bash">
echo 'export PATH="${PATH}:/usr/local/cuda-13.2/bin"' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/cuda-13.2/lib64"' >> ~/.bashrc
</syntaxhighlight>

==== OpenLBの再コンパイル ====
config.mkをconfig/gpu_only.mkを参考に書き換える。

GPUによってパラメータの変更は必要。

（RTX2060の場合）<syntaxhighlight lang="makefile">
# Example build config for OpenLB using CUDA on single GPU systems
#
# Tested using CUDA 11.4
#
# Usage:
# - Copy this file to OpenLB root as `config.mk`
# - Adjust CUDA_ARCH to match your specifc GPU
# - Run `make clean; make`
# - Switch to example directory, e.g. `examples/laminar/cavity3dBenchmark`
# - Run `make`
# - Start the simulation using `./cavity3d`

CXX := nvcc
CC := nvcc

CXXFLAGS := -O3
CXXFLAGS += -std=c++20 --forward-unknown-to-host-compiler

PARALLEL_MODE := NONE

PLATFORMS := CPU_SISD GPU_CUDA

# for e.g. RTX 30* (Ampere), see table in `rules.mk` for other options
CUDA_ARCH := 75

FLOATING_POINT_TYPE := float

USE_EMBEDDED_DEPENDENCIES := ON

</syntaxhighlight>再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== ソルバのコンパイル ====
ソルバも再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== 実行 ====
実行はCPU版と同じ。<syntaxhighlight lang="bash">
./<solver>
</syntaxhighlight>
----<references />

OpenLB

2026-03-19T22:55:16Z

Mmer547:

''OpenLBプロジェクトは、格子ボルツマン法を実装するためのC++パッケージを提供しています。このパッケージは、数値流体力学など、幅広いマルチフィジックス輸送問題に対応します。ソースコードは公開されており、読みやすく、モジュール化され、プラットフォームに依存しない方法で構築されています。これにより、学術アプリケーションと高度なエンジニアリングアプリケーションの両方で、迅速な実装が可能になります。また、新しい物理モデルを追加するための拡張も容易です。''

[https://www.openlb.net/ 公式ホームページ]

== インストール ==

=== Windows＋WSL ===
まずWSLをインストールする。<ref>https://learn.microsoft.com/ja-jp/windows/wsl/install</ref>

OpenLBをダウンロードする。<ref>https://www.openlb.net/download/</ref>ダウンロードしたら圧縮ファイルを解凍する。

WSLを起動する。

WSL内にmakeをインストールする。<syntaxhighlight lang="bash">
sudo apt update
sudo apt install make gcc g++ openmpi-bin libopenmpi-dev
</syntaxhighlight>WSL内で解答した圧縮ファイルのフォルダに移動する。

makeを実行します。<syntaxhighlight lang="bash">
make
</syntaxhighlight>これでOpenLBのコンパイルは完了です。

=== インストールの確認 ===
試しに簡単なソルバをコンパイルして計算してみます。<syntaxhighlight lang="bash">
cd examples/laminar/cavity2d
</syntaxhighlight>makeします。<syntaxhighlight lang="bash">
make
</syntaxhighlight>計算を実行してみます。<syntaxhighlight lang="bash">
./cavity2d
</syntaxhighlight>cavity2dフォルダ内にtmpフォルダが作成され、その中に計算結果が保存されています。

vtkDataフォルダの中にあるcavity2dvtk.pvdをParaViewで読み込み、計算が実行されていることを確認してください。

== GPUのみで計算実行 ==

=== WSL ===

==== CUDAのインストール ====
Windows側でNVIDIAのドライバーを入れておき、nvidia-smiコマンドが実行できることを確認する。

cudaをインストールする。<ref>https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&Distribution=WSL-Ubuntu&target_version=2.0&target_type=deb_local</ref><syntaxhighlight lang="bash">
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.2.0/local_installers/cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-13-2-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-2
</syntaxhighlight>インストール出来たら環境変数を追加する。<syntaxhighlight lang="bash">
echo "export PATH=${PATH}:/usr/local/cuda-13.2/bin" >> ~/.bashrc
echo "export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/cuda-13.2/lib64" >> ~/.bashrc
</syntaxhighlight>

==== OpenLBの再コンパイル ====
config.mkをconfig/gpu_only.mkを参考に書き換える。

GPUによってパラメータの変更は必要。

（RTX2060の場合）<syntaxhighlight lang="makefile">
# Example build config for OpenLB using CUDA on single GPU systems
#
# Tested using CUDA 11.4
#
# Usage:
# - Copy this file to OpenLB root as `config.mk`
# - Adjust CUDA_ARCH to match your specifc GPU
# - Run `make clean; make`
# - Switch to example directory, e.g. `examples/laminar/cavity3dBenchmark`
# - Run `make`
# - Start the simulation using `./cavity3d`

CXX := nvcc
CC := nvcc

CXXFLAGS := -O3
CXXFLAGS += -std=c++20 --forward-unknown-to-host-compiler

PARALLEL_MODE := NONE

PLATFORMS := CPU_SISD GPU_CUDA

# for e.g. RTX 30* (Ampere), see table in `rules.mk` for other options
CUDA_ARCH := 75

FLOATING_POINT_TYPE := float

USE_EMBEDDED_DEPENDENCIES := ON

</syntaxhighlight>再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== ソルバのコンパイル ====
ソルバも再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== 実行 ====
実行はCPU版と同じ。<syntaxhighlight lang="bash">
./<solver>
</syntaxhighlight>
----<references />

OpenLB

2026-03-19T22:53:26Z

Mmer547:

''OpenLBプロジェクトは、格子ボルツマン法を実装するためのC++パッケージを提供しています。このパッケージは、数値流体力学など、幅広いマルチフィジックス輸送問題に対応します。ソースコードは公開されており、読みやすく、モジュール化され、プラットフォームに依存しない方法で構築されています。これにより、学術アプリケーションと高度なエンジニアリングアプリケーションの両方で、迅速な実装が可能になります。また、新しい物理モデルを追加するための拡張も容易です。''

[https://www.openlb.net/ 公式ホームページ]

== インストール ==

=== Windows＋WSL ===
まずWSLをインストールする。<ref>https://learn.microsoft.com/ja-jp/windows/wsl/install</ref>

OpenLBをダウンロードする。<ref>https://www.openlb.net/download/</ref>ダウンロードしたら圧縮ファイルを解凍する。

WSLを起動する。

WSL内にmakeをインストールする。<syntaxhighlight lang="bash">
sudo apt update
sudo apt install make gcc g++ openmpi-bin libopenmpi-dev
</syntaxhighlight>WSL内で解答した圧縮ファイルのフォルダに移動する。

makeを実行します。<syntaxhighlight lang="bash">
make
</syntaxhighlight>これでOpenLBのコンパイルは完了です。

=== インストールの確認 ===
試しに簡単なソルバをコンパイルして計算してみます。<syntaxhighlight lang="bash">
cd examples/laminar/cavity2d
</syntaxhighlight>makeします。<syntaxhighlight lang="bash">
make
</syntaxhighlight>計算を実行してみます。<syntaxhighlight lang="bash">
./cavity2d
</syntaxhighlight>cavity2dフォルダ内にtmpフォルダが作成され、その中に計算結果が保存されています。

vtkDataフォルダの中にあるcavity2dvtk.pvdをParaViewで読み込み、計算が実行されていることを確認してください。

== GPUのみで計算実行 ==

=== WSL ===

==== CUDAのインストール ====
Windows側でNVIDIAのドライバーを入れておき、nvidia-smiコマンドが実行できることを確認する。

cudaをインストールする。<ref>https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&Distribution=WSL-Ubuntu&target_version=2.0&target_type=deb_local</ref><syntaxhighlight lang="bash">
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.2.0/local_installers/cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-13-2-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-2
</syntaxhighlight>インストール出来たら環境変数を追加する。<syntaxhighlight lang="bash">
echo export PATH=${PATH}:/usr/local/cuda-13.2/bin >> ~/.bashrc
echo export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/cuda-13.2/lib64 >> ~/.bashrc
</syntaxhighlight>

==== OpenLBの再コンパイル ====
config.mkをconfig/gpu_only.mkを参考に書き換える。

GPUによってパラメータの変更は必要。

（RTX2060の場合）<syntaxhighlight lang="makefile">
# Example build config for OpenLB using CUDA on single GPU systems
#
# Tested using CUDA 11.4
#
# Usage:
# - Copy this file to OpenLB root as `config.mk`
# - Adjust CUDA_ARCH to match your specifc GPU
# - Run `make clean; make`
# - Switch to example directory, e.g. `examples/laminar/cavity3dBenchmark`
# - Run `make`
# - Start the simulation using `./cavity3d`

CXX := nvcc
CC := nvcc

CXXFLAGS := -O3
CXXFLAGS += -std=c++20 --forward-unknown-to-host-compiler

PARALLEL_MODE := NONE

PLATFORMS := CPU_SISD GPU_CUDA

# for e.g. RTX 30* (Ampere), see table in `rules.mk` for other options
CUDA_ARCH := 75

FLOATING_POINT_TYPE := float

USE_EMBEDDED_DEPENDENCIES := ON

</syntaxhighlight>再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== ソルバのコンパイル ====
ソルバも再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== 実行 ====
実行はCPU版と同じ。<syntaxhighlight lang="bash">
./<solver>
</syntaxhighlight>
----<references />

OpenLB

2026-03-19T22:52:20Z

Mmer547:

''OpenLBプロジェクトは、格子ボルツマン法を実装するためのC++パッケージを提供しています。このパッケージは、数値流体力学など、幅広いマルチフィジックス輸送問題に対応します。ソースコードは公開されており、読みやすく、モジュール化され、プラットフォームに依存しない方法で構築されています。これにより、学術アプリケーションと高度なエンジニアリングアプリケーションの両方で、迅速な実装が可能になります。また、新しい物理モデルを追加するための拡張も容易です。''

[https://www.openlb.net/ 公式ホームページ]

== インストール ==

=== Windows＋WSL ===
まずWSLをインストールする。<ref>https://learn.microsoft.com/ja-jp/windows/wsl/install</ref>

OpenLBをダウンロードする。<ref>https://www.openlb.net/download/</ref>ダウンロードしたら圧縮ファイルを解凍する。

WSLを起動する。

WSL内にmakeをインストールする。<syntaxhighlight lang="bash">
sudo apt update
sudo apt install make gcc g++ openmpi-bin libopenmpi-dev
</syntaxhighlight>WSL内で解答した圧縮ファイルのフォルダに移動する。

makeを実行します。<syntaxhighlight lang="bash">
make
</syntaxhighlight>これでOpenLBのコンパイルは完了です。

=== インストールの確認 ===
試しに簡単なソルバをコンパイルして計算してみます。<syntaxhighlight lang="bash">
cd examples/laminar/cavity2d
</syntaxhighlight>makeします。<syntaxhighlight lang="bash">
make
</syntaxhighlight>計算を実行してみます。<syntaxhighlight lang="bash">
./cavity2d
</syntaxhighlight>cavity2dフォルダ内にtmpフォルダが作成され、その中に計算結果が保存されています。

vtkDataフォルダの中にあるcavity2dvtk.pvdをParaViewで読み込み、計算が実行されていることを確認してください。

== GPUのみで計算実行 ==

=== WSL ===

==== CUDAのインストール ====
Windows側でNVIDIAのドライバーを入れておき、nvidia-smiコマンドが実行できることを確認する。

cudaをインストールする。<ref>https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&Distribution=WSL-Ubuntu&target_version=2.0&target_type=deb_local</ref><syntaxhighlight lang="bash">
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.2.0/local_installers/cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-13-2-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-2
</syntaxhighlight>インストール出来たら環境変数を追加する。<syntaxhighlight lang="bash">
export PATH=${PATH}:/usr/local/cuda-13.2/bin >> ~/.bashrc
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/cuda-13.2/lib64 >> ~/.bashrc
</syntaxhighlight>

==== OpenLBの再コンパイル ====
config.mkをconfig/gpu_only.mkを参考に書き換える。

GPUによってパラメータの変更は必要。

（RTX2060の場合）<syntaxhighlight lang="makefile">
# Example build config for OpenLB using CUDA on single GPU systems
#
# Tested using CUDA 11.4
#
# Usage:
# - Copy this file to OpenLB root as `config.mk`
# - Adjust CUDA_ARCH to match your specifc GPU
# - Run `make clean; make`
# - Switch to example directory, e.g. `examples/laminar/cavity3dBenchmark`
# - Run `make`
# - Start the simulation using `./cavity3d`

CXX := nvcc
CC := nvcc

CXXFLAGS := -O3
CXXFLAGS += -std=c++20 --forward-unknown-to-host-compiler

PARALLEL_MODE := NONE

PLATFORMS := CPU_SISD GPU_CUDA

# for e.g. RTX 30* (Ampere), see table in `rules.mk` for other options
CUDA_ARCH := 75

FLOATING_POINT_TYPE := float

USE_EMBEDDED_DEPENDENCIES := ON

</syntaxhighlight>再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== ソルバのコンパイル ====
ソルバも再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== 実行 ====
実行はCPU版と同じ。<syntaxhighlight lang="bash">
./<solver>
</syntaxhighlight>
----<references />

OpenLB

2026-03-19T12:32:09Z

Mmer547:

''OpenLBプロジェクトは、格子ボルツマン法を実装するためのC++パッケージを提供しています。このパッケージは、数値流体力学など、幅広いマルチフィジックス輸送問題に対応します。ソースコードは公開されており、読みやすく、モジュール化され、プラットフォームに依存しない方法で構築されています。これにより、学術アプリケーションと高度なエンジニアリングアプリケーションの両方で、迅速な実装が可能になります。また、新しい物理モデルを追加するための拡張も容易です。''

[https://www.openlb.net/ 公式ホームページ]

== インストール ==

=== Windows＋WSL ===
まずWSLをインストールする。<ref>https://learn.microsoft.com/ja-jp/windows/wsl/install</ref>

OpenLBをダウンロードする。<ref>https://www.openlb.net/download/</ref>ダウンロードしたら圧縮ファイルを解凍する。

WSLを起動する。

WSL内にmakeをインストールする。<syntaxhighlight lang="bash">
sudo apt update
sudo apt install make gcc g++ openmpi-bin libopenmpi-dev
</syntaxhighlight>WSL内で解答した圧縮ファイルのフォルダに移動する。

makeを実行します。<syntaxhighlight lang="bash">
make
</syntaxhighlight>これでOpenLBのコンパイルは完了です。

=== インストールの確認 ===
試しに簡単なソルバをコンパイルして計算してみます。<syntaxhighlight lang="bash">
cd examples/laminar/cavity2d
</syntaxhighlight>makeします。<syntaxhighlight lang="bash">
make
</syntaxhighlight>計算を実行してみます。<syntaxhighlight lang="bash">
./cavity2d
</syntaxhighlight>cavity2dフォルダ内にtmpフォルダが作成され、その中に計算結果が保存されています。

vtkDataフォルダの中にあるcavity2dvtk.pvdをParaViewで読み込み、計算が実行されていることを確認してください。

== GPUのみで計算実行 ==

=== WSL ===

==== CUDAのインストール ====
Windows側でNVIDIAのドライバーを入れておき、nvidia-smiコマンドが実行できることを確認する。

cudaをインストールする。<ref>https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&Distribution=WSL-Ubuntu&target_version=2.0&target_type=deb_local</ref><syntaxhighlight lang="bash">
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.2.0/local_installers/cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-13-2-local_13.2.0-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-13-2-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-2
</syntaxhighlight>インストール出来たら環境変数を追加する。<syntaxhighlight lang="bash">
export PATH=${PATH}:/usr/local/cuda-13.2/bin > ~/.bashrc
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/cuda-13.2/lib64 > ~/.bashrc
</syntaxhighlight>

==== OpenLBの再コンパイル ====
config.mkをconfig/gpu_only.mkを参考に書き換える。

GPUによってパラメータの変更は必要。

（RTX2060の場合）<syntaxhighlight lang="makefile">
# Example build config for OpenLB using CUDA on single GPU systems
#
# Tested using CUDA 11.4
#
# Usage:
# - Copy this file to OpenLB root as `config.mk`
# - Adjust CUDA_ARCH to match your specifc GPU
# - Run `make clean; make`
# - Switch to example directory, e.g. `examples/laminar/cavity3dBenchmark`
# - Run `make`
# - Start the simulation using `./cavity3d`

CXX := nvcc
CC := nvcc

CXXFLAGS := -O3
CXXFLAGS += -std=c++20 --forward-unknown-to-host-compiler

PARALLEL_MODE := NONE

PLATFORMS := CPU_SISD GPU_CUDA

# for e.g. RTX 30* (Ampere), see table in `rules.mk` for other options
CUDA_ARCH := 75

FLOATING_POINT_TYPE := float

USE_EMBEDDED_DEPENDENCIES := ON

</syntaxhighlight>再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== ソルバのコンパイル ====
ソルバも再コンパイルする。<syntaxhighlight lang="bash">
make clean
make
</syntaxhighlight>

==== 実行 ====
実行はCPU版と同じ。<syntaxhighlight lang="bash">
./<solver>
</syntaxhighlight>
----<references />

OpenLB

2026-03-04T10:29:12Z

Mmer547:

OpenLB

2026-02-25T12:42:05Z

Mmer547:

OpenLB

2026-02-25T12:35:59Z

Mmer547: ページの作成:「''OpenLBプロジェクトは、格子ボルツマン法を実装するためのC++パッケージを提供しています。このパッケージは、数値流体力学など、幅広いマルチフィジックス輸送問題に対応します。ソースコードは公開されており、読みやすく、モジュール化され、プラットフォームに依存しない方法で構築されています。これにより、学術アプリケーションと高…」

メインページ

2026-02-25T12:12:40Z

Mmer547: /* 格子ボルツマン法 */

オープンCAEWikiにようこそ！

本wikiはオープンソースCAEソフトウェアについての情報まとめています。
クローズドなwikiではありません。
ご編集されたい方はアカウントをご登録ください。

なお、内容はオープンCAEに関連するものでお願いします。

本wikiはオープンCAE学会が管理しています。
オープンCAE学会については[http://www.opencae.or.jp 公式サイト]を参照してください。

[https://www.opencae.or.jp/ オープンCAE学会公式サイト]

オープンCAE学会リポジトリ [https://gitlab.com/OpenCAE Gitlab] [https://github.com/opencae Github]

=== オープンCAEの前提知識 ===

[[Linux]]

[[解析用語]]

=== CAD ===
[[FreeCAD]]

=== メッシャー ===
[[Netgen]]

[[Gmsh]]

=== 流体 ===
[[OpenFOAM]]

[[SU2]]

=== 構造 ===
[[FrontISTR]]

[[Salome-Meca]]

[[CalculiX]]

[[PrePoMax]]

[[StressRefine]]

[[FEBio]]

[[PlantFEM]]

[[OpenRadioss]]

=== MBD(モデルベースデザイン) ===
[[OpenModelica]]

=== 機構解析 ===

[[MBDyn]]

[[EXUDYN]]

=== 有限要素法ライブラリ・ツールセット ===

[[GetFEM]]

[[DelFEM2]]

[[sparselizard]]

[[ivyFEM]]

=== マルチフィジックス ===
[[Elmer]]

=== 粒子法 ===
[[DualSPHygics]]

[[OpenMPS]]

=== 格子ボルツマン法 ===
[[Palabos]]

[[waLBerla]]

[[OpenLB]]

=== 偏微分方程式ソルバ ===

[[FEniCSx]]

=== 可視化 ===
[[Paraview]]

[[PyVista]]

[[Mayavi]]

=== 最適化 ===
[[OpenMDAO]]

[[OpenDA]]

[[Dakota]]

=== クラウド ===

[[SimScale]]

=== V&V ===
[https://www.opencae.or.jp/activity/committee/vandv/ V&V小委員会(オープンCAE学会)]

[https://feaber.readthedocs.io/ja/latest/ FEABeR]

[https://www.grc.nasa.gov/www/wind/valid/tutorial/overview.html Overview of CFD Verification and Validation]

=== ベンチマーク ===
[https://www.cenav.org/ 計算工学ナビ]

[https://www.en.build.aau.dk/web/cfd-benchmarks CFD benchmarks]

[https://github.com/luo-yining/CFDBench CFDBench]

=== プログラミング ===
[[Python]]

[[C++]]

=== その他 ===

[[物性データベース]]

[[Blender]]

[[Maxima]]

[[REDUCE]]

[https://qiita.com/advent-calendar/2017/openfoam OpenFOAM Advent Calendar 2017]

[https://qiita.com/advent-calendar/2018/opencae-ac2018 オープンCAE Advent Calendar 2018]

[https://qiita.com/advent-calendar/2019/opencae-ac2019 オープンCAE Advent Calendar 2019]

[https://adventar.org/calendars/5192 オープンCAE Advent Calendar 2020]

[https://adventar.org/calendars/6423 オープンCAE Advent Calendar 2021]

[https://qiita.com/advent-calendar/2022/opencae オープンCAE Advent Calendar 2022]

[https://qiita.com/advent-calendar/2023/opencae オープンCAE Advent Calendar 2023]

=== オープンCAE ===
[[オープンCAEの系譜]]

[https://www.youtube.com/channel/UCuffpM6BjZWZ4AEDFiQexEg オープンCAE動画チャンネル]

[[各地の勉強会]]

[[勝手にブックレビュー]]

[[オープンCAE名言集]]

メインページ

2025-01-26T01:58:12Z

Mmer547: /* ベンチマーク */

オープンCAEWikiにようこそ！

本wikiはオープンソースCAEソフトウェアについての情報まとめています。
クローズドなwikiではありません。
ご編集されたい方はアカウントをご登録ください。

なお、内容はオープンCAEに関連するものでお願いします。

本wikiはオープンCAE学会が管理しています。
オープンCAE学会については[http://www.opencae.or.jp 公式サイト]を参照してください。

[https://www.opencae.or.jp/ オープンCAE学会公式サイト]

オープンCAE学会リポジトリ [https://gitlab.com/OpenCAE Gitlab] [https://github.com/opencae Github]

=== オープンCAEの前提知識 ===

[[Linux]]

[[解析用語]]

=== CAD ===
[[FreeCAD]]

=== メッシャー ===
[[Netgen]]

[[Gmsh]]

=== 流体 ===
[[OpenFOAM]]

[[SU2]]

=== 構造 ===
[[FrontISTR]]

[[Salome-Meca]]

[[CalculiX]]

[[PrePoMax]]

[[StressRefine]]

[[FEBio]]

[[PlantFEM]]

[[OpenRadioss]]

=== MBD(モデルベースデザイン) ===
[[OpenModelica]]

=== 機構解析 ===

[[MBDyn]]

[[EXUDYN]]

=== 有限要素法ライブラリ・ツールセット ===

[[GetFEM]]

[[DelFEM2]]

[[sparselizard]]

[[ivyFEM]]

=== マルチフィジックス ===
[[Elmer]]

=== 粒子法 ===
[[DualSPHygics]]

[[OpenMPS]]

=== 格子ボルツマン法 ===
[[Palabos]]

[[waLBerla]]

=== 偏微分方程式ソルバ ===

[[FEniCSx]]

=== 可視化 ===
[[Paraview]]

[[PyVista]]

[[Mayavi]]

=== 最適化 ===
[[OpenMDAO]]

[[OpenDA]]

[[Dakota]]

=== クラウド ===

[[SimScale]]

=== V&V ===
[https://www.opencae.or.jp/activity/committee/vandv/ V&V小委員会(オープンCAE学会)]

[https://feaber.readthedocs.io/ja/latest/ FEABeR]

[https://www.grc.nasa.gov/www/wind/valid/tutorial/overview.html Overview of CFD Verification and Validation]

=== ベンチマーク ===
[https://www.cenav.org/ 計算工学ナビ]

[https://www.en.build.aau.dk/web/cfd-benchmarks CFD benchmarks]

[https://github.com/luo-yining/CFDBench CFDBench]

=== プログラミング ===
[[Python]]

[[C++]]

=== その他 ===

[[物性データベース]]

[[Blender]]

[[Maxima]]

[[REDUCE]]

[https://qiita.com/advent-calendar/2017/openfoam OpenFOAM Advent Calendar 2017]

[https://qiita.com/advent-calendar/2018/opencae-ac2018 オープンCAE Advent Calendar 2018]

[https://qiita.com/advent-calendar/2019/opencae-ac2019 オープンCAE Advent Calendar 2019]

[https://adventar.org/calendars/5192 オープンCAE Advent Calendar 2020]

[https://adventar.org/calendars/6423 オープンCAE Advent Calendar 2021]

[https://qiita.com/advent-calendar/2022/opencae オープンCAE Advent Calendar 2022]

[https://qiita.com/advent-calendar/2023/opencae オープンCAE Advent Calendar 2023]

=== オープンCAE ===
[[オープンCAEの系譜]]

[https://www.youtube.com/channel/UCuffpM6BjZWZ4AEDFiQexEg オープンCAE動画チャンネル]

[[各地の勉強会]]

[[勝手にブックレビュー]]

[[オープンCAE名言集]]

メインページ

2025-01-26T01:51:51Z

Mmer547: /* ベンチマーク */

オープンCAEWikiにようこそ！

本wikiはオープンソースCAEソフトウェアについての情報まとめています。
クローズドなwikiではありません。
ご編集されたい方はアカウントをご登録ください。

なお、内容はオープンCAEに関連するものでお願いします。

=== オープンCAEの前提知識 ===

[[Linux]]

[[解析用語]]

=== CAD ===
[[FreeCAD]]

=== メッシャー ===
[[Netgen]]

[[Gmsh]]

=== 流体 ===
[[OpenFOAM]]

[[SU2]]

=== 構造 ===
[[FrontISTR]]

[[Salome-Meca]]

[[CalculiX]]

[[PrePoMax]]

[[StressRefine]]

[[FEBio]]

[[PlantFEM]]

[[OpenRadioss]]

=== MBD(モデルベースデザイン) ===
[[OpenModelica]]

=== 機構解析 ===

[[MBDyn]]

[[EXUDYN]]

=== 有限要素法ライブラリ・ツールセット ===

[[GetFEM]]

[[DelFEM2]]

[[sparselizard]]

[[ivyFEM]]

=== マルチフィジックス ===
[[Elmer]]

=== 粒子法 ===
[[DualSPHygics]]

[[OpenMPS]]

=== 格子ボルツマン法 ===
[[Palabos]]

[[waLBerla]]

=== 偏微分方程式ソルバ ===

[[FEniCSx]]

=== 可視化 ===
[[Paraview]]

[[PyVista]]

[[Mayavi]]

=== 最適化 ===
[[OpenMDAO]]

[[OpenDA]]

[[Dakota]]

=== クラウド ===

[[SimScale]]

=== ベンチマーク ===
[https://www.cenav.org/ 計算工学ナビ]

[https://www.en.build.aau.dk/web/cfd-benchmarks CFD benchmarks]

[https://github.com/luo-yining/CFDBench CFDBench]

=== V&V ===
[https://feaber.readthedocs.io/ja/latest/ FEABeR]

[https://www.grc.nasa.gov/www/wind/valid/tutorial/overview.html Overview of CFD Verification and Validation]

=== プログラミング ===
[[Python]]

[[C++]]

=== その他 ===

[[物性データベース]]

[[Blender]]

[[Maxima]]

[[REDUCE]]

[https://qiita.com/advent-calendar/2023/opencae オープンCAE Advent Calendar 2023]

[https://qiita.com/advent-calendar/2022/opencae オープンCAE Advent Calendar 2022]

[https://adventar.org/calendars/6423 オープンCAE Advent Calendar 2021]

[https://adventar.org/calendars/5192 オープンCAE Advent Calendar 2020]

[https://qiita.com/advent-calendar/2019/opencae-ac2019 オープンCAE Advent Calendar 2019]

[https://qiita.com/advent-calendar/2018/opencae-ac2018 オープンCAE Advent Calendar 2018]

[https://qiita.com/advent-calendar/2017/openfoam OpenFOAM Advent Calendar 2017]

=== オープンCAE ===
[[オープンCAEの系譜]]

[https://www.youtube.com/channel/UCuffpM6BjZWZ4AEDFiQexEg オープンCAE動画チャンネル]

[[各地の勉強会]]

[[勝手にブックレビュー]]

[[オープンCAE名言集]]

=== Wikiについて ===

本wikiはオープンCAE学会が管理しています。
オープンCAE学会については[http://www.opencae.or.jp 公式サイト]を参照してください。

OpenFOAM v2412 リリースノート

2024-12-28T04:04:09Z

Mmer547: All words covert to japanese

== ESI OpenCFD Release OpenFOAM® v2412 ==
OpenCFDは、OpenFOAM® v2412の2024年12月リリースを発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v2406の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージもあります。

* Ubuntu Linux: Ubuntu 用パッケージインストール (近日公開予定)
*openSUSE Linux: パッケージインストール (近日公開予定)
*Redhat Linux variants: パッケージインストール (近日公開予定)
*apptainer イメージ: dockerhub から入手可能 (近日公開予定)

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢がある（詳細）：

* Linux用Windowsサブシステムの使用（Ubuntu、openSUSEなどがベース）
* クロスコンパイルによるネイティブ実行可能ファイル
* ドッカーのインストール

OpenFOAMのapptainerサポートは、事前に組み立てられたイメージではなく、記述ファイルによって提供されます：

* パッケージ/コンテナを確認する

Mac OSXユーザーには、ソースからコンパイルするか、コンパイル済みパッケージのDockerコンテナを使用するオプションがある（詳細はこちら）。

== アップグレード ==

* ユーザー向けのヘルプは、ユーザー・アップグレード・ガイドに記載されています。
* 開発者向けのヘルプは、開発者向けアップグレードガイドに記載されています。

== 前処理 ==

=== createPatchユーティリティの改良 ===
createPatchユーティリティが拡張され、例えばcyclicACMIの作成時に重複した境界面を作成できるようになりました。これは、外部生成メッシュ間のcyclicACMI接続を作成するために使用できます。

system/createPatchDictのサンプル：
<code>// Patches to create.
patches
(
{
//- Master side patch
name central_inlet_couple;
patchInfo
{
type cyclicACMI;
nonOverlapPatch central_inlet_blockage;
neighbourPatch inlet_central_couple;
}
constructFrom patches;
patches (central_inlet);
}
{
//- Blockage
name central_inlet_blockage;
patchInfo
{
type wall;
}
constructFrom patches;
patches (central_inlet);
}

{
//- Slave side patch
name inlet_central_couple;
patchInfo
{
type cyclicACMI;
nonOverlapPatch inlet_central_blockage;
neighbourPatch central_inlet_couple;
}
constructFrom patches;
patches (inlet_couple);
}
{
//- Blockage
name inlet_central_blockage;
patchInfo
{
type wall;
}
constructFrom patches;
patches (inlet_couple);
}
);</code>
注意：createPatchを実行する前に、作成するcyclicACMIパッチが存在してはならない。

チュートリアル

* $FOAM_TUTORIALS/mesh/createPatch/TJunctionSwitching_createPatch

ソースコード

* $FOAM_SRC/utilities/mesh/manipulation/createPatch
* $FOAM_SRC/utilities/mesh/manipulation/mergeMeshes

リクエストのマージ

* Merge request #702

=== snappyHexMeshの改良：スナップの前にレイヤーをバッファリングする。 ===
スナップ前にメッシュにバッファレイヤーを追加できるようになり、スナップアルゴリズムをユーザーが選択できるようになりました。

snappyHexMeshDictの新しいトップレベル・エントリーを使用して、バッファー・レイヤーの追加とメッシュ・モーション機能の使用を選択できるようになりました：
<code>// Type of mesh generation:
// - castellated (default)
// - castellatedBufferLayer
type castellatedBufferLayer;</code>
バッファ層の追加はすべてのメッシュ化されたパッチに適用されます。オプションで、addBufferLayersキーワードを使用してサーフェスごとにオーバーライドできます：
<code>refinementSurfaces
{
sphere
{
// Surface-wise min and max refinement level
level (1 1);
// Disable buffer layers
addBufferLayers false;
}
}</code>
スナップ時に使用するメッシュ・モーション・ソルバの選択：
<code>snapControls
{
..
solver displacementPointSmoothing;
displacementPointSmoothingCoeffs
{
// Use laplacian to untangle problem areas
pointSmoother laplacian;
nPointSmootherIter 10;
}</code>
下の画像は、回転したボックスの外側に追加されたバッファー・セルの単層で、セルはセル・インデックスに従って色分けされている：

2つ目の例は、バッファレイヤーを追加することで、内側と外側の両方の領域を維持しながら、フェイスゾーンにスナップするのに役立つことを示しています。ここでは、セルは非直交性に従って色付けされている：

バッファレイヤーは（まだ）フィーチャーのエッジを考慮していないことに注意してください。

チュートリアル

* $FOAM_TUTORIALS/mesh/snappyHexMesh/rotated_block Meshing the outside of a rotated cube.
* $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_multiRegion Meshing the inside and outside of a sphere.

ソースコード

* $FOAM_SRC/utilities/mesh/generation/snappyHexMesh

リクエストのマージ

* Merge request #715

== 境界条件 ==

=== pointMeshの境界処理の改善 ===
pointMeshはパッチのリスト（オプション）を持つようになった。通常の動作は、pointMeshはボリュームの'poly'メッシュと同じパッチのセットを使い、'poly'パッチのポイントで操作します。

ポイントパッチ条件をpolyMesh/pointMesh/boundaryファイルで指定できるようになり、フィーチャーのエッジ、ポイント、内部ポイントにも制約を適用できるようになりました。

チュートリアルのmesh/blockMesh/sphere7は、これを使用して球状のブロックメッシュを立方体に戻す方法を示しています。

このチュートリアルでは、プラグインのポイントスムーサーを使う、新しいdisplacementPointSmoothingモーションソルバーの使用例も紹介します：

* laplacian : 近隣点の平均位置
* geometricElementTransform : 最も直交する形状に移動する。

注

* 点の移動中に点法線が更新されない
* ポイントモーションでは、周期的なパッチは現在正しく処理されていません。
* これらの追加pointPatchは以下によってサポートされる：
** moveDynamicMesh, subsetMesh
** decomposePar, reconstructPar, redistributePar
** some mesh motion solvers

チュートリアル

* $FOAM_TUTORIALS/mesh/blockMesh/pipe
* $FOAM_TUTORIALS/mesh/blockMesh/sphere7
* $FOAM_TUTORIALS/mesh/moveDynamicMesh/badMove
* $FOAM_TUTORIALS/mesh/moveDynamicMesh/bendJunction
* $FOAM_TUTORIALS/mesh/moveDynamicMesh/faceZoneBlock

ソースコード

* $FOAM_SRC/OpenFOAM/meshes/pointMesh/pointBoundaryMesh/pointBoundaryMesh.C

リクエストのマージ

* Merge request #715

=== 新しいポイントパッチ機能 ===

* topoSet に patchToPoint が追加されました : pointPatch のすべての点を選択します (patchToFace と faceToPoint を使って polyPatch の点を取得します)。
* 新しい点境界条件：edgeSlipとpointAttraction（新しいpointMesh境界条件のチュートリアルで使用されます。）
* symmetryPolyPatch : 平均方位を計算する際に、ゼロサイズの面を無視する。これは、後の押し出しのために厚さゼロのレイヤーを追加できるようにするための便利な機能です。

== 数値 ==

=== 新しい融合離散化 ===
新しい融合離散化手法は、中間補間ステップを回避し、面ベースの積分と融合する。機能は通常の離散化と同等です：

* gradSchemes : fusedGauss
* divSchemes : fusedGauss
* laplacianSchemes : fusedGauss, fusedLeastSquares

これらの方式はメモリ操作を回避するため、パッチ数が多い場合や、GPUがCPUのデータにアクセスするなど、メモリアクセスが遅いノードに有利である。 logs-gauss'がデフォルトの動作、'logs-fused'がドロップイン置換融合スキームを示しています：

これは予備的な作業であり、明示的な操作しか考慮していないこと、また操作の順序が異なるために切り捨て誤差が異なることに注意されたい。

チュートリアル

* $FOAM_TUTORIALS/ncompressible/simpleFoam/pitzDaily_fused

ソースコード

* $FOAM_SRC/src/fusedDiscretisation

リクエストのマージ

* MR!712

=== 新しいGAMGアグロメレーション・キャッシング ===
メッシュを動かすケースでは、時間ステップごとに（あるいは圧力補正ごとに）自動的に凝集を再構築します。しかし、ほとんどのメッシュモーションのケースでは、GAMGアグロメレーションテーブルは、再作成が必要になる前に、いくつかの反復のために保持することができます。ソリッドボディモーションの場合、凝集ロジックは行列係数にのみ依存するため、テーブルを更新する必要はありません。キャッシュは新しい updateInterval エントリで有効になります。これは、ソリッドボディシミュレーションでは非常に大きな数値になります。一般的なメッシュモーションでは、予想されるメッシュクーラント数に基づいて設定する必要があります。
<code>p
{
solver GAMG;
..
cacheAgglomeration yes;
updateInterval 100000;
}</code>
凝集に関する詳細なフィードバックを得るには、system/controlDictのデバッグ・スイッチを有効にしてください。
<code>DebugSwitches
{
// Print agglomeration
GAMGAgglomeration 1;
}</code>
faceAreaWeightの最適化

デフォルトの凝集法は、セルを結ぶ面重みの大きさに基づく「セル」の一対一の組み合わせを採用している。現在、これは軸合わせされたメッシュ上の凝集境界のジッターを避けるために摂動された面面積ベクトルから派生した面重みを使用しています。

updateIntervalが1でない場合は、ガウシアンタイプの離散化との整合性を高めるために、スケーリングされていない、摂動されていない顔の面積の大きさを用いて重みが計算される。例えば、simpleFoamを10回繰り返したincompressible/pisoFoam/SLES/motorBikeのチュートリアルでは、平均約10％のサイクル削減を示しました：

代数的凝集はupdateIntervalで実行できることに注意。

* それはcyclicA(C)MIを更新せず、粗いレベルでは古いステンシルを使用するため、補間に失敗する。
* それは、シミュレーション中に変化する行列係数に基づいているため、固体の運動中であっても一定ではない。

チュートリアル

* $FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/propeller

ソースコード

* $FOAM_SRC/finiteVolume/fvMatrices/solvers/GAMGSymSolver/GAMGAgglomerations/faceAreaPairGAMGAgglomeration

リクエストのマージ

* Merge request #707

=== lduMatrix, lduAddressingの改善 ===
スカラー行列クラス lduMatrix が拡張され、セルベースのアルゴリズムがより使いやすくなりました。アドレス指定 lduAddressing には、下位アドレス指定を返す lowerCSRAddr アクセサが追加され、loSortAddressing を使った追加的なインダイレクトを避けることができます：
<code>const labelUList& lduAddressing::lowerCSRAddr() const</code>
これは、lowerAddr()アドレッシングからオンザフライで構築される。

さらに、この行列には、対応する lower() 係数の並べ替えを返す lowerCSR() アクセサが追加された：
<code>const scalarField& lduMatrix::lowerCSR() const</code>
アドレス指定が可能かどうかは、hasLowerCSR()関数で確認できる。

使用例は lduMatrix::Amul ルーチンの中にあります：
<code>if (hasLowerCSR())
{
// Note: lowerCSR constructed from lower if available, upper otherwise
// so is handling symmetric()
const scalar* const __restrict__ lowercsrPtr = lowerCSR().begin();

for (label cell=0; cell<nCells; cell++)
{
scalar& val = ApsiPtr[cell];

val = diagPtr[cell]*psiPtr[cell];

// Add lower contributions
{
const label start = loStartPtr[cell];
const label end = loStartPtr[cell+1];

for (label i = start; i < end; i++)
{
const label nbrCell = lcsrPtr[i];
val += lowercsrPtr[i]*psiPtr[nbrCell];
}
}
// Add upper contributions
{
const label start = oStartPtr[cell];
const label end = oStartPtr[cell+1];

for (label i = start; i < end; i++)
{
const label nbrCell = uPtr[i];
val += upperPtr[i]*psiPtr[nbrCell];
}
}
}
}</code>
ソースコード

* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduAddressing/lduAddressing.H
* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrix.H
* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixATmul.C

=== 壁との距離の改善 ===
乱流壁関数などで使用されている壁面近傍距離フィールドが壁面に対して更新され、複数の壁面パッチに面を持つセルの挙動が変更されました。最近接距離は、セル中心から局所的な壁面、または任意の局所的なエッジまたは点に接続された面までの最小距離として計算されます。

* これは並列一貫性がない
* これは一面しか見ない

より一貫した挙動を得るためには、正確な壁面距離法を採用すべきである。

以前の動作（OpenFOAM v2406 以前）は、etc/controlDict またはローカルの system/controlDict の useCombinedWallPatch 情報スイッチを無効にすることで得られます：
<code>OptimisationSwitches
{
useCombinedWallPatch 0;
}</code>
ソースコード

* $FOAM_SRC/meshTools/cellDist/cellDistFuncs.C
* $FOAM_SRC/finiteVolume/fvMesh/wallDist/nearWallDist/nearWallDist.C
* $FOAM_SRC/finiteVolume/fvMesh/wallDist/wallDistAddressing/wallDistAddressing.C
* $FOAM_SRC/meshTools/cellDist/patchWave/patchDataWave.C
* $FOAM_SRC/meshTools/cellDist/patchWave/patchWave.C

リクエストのマージ

* Merge request #700

問題

* Issue #3215

=== 地域貢献：アドジョイント最適化の改善 ===
OpenFOAM v2412では、アジョイント・ライブラリにいくつかの機能変更が加えられました。トポロジー最適化の設計変数の初期値を0/alphaフィールドから読み込めるようになり、topoSet/setFieldsユーティリティで簡単に設定できるようになりました。以前は、0/uniform/topOVarsを通してのみ可能でしたが、これは操作が難しくなっています。

ISQPの数学的最適化問題に追加され、実現可能性を保証するためにMMAに追加された項の乗数（'c'と命名）は、関数1で与えられるようになり、最適化ループ全体で操作できるようになりました。典型的な例としては、実現可能性よりも最適性を重視するために、最初の数サイクルの最適化では小さな値に設定し、徐々に大きくしていきます。

ISQPで近似ヘシアンの減衰を無効にするオプションを追加。一般的なケースでは、これは避けるべきですが、いくつかのフリンジケースではアルゴリズムを加速させることができます。

チュートリアル

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/1_Inlet_2_Outlet/porosityBased/R_10x-init

ソースコード

* $FOAM_SRC/optimisation/adjointOptimisation

リクエストのマージ

* Merge request #710

=== 新ゾーンブレンド・スキーム ===
新しいzoneBlendedスキームにより、ユーザーはフェイスゾーンごとに差分スキームを適用できる。スキームは辞書形式で設定される：
<code>divSchemes
{
.
.
div(phi,U) Gauss zoneBlended
{
default defaultScheme;
faceZone1 scheme1;
faceZone2 scheme2;
...
faceZoneN schemeN;
}
.
.
}</code>
デフォルトのエントリーは背景スキームを指定します。追加のスキームをフェイスゾーンごとに設定できます。例えば、スキーム1はフェイスゾーン1に適用され、スキーム2はフェイスゾーン2に適用されます。

ソースコード

* $FOAM_SRC/finiteVolume/interpolation/surfaceInterpolation/schemes/zoneBlended

== ソルバーと物理モデル ==

=== 地域貢献： SA-DDES乱流モデルの遮蔽機能の改善 ===
DDES（Delayed Detached-Eddy Simulation）モデル[1]は、RANS/LESのハイブリッドアプローチであり、RANSによってすべての付着境界層をモデル化し、LESによって大きく分離した流れ領域をモデル化することを目的としています。付着境界層内部でのLESモードの起動を防止するために、「遮蔽」機能と呼ばれる追加的なセーフガード機能が実装されています。残念ながら，標準的な定式化[1]は，細かい格子上で崩壊することがあり，壁せん断応力の低下や，流れの早期剥離につながる可能性がある．これらの現象は、文献ではしばしば "モデル化された応力の枯渇 "や "グリッド誘起剥離 "と呼ばれています。 Deck & Renard [2]は最近、よりロバストな挙動を提供しながら、分離したせん断層でのLESへの迅速な切り替えを可能にする、改良された遮蔽関数を提案しました。この定式化は、SA-DDESモデルの変形であるZDESモード2（2020）乱流モデル用に開発されました。図は，後縁が分離した NACA4412 翼周りの流れに対して，改良された遮蔽機能の利点を示しています．吸込側のグリッドが流れ方向とスパン方向で強くリファインされているため，標準の遮蔽機能が後退し，流れの剥離が早期に発生している．一方，改良された遮蔽関数は，吸込側の付着境界層領域全体で RANS モードを保持し，NASA コード CFL3D の参照 RANS とよく一致する．

以下の乱流モデリング機能がv2412リリースに含まれています：

* Improved shielding function formulation of Deck & Renard [2], implemented for SpalartAllmarasDDES, activated via the new option “shielding” (keyword “standard” selects the standard function [1], “ZDES2020” selects the improved formulation [2]).
* An additional option “usefP2” activates a more robust shielding mode for the Deck & Renard formulation (detailed in equation A.9 of [2]).

使用例
<code>simulationType LES;
LES
{
LESModel SpalartAllmarasDDES;
SpalartAllmarasDDESCoeffs
{
// optional keywords for shielding function
shielding ZDES2020; // default: standard
usefP2 false; // default: false
}

delta maxDeltaxyz;

turbulence on;
printCoeffs on;
}</code>
2]で示された定式化はSAベースのDDESに特化して導き出されたものであるため、改善された遮蔽関数はkOmegaSSTDDESモデルには実装されていないことに注意してください。

チュートリアル

* $FOAM_TUTORIALS/incompressible/pimpleFoam/LES/NACA4412

帰属

* The improved shielding function of Deck & Renard (2020) [2] was implemented by Upstream CFD GmbH and integrated into OpenFOAM in collaboration with ESI-UK Ltd with funding by Volkswagen AG.

参考文献

* [1] P. Spalart, S. Deck, M. Shur, K. Squires, M. Strelets, and A. Travin. A new version of detached-eddy simulation, resistant to ambiguous grid densities. Theoretical and Computational Fluid Dynamics, 20(3):181–195, 2006.
* [2] Deck, S., & Renard, N. (2020). Towards an enhanced protection of attached boundary layers in hybrid RANS/LES methods. Journal of Computational Physics, vol. 400, pp. 108970, 2020.

=== 改良されたラグランジュ射出モデル：コーンノズル・インジェクション（coneNozzleInjection ===
このリリースでは、coneNozzleInjectionモデルに2つのマイナーな改良が加えられました：

* 粒子をディスク全体に角度間隔で均一に分布させる新しい射出方法；
* 粒子噴射にインジェクターの推定速度を含める。静的インジェクタの入出力動作に変更はありませんが、移動インジェクタから噴射される粒子の速度にインジェクタの速度が含まれるようになりました。

最小限の使用例は以下の通り：
<code>injectionModels
{
model1
{
type coneNozzleInjection;

...

// The new injection method: discSegments
injectionMethod discSegments;
nInjectors 10;
initialInjectorDir (1 0 0);
}
}</code>
ソースコード

* $FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/InjectionModel/ConeNozzleInjection/ConeNozzleInjection.H

リクエストのマージ

* Merge request #719

=== 改良されたソリッドボディモーション機能：tabulated6DoFMotion ===
表6DoFMotionモデルに線形補間オプションが追加されました。最小限の使用例を以下に示します：
<code>solidBodyMotionFunction tabulated6DoFMotion;

interpolationScheme linear; // spline;</code>
ソースコード

* $FOAM_SRC/meshTools/solidBodyMotionFunctions/tabulated6DoFMotion/tabulated6DoFMotion.H

=== 新しい有限領域のフレームワーク：膜分離モデル ===
有限面積ベースのフィルム曲率分離モデルが更新され、シャープエッジ用の新しいフィルム分離モデルが追加された。これらの更新により、さまざまな幾何学的条件や流動条件下での膜分離予測の精度と柔軟性が向上しました。

主な変更点と追加点

* オーウェン-ライリーモデル：
** 既存のcurvatureSeparationモデルは、Owen & Ryley (1983)の研究に基づき、OwenRyleyModelとして再実装された。このモデルは次のように仮定しています：
*** フィルムが表面から剥がれると、すぐに細かい霧状の液滴になる。その結果、液体が凝集塊として離脱するシナリオを正確に表現できない可能性がある。
*** フィルムは一定の半径を持つ丸みを帯びたコーナーの周囲を流れるため、曲率が明確でない鋭角のコーナーでは適用が制限される可能性がある。
*** 膜厚は1e-4 mより薄く、粘性効果と表面擾乱は無視される。
*** 均一な膜速度と膜厚。
*** 分離基準は明示的に定式化されるのではなく、モデルの仮定に基づいて推測される。
* シャープエッジのための新しいフィルム分離モデル：
** 新しいモデルFriedrichModelを導入し、シャープエッジでの膜分離特性を計算し、完全膜分離と部分膜分離の両方のシナリオをカバーする。このモデルは、Friedrichら（2008）とZhangら（2018）の研究に基づいている：
*** Friedrichら（2008）：
**** 剥離点における制御体積内の力の平衡に根ざした剥離基準を開発。
**** 最大膜厚を1e-4 mと仮定。
**** 表面張力、重力、フィルムの慣性を考慮する。
**** 早期破裂を予測することはできるが、比較的信頼できることが知られている。
**** ANSYS Forte 18.2 に実装されている分離メソッドとして機能します。
*** Zhangら（2018）：
**** 質量分率基準を導入することで、Friedrichらのモデルを強化した。細胞内の膜全体が同時に剥離すると仮定するモデルとは異なり、Zhangらのアプローチは、これらの基準に基づいて膜の一部のみを剥離する。これにより、フィルムが実際にどの程度剥離するかについて、より現実的な予測が可能になった。

包括的な直列および並列テストケースは、ロバストなコーナーおよび分離同定を確実にするために実施され、流れ方向に対して様々な形状や向きの鋭角エッジを持つケース、複数の空間分解能および並列化構成を含む。

その結果、ユーザーは、メッシュの複雑さや計算設定に関係なく、膜分離現象をシミュレーションする際の一貫性と信頼性の向上を期待することができます。

最小限の使用例は以下の通り：
<code>injectionModels
{
filmSeparation
}

filmSeparationCoeffs
{
model OwenRyley;
definedPatchRadii 0;
minInvR1 0;
deltaByR1Min 0;
}</code>
ソースコード

* $FOAM_SRC/regionFaModels/liquidFilm/subModels/kinematic/injectionModel/filmSeparation/filmSeparationModels

チュートリアル

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/pitzDailyWithSprinklers

リクエストのマージ

* Merge request #714

=== simpleFoamの改良：新しいdynamicMeshのサポート ===
simpleFoamはpimpleFoamと同様にdynamicFvMeshをサポートするようになりました。 constant/dynamicMeshDictがあればそれを読み込み、繰り返しごとにupdate()ルーチンを呼び出します。これにより、例えば、動的なメッシュのリファインメント/アンリファインメントを用いた定常シミュレーションが可能になります。

==== 詳細情報 ====

* Issue #3269

== 後処理 ==

=== 新しいレポート作成 ===
foamReport関数オブジェクトは、OpenFOAMの実行データを収集するためのテンプレートベースのテキスト置換システムを提供します。ユーザーが提供するテンプレートファイルは、マークダウン(.md)、ウェブ(.html)、ラテックス(.tex)などのプレーンテキストファイルの形式をとることができます。ダブルハンドル構文{{ENTRY}}を使用して提供された項目は置換されます（大文字と小文字は区別されません）。 OF_で始まる一般的な組み込みエントリのセットが提供されます。

* OF_HOST: ホストマシン名
* OF_CASE_NAME: ケース名
* OF_API: OpenFOAM APIレベル
* OF_DATE_START: ジョブ開始日
* OF_CASE_PATH: ケースへのファイルパス
* ...

組み込みキーとユーザー提供キーの完全なセットは、debugKeysエントリーを使用して書き込むことができる。ユーザー定義の置換は辞書形式でリストされ、置換モデルには以下が含まれる：

* fileRegEx : ファイルからの正規表現
* functionObjectValue : 関数オブジェクトの結果を取り出す
* dictionaryValue : 辞書からの値 - ファイルベースまたはレジストリ検索から
* environmentVariable : キーワードを環境変数に置き換える
* userValue : キーワードをユーザが指定した文字列に置き換える：

マークダウン・テンプレートに基づく使用例：

<code>foamReport1
{
// Mandatory entries (unmodifiable)
type foamReport;
libs (utilityFunctionObjects);

template "/myReportTemplate.md";

substitutions
{
divSchemes1
{
type dictionaryValue;
object fvSchemes;

entries
{
divSchemes "divSchemes";
}
}
fvSolution1
{
type dictionaryValue;
path "/fvSolution";

entries
{
solver_p "solvers/p/solver";
solver_p_tol "solvers/p/tolerance";
solver_p_reltol "solvers/p/relTol";
solver_U "solvers/U/solver";
solver_U_tol "solvers/U/tolerance";
solver_U_reltol "solvers/U/relTol";
}
}
controlDict1
{
type dictionaryValue;
path "/controlDict";

entries
{
initial_deltaT "deltaT";
}
}
continuityErrors
{
type functionObjectValue;
functionObject continuityError1;

entries
{
cont_error_local local;
cont_error_global global;
cont_error_cumulative cumulative;
}
}
}

// Optional entries (runtime modifiable)

// Inherited entries
...
}</code>
マークダウン・ベースのテンプレート・ファイルの例：
<code># <nowiki>{{OF_EXECUTABLE}}</nowiki> : <nowiki>{{OF_CASE_NAME}}</nowiki> tutorial

- Case: : <nowiki>{{OF_CASE_PATH}}</nowiki>
- Submission: <nowiki>{{OF_CLOCK_START}}</nowiki> on <nowiki>{{OF_DATE_START}}</nowiki>
- Report time: <nowiki>{{OF_CLOCK_NOW}}</nowiki> on <nowiki>{{OF_DATE_NOW}}</nowiki>

---

<nowiki>##</nowiki> Run information

<nowiki>| Property |</nowiki> Value |
<nowiki>|----------------|--------------------|</nowiki>
<nowiki>| Host |</nowiki> <nowiki>{{OF_HOST}}</nowiki> |
<nowiki>| Processors |</nowiki> <nowiki>{{OF_NPROCS}}</nowiki> |
<nowiki>| Time steps |</nowiki> <nowiki>{{OF_TIME_INDEX}}</nowiki> |
<nowiki>| Initial deltaT |</nowiki> <nowiki>{{initial_deltaT}}</nowiki> |
<nowiki>| Current deltaT |</nowiki> <nowiki>{{OF_TIME_DELTAT}}</nowiki> |
<nowiki>| Execution time |</nowiki> <nowiki>{{executionTime}}</nowiki> |

---

<nowiki>##</nowiki> OpenFOAM information

<nowiki>| Property |</nowiki> Value |
<nowiki>|----------------|--------------------|</nowiki>
<nowiki>| Version |</nowiki> <nowiki>{{OF_VERSION}}</nowiki> |
<nowiki>| API |</nowiki> <nowiki>{{OF_API}}</nowiki> |
<nowiki>| Patch |</nowiki> <nowiki>{{OF_PATCH}}</nowiki> |
<nowiki>| Build |</nowiki> <nowiki>{{OF_BUILD}}</nowiki> |
<nowiki>| Architecture |</nowiki> <nowiki>{{OF_BUILD_ARCH}}</nowiki> |

---

<nowiki>##</nowiki> Mesh statistics

<nowiki>| Property |</nowiki> Value |
<nowiki>|-------------------|----------------------|</nowiki>
<nowiki>| Bounds |</nowiki> <nowiki>{{OF_MESH_BOUNDS_MIN}}</nowiki><nowiki>{{OF_MESH_BOUNDS_MAX}}</nowiki> |
<nowiki>| Number of cells |</nowiki> <nowiki>{{OF_MESH_NCELLS}}</nowiki> |
<nowiki>| Number of faces |</nowiki> <nowiki>{{OF_MESH_NFACES}}</nowiki> |
<nowiki>| Number of points |</nowiki> <nowiki>{{OF_MESH_NPOINTS}}</nowiki> |
<nowiki>| Number of patches |</nowiki> <nowiki>{{OF_MESH_NPATCHES}}</nowiki> |

---

<nowiki>##</nowiki> Linear solvers

<nowiki>| Property |</nowiki> Value | tolerance(rel) | Tolerance(abs) |
<nowiki>|----------|----------------|------------------|---------------------|</nowiki>
<nowiki>| p |</nowiki> `<nowiki>{{solver_p}}</nowiki>` | <nowiki>{{solver_p_tol}}</nowiki> | <nowiki>{{solver_p_reltol}}</nowiki> |
<nowiki>| U |</nowiki> `<nowiki>{{solver_U}}</nowiki>` | <nowiki>{{solver_u_tol}}</nowiki> | <nowiki>{{solver_u_reltol}}</nowiki> |

---

<nowiki>##</nowiki> Numerical scehemes

The chosen divergence schemes comprised:

[[利用者:Mmer547|mmer547]] ([[利用者・トーク:Mmer547|トーク]])
<nowiki>{{divSchemes}}</nowiki>
[[利用者:Mmer547|mmer547]] ([[利用者・トーク:Mmer547|トーク]])

---

<nowiki>##</nowiki> Graphs

Residuals

<nowiki>![]({{OF_CASE_PATH}}</nowiki>/postProcessing/residualGraph1/<nowiki>{{OF_TIME}}</nowiki>/residualGraph1.svg)

---

<nowiki>##</nowiki> Results

Forces

<nowiki>![]({{OF_CASE_PATH}}</nowiki>/postProcessing/forceCoeffsGraph1/<nowiki>{{OF_TIME}}</nowiki>/forceCoeffsGraph1.svg)

---</code>
ソースコード

* $FOAM_SRC/functionObjects/utilities/foamReport

チュートリアル

* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike

リクエストのマージ

* Merge request #716

=== 新しいグラフ生成 ===
graphFunctionObjectは、ユーザーが関数オブジェクトの結果値のSVGグラフを生成することを可能にします。例えば、進化の残差や、力係数のような削減されたデータを表示します。

最小限の例を以下に示す：
<code>// Generate the result values
solverInfo1
{
type solverInfo;
libs (utilityFunctionObjects);
fields (U p);
}

// Describe the graph
residualGraph
{
// Mandatory entries
libs (utilityFunctionObjects);

functions
{
//entry
//{
// // Mandatory entries
// object ;
// entry ;
//
// // Optional entries
// title ; // Default: take from dict name
// colour ; // labels in range 0-255 (255 0 0)
// dashes ; // (4 1 1)
//}
Ux
{
object solverInfo1;
entry Ux_initial;
}
Uy
{
object solverInfo1;
entry Uy_initial;
}
Uz
{
object solverInfo1;
entry Uz_initial;
}
p
{
object solverInfo1;
entry p_initial;
}
}

// Optional entries
//xMin ;
//xMax ;
//yMin ;
//yMax ;
//xlabel ; // "Iteration";
//ylabel ; // "log10(Initial residual)";
//width ;
//height ;
//strokeWidth ;
//logScaleX ;
//logScaleY ;
//drawGrid ;

// Inherited entries
//...
}</code>
ソースコード

* $FOAM_SRC/functionObjects/utilities/graphFunctionObject

チュートリアル

* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike

=== 新しい有限領域関数オブジェクト：surfaceCourantNumber ===
新しい有限面積関数オブジェクトsurfaceCourantNumberは、有限面積の面中心で表面のクーラント数フィールドを計算します。これは、liquidFilmFoamソルバーで使用されているような、エッジ中心でクーラント数を計算するアプローチからの概念的な転換を意味します。面中心でクーラント数を評価することにより、surfaceCourantNumberは、より局所的で、より正確な表面ベースの流れ解析の指標を提供することができます。

最小限の使用例は以下の通り：
<code>surfaceCourantNumber1
{
// Mandatory entries
type surfaceCourantNumber;
libs (regionFaModels);

// Optional entries
area <word>;
result <word>;
phis <word>;
rho <word>;

// Inherited entries
...
}</code>
ソースコード

* $FOAM_SRC/regionFaModels/functionObjects/surfaceCourantNumber/surfaceCourantNumber.H

チュートリアル

* $FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder

リクエストのマージ

* Merge request #706

=== ソルバー関数オブジェクトの改良アウターループ収束チェック ===
ソルバー関数オブジェクト（scalarTransport、energyTransport、electricPotential）に外部ループの収束チェック機能が追加されました。この改良により、収束が達成された時点で不要なループを排除することで、計算オーバーヘッドを削減し、解法プロセスを合理化することができます。最小限の使用例を以下に示します：
<code>scalarTransport1
{
// Optional entries
tolerance <scalar>;
...
}</code>
ソースコード

* $FOAM_SRC/functionObjects/solvers/scalarTransport/scalarTransport.H
* $FOAM_SRC/functionObjects/solvers/energyTransport/energyTransport.H
* $FOAM_SRC/functionObjects/solvers/electricPotential/electricPotential.H

リクエストのマージ

* Merge request #699

== パラレル ==

=== ノンブロッキング・エクスチェンジ（NBX）の改善 ===
OpenFOAM-v2306では、実験的な「ノンブロッキング・コンセンサス交換」（NBX）オプションが導入されました。 8192コアに複数のcyclicAMIがあり、（etc/controlDictまたはローカルシステム/controlDictに）エントリがある場合です：
<code>OptimisationSwitches
{
// Additional PstreamBuffers tuning parameters (experimental)
// 0 : (legacy PEX)
// * all-to-all for buffer sizes [legacy approach]
// * point-to-point for contents
// 1 : (hybrid PEX)
// * NBX for buffer sizes [new approach]
// * point-to-point for contents
pbufs.tuning 1;
}</code>
以下の時間帯を提供：
{| class="wikitable"
|NBX
|Time (s)
|-
|No
|28k
|-
|Yes
|18k
|}
NBXは、「受信と消費」の順序が「送信の順序」と同じであることを保証していない。これは、cyclicAMIのジオメトリなど、長いメッセージではより敏感であり、一意の「タグ」（デフォルトのPstream::msgType()ではない）を確保するように注意しなければならない。

ソースコード

* $FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation

リクエストのマージ

* Merge request #704

=== 改良された有限領域フレームワーク ===
いくつかの有限領域フレームワークルーチンは、歪度や非直交性に関係なく、平面および非平面有限領域メッシュに影響を与え、並列処理時に一貫性のない挙動を示します。これらの不整合は、主に内部エッジとプロセッサエッジに適用されるアルゴリズムの違いから生じています。例えば、非平面有限面積メッシュのコーナーエッジが2つのプロセッサ間で共有されている場合、接線方向に微妙な正負の摂動が生じることがあります。この摂動は時間の経過とともに伝播し、膜分離のような予期せぬ流れ挙動を引き起こす可能性があります。

入念にテストされた一連のコミットは、主に以下のコアルーチンに対処するために、並列一貫性を改善した：
<code>makeLPN
makeWeights
makeDeltaCoeffs
makeCorrectionVectors
makeSkewCorrectionVectors</code>
ソースコード

* $FOAM_SRC/finiteArea/faMesh/faMeshDemandDrivenData.C
* $FOAM_SRC/finiteArea/faMesh/faPatches/constraint/processor/processorFaPatch.C

リクエストのマージ

* Merge request #708

=== reconstructParMesh の改良 ===
reconstructParMeshユーティリティは、有限面積（'faMesh'）メッシュを再構築することができ、有限面積メッシュが並列に生成される場合に便利です。ソースコード

* $FOAM_UTILITIES/parallelProcessing/reconstructParMesh

リクエストのマージ

* Merge request #711

=== 改良された分散トライサーフェス ===
distributedTriSurfaceMeshは、例えばsystem/snappyHexMeshDictのように、関連する辞書で分解方法を指定することで、他のシミュレーションとは異なる分解方法で実行できるようになりました：
<code>box
{
file "box.obj";
type distributedTriSurfaceMesh;

// Override the decomposition method
numberOfSubdomains 8;
method hierarchical;
n (2 2 2);
}</code>
を指定することで、三角形を複製せずに実行することもできます。
<code>decomposeUsingBbs false;</code>
これは過剰なメモリ使用を回避し、頂点ごとの法線を保存するので、滑らかな法線を持つように拡張できる。

この2つの変更により、単純なメッシュで非並列または並列を実行しても、同じ結果が得られるようになった。下の図では、非平行メッシュを青い面で、平行メッシュを赤い線で表しています。

チュートリアル

* $FOAM_TUTORIALS/mesh/snappyHexMesh/distributedTriSurfaceMesh

ソースコード

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

リクエストのマージ

* Merge request #720

== ユーザビリティ ==

=== C++17に更新 ===
現在進行中のGPU開発をサポートするため、C++の最低規格がC++14からC++17に引き上げられた。

* コミット: #44f7a726
* ソース: $WM_PROJECT_DIR/wmake/rules

=== 新しいチュートリアルのデモンストレーション ===

==== ミッシングコーナー ====
これは様々なメッシュ・ユーティリティを紹介するシンプルなチュートリアルです：

* cellDecomposition関数四角形メッシュを作成するオブジェクト
* テットを多面体に変換するpolyDualMesh
* surfaceMeshExtractで追加のポイントパッチを作成する。
* moveDynamicMeshでメッシュを少し変形させる。メッシュのモーフィングは、特徴制約を無視したラプラシアン点スムージングを使って行われるため、メッシュの品質を向上させるのに悪い働きをします。

ソースコード

* $FOAM_SRC/functionObjects/field/cellDecomposer
* $FOAM_UTILITIES/mesh/manipulation/polyDualMesh

チュートリアル

* $FOAM_TUTORIALS/mesh/polyDualMesh/missingCorner

==== ダム決壊 ====
これはdamBreakチュートリアルの変形で、cyclicACMIを使ってフローをコントロールすることを紹介している。このチュートリアルでは

* 追加の（cyclicACMI）バッフルが液体の流れを遮断する。
* 時刻0.5秒、閉塞部の下半分の面が開く
* これは、スケールファクターを使用して完全非結合（すなわち壁）から完全結合に変換するcyclicACMIによって行われる。
* スケールはconstant/polyMesh/boundaryのパッチ定義にあるコード化されたFunction1の項目を通して設定されます。
* 初期状態：閉塞（赤）

ソースコード

* $FOAM_SRC/OpenFOAM/primitives/functions/Function1/Coded
* $FOAM_SRC/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch

チュートリアル

* $FOAM_TUTORIALS/multiphase/interFoam/RAS/damBreakLeakage

== コミュニティ ==
OpenFOAM v2412のリリースは、OpenFOAMのコアチーム以外からの貢献の努力を認め、OpenFOAMの開発を統一するために、より広いOpenFOAMコミュニティに参加してもらうための継続的な努力の上に成り立っています。

いくつかの開発は、メインのコードベースに直接統合されている。

* 地域貢献：アドジョイント最適化の改良詳細
* 地域貢献： SA-DDES乱流モデルの遮蔽機能を改善詳細...

もし、共同開発の可能性を模索し、あなたの開発したものを含めたいとお考えでしたら、ぜひご連絡ください。

=== 乱流専門委員会リポジトリへの新しい投稿 ===
乱流技術委員会リポジトリ傘下の以下の2つのリポジトリを公開いたします：

* gammaSST :3方程式遷移と乱流モデル。
* HelicitySpalartAllmaras : Liuらのヘリシティ補正を用いたSpalart-Allmaras乱流モデル。

ソースコード

* $FOAM_SRC/$WM_PROJECT_DIR/plugins/turbulence-community

帰属

* OpenCFDは、Jiří Fürst、Jeff Defoe、そして彼らの同僚たちの貴重な貢献と援助に感謝したい。

=== 謝辞 ===

==== 謝辞 ====
OpenFOAMに貢献してくれた以下の方々に感謝します。

==== 特別感謝 ====

* Johan Rønby Pedersen: マルチフェーズフレームワークの並列化に貢献
* マーカス・ノードランド：流体-多孔質界面のモデリングに関する技術的な議論に協力してくれている。

==== 課題追跡への貢献 ====

* ilyapopov (Ilya Popov) リポジトリ内の設定ファイルの迷子？ GL#3192
* carlo.fiorina (carlo fiorina) v2406 で READ_IF_PRESENT の動作に一貫性がない GL#3193
* xpqiu (xpqiu) SPDP モードで実行するとソルバがクラッシュする GL#3194
* gng015 (gng) reconstructParMesh がバイナリでメッシュが大きすぎる場合，メッシュの再構築でスタックする GL#3196
* stefano.garbin (Stefano Garbin) OF2406 で CFMESH 実行ファイルが見つからない GL#3198
* duyquang.tdm.bd (Quang Nguyen) OpenFOAM-v2406 での ccmToFoam のクロスコンパイル時のエラー GL#3199
* ChrisSessler (Christian Sessler) multiComponentMixture と組み合わせた hConst がすべての参照エンタルピーに最初の種の Tref を使用する Href GL#3200
* ChennaK85 (Chennakesava Kadapa) sixDoFRigidBody の Newmark および Crank-Nicolson スキームの問題 GL#3202
* santiagomarquezd (Santiago Marquez Damian) 3 次元未満でテンソルの球面部分が間違って計算される GL#3203
* DL (David Ludlow) overPimpleDyMFoam と v2406 における kOmegaSST 分割の不具合 GL#3204
* bPaillard (Benoit Paillard) オーバーセットチュートリアルにおける圧力変動 GL#3207
* mzy (Zeyao Ma) icoReactingMultiphaseInterFoam V2206 で凝固問題を解くと固相が常に動いてしまう GL#3208
* zzphub (Zhipeng Zhang) 2306 の debian12 ソースビルドに失敗 GL#3210
* Charlfmare (Charl Mare) SwirlFanVelocity が新しい OF バージョンで動作しない GL#3211
* lizhisongsjtu (zhisong li) bug: solitary wave - McCowan and Grimshaw GL#3212
* daniel.jasinski (Daniel) buoyantSimpleFoam の圧力制御の欠落 GL#3213
* pferro (Paulin FERRO) solidificationMeltingSource がバグっぽい GL#3214
* rbonin (Rémi Bonin) precompiled OpenFOAM (v2406 / Windows 10) で表面膜を使用すると reactingParcelFoam がクラッシュする GL#3216
* takuya (takuya yamamoto) blockMeshDict の project 関数のチュートリアルの記述が正しくない GL#3217
* snaka (Shinji Nakagawa) foamMonitor が Gnuplot バージョン 6 の 'reread' コマンドの非推奨のためにグラフの更新に失敗する GL#3219
* ilyapopov (Ilya Popov) energyTransport が dynamicRefineFvMesh と組み合わせて動作しない GL#3221
* ntilton (Nils Tilton) fixedProfile 条件が最後のタイムステップからシミュレーションを再開しない GL#3223
* porori (takashi suzuki) diffusionGasEvaporation: 例題の使い方とチュートリアルが不適切 <= アントワーヌ方程式の定義が一般的でない（第2項の符号が逆）． GL#3224
* raphalace (Raphael Aranha) SymmetryPlane と ABL シミュレーションの不具合 GL#3226
* porori (takashi suzuki) snappyHexMesh v2012 以降で、サーフェスがサイクリックタイプの境界に接続されている場合、サーフェスレイヤーを追加できない。 GL#3227
* Skolo (Robert) wallShearStress, yPlus の入力フィールドを指定できるようにした GL#3228
* flex99 (Felix Burger) メッシュとフィールドをインポートする際の vtkUnstructuredToFoam エラー GL#3230
* acassinelli (Andrea Cassinelli) v2406 が v2312 より最大 ~3% 遅くなった GL#3231
* croquemadame (Juan Salazar) 後処理のためにフォームファイルのサーフェスフォーマットをディスクから指定の場所に読み込むクラス (foamSurfaceReader) GL#3232
* gerlero (Gabriel Gerlero) CGAL 6 との互換性 GL#3234
* xuegy (Guanyang Xue) SolidificationMeltingSource の異なる液相線と固相線 GL#3235
* gerlero (Gabriel Gerlero) dl.openfoam.comがGitHub Actionsからのリクエストを拒否している GL#3236
* cthorenz (Carsten Thorenz) interFoam：可変密度乱流モデル使用時のせん断応力計算が正しくない / 動作しない GL#3237
* mfikrikasim (Mohd Fikri Kasim) OpenFoam v2306 - SnappyHexMesh の問題 GL#3239
* hikassem (Hassan Kassem) ConeNozzleInjection が均一でない GL#3240
* jczhang07 (Junchao Zhang) "openfoam/etc/bashrc" が非常に遅い GL#3245
* jczhang07 (Junchao Zhang) Icx コンパイラで `pthread_create' への未定義参照のリンクエラー GL#3251
* djarecki (Dominic Jarecki) EASY FIX: アクティブ熱物理モデルに線形 EOS を含める GL#3252
* jczhang07 (Junchao Zhang) "petscFoam" を未定義のシンボルでロードできなかった GL#3253
* richardt (Richard Tribess) BUG: AMR および collisionModel pairCollision でラグランジアンソルバーを実行する際に storeGlobalPositions が呼び出されない GL#3256
* hungnguyenphd (Quoc Hung Nguyen) sphereDrag が非常に小さい粒子サイズで動作しない GL#3257
* rbonin (Rémi Bonin) 太陽計算機が 24 時間以上の実行時間で間違った太陽方向を提供する GL#3258
* jczhang07 (Junchao Zhang) '-fp-model precise は -fp-model=precise であるべき GL#3259
* porori (takashi suzuki) interCondensatingEvaporatingFoam with InterfaceHeatResistance モデルが蒸発による体積変化を適切に評価しない GL#3261
* licg1981 (CHENGGONG LI) foamInstallationTest が gcc/g++ のバージョンを読み込めない GL#3263
* lizhisongsjtu (zhisong li) of2206: vectorCodedSource が動作しない。 GL#3264
* cibanez (Cristóbal Ibáñez) dynamicMotionSolverFvMeshMAMI の再実装 GL#3265
* cthorenz (Carsten Thorenz) snappyHexMesh：レイヤー追加処理でパッチ形状が破壊されることがある GL#3270
* jczhang07 (Junchao Zhang) RPATH リンクの失敗 GL#3274
* janga (Jan Gärtner) v2406 における boundaryInternalField() のコンパイルエラー GL#3277
* johan_roenby (Johan Roenby) BUG: plicRDF が周期的なパッチを越えて正常に動作しない GL#3279
* haampie (Harmen Stoppels) stubs サブディレクトリへの rpath が見つからない GL#3283
* sreplogl (Scott Replogle) マスターの初期クローンは成功したが、無効なパスのためチェックアウトに失敗 GL#3284
* janga (Jan Gärtner) Parcels の origProcId の命名を統一する GL#3287

== 会社概要 ==
OpenFOAMは、ESI-OpenCFDのコアチームによって制作されています。

* Andrew Heather
* Mattijs Janssens
* Mark Olesen
* Prashant Sonakar
* Pawan Ghildiyal
* Kutalmış Berçin
* Matej Forman
* Chiara Pesci
* Martin Lichtmes
* Jiri Polansky
* Ann Ronchetti
* Fred Mendonça
* Swapnil Salokhe

グローバルESIチームからの幅広いサポート

* ESI Group (GmbH)
* ESI Group (ESI Software (India) Private Limited)
* ESI Group (North America)
* ESI Group (Nihon ESI)
* ESI webteam

次からの寄付もある。

* Marian Fuchs: Upstream CFD GmbH
* Vaggelis Papoutsis: PCOpt/NTUA and FOSS GP
* The OpenFOAM Community

OpenFOAM

2024-12-28T03:42:54Z

Mmer547: /* リリースノート */

このページではOpenFOAMについてまとめていきます。

== リリースノート ==

'''OpenCFD'''

[[OpenFOAM v2412 リリースノート]]

[[OpenFOAM v2406 リリースノート]]

[[OpenFOAM v2312リリースノート|OpenFOAM v2312 リリースノート]]

[[OpenFOAM v2306リリースノート|OpenFOAM v2306 リリースノート]]

[[OpenFOAM v2212 リリースノート]]

[[OpenFOAM v2206 リリースノート]]

[[OpenFOAM v2112 リリースノート]]

[[OpenFOAM v2106 リリースノート]]

[https://www.notion.so/OF2012-3625e0d8029b40bda20fafe481dcbd95 OpenFOAM v2012 リリースノート]

[[OpenFOAM v2006 リリースノート]]

[[OpenFOAM v1912 リリースノート]]

[[OpenFOAM v1906 リリースノート]]

[[OpenFOAM v1812 リリースノート]]

[[OpenFOAM v1806 リリースノート]]

'''The OpenFOAM Foundation'''

[[OpenFOAM 12 リリースノート]]

[[OpenFOAM 11 リリースノート]]

[[OpenFOAM 10 リリースノート]]

[[OpenFOAM 9|OpenFOAM 9 リリースノート]]

[[OpenFOAM 8 リリースノート]]

[[OpenFOAM v7 リリースノート]]

[[OpenFOAM v6.0 リリースノート]]

[[OpenFOAM 4.0 リリースノート]]

[[OpenFOAM 3.0.0 リリースノート]]

[[OpenFOAM 2.4.0 リリースノート]]

==スターティングガイド==
[[OpenFOAMについて]]

[[OpenFOAMのインストール]]

[https://qiita.com/mmer547/items/e63d4cf76ea2fea659b2 チュートリアルケースの実行]

[https://qiita.com/mmer547/items/24b8491bf9776c3a27db OpenFOAMで入力できる項目の調べ方]

[https://qiita.com/mmer547/items/e4b13100e15508981a85 OpenFOAMの$FOAM変数]

==困った時は？==
[https://qiita.com/mmer547/items/7c7c257dcaf2efbc730b OpenFOAM Google Groupに投稿する際に抑えるポイント]

[https://qiita.com/mmer547/items/6b041536e2ac5dd17721 OpenFOAMで計算するネタがない時の探し方]

[[OpenFOAMのエラーメッセージの対応]]

==プリプロセス==

===形状作成===

[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%EF%BC%9A%E5%BD%A2%E7%8A%B6%E4%BD%9C%E6%88%90 形状作成ツールまとめ]

===メッシュ===
[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%E3%81%AE%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A3%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 OpenFOAMのメッシャーについて]

[[メッシュ作成:blockMesh]]

[[メッシュ作成:snappyHexMesh]]

[[メッシュ作成:cfMesh]]

[https://qiita.com/mmer547/items/9fca38b8e8eadc869bb8 SalomeでOpenFOAMのメッシュを用意する方法]

===境界条件===
[[境界条件]]

==ソルバ==
[[simpleFoamについて]]

[[ExecutionTimeとClockTimeについて]]

[https://scrapbox.io/opencae-kansai-memo/SIMPLEC%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E8%A8%88%E7%AE%97%E5%AE%9F%E8%A1%8C%EF%BC%88OpenFOAM3.0.1%EF%BC%89 SIMPLECを使用した計算実行（OpenFOAM3.0.1）]

===並列計算の実行方法===

[[decomposeParDictの中身]]

===エラーメッセージ===
[[v1806のエラーメッセージ]]

==ポストプロセス==
[[ログファイルから残差ログを抽出]]

[https://qiita.com/mmer547/items/e463235ddb93f08db68a OpenFOAMのpostProcessについて]

==チュートリアルケース==
[[チュートリアルケース|チュートリアルケース一覧]]

==カスタマイズ==
[https://qiita.com/mmer547/items/2997bf8c71fe1e2423c9 OpenFOAM ソースコードの探し方]

==その他==
[https://scrapbox.io/opencae-kansai-memo/foam-extend_4.0%E3%82%92Bash_on_Ubuntu_on_Windows%E3%81%AB%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB foam-extend 4.0をBash on Ubuntu on Windowsにインストール]

[https://scrapbox.io/opencae-kansai-memo/ESI_Windows%E7%89%88OpenFOAM%E3%81%AE%E5%B0%8E%E5%85%A5 ESI Windows版OpenFOAMの導入]

[https://gitlab.com/OpenCAE/Supercomputer-OpenFOAM-Training/-/wikis/home スーパーコンピュータOpenFOAM講習会]

== 関連サービス ==
=== プリプロセス ===
[https://www.xsim.info/products/products.html XSim.Work]

== 関連書籍 ==

[https://www.amazon.co.jp/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEDEXCS-OpenFOAM%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E9%87%8E%E6%9D%91-%E6%82%A6%E6%B2%BB/dp/4621306138/ref=sr_1_5?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-5 オープンCAEのためのDEXCS for OpenFOAMハンドブック]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E7%AC%AC2%E7%89%88-%E4%B8%80%E8%88%AC%E7%A4%BE%E5%9B%A3%E6%B3%95%E4%BA%BA%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691025/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-1 OpenFOAMによる熱移動と流れの数値解析(第2版) ]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AE%E6%AD%A9%E3%81%8D%E6%96%B9-%E6%8A%80%E8%A1%93%E3%81%AE%E6%B3%89%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%EF%BC%88NextPublishing%EF%BC%89-%E5%B7%9D%E7%95%91-%E7%9C%9F%E4%B8%80/dp/4844379526/ref=sr_1_6?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-6　OpenFOAMの歩き方]

[https://www.amazon.co.jp/OpenFOAM%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%83%86%E3%83%A9%E3%83%90%E3%82%A4%E3%83%88/dp/4627691610/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-2 OpenFOAMライブラリリファレンス]

[https://www.amazon.co.jp/OpenFOAM%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-Tomislav-Mari%C2%B4c/dp/4627670915/ref=sr_1_3?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-3 OpenFOAMプログラミング]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691017/ref=sr_1_4?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-4 OpenFOAMによる熱移動と流れの数値解析]

OpenFOAM v2412 リリースノート

2024-12-28T03:42:48Z

Mmer547: snapshot1

== ESI OpenCFD Release OpenFOAM® v2412 ==
OpenCFDは、OpenFOAM® v2412の2024年12月リリースを発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v2406の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージもあります。

* Ubuntu Linux: Ubuntu 用パッケージインストール (近日公開予定)
*openSUSE Linux: パッケージインストール (近日公開予定)
*Redhat Linux variants: パッケージインストール (近日公開予定)
*apptainer イメージ: dockerhub から入手可能 (近日公開予定)

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢がある（詳細）：

* Linux用Windowsサブシステムの使用（Ubuntu、openSUSEなどがベース）
* クロスコンパイルによるネイティブ実行可能ファイル
* ドッカーのインストール

OpenFOAMのapptainerサポートは、事前に組み立てられたイメージではなく、記述ファイルによって提供されます：

* パッケージ/コンテナを確認する

Mac OSXユーザーには、ソースからコンパイルするか、コンパイル済みパッケージのDockerコンテナを使用するオプションがある（詳細はこちら）。

== アップグレード ==

* ユーザー向けのヘルプは、ユーザー・アップグレード・ガイドに記載されています。
* 開発者向けのヘルプは、開発者向けアップグレードガイドに記載されています。

== 前処理 ==

=== createPatchユーティリティの改良 ===
createPatchユーティリティが拡張され、例えばcyclicACMIの作成時に重複した境界面を作成できるようになりました。これは、外部生成メッシュ間のcyclicACMI接続を作成するために使用できます。

system/createPatchDictのサンプル：
<code>// Patches to create.
patches
(
{
//- Master side patch
name central_inlet_couple;
patchInfo
{
type cyclicACMI;
nonOverlapPatch central_inlet_blockage;
neighbourPatch inlet_central_couple;
}
constructFrom patches;
patches (central_inlet);
}
{
//- Blockage
name central_inlet_blockage;
patchInfo
{
type wall;
}
constructFrom patches;
patches (central_inlet);
}

{
//- Slave side patch
name inlet_central_couple;
patchInfo
{
type cyclicACMI;
nonOverlapPatch inlet_central_blockage;
neighbourPatch central_inlet_couple;
}
constructFrom patches;
patches (inlet_couple);
}
{
//- Blockage
name inlet_central_blockage;
patchInfo
{
type wall;
}
constructFrom patches;
patches (inlet_couple);
}
);</code>
注意：createPatchを実行する前に、作成するcyclicACMIパッチが存在してはならない。

チュートリアル

* $FOAM_TUTORIALS/mesh/createPatch/TJunctionSwitching_createPatch

ソースコード

* $FOAM_SRC/utilities/mesh/manipulation/createPatch
* $FOAM_SRC/utilities/mesh/manipulation/mergeMeshes

リクエストのマージ

* Merge request #702

=== snappyHexMeshの改良：スナップの前にレイヤーをバッファリングする。 ===
スナップ前にメッシュにバッファレイヤーを追加できるようになり、スナップアルゴリズムをユーザーが選択できるようになりました。

snappyHexMeshDictの新しいトップレベル・エントリーを使用して、バッファー・レイヤーの追加とメッシュ・モーション機能の使用を選択できるようになりました：
<code>// Type of mesh generation:
// - castellated (default)
// - castellatedBufferLayer
type castellatedBufferLayer;</code>
バッファ層の追加はすべてのメッシュ化されたパッチに適用されます。オプションで、addBufferLayersキーワードを使用してサーフェスごとにオーバーライドできます：
<code>refinementSurfaces
{
sphere
{
// Surface-wise min and max refinement level
level (1 1);
// Disable buffer layers
addBufferLayers false;
}
}</code>
スナップ時に使用するメッシュ・モーション・ソルバの選択：
<code>snapControls
{
..
solver displacementPointSmoothing;
displacementPointSmoothingCoeffs
{
// Use laplacian to untangle problem areas
pointSmoother laplacian;
nPointSmootherIter 10;
}</code>
下の画像は、回転したボックスの外側に追加されたバッファー・セルの単層で、セルはセル・インデックスに従って色分けされている：

2つ目の例は、バッファレイヤーを追加することで、内側と外側の両方の領域を維持しながら、フェイスゾーンにスナップするのに役立つことを示しています。ここでは、セルは非直交性に従って色付けされている：

バッファレイヤーは（まだ）フィーチャーのエッジを考慮していないことに注意してください。

チュートリアル

* $FOAM_TUTORIALS/mesh/snappyHexMesh/rotated_block Meshing the outside of a rotated cube.
* $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_multiRegion Meshing the inside and outside of a sphere.

ソースコード

* $FOAM_SRC/utilities/mesh/generation/snappyHexMesh

リクエストのマージ

* Merge request #715

== 境界条件 ==

=== pointMeshの境界処理の改善 ===
pointMeshはパッチのリスト（オプション）を持つようになった。通常の動作は、pointMeshはボリュームの'poly'メッシュと同じパッチのセットを使い、'poly'パッチのポイントで操作します。

ポイントパッチ条件をpolyMesh/pointMesh/boundaryファイルで指定できるようになり、フィーチャーのエッジ、ポイント、内部ポイントにも制約を適用できるようになりました。

チュートリアルのmesh/blockMesh/sphere7は、これを使用して球状のブロックメッシュを立方体に戻す方法を示しています。

このチュートリアルでは、プラグインのポイントスムーサーを使う、新しいdisplacementPointSmoothingモーションソルバーの使用例も紹介します：

* laplacian : 近隣点の平均位置
* geometricElementTransform : 最も直交する形状に移動する。

注

* 点の移動中に点法線が更新されない
* ポイントモーションでは、周期的なパッチは現在正しく処理されていません。
* これらの追加pointPatchは以下によってサポートされる：
** moveDynamicMesh, subsetMesh
** decomposePar, reconstructPar, redistributePar
** some mesh motion solvers

チュートリアル

* $FOAM_TUTORIALS/mesh/blockMesh/pipe
* $FOAM_TUTORIALS/mesh/blockMesh/sphere7
* $FOAM_TUTORIALS/mesh/moveDynamicMesh/badMove
* $FOAM_TUTORIALS/mesh/moveDynamicMesh/bendJunction
* $FOAM_TUTORIALS/mesh/moveDynamicMesh/faceZoneBlock

ソースコード

* $FOAM_SRC/OpenFOAM/meshes/pointMesh/pointBoundaryMesh/pointBoundaryMesh.C

リクエストのマージ

* Merge request #715

=== 新しいポイントパッチ機能 ===

* topoSet に patchToPoint が追加されました : pointPatch のすべての点を選択します (patchToFace と faceToPoint を使って polyPatch の点を取得します)。
* 新しい点境界条件：edgeSlipとpointAttraction（新しいpointMesh境界条件のチュートリアルで使用されます。）
* symmetryPolyPatch : 平均方位を計算する際に、ゼロサイズの面を無視する。これは、後の押し出しのために厚さゼロのレイヤーを追加できるようにするための便利な機能です。

== 数値 ==

=== 新しい融合離散化 ===
新しい融合離散化手法は、中間補間ステップを回避し、面ベースの積分と融合する。機能は通常の離散化と同等です：

* gradSchemes : fusedGauss
* divSchemes : fusedGauss
* laplacianSchemes : fusedGauss, fusedLeastSquares

これらの方式はメモリ操作を回避するため、パッチ数が多い場合や、GPUがCPUのデータにアクセスするなど、メモリアクセスが遅いノードに有利である。 logs-gauss'がデフォルトの動作、'logs-fused'がドロップイン置換融合スキームを示しています：

これは予備的な作業であり、明示的な操作しか考慮していないこと、また操作の順序が異なるために切り捨て誤差が異なることに注意されたい。

チュートリアル

* $FOAM_TUTORIALS/ncompressible/simpleFoam/pitzDaily_fused

ソースコード

* $FOAM_SRC/src/fusedDiscretisation

リクエストのマージ

* MR!712

=== 新しいGAMGアグロメレーション・キャッシング ===
Moving mesh cases automatically rebuild the agglomeration for every time step (or even every pressure corrector). For most mesh motion cases, however, the GAMG agglomeration table can be kept for some iterations before needing to be recreated. For solid-body motion there is no need to update the table since the agglomeration logic only depends on the matrix coefficients.
Caching is enabled via the new updateInterval entry. This can be a very large number for solid-body simulations; for general mesh motion this should be based on the expected mesh Courant number.
<code>p
{
solver GAMG;
..
cacheAgglomeration yes;
updateInterval 100000;
}</code>
For verbose feedback on the agglomeration, activate the debug switches in the system/controlDict
<code>DebugSwitches
{
// Print agglomeration
GAMGAgglomeration 1;
}</code>
faceAreaWeight optimisation

The default agglomeration method employs a pair-wise combination of 'cells' based on the magnitude of the face weight connecting the cells. Currently this uses a face weight derived from face area vectors, perturbed to avoid jitter in the agglomeration boundary on an axis-aligned mesh.

When the updateInterval is not 1, the weights are calculated using unscaled, unperturbed face area magnitudes to be more consistent with Gaussian-type discretisation. This can yield a slight improvement in the number of GAMG cycles, e.g. the incompressible/pisoFoam/LES/motorBike tutorial using 10 iterations of simpleFoam showed an average reduction in cycles of around 10%:

Note that algebraic agglomeration can run with updateInterval; but it

* does not update cyclicA(C)MI and will do a bad job of the interpolation since it uses an old stencil at the coarser levels
* is based on the matrix coefficients which are changing during the simulation so would not be constant even during solid-body motion

Tutorials

* $FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/propeller

Source code

* $FOAM_SRC/finiteVolume/fvMatrices/solvers/GAMGSymSolver/GAMGAgglomerations/faceAreaPairGAMGAgglomeration

Merge request

* Merge request #707

=== Improved lduMatrix, lduAddressing ===
The scalar matrix class lduMatrix has been extended to make it easier to work with cell-based algorithms.
The addressing lduAddressing includes a lowerCSRAddr accessor that returns the lower addressing, avoiding the additional indirection using loSortAddressing:
<code>const labelUList& lduAddressing::lowerCSRAddr() const</code>
This is constructed on-the-fly from the lowerAddr() addressing.

Additionally, the matrix has been extended with a lowerCSR() accessor that returns the corresponding reordering of the lower() coefficients, or can be constructed directly:
<code>const scalarField& lduMatrix::lowerCSR() const</code>
Availability of the addressing can be checked using the hasLowerCSR() function.

An example usage is given inside the lduMatrix::Amul routine:
<code>if (hasLowerCSR())
{
// Note: lowerCSR constructed from lower if available, upper otherwise
// so is handling symmetric()
const scalar* const __restrict__ lowercsrPtr = lowerCSR().begin();

for (label cell=0; cell<nCells; cell++)
{
scalar& val = ApsiPtr[cell];

val = diagPtr[cell]*psiPtr[cell];

// Add lower contributions
{
const label start = loStartPtr[cell];
const label end = loStartPtr[cell+1];

for (label i = start; i < end; i++)
{
const label nbrCell = lcsrPtr[i];
val += lowercsrPtr[i]*psiPtr[nbrCell];
}
}
// Add upper contributions
{
const label start = oStartPtr[cell];
const label end = oStartPtr[cell+1];

for (label i = start; i < end; i++)
{
const label nbrCell = uPtr[i];
val += upperPtr[i]*psiPtr[nbrCell];
}
}
}
}</code>
Source code

* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduAddressing/lduAddressing.H
* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrix.H
* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixATmul.C

=== Improved wall distance ===
The near-wall distance field used in e.g. turbulence wall functions, has been updated for wall faces, changing the behaviour of cells with faces on multiple wall patches.
The nearest distance is calculated as the minimum distance from the cell centre to the local wall face or any local edge- or point-connected face. Note that this

* is not parallel consistent
* only considers one face

For more consistent behaviour the exact wall distance method should be employed.

Previous behaviour (OpenFOAM v2406 and earlier) can be obtained by deactivating the useCombinedWallPatch info switch in etc/controlDict or the local system/controlDict:

<code>OptimisationSwitches
{
useCombinedWallPatch 0;
}</code>
With a skewed/tetified version of the cavity mesh, v2406 wall distance:

The new behaviour looks across the side patches as well as the top patch:

Source code

* $FOAM_SRC/meshTools/cellDist/cellDistFuncs.C
* $FOAM_SRC/finiteVolume/fvMesh/wallDist/nearWallDist/nearWallDist.C
* $FOAM_SRC/finiteVolume/fvMesh/wallDist/wallDistAddressing/wallDistAddressing.C
* $FOAM_SRC/meshTools/cellDist/patchWave/patchDataWave.C
* $FOAM_SRC/meshTools/cellDist/patchWave/patchWave.C

Merge request

* Merge request #700

Issue

* Issue #3215

=== Community contribution: Improved adjoint optimisation ===
OpenFOAM v2412 adds some quality-of-life changes to the adjoint library.
The initial values of the design variables in topology optimisation can now be read through the 0/alpha field, which can be easily set using the topoSet/setFields utilities. Previously, this was only possible through 0/uniform/topOVars, which is harder to manipulate.

The multiplier of the term added to the mathematical optimisation problem of ISQP and MMA to guarantee feasibility (named 'c') can now be given by a Function1, to allow its manipulation throughout the optimisation loop. A typical example would be setting it to a small value in the first few optimisation cycles, to focus on optimality rather than feasibility, and gradually increase it.

Added the option to disable damping of the approximate Hessian in ISQP. In the general case, this is to be avoided but can accelerate the algorithm in some fringe cases.

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/1_Inlet_2_Outlet/porosityBased/R_10x-init

Source code

* $FOAM_SRC/optimisation/adjointOptimisation

Merge request

* Merge request #710

=== New zoneBlended scheme ===
The new zoneBlended scheme enables users to apply differencing schemes per-face-zone. Schemes are set in dictionary format according to:
<code>divSchemes
{
.
.
div(phi,U) Gauss zoneBlended
{
default defaultScheme;
faceZone1 scheme1;
faceZone2 scheme2;
...
faceZoneN schemeN;
}
.
.
}</code>
The default entry specifies the background scheme; additional schemes can be set per faceZone, e.g. scheme1 is applied to faceZone1, scheme2 is applied to faceZone2 etc.

Source code

* $FOAM_SRC/finiteVolume/interpolation/surfaceInterpolation/schemes/zoneBlended

== Solvers and physical models ==

=== Community contribution: Improved shielding function for SA-DDES turbulence model ===
The Delayed Detached-Eddy Simulation (DDES) model [1] is a hybrid RANS/LES approach which aims to model all attached boundary layers via RANS and massively separated flow regions via LES. To prevent the activation of the LES mode inside of attached boundary layers, an additional safeguard function referred to as "shielding" function is implemented. Unfortunately, the standard formulation [1] can collapse on fine grids, leading to a decline of wall shear stresses and potentially premature flow separation. These phenomena are often referred to as "modelled stress depletion" and "grid-induced separation" in the literature.
Deck & Renard [2] recently proposed an improved shielding function which offers more robust behaviour while still allowing a rapid switch to LES in separated shear layers. The formulation was developed for the ZDES mode 2 (2020) turbulence model, which is a variant of the SA-DDES model. The figures demonstrate the benefit of the improved shielding function for the flow around a NACA4412 airfoil with trailing edge separation. The grid on the suction side is strongly refined in the streamwise and spanwise directions, causing the standard shielding function to retreat and premature flow separation to occur. In contrast, the improved shielding function retains RANS mode in the entire attached boundary layer region on the suction side, and the prediction agrees well with reference RANS from the NASA code CFL3D.

following turbulence modelling features are included in the v2412 release:

* Improved shielding function formulation of Deck & Renard [2], implemented for SpalartAllmarasDDES, activated via the new option “shielding” (keyword “standard” selects the standard function [1], “ZDES2020” selects the improved formulation [2]).
* An additional option “usefP2” activates a more robust shielding mode for the Deck & Renard formulation (detailed in equation A.9 of [2]).

Example usage
<code>simulationType LES;
LES
{
LESModel SpalartAllmarasDDES;
SpalartAllmarasDDESCoeffs
{
// optional keywords for shielding function
shielding ZDES2020; // default: standard
usefP2 false; // default: false
}

delta maxDeltaxyz;

turbulence on;
printCoeffs on;
}</code>
Note that the improved shielding function is not implemented for the kOmegaSSTDDES model, since the formulation presented in [2] was specifically derived for SA-based DDES.

Tutorial

* $FOAM_TUTORIALS/incompressible/pimpleFoam/LES/NACA4412

Attribution

* The improved shielding function of Deck & Renard (2020) [2] was implemented by Upstream CFD GmbH and integrated into OpenFOAM in collaboration with ESI-UK Ltd with funding by Volkswagen AG.

References

* [1] P. Spalart, S. Deck, M. Shur, K. Squires, M. Strelets, and A. Travin. A new version of detached-eddy simulation, resistant to ambiguous grid densities. Theoretical and Computational Fluid Dynamics, 20(3):181–195, 2006.
* [2] Deck, S., & Renard, N. (2020). Towards an enhanced protection of attached boundary layers in hybrid RANS/LES methods. Journal of Computational Physics, vol. 400, pp. 108970, 2020.

=== Improved Lagrangian injection model: coneNozzleInjection ===
This release introduces two minor enhancements to the coneNozzleInjection model:

* A new injection method that distributes particles uniformly at angular intervals across a disc;
* Inclusion of the injector's estimated speed to particle injection. While there is no change in the input or output behaviour for static injectors, the velocity of particles injected from moving injectors now includes the injector velocity.

A minimal example usage is as follows:
<code>injectionModels
{
model1
{
type coneNozzleInjection;

...

// The new injection method: discSegments
injectionMethod discSegments;
nInjectors 10;
initialInjectorDir (1 0 0);
}
}</code>
Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/InjectionModel/ConeNozzleInjection/ConeNozzleInjection.H

Merge request

* Merge request #719

=== Improved solid-body motion function: tabulated6DoFMotion ===
The tabulated6DoFMotion model now includes a linear interpolation option. A minimal example usage is as follows:
<code>solidBodyMotionFunction tabulated6DoFMotion;

interpolationScheme linear; // spline;</code>
Source code

* $FOAM_SRC/meshTools/solidBodyMotionFunctions/tabulated6DoFMotion/tabulated6DoFMotion.H

=== New finite-area framework: Film-separation models ===
Finite-area-based film curvature separation models have been updated, and a new film-separation model added for sharp edges. These updates improve the accuracy and flexibility of film-separation predictions under a wide range of geometric and flow conditions.

Key changes and additions:

* Owen-Ryley model:
** The existing curvatureSeparation model has been re-implemented as the OwenRyleyModel, based on the work of Owen & Ryley (1983). This model assumes:
*** Once the film detaches from the surface, it immediately breaks into a fine mist of droplets. As a result, it may not accurately represent scenarios where the liquid leaves as a cohesive mass.
*** The film flows around a rounded corner with a fixed radius, potentially limiting its applicability at sharp corners where curvature is not well-defined.
*** Films are thinner than 1e-4 m, with viscous effects and surface disturbances neglected.
*** Uniform film velocity and thickness.
*** The separation criterion is not explicitly formulated, but rather inferred based on the model’s assumptions.
* New film-separation model for sharp edges:
** A new model, FriedrichModel has been introduced to compute film-separation properties at sharp edges, covering both full and partial film-separation scenarios. This model is based on the work of Friedrich et al. (2008) and Zhang et al. (2018):
*** Friedrich et al. (2008):
**** Developed a separation criterion rooted in force equilibrium within a control volume at the detachment point.
**** Assumes a maximum film thickness of 1e-4 m.
**** Considers surface tension, gravity, and film inertia.
**** Known to be relatively reliable, though it can predict premature rupture.
**** Serves as the separation method implemented in ANSYS Forte 18.2.
*** Zhang et al. (2018):
**** Enhanced the Friedrich et al. model by introducing a mass-fraction criterion. Unlike models that assume the entire film in a cell detaches simultaneously, the Zhang et al. approach detaches only a fraction of the film based on these criteria. This leads to more realistic predictions of how much film actually separates.

Comprehensive serial and parallel test cases were conducted to ensure robust corner and separation identification, involving cases with sharp edges of various shapes and orientations relative to the flow direction, and multiple spatial resolutions and parallelization configurations.

As a result, users can expect improved consistency and reliability when simulating film-separation phenomena, regardless of mesh complexity or computational setup.

A minimal example usage is as follows:
<code>injectionModels
{
filmSeparation
}

filmSeparationCoeffs
{
model OwenRyley;
definedPatchRadii 0;
minInvR1 0;
deltaByR1Min 0;
}</code>
Source code

* $FOAM_SRC/regionFaModels/liquidFilm/subModels/kinematic/injectionModel/filmSeparation/filmSeparationModels

Tutorial

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/pitzDailyWithSprinklers

Merge request

* Merge request #714

=== Improved simpleFoam: new dynamicMesh support ===
simpleFoam now supports a dynamicFvMesh, similar to pimpleFoam. It reads constant/dynamicMeshDict if it is present and calls its update() routine every iteration. This enables, e.g. use of steady-state simulations with dynamic mesh refinement/unrefinement.

==== More information ====

* Issue #3269

== Post-processing ==

=== New report generation ===
The foamReport function object provides a template-based text substitution system to collect OpenFOAM run data. The user-supplied template file can take the form of any plain-text file, e.g. markdown (.md), web (.html) and latex (.tex). Entries supplied using double handlebar syntax <nowiki>{{ENTRY}}</nowiki> are replaced (case insensitive). A set of common built-ins entries beginning with OF_ are provided, e.g.

* OF_HOST: Host machine name
* OF_CASE_NAME: Case name
* OF_API: OpenFOAM API level
* OF_DATE_START: Date when job was started
* OF_CASE_PATH: file path to case
* ...

The full set of built-in and user-supplied keys can be written using the debugKeys entry. User-defined substitutions are listed in dictionary format, where substitution models include:

* fileRegEx : regular expression from file
* functionObjectValue : retrieve function object result
* dictionaryValue : value from dictionary - file-based or from registry lookup
* environmentVariable : replace keyword with environment variable
* userValue : replace keyword with user-supplied string:

Example usage based on a markdown template:

<code>foamReport1
{
// Mandatory entries (unmodifiable)
type foamReport;
libs (utilityFunctionObjects);

template "/myReportTemplate.md";

substitutions
{
divSchemes1
{
type dictionaryValue;
object fvSchemes;

entries
{
divSchemes "divSchemes";
}
}
fvSolution1
{
type dictionaryValue;
path "/fvSolution";

entries
{
solver_p "solvers/p/solver";
solver_p_tol "solvers/p/tolerance";
solver_p_reltol "solvers/p/relTol";
solver_U "solvers/U/solver";
solver_U_tol "solvers/U/tolerance";
solver_U_reltol "solvers/U/relTol";
}
}
controlDict1
{
type dictionaryValue;
path "/controlDict";

entries
{
initial_deltaT "deltaT";
}
}
continuityErrors
{
type functionObjectValue;
functionObject continuityError1;

entries
{
cont_error_local local;
cont_error_global global;
cont_error_cumulative cumulative;
}
}
}

// Optional entries (runtime modifiable)

// Inherited entries
...
}</code>
Example markdown-based template file:
<code># <nowiki>{{OF_EXECUTABLE}}</nowiki> : <nowiki>{{OF_CASE_NAME}}</nowiki> tutorial

- Case: <nowiki>{{OF_CASE_PATH}}</nowiki>
- Submission: <nowiki>{{OF_CLOCK_START}}</nowiki> on <nowiki>{{OF_DATE_START}}</nowiki>
- Report time: <nowiki>{{OF_CLOCK_NOW}}</nowiki> on <nowiki>{{OF_DATE_NOW}}</nowiki>

---

<nowiki>##</nowiki> Run information

<nowiki>| Property |</nowiki> Value |
<nowiki>|----------------|--------------------|</nowiki>
<nowiki>| Host |</nowiki> <nowiki>{{OF_HOST}}</nowiki> |
<nowiki>| Processors |</nowiki> <nowiki>{{OF_NPROCS}}</nowiki> |
<nowiki>| Time steps |</nowiki> <nowiki>{{OF_TIME_INDEX}}</nowiki> |
<nowiki>| Initial deltaT |</nowiki> <nowiki>{{initial_deltaT}}</nowiki> |
<nowiki>| Current deltaT |</nowiki> <nowiki>{{OF_TIME_DELTAT}}</nowiki> |
<nowiki>| Execution time |</nowiki> <nowiki>{{executionTime}}</nowiki> |

---

<nowiki>##</nowiki> OpenFOAM information

<nowiki>| Property |</nowiki> Value |
<nowiki>|----------------|--------------------|</nowiki>
<nowiki>| Version |</nowiki> <nowiki>{{OF_VERSION}}</nowiki> |
<nowiki>| API |</nowiki> <nowiki>{{OF_API}}</nowiki> |
<nowiki>| Patch |</nowiki> <nowiki>{{OF_PATCH}}</nowiki> |
<nowiki>| Build |</nowiki> <nowiki>{{OF_BUILD}}</nowiki> |
<nowiki>| Architecture |</nowiki> <nowiki>{{OF_BUILD_ARCH}}</nowiki> |

---

<nowiki>##</nowiki> Mesh statistics

<nowiki>| Property |</nowiki> Value |
<nowiki>|-------------------|----------------------|</nowiki>
<nowiki>| Bounds |</nowiki> <nowiki>{{OF_MESH_BOUNDS_MIN}}</nowiki><nowiki>{{OF_MESH_BOUNDS_MAX}}</nowiki> |
<nowiki>| Number of cells |</nowiki> <nowiki>{{OF_MESH_NCELLS}}</nowiki> |
<nowiki>| Number of faces |</nowiki> <nowiki>{{OF_MESH_NFACES}}</nowiki> |
<nowiki>| Number of points |</nowiki> <nowiki>{{OF_MESH_NPOINTS}}</nowiki> |
<nowiki>| Number of patches |</nowiki> <nowiki>{{OF_MESH_NPATCHES}}</nowiki> |

---

<nowiki>##</nowiki> Linear solvers

<nowiki>| Property |</nowiki> Value | tolerance(rel) | Tolerance(abs) |
<nowiki>|----------|----------------|------------------|---------------------|</nowiki>
<nowiki>| p |</nowiki> `<nowiki>{{solver_p}}</nowiki>` | <nowiki>{{solver_p_tol}}</nowiki> | <nowiki>{{solver_p_reltol}}</nowiki> |
<nowiki>| U |</nowiki> `<nowiki>{{solver_U}}</nowiki>` | <nowiki>{{solver_u_tol}}</nowiki> | <nowiki>{{solver_u_reltol}}</nowiki> |

---

<nowiki>##</nowiki> Numerical scehemes

The chosen divergence schemes comprised:

[[利用者:Mmer547|mmer547]] ([[利用者・トーク:Mmer547|トーク]])
<nowiki>{{divSchemes}}</nowiki>
[[利用者:Mmer547|mmer547]] ([[利用者・トーク:Mmer547|トーク]])

---

<nowiki>##</nowiki> Graphs

Residuals

<nowiki>![]({{OF_CASE_PATH}}</nowiki>/postProcessing/residualGraph1/<nowiki>{{OF_TIME}}</nowiki>/residualGraph1.svg)

---

<nowiki>##</nowiki> Results

Forces

<nowiki>![]({{OF_CASE_PATH}}</nowiki>/postProcessing/forceCoeffsGraph1/<nowiki>{{OF_TIME}}</nowiki>/forceCoeffsGraph1.svg)

---</code>
Source code

* $FOAM_SRC/functionObjects/utilities/foamReport

Tutorial

* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike

Merge request

* Merge request #716

=== New graph generation ===
The graphFunctionObject enables users to generate SVG graphs of function object result values, e.g. to show the evolution residuals, or reduced data such as force coefficients.

A minimal example is shown below:
<code>// Generate the result values
solverInfo1
{
type solverInfo;
libs (utilityFunctionObjects);
fields (U p);
}

// Describe the graph
residualGraph
{
// Mandatory entries
libs (utilityFunctionObjects);

functions
{
//entry
//{
// // Mandatory entries
// object ;
// entry ;
//
// // Optional entries
// title ; // Default: take from dict name
// colour ; // labels in range 0-255 (255 0 0)
// dashes ; // (4 1 1)
//}
Ux
{
object solverInfo1;
entry Ux_initial;
}
Uy
{
object solverInfo1;
entry Uy_initial;
}
Uz
{
object solverInfo1;
entry Uz_initial;
}
p
{
object solverInfo1;
entry p_initial;
}
}

// Optional entries
//xMin ;
//xMax ;
//yMin ;
//yMax ;
//xlabel ; // "Iteration";
//ylabel ; // "log10(Initial residual)";
//width ;
//height ;
//strokeWidth ;
//logScaleX ;
//logScaleY ;
//drawGrid ;

// Inherited entries
//...
}</code>
Source code

* $FOAM_SRC/functionObjects/utilities/graphFunctionObject

Tutorial

* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike

=== New finite-area function object: surfaceCourantNumber ===
A new finite-area function object, surfaceCourantNumber, calculates the surface Courant number field at finite-area face centres.
This represents a conceptual shift from approaches like those used in the liquidFilmFoam solver, where the Courant number is computed at edge centres. By evaluating the Courant number at face centres, surfaceCourantNumber can provide a more localized and potentially more accurate measure for surface-based flow analyses.

A minimal example usage is as follows:
<code>surfaceCourantNumber1
{
// Mandatory entries
type surfaceCourantNumber;
libs (regionFaModels);

// Optional entries
area <word>;
result <word>;
phis <word>;
rho <word>;

// Inherited entries
...
}</code>
Source code

* $FOAM_SRC/regionFaModels/functionObjects/surfaceCourantNumber/surfaceCourantNumber.H

Tutorial

* $FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder

Merge request

* Merge request #706

=== Improved solver function objects: Outer-loop convergence check ===
A convergence check for outer loops has been added to the solver function objects (scalarTransport, energyTransport and electricPotential), enabling the function object to detect and terminate when further iterations are no longer necessary. This improvement can help reduce computational overhead and streamline the solution process by eliminating unnecessary loops once convergence has been achieved.
A minimal example usage is as follows:
<code>scalarTransport1
{
// Optional entries
tolerance <scalar>;
...
}</code>
Source code

* $FOAM_SRC/functionObjects/solvers/scalarTransport/scalarTransport.H
* $FOAM_SRC/functionObjects/solvers/energyTransport/energyTransport.H
* $FOAM_SRC/functionObjects/solvers/electricPotential/electricPotential.H

Merge request

* Merge request #699

== Parallel ==

=== Improved Non-Blocking Exchange (NBX) ===
In OpenFOAM-v2306 an experimental 'non-blocking consensus exchange' (NBX) option was introduced - see configuration switches
It can have a dramatic effect on extreme core counts with moving meshes. On a case with multiple cyclicAMI on 8192 cores and the entry (in etc/controlDict or local system/controlDict):
<code>OptimisationSwitches
{
// Additional PstreamBuffers tuning parameters (experimental)
// 0 : (legacy PEX)
// * all-to-all for buffer sizes [legacy approach]
// * point-to-point for contents
// 1 : (hybrid PEX)
// * NBX for buffer sizes [new approach]
// * point-to-point for contents
pbufs.tuning 1;
}</code>
Provided the following timings:
{| class="wikitable"
|NBX
|Time (s)
|-
|No
|28k
|-
|Yes
|18k
|}
Note that NBX does not guarantee that the 'receive and consume' order is the same as the 'send order', meaning the truncation errors may accumulate differently. This is more sensitive for longer messages, e.g. geometry in cyclicAMI, and care must be taken to ensure a unique 'tag' (not the default Pstream::msgType()).

Source code

* $FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation

Merge request

* Merge request #704

=== Improved finite-area framework ===
Several finite-area framework routines exhibit inconsistent behaviour under parallel operation, affecting planar and non-planar finite-area meshes—regardless of skewness or non-orthogonality. These inconsistencies mainly stem from differing algorithms applied to internal- and processor-edges.
For example, when a corner edge of a non-planar finite-area mesh is shared between two processors, it can introduce a subtle positive/negative perturbation in the tangential direction. Over time, this perturbation may propagate and lead to unexpected flow behaviour, such as film separation.

A series of carefully tested commits improve parallel consistency, mainly to address the following core routines:
<code>makeLPN
makeWeights
makeDeltaCoeffs
makeCorrectionVectors
makeSkewCorrectionVectors</code>
Source code

* $FOAM_SRC/finiteArea/faMesh/faMeshDemandDrivenData.C
* $FOAM_SRC/finiteArea/faMesh/faPatches/constraint/processor/processorFaPatch.C

Merge request

* Merge request #708

=== Improved reconstructParMesh ===
The utility reconstructParMesh can reconstruct finite-area ('faMesh') meshes, useful when the finite-area mesh is generated in parallel.
Source code

* $FOAM_UTILITIES/parallelProcessing/reconstructParMesh

Merge request

* Merge request #711

=== Improved distributed tri-surfaces ===
The distributedTriSurfaceMesh can now run with a different decomposition method compared to the rest of the simulation, by specifying a decomposition method in the relevant dictionary, e.g. system/snappyHexMeshDict:
<code>box
{
file "box.obj";
type distributedTriSurfaceMesh;

// Override the decomposition method
numberOfSubdomains 8;
method hierarchical;
n (2 2 2);
}</code>
It can optionally run without duplicating triangles by specifying
<code>decomposeUsingBbs false;</code>
This avoids excessive memory usage, and stores a per-vertex normal and so can be extended to have smooth normals.

With both changes we now recover identical results from running non-parallel or parallel on a simple mesh. In the figure below a slice shows the non-parallel mesh as a blue surface with the parallel mesh as red lines.

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/distributedTriSurfaceMesh

Source code

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

Merge request

* Merge request #720

== Usability ==

=== Updated to C++17 ===
The minimum C++ standard has been increased from C++14 to C++17 to help support ongoing GPU developments

* Commit: #44f7a726
* Source: $WM_PROJECT_DIR/wmake/rules

=== New tutorial demonstrations ===

==== missingCorner ====
This is a simple tutorial to showcase various mesh utilities:

* cellDecomposition functionObject to create a tet mesh
* polyDualMesh to convert the tets to polyhedra
* surfaceMeshExtract to create additional pointPatches
* moveDynamicMesh to slightly morph the mesh. The mesh morphing is done using a Laplacian point smoothing ignoring the feature constraints so does a bad job of improving the mesh quality.

Source code

* $FOAM_SRC/functionObjects/field/cellDecomposer
* $FOAM_UTILITIES/mesh/manipulation/polyDualMesh

Tutorial

* $FOAM_TUTORIALS/mesh/polyDualMesh/missingCorner

==== damBreakLeakage ====
This is a variant of the damBreak tutorial to showcase using cyclicACMI to control flow. In this tutorial

* additional (cyclicACMI) baffles block the flow of the liquid
* at time 0.5s a set of faces at the bottom half of the blockage open
* this is done through a cyclicACMI which uses the scale factor to convert from fully uncoupled, i.e. wall, to fully coupled.
* the scale is set through a coded Function1 entry in the patch definition in constant/polyMesh/boundary
* Initial condition: closed blockage (red)

Source code

* $FOAM_SRC/OpenFOAM/primitives/functions/Function1/Coded
* $FOAM_SRC/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch

Tutorial

* $FOAM_TUTORIALS/multiphase/interFoam/RAS/damBreakLeakage

== Community ==
The release of OpenFOAM v2412 builds upon ongoing efforts to engage the wider OpenFOAM community to unify OpenFOAM developments, acknowledging the efforts of contributions from outside of the core OpenFOAM team.

Some developments are integrated directly into the main code base, e.g.

* Community contribution: Improved adjoint optimisation more...
* Community contribution: Improved shielding function for SA-DDES turbulence model more...

If you would like to explore the possibility to collaborate and include your developments, please contact us.

=== New contributions to the Turbulence Technical Committee repository ===
We are pleased to announce the release of the following two repositories under the umbrella of the Turbulence Technical Committee repository:

* gammaSST : A three-equation transition and turbulence model.
* HelicitySpalartAllmaras : Spalart-Allmaras turbulence model with Liu et al.'s helicity correction.

Source code

* $FOAM_SRC/$WM_PROJECT_DIR/plugins/turbulence-community

Attribution

* OpenCFD would like to acknowledge and thank Jiří Fürst, Jeff Defoe, and their colleagues for their valuable contributions and assistance.

=== 謝辞 ===

==== 謝辞 ====
OpenFOAMに貢献してくれた以下の方々に感謝します。

==== 特別感謝 ====

* Johan Rønby Pedersen: マルチフェーズフレームワークの並列化に貢献
* マーカス・ノードランド：流体-多孔質界面のモデリングに関する技術的な議論に協力してくれている。

==== 課題追跡への貢献 ====

* ilyapopov (Ilya Popov) リポジトリ内の設定ファイルの迷子？ GL#3192
* carlo.fiorina (carlo fiorina) v2406 で READ_IF_PRESENT の動作に一貫性がない GL#3193
* xpqiu (xpqiu) SPDP モードで実行するとソルバがクラッシュする GL#3194
* gng015 (gng) reconstructParMesh がバイナリでメッシュが大きすぎる場合，メッシュの再構築でスタックする GL#3196
* stefano.garbin (Stefano Garbin) OF2406 で CFMESH 実行ファイルが見つからない GL#3198
* duyquang.tdm.bd (Quang Nguyen) OpenFOAM-v2406 での ccmToFoam のクロスコンパイル時のエラー GL#3199
* ChrisSessler (Christian Sessler) multiComponentMixture と組み合わせた hConst がすべての参照エンタルピーに最初の種の Tref を使用する Href GL#3200
* ChennaK85 (Chennakesava Kadapa) sixDoFRigidBody の Newmark および Crank-Nicolson スキームの問題 GL#3202
* santiagomarquezd (Santiago Marquez Damian) 3 次元未満でテンソルの球面部分が間違って計算される GL#3203
* DL (David Ludlow) overPimpleDyMFoam と v2406 における kOmegaSST 分割の不具合 GL#3204
* bPaillard (Benoit Paillard) オーバーセットチュートリアルにおける圧力変動 GL#3207
* mzy (Zeyao Ma) icoReactingMultiphaseInterFoam V2206 で凝固問題を解くと固相が常に動いてしまう GL#3208
* zzphub (Zhipeng Zhang) 2306 の debian12 ソースビルドに失敗 GL#3210
* Charlfmare (Charl Mare) SwirlFanVelocity が新しい OF バージョンで動作しない GL#3211
* lizhisongsjtu (zhisong li) bug: solitary wave - McCowan and Grimshaw GL#3212
* daniel.jasinski (Daniel) buoyantSimpleFoam の圧力制御の欠落 GL#3213
* pferro (Paulin FERRO) solidificationMeltingSource がバグっぽい GL#3214
* rbonin (Rémi Bonin) precompiled OpenFOAM (v2406 / Windows 10) で表面膜を使用すると reactingParcelFoam がクラッシュする GL#3216
* takuya (takuya yamamoto) blockMeshDict の project 関数のチュートリアルの記述が正しくない GL#3217
* snaka (Shinji Nakagawa) foamMonitor が Gnuplot バージョン 6 の 'reread' コマンドの非推奨のためにグラフの更新に失敗する GL#3219
* ilyapopov (Ilya Popov) energyTransport が dynamicRefineFvMesh と組み合わせて動作しない GL#3221
* ntilton (Nils Tilton) fixedProfile 条件が最後のタイムステップからシミュレーションを再開しない GL#3223
* porori (takashi suzuki) diffusionGasEvaporation: 例題の使い方とチュートリアルが不適切 <= アントワーヌ方程式の定義が一般的でない（第2項の符号が逆）． GL#3224
* raphalace (Raphael Aranha) SymmetryPlane と ABL シミュレーションの不具合 GL#3226
* porori (takashi suzuki) snappyHexMesh v2012 以降で、サーフェスがサイクリックタイプの境界に接続されている場合、サーフェスレイヤーを追加できない。 GL#3227
* Skolo (Robert) wallShearStress, yPlus の入力フィールドを指定できるようにした GL#3228
* flex99 (Felix Burger) メッシュとフィールドをインポートする際の vtkUnstructuredToFoam エラー GL#3230
* acassinelli (Andrea Cassinelli) v2406 が v2312 より最大 ~3% 遅くなった GL#3231
* croquemadame (Juan Salazar) 後処理のためにフォームファイルのサーフェスフォーマットをディスクから指定の場所に読み込むクラス (foamSurfaceReader) GL#3232
* gerlero (Gabriel Gerlero) CGAL 6 との互換性 GL#3234
* xuegy (Guanyang Xue) SolidificationMeltingSource の異なる液相線と固相線 GL#3235
* gerlero (Gabriel Gerlero) dl.openfoam.comがGitHub Actionsからのリクエストを拒否している GL#3236
* cthorenz (Carsten Thorenz) interFoam：可変密度乱流モデル使用時のせん断応力計算が正しくない / 動作しない GL#3237
* mfikrikasim (Mohd Fikri Kasim) OpenFoam v2306 - SnappyHexMesh の問題 GL#3239
* hikassem (Hassan Kassem) ConeNozzleInjection が均一でない GL#3240
* jczhang07 (Junchao Zhang) "openfoam/etc/bashrc" が非常に遅い GL#3245
* jczhang07 (Junchao Zhang) Icx コンパイラで `pthread_create' への未定義参照のリンクエラー GL#3251
* djarecki (Dominic Jarecki) EASY FIX: アクティブ熱物理モデルに線形 EOS を含める GL#3252
* jczhang07 (Junchao Zhang) "petscFoam" を未定義のシンボルでロードできなかった GL#3253
* richardt (Richard Tribess) BUG: AMR および collisionModel pairCollision でラグランジアンソルバーを実行する際に storeGlobalPositions が呼び出されない GL#3256
* hungnguyenphd (Quoc Hung Nguyen) sphereDrag が非常に小さい粒子サイズで動作しない GL#3257
* rbonin (Rémi Bonin) 太陽計算機が 24 時間以上の実行時間で間違った太陽方向を提供する GL#3258
* jczhang07 (Junchao Zhang) '-fp-model precise は -fp-model=precise であるべき GL#3259
* porori (takashi suzuki) interCondensatingEvaporatingFoam with InterfaceHeatResistance モデルが蒸発による体積変化を適切に評価しない GL#3261
* licg1981 (CHENGGONG LI) foamInstallationTest が gcc/g++ のバージョンを読み込めない GL#3263
* lizhisongsjtu (zhisong li) of2206: vectorCodedSource が動作しない。 GL#3264
* cibanez (Cristóbal Ibáñez) dynamicMotionSolverFvMeshMAMI の再実装 GL#3265
* cthorenz (Carsten Thorenz) snappyHexMesh：レイヤー追加処理でパッチ形状が破壊されることがある GL#3270
* jczhang07 (Junchao Zhang) RPATH リンクの失敗 GL#3274
* janga (Jan Gärtner) v2406 における boundaryInternalField() のコンパイルエラー GL#3277
* johan_roenby (Johan Roenby) BUG: plicRDF が周期的なパッチを越えて正常に動作しない GL#3279
* haampie (Harmen Stoppels) stubs サブディレクトリへの rpath が見つからない GL#3283
* sreplogl (Scott Replogle) マスターの初期クローンは成功したが、無効なパスのためチェックアウトに失敗 GL#3284
* janga (Jan Gärtner) Parcels の origProcId の命名を統一する GL#3287

== 会社概要 ==
OpenFOAMは、ESI-OpenCFDのコアチームによって制作されています。

* Andrew Heather
* Mattijs Janssens
* Mark Olesen
* Prashant Sonakar
* Pawan Ghildiyal
* Kutalmış Berçin
* Matej Forman
* Chiara Pesci
* Martin Lichtmes
* Jiri Polansky
* Ann Ronchetti
* Fred Mendonça
* Swapnil Salokhe

グローバルESIチームからの幅広いサポート

* ESI Group (GmbH)
* ESI Group (ESI Software (India) Private Limited)
* ESI Group (North America)
* ESI Group (Nihon ESI)
* ESI webteam

次からの寄付もある。

* Marian Fuchs: Upstream CFD GmbH
* Vaggelis Papoutsis: PCOpt/NTUA and FOSS GP
* The OpenFOAM Community

OpenFOAM v2412 リリースノート

2024-12-28T03:17:28Z

Mmer547: First comiit

== ESI OpenCFD Release OpenFOAM® v2412 ==
OpenCFD is pleased to announce the December 2024 release of OpenFOAM® v2412. This release extends OpenFOAM-v2406 features across many areas of the code. The new functionality represents development sponsored by OpenCFD's customers, internally funded developments, and integration of features and changes from the OpenFOAM community.

OpenFOAM is distributed by OpenCFD under the GPL License. In addition to source code packages suitable for compilation on a variety of Linux and other POSIX systems, this release also has a number of pre-compiled binary packages

* Ubuntu Linux: packaged installation for Ubuntu (coming soon)
* openSUSE Linux: packaged installation for (coming soon)
* Redhat Linux variants: packaged installation for (coming soon)
* apptainer images: available from dockerhub (coming soon)

Windows users have three options for pre-compiled packages (more information):

* Using Windows Subsystem for Linux (based on Ubuntu, openSUSE etc.)
* Native executables with cross-compilation
* A docker installation

OpenFOAM apptainer support is provided via description files rather than pre-assembled images:

* See packaging/containers

Mac OSX users have the option to compile from source, or use Docker containers for pre-compiled packages (more information).

== Upgrading ==

* Help for users is provided in the user upgrade guide
* Help for developers is provided in the developer upgrade guide

== Pre-processing ==

* Improved createPatch utility more...
* Improved snappyHexMesh: buffer layers before snapping more...

== Boundary conditions ==

* Improved pointMesh boundary handling more...
* New point patch functionality more...

== Numerics ==

* New fused discretisation more...
* New GAMG agglomeration caching more...
* Improved lduMatrix, lduAddressing more...
* Improved wall distance more...
* Community contribution: Improved adjoint optimisation more...
* New zoneBlended scheme more...

== Solvers and physical models ==

* Community contribution: Improved shielding function for SA-DDES turbulence model more...
* Improved Lagrangian injection model: coneNozzleInjection more...
* Improved solid-body motion function: tabulated6DoFMotion more...
* New finite-area framework: Film-separation models more...
* Improved simpleFoam: new dynamicMesh support more...

== Post-processing ==

* New report generation more...
* New graph generation more...
* New finite-area function object: surfaceCourantNumber more...
* Improved solver function objects: Outer-loop convergence check more...

== Parallel ==

* Improved Non-Blocking Exchange (NBX) more...
* Improved finite-area framework more...
* Improved reconstructParMesh more...
* Improved distributed tri-surfaces more...

== Usability ==

* Updated to c++17 more...
* New tutorial demonstrations more...

== Community ==

* New contributions to the Turbulence Technical Committee repository more...
* Thank you more...

== About us ==
OpenFOAM is produced by the core ESI-OpenCFD team

* Andrew Heather
* Mattijs Janssens
* Mark Olesen
* Prashant Sonakar
* Pawan Ghildiyal
* Kutalmış Berçin
* Matej Forman
* Chiara Pesci
* Martin Lichtmes
* Jiri Polansky
* Ann Ronchetti
* Fred Mendonça
* Swapnil Salokhe

With wider support from the global ESI team

* ESI Group (GmbH)
* ESI Group (ESI Software (India) Private Limited)
* ESI Group (North America)
* ESI Group (Nihon ESI)
* ESI webteam

And contributions from

* Marian Fuchs: Upstream CFD GmbH
* Vaggelis Papoutsis: PCOpt/NTUA and FOSS GP
* The OpenFOAM Community

OpenFOAM v2406 リリースノート

2024-12-03T14:30:52Z

Mmer547: ページの作成:「 OpenCFDは、OpenFOAM® v2406の2024年6月リリースを発表します。このリリースは、コードの多くの領域にわたってOpenFOAM-v2312の機能を拡張します。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。 OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。…」

OpenCFDは、OpenFOAM® v2406の2024年6月リリースを発表します。このリリースは、コードの多くの領域にわたってOpenFOAM-v2312の機能を拡張します。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージもあります。

* Ubuntu Linux: Ubuntu 24.04（LTS）、22.04（LTS）、20.04（LTS）、18.04（LTS）用パッケージインストール
* openSUSE Linux: Leap 15.6、15.5用パッケージインストール
* Redhat Linux の亜種: epel 9 用パッケージ・インストール; Fedora 40
* apptainer イメージ: dockerhub から openfoam-dev:2406-apptainer および openfoam-dev:apptainer として入手可能。

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢がある（詳細）：

* Linux用Windowsサブシステムの使用（Ubuntu、openSUSEなどベース）
* クロスコンパイルによるネイティブ実行可能ファイル
* ドッカーのインストール

OpenFOAMのapptainerサポートは、事前に組み立てられたイメージではなく、記述ファイルによって提供されます：

* 包装・容器を見る

Mac OSXユーザーには、ソースからコンパイルするか、コンパイル済みパッケージのDockerコンテナを使用するオプションがある（詳細はこちら）。

== アップグレード ==

* ユーザー向けのヘルプは、[https://develop.openfoam.com/Development/openfoam/-/wikis/upgrade/v2406-User-Upgrade-Guide ユーザー・アップグレード・ガイド]に記載されています。
* 開発者向けのヘルプは、開発者向け[https://develop.openfoam.com/Development/openfoam/-/wikis/upgrade/v2406-Developer-Upgrade-Guide アップグレードガイド]に記載されています。
* 現在進行中のGPU開発をサポートするため、C++の最低規格が2024年にC++14からC++17に引き上げられる予定であることに注意。

== 前処理 ==

=== 新しいcreateViewFactorsアプリケーション ===
新しいcreateViewFactorsユーティリティは、viewFactor放射モデルのパッチ間のビュー因子を作成します。これは、現在のviewFactorsGenユーティリティを置き換える可能性があります。ユーザーは、対面アドレッシングの構築とビューファクターの計算方法の両方に使用するモデルを選択できます。
レイ世代：

* ボクセル：均一なボクセルに分割された空間
* ...近い将来、さらなる方法が発表されるだろう

ビューファクターの計算：

* viewFactorHottel: Hottelの交差弦メソッドに基づく2Dメソッド
* viewFactor2AI: double 面積積分
* viewFactor2LI: 二重線積分

すべての面に対してすべての面をテストする、つまりN^2アルゴリズム（viewFactorsGen）を使用する代わりに、ユーザーは面ごとにシードする光線の数を供給します。これらは、半球全体で一様に発行されます。したがって、結果は以前のユーティリティよりも近似的ですが、はるかに改善されたパフォーマンスでプロダクションケースに適用できるようになりました。

なお、これは現在ベータレベルであり、近い将来変更される可能性がある。

チュートリアル

* 未定

ソースコード

* $FOAM_UTILITIES/preProcessing/createViewFactors

Gitlab

* Merge request #692

=== renumberMeshの改良 ===
renumberMeshユーティリティに新しいオプションと機能が追加されました。

* dry-runを-write-mapsオプションとともに使用すると、変更を加えずにリナンバリングの前後を視覚化できる（VTKファイルが作成される）。
* フィールドに影響を与えずにメッシュの番号だけを変更するには、-no-fieldsオプションを使用します。これは、入力フィールドが一様で、-overwriteオプションが指定されている場合に便利で、はるかに高速です。

新しい-renumber-methodオプションと-renumber-coeffsオプションは、別のファイルを編集することなくrenumberMeshを使用できるようにした。

* renumberMesh -renumber-method CuthillMcKee
* renumberMesh -renumber-method RCM (すなわち、逆キューシルマッキー)
* renumberMesh -renumber-method random
* renumberMesh -renumber-method none (非常に特殊なケースだ！)

係数を必要とするメソッドでは、-renumber-coeffsオプションで指定できる。逆Cuthill-McKeeを指定する4つの異なる方法を示します：

* renumberMesh -renumber-method RCM
* renumberMesh -renumber-method CuthillMcKee -renumber-coeffs 'reverse true;'
* `renumberMesh -renumber-coeffs 'method CuthillMcKee; reverse true;'
* `renumberMesh -renumber-coeffs 'method RCM;'

これらの例からわかるように、-renumber-coeffsはOpenFOAM辞書の内容に対応し、比較的複雑な内容を許容します：
<code>renumberMesh \
renumber-method spring \
renumber-coeffs 'maxCo 0.1; maxIter 1000; freezeFraction 0.99;'</code>
リナンバリングメソッドに加えて、renumberMeshはリナンバリングの前に適用される-decomposeメソッドをサポートするようになった。これは並列リナンバリングの代わりとして使用でき、ワークフローを簡素化します。

チュートリアル

* $FOAM_TUTORIALS/mesh/parallel/cavity

ソースコード

* $FOAM_UTILITIES/mesh/manipulation/renumberMesh

=== snappyHexMeshの改良 ===
snappyHexMeshはシリアルとパラレルの両モードで実行したときに同一のメッシュを生成することを目指しています。このリリースでは2つの同期に対応しました：

* 2:1より遅い精製を使用する場合、すなわちnCellsBetweenLevels > 1
* すべての点が境界上にあるセルを検出する場合。これらの点はプロセッサの境界上にある場合は異なる扱いを受けた。

チュートリアル

* N/A

ソースコード

* $FOAM_SRC/dynamicMesh/polyTopoChange/polyTopoChange/hexRef8/hexRef8.C
* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementProblemCells.C

Gitlab

* Commit #690d02f9
* Commit #e1d45ec2

=== surfaceInertiaユーティリティの改良 ===
surfaceInertiaユーティリティが平均面積法線に関する情報を出力するようになり、プリ・ポスト処理中のさまざまな方向関連のジオメトリやメッシュ操作に役立つようになりました：

* cをlinearDirectionと組み合わせることで、より優れた押し出し結果を得ることができます。
* 変換の向き、ブロックメッシュ、結果の投影、...

ソースコード

* $FOAM_UTILITIES/surface/surfaceInertia

=== 新しいオーバーラップゾーン ===
点、面、セルのオーバーラップゾーンをサポートするユーティリティが増えました。以前のリリースでは、これはdecomposeParと特定のソルバーでのみサポートされていました。

* redistributePar : フルサポート
* subsetMesh : フルサポート
* polyTopoChange : メッシュ要素を単一のゾーンではなく、複数のゾーンに追加／修正するルーチンを拡張。
* polyMesh : エレメントがあるゾーンをチェックするための追加質問ルーチン

これは、任意のソースを使用してtopoSet内部で直接ゾーンを構築するための既存のサポートに追加される：
<code>name c0;
type cellZoneSet;
action new;
source boxToCell;
box (0.04 0 0)(0.06 100 100);</code>
これはメッシュの矩形部分から直接セルゾーンc0を生成する。

ソースコード

* $FOAM_SRC/meshTools/topoSet/topoSets/topoSet.C

チュートリアル

* $FOAM_TUTORIALS/mesh/parallel/filter

Gitlab

* Merge request #670

=== topoSet : 幾何学的選択のオプション変換 ===
topoSet のジオメトリック選択ソースが、選択が適用される前のセル、面中心、点の位置のオプション変換をサポートするようになりました。変換は solidBodyMotionFunctions の形式をとります。
<code>name c0;
type cellSet;
action new;
source boxToCell;
box (0.04 0 0)(0.06 100 100);
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
// coefficients
}</code>
これは、<constant>/fvOptionsなどで、移動するソースをシミュレートするのに便利です：
<code>selectionMode geometric;
selection
{
cyl1
{
action use;
source cylinder;

point1 (0.05 0.03 -1); // beg point on cylinder axis
point2 (0.05 0.03 1); // end point on cylinder axis
radius 0.003;

solidBodyMotionFunction oscillatingLinearMotion;
oscillatingLinearMotionCoeffs
{
// coefficients
amplitude (0 0.02 0);
omega 0.7; // rad/s
}
}
}</code>
ソースコード

* $FOAM_SRC/meshTools/topoSet/topoSets/topoSet.C

チュートリアル

* $FOAM_TUTORIALS/basic/scalarTransportFoam/moving_source

Gitlab

* Merge request #668
* Merge request #693

=== トランスフォームの改善 ===
transformPointsとsurfaceTransformPointsユーティリティは、メッシュ（またはサーフェス）ポイントの変換に使用されます。新しいオプション-cylToCartは、円筒形メッシュ生成を補助するために、円筒形からデカルトへの変換を適用します。
下の例は、新しいチュートリアル$FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/axialTurbine_rotating_oneBladeからのもので、左の画像は、円柱座標で構成されたコンポーネントを示し、右の画像は、デカルト座標に変換した後の断面です。

チュートリアル

* $FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/axialTurbine_rotating_oneBlade

ソースコード

* $FOAM_UTILITIES/mesh/manipulation/transformPoints

Gitlab

* Merge request #688

帰属

* 変換コードを提供してくれたHåkan Nilssonに感謝する。

== 数値 ==

=== 圧縮性ケースに対する改良型MRF ===
エネルギー方程式は、ムービングメッシュ計算を行う際に採用される寄与と同様に、MRFが行った仕事の影響を含むようになった。この追加項は次のような形になります：
<code>if (MRF.active())
{
EEqn += fvc::div(MRF.phi(), p);
}</code>
この変更には、<case>/fvSchemesファイルに追加のエントリーが必要です。
<code>div(phiMRF,p) Gauss limitedLinear 1;</code>
その効果は、コンプレッサーのケースにおける以下の総温度予測で見ることができる。左の画像は以前の挙動（v2312以前）と新しい挙動（右）を示している。

チュートリアル

* $FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/mixerVessel2D/system/fvSchemes

ソースコード

* $FOAM_SOLVERS/compressible/rhoPimpleFoam/EEqn.H

Gitlab

* Merge request #689

=== 有限面積の改善 ===
OpenFOAM-v2406では、将来的に複数の有限領域領域をサポートするための重要な第一歩が踏み出されました。
残念ながら、これらの変更は、有限領域を使用するワークフローに若干の調整を必要とする（他のワークフローは影響を受けない）。 OpenCFDではワークフローを中断させないように最善を尽くしていますが、やむを得ない場合もあります。

有限面積ケースのセットアップのアップグレードを支援するために、bin/foamUpgradeFiniteAreaスクリプトが用意されています：
<code>Usage: foamUpgradeFiniteArea [OPTION]
options:
-case=DIR Specify starting directory, default is cwd
-dry-run | -n Test without performing actions
-verbose | -v Additional verbosity
-link-back Link back from new finite-area/ to old locations
-no-mesh Do not move system/faMeshDefinition
-git Use 'git mv' when making changes
-help Print help and exit

Relocate finite-area files to new sub-directory locations</code>
幸いなことに、これは思ったより複雑なことではなく、有限領域のサブディレクトリが追加されただけである。
{| class="wikitable"
!old location
!new location
|-
|0/{areafield}
|0/finite-area/{areafield}
|-
|constant/faMesh/
|constant/finite-area/faMesh/
|-
|system/faMeshDefinition
|system/finite-area/faMeshDefinition
|-
|system/faSchemes
|system/finite-area/faSchemes
|-
|system/faSolution
|system/finite-area/faSolution
|}
コード開発者にとっても、大きな変化はない。エリア・フィールドが正しい位置に登録されていることが重要なだけだ：

<code>// Good, uses area mesh thisDb()

areaScalarField h
(
IOobject
(
"h",
runTime.timeName(),
aMesh.thisDb(),
// ^-- works with v2312, v2406, ...
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
aMesh
);</code>
例によって、より詳しい情報はユーザーアップグレードガイドと開発者アップグレードガイドにあります。

チュートリアル

* $FOAM_TUTORIALS/compressible/acousticFoam/obliqueAirJet/main
* $FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder
* $FOAM_TUTORIALS/finiteArea/sphereSurfactantFoam/sphereTransport
* $FOAM_TUTORIALS/finiteArea/surfactantFoam/planeTransport
* $FOAM_TUTORIALS/heatTransfer/buoyantPimpleFoam/hotRoomWithThermalShell
* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contactAngleCavity
* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contaminatedDroplet2D
* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/filmPanel0
* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/inclinedPlaneFilm
* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/sloshing2D
* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike/system/finite-area/faSchemes
* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/drippingChair
* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/pitzDailyWithSprinklers
* $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/liquidFilmStepWithSprinklers
* $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/splashPanelFilm

== ソルバーと物理モデル ==

=== 温度依存の放射特性 ===
constantAbsorptionおよびconstantTransmissivity放射サブモデルが更新され、吸収率、放射率、透過率などの時間変化する特性がサポートされました。
チュートリアル

* TBA

ソースコード

* $FOAM_SRC/thermophysicalModels/radiation/submodels/wallAbsorptionEmissionModel/constantAbsorption
* $FOAM_SRC/thermophysicalModels/radiation/submodels/wallTransmissivityModel/constantTransmissivity

Gitlab

* Merge request #685

=== 新しいFreezeParticlesクラウド機能オブジェクト ===
新しいFreezeParticlesクラウドファンクションオブジェクトは、パーティクルのアクティブフラグをfalseに設定し、物理モデルを進化させながら空間内でパーティクルをフリーズさせます。使用例：
<code>cloudFunctions
{
FreezeParticles
{
// Mandatory entries
type FreezeParticles;
}
}</code>
チュートリアル

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/particleDrag/parcelInBox

ソースコード

* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/FreezeParticles

Gitlab

* Merge request #686

=== トミヤマ新バブル・ドラッグ・モデル ===
tomiyamaDragモデルがラグランジュ粒子追跡ライブラリに追加されました。
使用例：
<code>subModels
{
particleForces
{
tomiyamaDrag
{
sigma 0.07;
contamination pure; // pure | slight | full
}
}
}</code>

チュートリアル

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/particleDrag/parcelInBox

ソースコード

* $FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/ParticleForces/TomiyamaDrag

参考

* Tomiyama, A., Kataoka, I., Zun, I., Sakaguchi, T. (1998) Drag coefficients of single bubbles under normal and micro gravity conditions JSME International Journal, 41(2), 472-479.

Gitlab

* Merge request #686

=== icoReacting...Foamソルバーの改良 ===
icoReactingMultiphaseInterFoamソルバーアプリケーションがインクリメンタルアップデートを受けました：

* 追加乱流モデルへのアクセス：realizableKE、kOmega、kOmegaSST
* <case>/fvSolution を使ってフローを凍結させることもできる。

<code>PIMPLE
{
frozenFlow yes;
...
}</code>
ソースコード

* $FOAM_SOLVERS/multiphase/icoReactingMultiphaseInterFoam

Gitlab

* Issue #3128
* Commit #bb483951

== 後処理 ==

=== 新しいviewFactorHeatFlux関数オブジェクト ===
viewFactorHeatFlux関数オブジェクトを使用すると、viewFactor放射モデルを使用した場合のパッチ間の熱交換を簡単に特定することができます。
使用例：
<code>viewFactorHeatFlux1
{
// Mandatory entries (unmodifiable)
type viewFactorHeatFlux;
libs (utilityFunctionObjects);

// Optional entries (runtime modifiable)
qr qr;
}</code>
チュートリアル

* NA

Source code

* $FOAM_SRC/functionObjects/utilities/viewFactorHeatFlux

=== 新しいEnsightシングル・ファイル・フォーマットの読み込み ===
過渡的な結果を保存するために複数のファイルを使用する、より馴染み深いEnSightのケースに加えて、EnSightは、より効率的、あるいは単純により便利に使用できる可能性のある、単一のファイル形式での過渡的な結果の保存も可能です。
このリリースでは、このトランジェント・シングル・ファイル・フォーマットが、サポートされるサーフェス・フィールド・フォーマットとして、*MappedFile*関数やsurfaceNoiseユーティリティなどで使用できるようになった。

ソースコード

* $FOAM_SRC/fileFormats/ensight/file
* $FOAM_SRC/surfMesh/readers/ensight

Gitlab

* Merge request #682

=== 新しいEnsightクラウド機能オブジェクト ===
ensightCloud関数オブジェクトは、ラグランジュデータをEnSight計測フォーマットで書き込みます。並行して、すべてのデータがマスターから書き込まれます。
ensightCloud関数オブジェクトの設定パラメータと動作は、ストライドに基づく区画選択、フィールドフィルタリングなどをサポートするvtkCloud関数オブジェクトとほぼ同じです。

生成されたEnSightファイルには、メッシュのバウンディングボックスも含まれます。これは、視覚化のためのリファレンスとなります（ParaViewリーダーにも必要です）。

ソースコード

* $FOAM_SRC/functionObjects/lagrangian/ensightCloud

=== 新しい多面体セル変換 ===
cellDecomposer関数オブジェクトは、mapFieldsユーティリティと同様に、セルを「基本」形状に分解し、選択したフィールドをその上にマッピングします。主な利点は、多面体形状を扱えないサードパーティ製ツールでOpenFOAMメッシュや結果をポスト処理する場合です。 2つの主要なコントロールがあります：

* 細胞の選択。これはどのfvOptionとも同じコントロールを使う。例えばselectionMode allやselectionMode cellSetなど。
* decomposeTypeによる分解方法：
** faceCentre : 面の中心とセルの中心を使ってセルをテットに分解する。
** faceDiagonal : 面対角を使ってセルをテッツに分解。ラグランジュ粒子トラッキングの分解と似ていて、ヘックスが6*2のテッツになる。
** ピラミッド：面はそのままに、セルの中心を使って（多角形ベースの）ピラミッドを作る。
** faceDiagonalQuads : faceDiagonalに似ているが、面を[三角形のみ]ではなく、四角形と三角形に分割する。
** polyhedral : faceDiagonalQuadsのようなものだが、選択された集合内の非hex/prism/tetセルだけを分解する。多面体メッシュを「単純」メッシュに変換するのに使用。

すべての多面体セルを非多面体セルだけを含むサブリージョンメッシュに変換する典型的な例：
<code>functions
{
cellDecomposer
{
// Mandatory entries
type cellDecomposer;
fields (p U);
mapRegion simpleMesh;

// Execute when results are written
writeControl writeTime;

// Decompose type
decomposeType polyhedral;

// Which cells to convert
selectionMode all;
}
}</code>
このメッシュと結果は、通常の-regionオプションを使って処理できる：
<code>checkMesh -region simpleMesh
foamToEnsight -region simpleMesh</code>
下の画像はシンプルな3セル厚のブロックメッシュで、コーナーセルの1つが2x2x2リファインメントを使って分割され、多面体セルが作成されている：

左：リファインメントを施した元のメッシュ、右：新しいファンクションオブジェクトを実行した後、残りのセルは六角形、四角錐、角柱、四面体になる。

ある幾何学的領域内のすべてのセルを四面体に変換する別の例：
<code>functions
{
cellDecomposer
{
// Mandatory entries
type cellDecomposer;
fields (p U);
mapRegion tetMesh;
// Decompose type
decomposeType faceCentre;
// Which cells to convert
selectionMode geometric;
// Generate cellSet c0 using topoSet commands:
cellSet c0;
selection
{
a
{
action use;
source boxToCell;
box (1 1 1)(0 0 0);
}
b
{
action invert;
}

}
}
}</code>

==== 制限事項 ====

* メッシュの移動とトポロジーの変更は現在サポートされていません。
* 微細化によってセルを分解すると、2つのセルの間に複数の面ができることがある：
** ヘクスは2つのエッジに分割される。エッジで接続されたセルはリファインされるからだ（このヘクスは多面体セルとなる）。
** 元の六角形のエッジは2つの隣接する四面体に分割されるが、今度はその間の四角形が2つの三角形に分割され、どちらも同じ2つのセルを共有する：

* と報告される。

<code>Checking topology...
..
<<Found 2015 neighbouring cells with multiple inbetween faces.
Upper triangular ordering OK.
<<Writing 4034 unordered faces to set upperTriangularFace</code>

* 複雑なセルを分割すると、幾何学的に無効なセルが簡単に生成される。

<code>***High aspect ratio cells found, Max aspect ratio: 1.59875e+96, number of cells 99
<<Writing 99 cells with high aspect ratio to set highAspectRatioCells
Minimum face area = 1.34886e-06. Maximum face area = 1.00344. Face area magnitudes OK.
***Zero or negative cell volume detected. Minimum negative volume: -3.55077e-07, Number of negative volume cells: 99
<<Writing 99 zero volume cells to set zeroVolumeCells
Mesh non-orthogonality Max: 158.664 average: 21.4979</code>
ソースコード

* $FOAM_SRC/src/functionObjects/field/cellDecomposer/cellDecomposer.H

チュートリアル

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk

== パラレル ==

=== GAMG : プロセッサ・アグロメレーションを修正する ===
ローカル・アグロメレーションに加えて、GAMGソルバーは、プロセッサー・アグロメレーションを使用してプロセッサー間で行列を結合することもサポートしている。これは、以下の理由により、コア数が多い場合に特に効果的であることが示されている：

* コアの数を減らすことは、最も粗いレベルで作用する。
* スムージングやプリコンディショニングなど、すべての操作の暗黙性を高める。

以前のリリース（v2312）では、あらゆる種類の結合境界条件を含めることができるようにメカニズムが書き換えられました。しかし、これは既存の、プロセッサ境界のみの、プロセッサのアグロメレーションを壊しました。これは今回のリリースで修正されました。

ソースコード

* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGSolverAgglomerateMatrix.C

チュートリアル

* $FOAM_TUTORIALS/basic/laplacianFoam/implicitAMI-nonblocking

Gitlab

* Merge request #645
* Issue #3172

=== cyclicAMI : 大きなコア数の線形ソルバーにおけるcyclicAMIの修正 ===
マージリクエスト#641で導入された、終了したMPIリクエストへの参照を保持するオーバーラップ通信が修正されました。これはコア数が大きく、インターコネクトが高速で、パイプライン化された線形ソルバーで発生する可能性があります。
ソースコード

* $FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint/cyclicAMI/cyclicAMIFvPatchField.C
* $FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint/cyclicACMI/cyclicACMIFvPatchField.C
* $FOAM_SRC/meshTools/AMIInterpolation/GAMG/interfaceFields/cyclicAMIGAMGInterfaceField/cyclicAMIGAMGInterfaceField.C
* $FOAM_SRC/meshTools/AMIInterpolation/GAMG/interfaceFields/cyclicACMIGAMGInterfaceField/cyclicACMIGAMGInterfaceField.C

Gitlab

* Merge request #641

== ユーザビリティ ==

=== 新しいルックアップ機能1 ===

==== lookup' 関数1 ====
データベース（通常はメッシュ）からUniformDimensionedFieldを検索できる新しいルックアップ関数1が導入されました。これは、境界条件やシミュレーション設定などの計算値に適用することができます。次の例は、rotatingMotionモデルで計算された回転速度を使用する方法を示しています：
<code>solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0.005 0.005 0.005);
axis (0 0 1);
omega lookup;
// Name of UniformDimensionedField to look up
name myRotationalVelocity;
}</code>
または拡張構文、例えばすでに名前エントリーが存在する場合：
<code>omega lookup
lookupCoeffs
{
name myRotationalVelocity;
}</code>
変数の中には、UniformDimensionedFieldとしてすでに利用可能なものもある。その他の変数は、例えばコード化された関数オブジェクトの中など、ユーザーコーディングによって追加することができます：
<code>libs (utilityFunctionObjects);
type coded;
name register_myVar;

codeRead
#{
const IOobject io
(
"myVar",
mesh().time().constant(),
mesh()
);

auto* ptr =
const_cast<objectRegistry&>
(
io.db().findObject<uniformDimensionedScalarField>(io.name())
);

if (!ptr)
{
ptr = new uniformDimensionedScalarField
(
io,
dimless,
0.80
);
ptr->store();
}
#};</code>

==== 'lookup' PatchFunction1 ====
このバリアントはパッチ上で動作し、与えられた名前のボリューム、サーフェス、またはポイントフィールドを検索し、パッチ上の値を抽出する。
<code>movingWall
{
type uniformFixedValue;
uniformValue lookup;
name U.water; // use patch value of field U.water
value $internalField;
}</code>

チュートリアル

* $FOAM_TUTORIALS/mesh/blockMesh/pipe

ソースコード

* $FOAM_SRC/finiteVolume/expressions/PatchFunction1

=== topoSetユーティリティの改善：セットまたはゾーンの選択 ===
topoSet ソース・メソッドで set または sets というキーワードを期待するメソッドは、zone または zones というキーワードも受け付けるようになった。これは、constant/polyMesh/sets ディレクトリからセットを読み込む代わりに、現在のメッシュゾーンから要素を選択します。
Gitlab

* Merge request #674

=== 新しい周期的環状AMIチュートリアル ===
周期的に繰り返されるAMIの症例を組み立てるのは難しい。 OpenFOAMコミュニティのメンバーであるHakan Nilsson氏から提供された回転軸流タービンケースは、メッシュが円筒座標で構築され、後にOpenFOAM v2406の新しい変換オプションを使用してデカルト座標に変換されます。

チュートリアル

* $FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/axialTurbine_rotating_oneBlade

Gitlab

* MR!648

Attribution

* ホーカン・ニルソンに感謝

== コミュニティ ==

=== 新しいサブモジュール：データ駆動モデリングSIGリポジトリ ===
OpenFOAMガバナンス内のData-Driven Modelling Special Interest Groupから、入れ子になったサブモジュールを含む新しいコミュニティ・サブモジュールが開始されました。このサブモジュールは、公開されているData-Driven Modelling Special Interest Groupリポジトリでホストされています。
コミュニティ・サブモジュールは、CFDや機械学習モデルに関する学術的・産業的な貢献のホストとして機能し、知識交換の場を作り、コラボレーションを促進する。

BitbucketやGitHubのような、gitベースのソースコードリポジトリホスティングサービスにホストし、このサブモジュールを介してOpenFOAMソフトウェアにリンクすることができます。

今回のリリースでは、以下のサブモジュールを発表する：

* openfoam-smartsim : SmartRedisとSmartSimによるOpenFOAMと機械学習の結合。
* NN_Pred : CFDコードに機械学習モデルを導入するためのインターフェイスライブラリ。

ソースコード

* <nowiki>https://gitlab.com/openfoam/community/sig-data-modelling/data-community</nowiki>

Attribution

* OpenCFD would like to acknowledge and thank the data-driven modelling special interest group members; Weishuo Liu and their colleagues for their valuable contributions and assistance.

=== Turbulence TCリポジトリへの新しい投稿 ===
乱流技術委員会リポジトリの傘下に、以下の6つのリポジトリを公開いたします：

* MachineLearningTurbulenceModels : 機械学習アプローチに基づくいくつかの乱流モデル。
* KOSSTPDA : プログレッシブデータ拡張k-ωSSTモデル.
* SpalartAllmarasRCsend : Spalart-Shur曲率補正を用いたSpalart-Allmaras乱流モデル.
* SST-CND : SST-CNDモデル。
* dynamicSmagorinsky : ダイナミックスマゴリンスキーモデル。
* EllipticBlending : k-epsilonラグ楕円ブレンディング乱流モデル.

ソースコード

* $WM_PROJECT_DIR/plugins/turbulence-community

Attribution

OpenCFDは謝意を表する。

* the Turbulence Technical Committee
* Matheus Macedo, Chenyu Wu, Yufei Zhang Michael Alletto, Mario J. Rincón, Alberto Passalacqua, Eleonora Gajetti, and their colleagues for their valuable contributions and assistance.

== 会社概要 ==
OpenFOAMは、ESI-OpenCFDのコアチームによって制作されています。
アンドリュー・ヘザー

マティス・ヤンセンス

マーク・オレセン

プラシャント・ソナーカル

パワン・ギルディヤル

クタルムシュ・ベルシン

マテイ・フォルマン

キアラ・ペシ

マルティン・リヒトメス

ジリ・ポランスキー

アン・ロンチェッティ

フレッド・メンドンサ

スワプニル・サロケ

ヴェンカタ・ラマナ・イーガ

グローバルESIチームからの幅広いサポート

ESIグループ

ESIグループ（ESIソフトウェア（インド）プライベート・リミテッド）

ESIグループ（北米）

ESIグループ（日本ESI）

ESIウェブチーム

そして、以下からの貢献

OpenFOAMコミュニティ

OpenFOAM

2024-12-03T14:06:41Z

Mmer547: /* リリースノート */

このページではOpenFOAMについてまとめていきます。

== リリースノート ==

'''OpenCFD'''

[[OpenFOAM v2406 リリースノート]]

[[OpenFOAM v2312リリースノート|OpenFOAM v2312 リリースノート]]

[[OpenFOAM v2306リリースノート|OpenFOAM v2306 リリースノート]]

[[OpenFOAM v2212 リリースノート]]

[[OpenFOAM v2206 リリースノート]]

[[OpenFOAM v2112 リリースノート]]

[[OpenFOAM v2106 リリースノート]]

[https://www.notion.so/OF2012-3625e0d8029b40bda20fafe481dcbd95 OpenFOAM v2012 リリースノート]

[[OpenFOAM v2006 リリースノート]]

[[OpenFOAM v1912 リリースノート]]

[[OpenFOAM v1906 リリースノート]]

[[OpenFOAM v1812 リリースノート]]

[[OpenFOAM v1806 リリースノート]]

'''The OpenFOAM Foundation'''

[[OpenFOAM 12 リリースノート]]

[[OpenFOAM 11 リリースノート]]

[[OpenFOAM 10 リリースノート]]

[[OpenFOAM 9|OpenFOAM 9 リリースノート]]

[[OpenFOAM 8 リリースノート]]

[[OpenFOAM v7 リリースノート]]

[[OpenFOAM v6.0 リリースノート]]

[[OpenFOAM 4.0 リリースノート]]

[[OpenFOAM 3.0.0 リリースノート]]

[[OpenFOAM 2.4.0 リリースノート]]

==スターティングガイド==
[[OpenFOAMについて]]

[[OpenFOAMのインストール]]

[https://qiita.com/mmer547/items/e63d4cf76ea2fea659b2 チュートリアルケースの実行]

[https://qiita.com/mmer547/items/24b8491bf9776c3a27db OpenFOAMで入力できる項目の調べ方]

[https://qiita.com/mmer547/items/e4b13100e15508981a85 OpenFOAMの$FOAM変数]

==困った時は？==
[https://qiita.com/mmer547/items/7c7c257dcaf2efbc730b OpenFOAM Google Groupに投稿する際に抑えるポイント]

[https://qiita.com/mmer547/items/6b041536e2ac5dd17721 OpenFOAMで計算するネタがない時の探し方]

[[OpenFOAMのエラーメッセージの対応]]

==プリプロセス==

===形状作成===

[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%EF%BC%9A%E5%BD%A2%E7%8A%B6%E4%BD%9C%E6%88%90 形状作成ツールまとめ]

===メッシュ===
[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%E3%81%AE%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A3%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 OpenFOAMのメッシャーについて]

[[メッシュ作成:blockMesh]]

[[メッシュ作成:snappyHexMesh]]

[[メッシュ作成:cfMesh]]

[https://qiita.com/mmer547/items/9fca38b8e8eadc869bb8 SalomeでOpenFOAMのメッシュを用意する方法]

===境界条件===
[[境界条件]]

==ソルバ==
[[simpleFoamについて]]

[[ExecutionTimeとClockTimeについて]]

[https://scrapbox.io/opencae-kansai-memo/SIMPLEC%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E8%A8%88%E7%AE%97%E5%AE%9F%E8%A1%8C%EF%BC%88OpenFOAM3.0.1%EF%BC%89 SIMPLECを使用した計算実行（OpenFOAM3.0.1）]

===並列計算の実行方法===

[[decomposeParDictの中身]]

===エラーメッセージ===
[[v1806のエラーメッセージ]]

==ポストプロセス==
[[ログファイルから残差ログを抽出]]

[https://qiita.com/mmer547/items/e463235ddb93f08db68a OpenFOAMのpostProcessについて]

==チュートリアルケース==
[[チュートリアルケース|チュートリアルケース一覧]]

==カスタマイズ==
[https://qiita.com/mmer547/items/2997bf8c71fe1e2423c9 OpenFOAM ソースコードの探し方]

==その他==
[https://scrapbox.io/opencae-kansai-memo/foam-extend_4.0%E3%82%92Bash_on_Ubuntu_on_Windows%E3%81%AB%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB foam-extend 4.0をBash on Ubuntu on Windowsにインストール]

[https://scrapbox.io/opencae-kansai-memo/ESI_Windows%E7%89%88OpenFOAM%E3%81%AE%E5%B0%8E%E5%85%A5 ESI Windows版OpenFOAMの導入]

[https://gitlab.com/OpenCAE/Supercomputer-OpenFOAM-Training/-/wikis/home スーパーコンピュータOpenFOAM講習会]

== 関連サービス ==
=== プリプロセス ===
[https://www.xsim.info/products/products.html XSim.Work]

== 関連書籍 ==

[https://www.amazon.co.jp/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEDEXCS-OpenFOAM%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E9%87%8E%E6%9D%91-%E6%82%A6%E6%B2%BB/dp/4621306138/ref=sr_1_5?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-5 オープンCAEのためのDEXCS for OpenFOAMハンドブック]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E7%AC%AC2%E7%89%88-%E4%B8%80%E8%88%AC%E7%A4%BE%E5%9B%A3%E6%B3%95%E4%BA%BA%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691025/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-1 OpenFOAMによる熱移動と流れの数値解析(第2版) ]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AE%E6%AD%A9%E3%81%8D%E6%96%B9-%E6%8A%80%E8%A1%93%E3%81%AE%E6%B3%89%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%EF%BC%88NextPublishing%EF%BC%89-%E5%B7%9D%E7%95%91-%E7%9C%9F%E4%B8%80/dp/4844379526/ref=sr_1_6?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-6　OpenFOAMの歩き方]

[https://www.amazon.co.jp/OpenFOAM%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%83%86%E3%83%A9%E3%83%90%E3%82%A4%E3%83%88/dp/4627691610/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-2 OpenFOAMライブラリリファレンス]

[https://www.amazon.co.jp/OpenFOAM%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-Tomislav-Mari%C2%B4c/dp/4627670915/ref=sr_1_3?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-3 OpenFOAMプログラミング]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691017/ref=sr_1_4?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-4 OpenFOAMによる熱移動と流れの数値解析]

OpenFOAM 12 リリースノート

2024-12-02T12:38:19Z

Mmer547: ページの作成:「OpenFOAM Foundationは、オープンソースCFDツールボックスOpenFOAMのバージョン12のリリースを発表します。バージョン12では、モジュール式ソルバーとNCC（Non Conformal Coupling）を活用し、メッシングやカップリングの簡素化など、複数の領域を含むシミュレーションを改善しました。インジェクションや分配、並列分解、再分配、負荷分散など、粒子コー…」

OpenFOAM Foundationは、オープンソースCFDツールボックスOpenFOAMのバージョン12のリリースを発表します。バージョン12では、モジュール式ソルバーとNCC（Non Conformal Coupling）を活用し、メッシングやカップリングの簡素化など、複数の領域を含むシミュレーションを改善しました。インジェクションや分配、並列分解、再分配、負荷分散など、粒子コードの書き換え作業が続いている。新しい便利な境界条件や、入力値に[bar]などの単位を含めるオプションがあり、それに応じて変換されます。 TUbuntu24.04および22.04用のopenfoam12パッケージが標準のparaviewパッケージを使用するようになり、サードパーティ製ソフトウェアのインストールがより簡単になりました。

OpenFOAM 12には次のようなハイライトがある。

* モジュール式ソルバー：他の変数の方程式のための1変数のソース項をサポートしています。
* 多相：質量、運動量、熱伝導、固相のモデルの改良。
* 乱流モデリング：簡略化および補正された壁関数のロバストな制限。
* 熱：粘性加熱モデルを追加し、熱力学的特性の名称を改良。
* 粒子追跡：一般化された射出と粒子分布。
* メッシュ：メッシュ生成と複数のメッシュ領域の結合をアップグレード。
* 並列実行：負荷分散、分解、再分配のための効率的なオプション。
* ファンクション・オブジェクト：system/functionsファイルに移動し、新しいファンクション・オブジェクトを追加。
* モデル：質量の連続性に追加される体積と質量のソース。
* 境界条件：新しい圧力、速度、温度の境界条件。
* ケース構成：パラメータには単位を含めることができる（例：[bar]）。
* プログラミング：ソースコードを検索するfoamFindスクリプト、コード化された関数オブジェクトの例。
* その他 ParaViewと分解ライブラリのインストールがより簡単になりました。
* 722件のコードコミット、100件以上の問題解決。
* ISO/IEC 14882:2011 (C++14): GCC v5.5+、Clang v16+でテスト済み（v10+でも動作するはず）。

OpenFOAM 12は、以下のプラットフォーム用にパッケージ化されています：

* Ubuntu Linux: Ubuntu 20.04、22.04、24.04用のパッケージインストール；
* Windows：UbuntuパックでLinux用のWindowsサブシステムを使用してインストールします；
* cmacOS: UbuntuパックでCanonical Multipassを使用したインストール。

OpenFOAM 12 Source Packは、適切なLinuxプラットフォームでコンパイルできます。

== モジュール式ソルバー ==

* 一般：ソルバーモジュールによる入力パラメータの再読み込みがよりシンプルで効率的になりました[ commit 6054b1 ]。多領域ケースに、特定の許容値に達したときに解を停止する、より単純なコントロールが含まれるようになりました[ commit 815f0b ]。
* 非圧縮ソルバーと圧縮ソルバー： dnsFoamソルバーはOUForce fvModelを持つincompressibleFluidソルバーモジュールに置き換えられました。
* 堅実なソルバー：熱物理モデル補正ステップを非直交補正ループ内に移動することにより、固体ソルバーモジュールを修正しました。
* フィルムソルバー： isothermalFilmソルバーモジュールでインピンジメント圧力が修正されました[ commit 0b321e ]。
* 数値計算：異なる変数に関する方程式に適用される1変数のソース項用の新しい sourceProxy() 関数を作成しました。例えば、体積/質量ソースを圧力方程式（密度ではなく）に適用します。[コミット a5ea0b ].

== 多相 ==

* 運動量移動: multiphaseEulerFoamに新しい陰解法抗力アルゴリズムが追加され、小粒子やEuler-VoFの高抗力ケースの収束が大幅に改善されました[ commit 5fd304 ]。新しい陰解法による仮想質量力の実装により、気泡流ケースの収束性が大幅に改善されました[ commit 18200e ]。
* 物質移動: multiphaseEulerFoam が均質凝結と相分離のモデルを含むようになりました [ commit 046680c4 ]。 coefficientMassTransfer fvModelは2相間の物質移動を生成するプロトタイプの例です[ commit 2f018f ]。
* 熱伝導： multiphaseEulerソルバーに単純なPrandtl熱伝達モデルを追加し、対応する抗力モデルの運動量伝達係数に比例した熱伝達係数を作成するようにしました[ commit 01d0af39 ]。
* 固相：固相の新しい熱相モデルを追加しました[ commit 020463 ]。定常相のサポートを改善しました[ commit 9c3a40 ]。新しいphaseSolidThermophysicalTransportModelクラスを使用するように更新し、定常固相での異方性伝導をサポートしました[ commit 5e0387 ]。等温定常固相のための新しいIsothermalSolidPhaseModel [ commit ad3d25 ]。
* 境界条件： multiphaseExternalTemperature境界条件は、multiphaseFluidソルバーモジュールのexternalTemperatureを提供します[ commit 6fce00 ]。
* インターフェイスのキャプチャ：多相ソルバーにおいて、PLICやMPLICなどの圧縮界面スキームをCrank-Nicolson時間スキーム[ commit 7ec1e2 ]でよりロバストにしました。
* 表面波：新しい不規則表面波モデル [ commit c0da2a ]。 GodaJONSWAP波浪スペクトルは、風速とフェッチの代わりに有義波高と周期が指定される、JONSWAPスペクトルの代替近似パラメータ化を提供します[ commit cbec0045 ]。

== 乱流モデリング ==

* RASのモデリング：乱流散逸εの境界の下限は、安定性とロバスト性を改善するεの最小値ではなく、最大乱流粘性ナットに基づいています[ commit 854f4541 ]また、乱流散逸ωについても同じです[ commit 195dfbe1 ]。
* 壁関数： alphatJayatillekeWallFunction熱壁関数は、実装を単純化し、より一貫性を持たせるために、それぞれのナット運動量壁関数のyPlusを使用します[ commit 054a5206 ]。乱流壁関数のωとεのコーナー重み付けを再実装しました[ commit 1218bd08 ]。非整形多領域の場合の壁関数の境界条件のマッピングを修正しました[ commit b6caf356 ]。

== 熱 ==

* エネルギーだ：新しいviscousHeating fvModelが、全エネルギー方程式に粘性加熱源を追加しました[ commit bbc39318 ]。
* 熱力学：熱力学のすべての物性関数は、エネルギーやエンタルピーが特定の量であることを示すために小文字を使うようになりました[ commit abe43a95 ]。

== パーティクルとトラッキング ==

* 分配金：分布のコードを一般化し、書き換え助詞のコードを含め、より広く使えるようにしました [ commit e1e0e258 ]。
* 注射をする：ラグランジュモデリングにおいて、パッチインジェクションモデルの U0 エントリに、初速度を補間するフィールド名を指定できるようになりました[ commit 96b61305 ]。
* データ処理：新しいvolumeFraction関数は粒子雲の体積率を計算します[ commit 31b096 ]。

== メッシュ ==

* 一般的なことだ： dynamicMeshライブラリは、保守性を向上させるためにコードを大幅にリファクタリングした結果、polyTopoChangeライブラリとmotionSolversライブラリに分離されました[ commit b9fe7df3 ]。
* 生成： extrudeMeshに新しいcylindricalRadial押し出しメソッドが追加されました [ commit e880ec ]. extrudeMeshは新しく生成されたセルを1つ以上のセルゾーンに割り当てることができるようになりました [ commit 33aa4496 ]. snappyHexMeshは-regionオプションを使ってリージョンメッシュを直接リージョンサブディレクトリに生成できるようになりました [ commit 9ace5366 ]. snappyHexMeshのレイヤー挿入のfeatureAngleパラメーターの使用を修正しました[ commit 47fa9bc6 ]。
* 複数リージョン：mergeMeshesは別々のメッシュ（別々のpolyMeshディレクトリ）のリストを1つのメッシュ（1つのpolyMeshディレクトリ）にまとめることができます[ commit f47e1b0b ]。 stitchMeshアプリケーションをnon-conformal coupledインターフェイスのパッチ交差機能を使用するように置き換えた [ commit 69da8f3d ]。
* 非共形結合： NCCを並列再分配（負荷分散）と適応的精密化でメッシュの動きに対応させる [ commit 9af6bd ]。 NCC などのメッシュスティッチャーのロバスト性を改善 [ commit 2057174b ]。
* Boundary: 新しい patchOrder ユーティリティでメッシュのパッチの並び替えができるようになりました [ commit 4707bc91 ]。
* その他 checkMeshユーティリティまたはcheckMesh関数オブジェクト(後者は移動メッシュの場合)を使ってメッシュをチェックすることができます。
* モーションマルチバルブICエンジンのメッシュモーションのための新しいfvMeshMover [ commit 7d65e66b ]。
* ゾーン：メッシュゾーンの処理が改善されました。[ コミット ca2cae8c] コードの重複を削減しました。[コミット4ad52ea1]

== パラレルランニング ==

* Lオードバランシング：パーティクルクラウドトラッキングやケミストリーの統合は、CPUロードキャッシングをオンにすることで、並列シミュレーション中に自動ロードバランシングを使用することができます[ commit 41705e9e ]。新しい parMETIS インターフェースは、ParMETIS ディストリビューターを使用したマルチ制約と再分配による負荷分散を提供した [ commit 40bcabf7 ]。 aachenBomb のチュートリアルの例では、ラグランジュと化学の両方による多制約の負荷分散を示しています [ commit e727809b ]。
* 分解と再配布: decomposePar が NCC を使用する際に nonConformalProcessorCyclic パッチを正しく作成するようになりました [ commit 89c818 ]。動的メッシュ精密化の並列ロバスト性を改善 [ commit cd133a28 ]。特にsnappyHexMesh [ commit adfc80c4 ]を使って並列メッシュを作成するときに起こりうる、あるプロセッサが一時的にゼロセルを含むときに、Zoltanをメッシュの再配分に使えるようになりました; ParMETIS [ commit 3cdec1dc ]でも同じです。

== 機能オブジェクト ==

* 一般的なことだ：関数オブジェクトは別の system/functions ファイルで設定されるべきで、不要な関数オブジェクトの読み込みやビルドを避けるためです [ commit de363dde ]。新しいfluidMaxDelta関数オブジェクトは、時間の関数として最大時間ステップとクーラント数を設定できます[ commit 277944 ]。writeObjects関数Objectは、指定されたオブジェクトが見つからない場合、オブジェクト・レジストリからすべてのオブジェクト名とその型を表示します[ commit 5039aec6 ]。パッチを操作する関数オブジェクトは、単一のパッチのpatchキーワードと複数のパッチのpatchキーワードの両方を読むことができます [ commit e5f48bfc ]。
* 力だ：新しいmovingForcesとrigidBodyForces関数オブジェクトは、指定された、または計算された回転中心を持つ移動剛体の力とモーメントを計算し、書き込みます[ commit 2daceb90 ]。wallShearStress関数オブジェクトは、filmWall [ commit 898cb9b5 ]など、どのタイプのウォールパッチでも計算できます。
* フィールド cylindricalパッケージ関数オブジェクトはベクトル場を円筒座標に変換します[ commit 1622e190 ]。新しいspecieFlux、specieAdvectiveFlux、specieDiffusiveFlux関数オブジェクトは流体種のフラックスをsurfaceScalarFieldとして計算します。
* ICエンジン：新しいmultiValveEngineState functionObjectはICエンジンの計算でピストンとバルブの動きを表示し、ログに記録します[ commit 9753b67f ]。
* その他 phaseScalarTransport関数オブジェクトで、alphaPhiフィールドが存在しない場合、新しいsolveAlphaPhiスイッチを設定することで計算できるようになりました[ commit 2bc91ecf ]。

== Models ==

* 一般的なことだ： MRFはアダプティブ・メッシュ・リファインメントで動作します[ commit cdef2003 ]。
* 液体ソース：新しいvolumeSource fvModelは非圧縮性ソルバーには連続方程式に体積ソースを適用し、圧縮性ソルバーには同等のmassSource fvModelを適用します[ commit 9181a6 ]。ドメインに流体を導入するfvModelsからのソースがフィールドファイルのboundaryFieldセクションで指定されるようになりました[ commit 171101 ]。
* 勢いだ：新しい propellerDisk fvModel は、プロペラ曲線 [ commit b3b1b5b6 ] に基づいて、プロペラを近似するディスク運動量ソースを提供します。
* その他新しいOUForce fvModelは等方乱流の箱の直接数値シミュレーションのためにランダムなOrnstein-Uhlenbeck過程の力を計算し、運動量方程式に適用します[ commit f0ee70 ]。

== 一般的な境界条件 ==

* 圧力：entrainmentPressure境界条件は、テンプレートケースの例[ commit 2a9a2d0e ]の開いた境界での圧力に推奨されています。
* ベロシティ円筒座標で入口速度を記述するcylindricalInletVelocity境界条件において、角速度をrad/sまたはrpmで指定できるようになりました。movingMappedWallVelocity境界条件は、2つのメッシュ領域の境界で使用することができ、片側の壁からもう片側の流体に対して滑り止め条件を適用することができます[ commit 59ebac71 ]。
* 温度だ：新しいlumpedMassTemperature境界条件は、境界パッチ[ commit 3ab0e63e ]によって全体的または部分的に囲まれた固体の温度をモデル化します。
* 一般的なことだ：表データを持つFunction1の補間スキームのデフォルトは線形ですが、ステップに設定できるようになりました[ commit 50c053 ]。すべての境界条件におけるフィールドマッピングの簡略化 [ commit cef86f ]。多項式 Function1 はより単純な入力構文を持つ [ commit c3f131e8 ]。
* カップリング： nonConformalMappedWallパッチタイプは、例えばCHTのために、界面で面を適合させる必要なしに、別々の領域のメッシュを接続する柔軟な方法を提供します[ commit a3e38977 ]。

== ケース構成 ==

* データの可視化: foamMonitorに、データの列を選択し、Y軸に独立変数をプロットし、定期的に更新することなく単一のグラフを表示する新しいオプションが追加されました[ commit 9252d0c0 ]。
* ケースの初期化: deltaTFactorをcontrolDictファイルで設定し、可変時間ステップでの調整率を制限することができます。無次元のパラメータはdimension []; [ commit 87ff44 ]で指定できる。 foamDictionaryに-outputオプションが追加され、変更された辞書を任意の指定されたファイルに書き出せるようになりました[ commit 6d9bc6 ]。寸法付きパラメータを値の前後に寸法を指定できるようになりました[ commit 209a3756 ]。foamDictionary に入力ファイルの項目名を変更するオプションが追加されました [ commit b0dbdd4a ]。
* 単位：入力パラメーターに単位を指定できるようになり、例えば圧力の[bar]は、kg/(ms²) [ commit 476bb42b ]のような従来の単位に変換されます。新しいfoamUnitsスクリプトは、入力パラメータの単位(例えば[cal]や[J])とその変換、および次元単位を記述します[ commit e4abe3d5 ]。例えば、回転速度omegaは[rpm] [ commit 3928fbb8 ]として指定されます。

単位については、"OpenFOAM User Guide "を参照してください： 4.2.6. 次元単位" と以下のサブセクション、および foamUnits スクリプトについては、"OpenFOAM User Guide： 4.7.7 foamUnits スクリプト" を参照してください。

== プログラミング ==

* コード化された入力：入力ファイル用の#calcディレクティブは、ニュートン・ラプソン反復を使って方程式の根を求める例で示されます[ commit cc9991 ]。入力ファイルに対する#codeStreamディレクティブは、グラフデータをプロットする例で示されます[ commit fbc36b ]。 pitzDailySteady のサンプルケースには、ひずみ率を書き込むコード化された関数オブジェクトが含まれています [ commit 58cb08 ]。コード化された関数オブジェクトの例をいくつか追加しました [ commit 811faaa0 ]。
* コード検索: 新しい foamFind スクリプトは OpenFOAM ファイルを検索し、オプションでファイル全体または検索文字列にマッチする行を表示して内容を処理します [ commit 1c6d785c ]。

foamFind スクリプトの詳細については、"OpenFOAM User Guide "を参照してください： 4.7.8 foamFind スクリプト" を参照してください。

== その他 ==

* その他の数字：一般的な分布に standardNormal 関数を追加 [ commit d34d9b93 ]。
* フィールドフィールドはメッシュのパッチの順番でパッチフィールドを構築するようになり、ロバスト性が向上しました [ commit 16b8bf5e ]。
* データ出力： I/Oで時刻が使用される場合、各値が一意になるように精度が自動的に調整される [ commit d2817a0 ]。
* インストール： ParaViewと分解ライブラリのインストールを制御する新しい環境変数を追加 [ commit 48fcb7f6 ]。

== クレジット ==
OpenFOAM12は、次のように制作された：

* メンテナンス (CFD Direct): Henry Weller, Will Bainbridge, Chris Greenshields.
* 投稿者: Timo Niemi, Juho Peltola, Heikki Kahila, Bulut Tekgül, Stanislau Stasheuski.

== ライセンス ==
OpenFOAM 12は、OpenFOAM FoundationによってGeneral Public Licence v3の下で配布されています。

OpenFOAM

2024-12-02T12:23:12Z

Mmer547: /* リリースノート */

このページではOpenFOAMについてまとめていきます。

== リリースノート ==

'''OpenCFD'''

[[OpenFOAM v2312リリースノート|OpenFOAM v2312 リリースノート]]

[[OpenFOAM v2306リリースノート|OpenFOAM v2306 リリースノート]]

[[OpenFOAM v2212 リリースノート]]

[[OpenFOAM v2206 リリースノート]]

[[OpenFOAM v2112 リリースノート]]

[[OpenFOAM v2106 リリースノート]]

[https://www.notion.so/OF2012-3625e0d8029b40bda20fafe481dcbd95 OpenFOAM v2012 リリースノート]

[[OpenFOAM v2006 リリースノート]]

[[OpenFOAM v1912 リリースノート]]

[[OpenFOAM v1906 リリースノート]]

[[OpenFOAM v1812 リリースノート]]

[[OpenFOAM v1806 リリースノート]]

'''The OpenFOAM Foundation'''

[[OpenFOAM 12 リリースノート]]

[[OpenFOAM 11 リリースノート]]

[[OpenFOAM 10 リリースノート]]

[[OpenFOAM 9|OpenFOAM 9 リリースノート]]

[[OpenFOAM 8 リリースノート]]

[[OpenFOAM v7 リリースノート]]

[[OpenFOAM v6.0 リリースノート]]

[[OpenFOAM 4.0 リリースノート]]

[[OpenFOAM 3.0.0 リリースノート]]

[[OpenFOAM 2.4.0 リリースノート]]

==スターティングガイド==
[[OpenFOAMについて]]

[[OpenFOAMのインストール]]

[https://qiita.com/mmer547/items/e63d4cf76ea2fea659b2 チュートリアルケースの実行]

[https://qiita.com/mmer547/items/24b8491bf9776c3a27db OpenFOAMで入力できる項目の調べ方]

[https://qiita.com/mmer547/items/e4b13100e15508981a85 OpenFOAMの$FOAM変数]

==困った時は？==
[https://qiita.com/mmer547/items/7c7c257dcaf2efbc730b OpenFOAM Google Groupに投稿する際に抑えるポイント]

[https://qiita.com/mmer547/items/6b041536e2ac5dd17721 OpenFOAMで計算するネタがない時の探し方]

[[OpenFOAMのエラーメッセージの対応]]

==プリプロセス==

===形状作成===

[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%EF%BC%9A%E5%BD%A2%E7%8A%B6%E4%BD%9C%E6%88%90 形状作成ツールまとめ]

===メッシュ===
[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%E3%81%AE%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A3%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 OpenFOAMのメッシャーについて]

[[メッシュ作成:blockMesh]]

[[メッシュ作成:snappyHexMesh]]

[[メッシュ作成:cfMesh]]

[https://qiita.com/mmer547/items/9fca38b8e8eadc869bb8 SalomeでOpenFOAMのメッシュを用意する方法]

===境界条件===
[[境界条件]]

==ソルバ==
[[simpleFoamについて]]

[[ExecutionTimeとClockTimeについて]]

[https://scrapbox.io/opencae-kansai-memo/SIMPLEC%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E8%A8%88%E7%AE%97%E5%AE%9F%E8%A1%8C%EF%BC%88OpenFOAM3.0.1%EF%BC%89 SIMPLECを使用した計算実行（OpenFOAM3.0.1）]

===並列計算の実行方法===

[[decomposeParDictの中身]]

===エラーメッセージ===
[[v1806のエラーメッセージ]]

==ポストプロセス==
[[ログファイルから残差ログを抽出]]

[https://qiita.com/mmer547/items/e463235ddb93f08db68a OpenFOAMのpostProcessについて]

==チュートリアルケース==
[[チュートリアルケース|チュートリアルケース一覧]]

==カスタマイズ==
[https://qiita.com/mmer547/items/2997bf8c71fe1e2423c9 OpenFOAM ソースコードの探し方]

==その他==
[https://scrapbox.io/opencae-kansai-memo/foam-extend_4.0%E3%82%92Bash_on_Ubuntu_on_Windows%E3%81%AB%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB foam-extend 4.0をBash on Ubuntu on Windowsにインストール]

[https://scrapbox.io/opencae-kansai-memo/ESI_Windows%E7%89%88OpenFOAM%E3%81%AE%E5%B0%8E%E5%85%A5 ESI Windows版OpenFOAMの導入]

[https://gitlab.com/OpenCAE/Supercomputer-OpenFOAM-Training/-/wikis/home スーパーコンピュータOpenFOAM講習会]

== 関連サービス ==
=== プリプロセス ===
[https://www.xsim.info/products/products.html XSim.Work]

== 関連書籍 ==

[https://www.amazon.co.jp/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEDEXCS-OpenFOAM%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E9%87%8E%E6%9D%91-%E6%82%A6%E6%B2%BB/dp/4621306138/ref=sr_1_5?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-5 オープンCAEのためのDEXCS for OpenFOAMハンドブック]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E7%AC%AC2%E7%89%88-%E4%B8%80%E8%88%AC%E7%A4%BE%E5%9B%A3%E6%B3%95%E4%BA%BA%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691025/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-1 OpenFOAMによる熱移動と流れの数値解析(第2版) ]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AE%E6%AD%A9%E3%81%8D%E6%96%B9-%E6%8A%80%E8%A1%93%E3%81%AE%E6%B3%89%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%EF%BC%88NextPublishing%EF%BC%89-%E5%B7%9D%E7%95%91-%E7%9C%9F%E4%B8%80/dp/4844379526/ref=sr_1_6?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-6　OpenFOAMの歩き方]

[https://www.amazon.co.jp/OpenFOAM%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%83%86%E3%83%A9%E3%83%90%E3%82%A4%E3%83%88/dp/4627691610/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-2 OpenFOAMライブラリリファレンス]

[https://www.amazon.co.jp/OpenFOAM%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-Tomislav-Mari%C2%B4c/dp/4627670915/ref=sr_1_3?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-3 OpenFOAMプログラミング]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691017/ref=sr_1_4?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-4 OpenFOAMによる熱移動と流れの数値解析]

チュートリアルケース

2024-11-08T08:06:09Z

Mmer547:

ドキュメント作成される方は既存ページをご参考の上、基本情報の表を各ページにお書きください。それ以外の記載はご自由にどうぞ。

テンプレートを用意しているので、新規ページには<nowiki>{{subst:OfTutTemplate}}</nowiki>と書いて一度保存後、編集してください。

XSim様がOpenFOAM v4.0についてチュートリアルのドキュメント化を完走されています。

[https://www.xsim.info/articles/OpenFOAM/Tutorials.html XSim：OpenFOAM 付属チュートリアル一覧]

== 標準tutorials ==
===DNS(直接数値シミュレーション)===
*dnsFoam：

===Basic(基礎的なCFDコード)===
*[[laplacianFoam：フランジの熱伝導解析]]
*[[PotentialFoam：pitzDaily（ポテンシャル流れ）]]
*[[potentialFoam：円柱周りの流れ（ポテンシャル流れ）]]
*[[scalarTransportFoam： pitzDaily（パッシブスカラの輸送）]]

===Combustion(燃焼)===
*[[chemFoam：燃焼反応 CH4 ( 53 化学種, 325 反応 )]]
*[[chemFoam：燃焼反応 H2 ( 10 化学種, 27 反応 )]]
*[[chemFoam：燃焼反応 n-ヘプタン ( 544 化学種, 2446 反応 )]]
*[[chemFoam：燃焼反応 iso-オクタン ( 874 化学種, 3796 反応 )]]
*dieselFoam：
*engineFoam：
*fireFoam：
*PDRFoam：
*reactingFoam：
*XiFoam：

===Compressible(圧縮性流れ)===
*rhoCentralFoam：
*rhoPimpleFoam：
*rhoPorousMRFLTSPimpleFoam：
*rhoPorousMRFPimpleFoam：
*rhoPorousMRFSimpleFoam：
*rhoSimplecFoam：
*sonicFoam：
*sonicLiquidFoam：

*[[steadyCompressibleSRFFoam : 平板動翼の定常回転流れ場]]
*[[steadyCompressibleSRFFoam : 曲がった動翼の定常回転流れ場]]
*[[steadyCompressibleMRFFoam : 平板動静翼の定常回転流れ場]]
*[[steadyCompressibleMRFFoam : 曲がった動静翼の定常回転流れ場]]
*[[steadyUniversalMRFFoam : 軸流タービンのggiジャンプ]]
*[[steadyUniversalMRFFoam : 軸流タービンのミキシングプレーン]]

===DiscreteMethods(離散法)===
*dsmcFoam：freeSpacePeriodic
*dsmcFoam：freeSpaceStream
*dsmcFoam：supersonicCorner
*dsmcFoam：wedge15Ma5
*molecularDynamics：mdEquilibrationFoam：periodicCubeArgon
*molecularDynamics：mdEquilibrationFoam：periodicCubeWater
*molecularDynamics：mdFoam：nanoNozzle

===Electromagnetics(電磁流体)===
*electrostaticFoam：chargedWire
*mhdFoam：hartmann

===Finance(金融工学)===
*[[financialFoam：ブラック・ショールズ方程式]]

===HeatTransfer(熱輸送と浮力駆動流れ)===
*buoyantBaffleSimpleFoam：
*[[buoyantBoussinesqPisoFoam:hotroom:非定常浮力対流計算]]
*buoyantBoussinesqPimpleFoam：hotRoom
*buoyantBoussinesqSimpleFoam：hotRoom
*[[buoyantBoussinesqSimpleFoam：iglooWithFidges]]
*buoyantPimpleFoam：hotRoom
*[[buoyantSimpleFoam：buoyantCavity]]
*[[buoyantSimpleFoam：circuitBoardCooling]]
*[[buoyantSimpleFoam：hotRoom]]
*buoyantSimpleRadiationFoam：hotRadiationRoom
*buoyantSimpleRadiationFoam：hotRadiationRoomFvDOM
*[[chtMultiRegionFoam：multiRegionHeater]]
*[[chtMultiRegionFoam：multiRegionLiquidHeater]]
*[[chtMultiRegionFoam：windshieldDefrost:氷層の融解シミュレーション]]
*[[chtMultiRegionSimpleFoam：流体-固体熱連成解析（定常）]]
*[[chtMultiRegionSimpleFoam：熱交換器とファン]]
*chtMultiRegionSimpleFoam：multiRegionHeaterRadiation

===Incompressible(非圧縮性流れ)===
*adjointShapeOptimizationFoam：pitzDaily
*[[boundaryFoam：平行平板間の発達した境界層の壁関数プロファイル]]
*channelFoam：
*icoFoam：
*[[MRFSimpleFoam：回転攪拌槽の流れ]]
*[[nonNewtonianIcoFoam：流路中心から外れた円柱周りの流れ]]
*[[pimpleDyMFoam：スクリューの回転流れ場]]
*[[pimpleDyMFoam: 円筒容器内での台形型ピストン押し込み流れ]]
*[[pimpleDyMFoam: 気流中にバネで懸架された翼型の６自由度剛体運動]]
*[[pimpleFoam：T型分岐管の流れ]]
*[[pimpleFoam:T型分岐管の流れ（ファン付き）]]
*[[pimpleFoam:楕円柱周りの流れ（乱流モデル比較）]]
*[[pisoFoam：pitzDaily(LES)]]
*porousSimpleFoam：
*[[potentialFreeSurfaceFoam:浮子の振動で生じる表面のさざ波]]
*[[shallowWaterFoam：浅水方程式による矩形段差流れ]]
*[[simpleFoam：pitzDaily]]
*[[simpleFoam（windSimpleFoam）：風力発電所の風環境シミュレーション]]
*SRFSimpleFoam：

*simpleSRFFoam : 軸流タービン動翼の定常非圧縮回転流れ場
*simpleSRFFoam : ミキサー動翼の定常非圧縮回転流れ場
*MRFSimpleFoam : 軸流タービン動静翼ggi定常回転流れ場
*MRFSimpleFoam : 軸流タービンのミキシングプレーン
*MRFSimpleFoam : ミキサー動静翼ggi定常回転流れ場
*pimpleDyMFoam : 軸流タービンの非定常回転流れ場

===Lagrangian(ラグランジュ法による粒子追跡)===
*DPMFoam：Goldschmidt
*coalChemistryFoam：simplifiedSiwek
*icoUncoupledKinematicParcelFoam：hopper
*LTSReactingParcelFoam：counterFlowFlame2D
*LTSReactingParcelFoam：verticalChannel
*MPPICFoam：Goldschmidt
*MPPICFoam：column
*MPPICFoam：cyclone
*MPPICFoam：injectionChannel
*porousExplicitSourceReactingParcelFoam：
*reactingParcelFilmFoam：cylinder
*reactingParcelFilmFoam：hotBoxes
*reactingParcelFilmFoam：rivuletPanel
*reactingParcelFilmFoam：splashPanel
*reactingParcelFoam：filter
*reactingParcelFoam：parcelInBox
*reactingParcelFoam：verticalChannel
*simpleReactingParcelFoam：verticalChannel
*sprayFoam：aachenBomb

===Mesh(メッシュ)===
*foamyHexMesh：blob
*foamyHexMesh：flange
*foamyHexMesh：mixerVessel
*foamyHexMesh：simpleShapes
*foamyHexMesh：straightDuctImplicit
*foamyQuadMesh：OpenCFD
*foamyQuadMesh：jaggedBoundary
*foamyQuadMesh：square
*[[moveDynamicMesh：simpleHarmonicMotion]]
*[[moveDynamicMesh:SnakeRiverCanyon]]
*snappyHexMesh：flange
*snappyHexMesh：iglooWithFridges
*snappyHexMesh：motorBike
*snappyHexMesh：snappyMultiRegionHeater

===Multiphase(多相流)===
*bubbleFoam：
*[[cavitatingFoam：フラッシング解析(ras)]]
*[[cavitatingFoam:フラッシング解析(2D-LES)]]
*[[cavitatingFoam:フラッシング解析(3D-LES)]]
*[[compressibleInterFoam：水中爆雷2D]]
*compressibleInterFoam:水中爆雷3D
*compressibletwoPhaseEulerFoam:
*[[interDyMFoam：撹拌槽内の流れ]]
*interDyMFoam:二次元スロッシングタンク
*interDyMFoam:三次元スロッシングタンク
*[[interFoam：ダム（水柱）の決壊]]
*[[interFoam：毛細管現象]]
*[[interFoam:ノズル噴流2D]]
*[[interFoam:水路]]
*[[interFoam:越流堰]]
*[[interFoam:傾斜ダクトの下面から注入した水が上面から溢れ出る挙動]]
*interMixingFoam：
*[[interPhaseChangeFoam：弾丸周りのキャビテーション流れ]]
*[[interPhaseChangeDyMFoam：プロペラのキャビテーション解析]]
*LTSInterFoam：
*[[MRFInterFoam：回転撹拌槽の二相流]]
*[[MRFMultiphaseInterFoam：多相ダム（水柱）の決壊]]
*[[multiphaseInterFoam:2D回転撹拌槽の混相流]]
*[[multiphaseEulerFoam:2D回転撹拌槽の混相流]]
*multiphaseInterFoam：
*[[potentialFreeSurfaceDyMFoam:浮子の振動で生じる表面のさざ波]]
*settlingFoam：
*twoPhaseEulerFoam：fluidized bed
*twoPhaseEulerFoam:fluidized bed2
*[[twoPhaseEulerFoam:気泡塔]]
*twoPhaseEulerFoam:回転撹拌槽
*[[twoPhaseEulerFoam:液中への気体注入]]

===StressAnalysis(固体応力解析)===
*[[solidDisplacementFoam：円孔板の応力解析]]
*[[solidEquilibriumDisplacementFoam：はりの曲げ解析]]

==ext版tutorials==
===coupled(領域の連成)===
*conjugateHeatFoam : conjugateCavity
*blockCoupledScalarTransportFoam : blockCoupledSwirlTest

===surfaceTracking(界面追跡法)===
*[[surfactantFoam : sphereTransport]]
*[[interTrackFoam : tank3D 3次元タンク内液面変化]]
*[[interTrackFoam : sloshing2D ２次元スロッシング]]
*[[interTrackFoam : ramp 傾斜がある場所での自由表面流れ]]
*[[interTrackFoam : hydrofoil 翼近くの自由表面変形問題]]
*[[bubbleInterTrackFoam : bubble2D_r0.75mm : 気泡の変形]]

===viscoelastic(粘弾性流体)===
*viscoelasticFluidFoam : XPP_SE
*viscoelasticFluidFoam : XPP_DE
*viscoelasticFluidFoam : whiteMetzer
*viscoelasticFluidFoam : S-MDCPP
*viscoelasticFluidFoam : PPT-Linear
*viscoelasticFluidFoam : PPT-Exponential
*viscoelasticFluidFoam : Oldroyd-B
*viscoelasticFluidFoam : Lenov
*viscoelasticFluidFoam : Giesekus
*viscoelasticFluidFoam : Feta-PTT
*viscoelasticFluidFoam : DCPP
*viscoelasticFluidFoam : FENE-P
*viscoelasticFluidFoam : FENE-CR

===[[cfMesh(メッシュ)]]===
*cartesian2DMesh：hatOctree
*cartesianMesh：asmoOctree
*cartesianMesh：bunnyOctree
*cartesianMesh：elbow_90degree
*cartesianMesh：intakePortOctree
*cartesianMesh：multipleOrifices
*cartesianMesh：sBendOctree
*cartesianMesh：sawOctree
*cartesianMesh：ship5415Octree
*cartesianMesh：singleOrifice
*pMesh：bunnyPoly
*pMesh：multipleOrifices
*tetMesh：cutCubeOctree
*tetMesh：socketOctree

メインページ

2024-10-05T08:00:38Z

Mmer547: /* その他 */

オープンCAEWikiにようこそ！

本wikiはオープンソースCAEソフトウェアについての情報まとめています。
クローズドなwikiではありません。
ご編集されたい方はアカウントをご登録ください。

なお、内容はオープンCAEに関連するものでお願いします。

=== オープンCAEの前提知識 ===

[[Linux]]

[[解析用語]]

=== CAD ===
[[FreeCAD]]

=== メッシャー ===
[[Netgen]]

[[Gmsh]]

=== 流体 ===
[[OpenFOAM]]

[[SU2]]

=== 構造 ===
[[FrontISTR]]

[[Salome-Meca]]

[[CalculiX]]

[[PrePoMax]]

[[StressRefine]]

[[FEBio]]

[[PlantFEM]]

[[OpenRadioss]]

=== MBD(モデルベースデザイン) ===
[[OpenModelica]]

=== 機構解析 ===

[[MBDyn]]

[[EXUDYN]]

=== 有限要素法ライブラリ・ツールセット ===

[[GetFEM]]

[[DelFEM2]]

[[sparselizard]]

[[ivyFEM]]

=== マルチフィジックス ===
[[Elmer]]

=== 粒子法 ===
[[DualSPHygics]]

[[OpenMPS]]

=== 格子ボルツマン法 ===
[[Palabos]]

[[waLBerla]]

=== 偏微分方程式ソルバ ===

[[FEniCSx]]

=== 可視化 ===
[[Paraview]]

[[PyVista]]

[[Mayavi]]

=== 最適化 ===
[[OpenMDAO]]

[[OpenDA]]

[[Dakota]]

=== クラウド ===

[[SimScale]]

=== ベンチマーク ===
[https://www.cenav.org/ 計算工学ナビ]

[https://feaber.readthedocs.io/ja/latest/ FEABeR]

=== プログラミング ===
[[Python]]

[[C++]]

=== その他 ===

[[物性データベース]]

[[Blender]]

[[Maxima]]

[[REDUCE]]

[https://qiita.com/advent-calendar/2023/opencae オープンCAE Advent Calendar 2023]

[https://qiita.com/advent-calendar/2022/opencae オープンCAE Advent Calendar 2022]

[https://adventar.org/calendars/6423 オープンCAE Advent Calendar 2021]

[https://adventar.org/calendars/5192 オープンCAE Advent Calendar 2020]

[https://qiita.com/advent-calendar/2019/opencae-ac2019 オープンCAE Advent Calendar 2019]

[https://qiita.com/advent-calendar/2018/opencae-ac2018 オープンCAE Advent Calendar 2018]

[https://qiita.com/advent-calendar/2017/openfoam OpenFOAM Advent Calendar 2017]

=== オープンCAE ===
[[オープンCAEの系譜]]

[https://www.youtube.com/channel/UCuffpM6BjZWZ4AEDFiQexEg オープンCAE動画チャンネル]

[[各地の勉強会]]

[[勝手にブックレビュー]]

[[オープンCAE名言集]]

=== Wikiについて ===

本wikiはオープンCAE学会が管理しています。
オープンCAE学会については[http://www.opencae.or.jp 公式サイト]を参照してください。

PyVista

2024-10-05T07:27:02Z

Mmer547: ページの作成:「公式ページよりの説明<blockquote>Visualization Toolkit (VTK) の合理化されたインタフェースによる3 Dプロットおよびメッシュ解析</blockquote>[https://docs.pyvista.org/ 公式ページ] [https://pyvista.github.io/pyvista-docs-dev-ja/index.html 日本語ページ]」

公式ページよりの説明<blockquote>Visualization Toolkit (VTK) の合理化されたインタフェースによる3 Dプロットおよびメッシュ解析</blockquote>[https://docs.pyvista.org/ 公式ページ]

[https://pyvista.github.io/pyvista-docs-dev-ja/index.html 日本語ページ]

メインページ

2024-10-05T07:24:34Z

Mmer547: /* 可視化 */

オープンCAEWikiにようこそ！

本wikiはオープンソースCAEソフトウェアについての情報まとめています。
クローズドなwikiではありません。
ご編集されたい方はアカウントをご登録ください。

なお、内容はオープンCAEに関連するものでお願いします。

=== オープンCAEの前提知識 ===

[[Linux]]

[[解析用語]]

=== CAD ===
[[FreeCAD]]

=== メッシャー ===
[[Netgen]]

[[Gmsh]]

=== 流体 ===
[[OpenFOAM]]

[[SU2]]

=== 構造 ===
[[FrontISTR]]

[[Salome-Meca]]

[[CalculiX]]

[[PrePoMax]]

[[StressRefine]]

[[FEBio]]

[[PlantFEM]]

[[OpenRadioss]]

=== MBD(モデルベースデザイン) ===
[[OpenModelica]]

=== 機構解析 ===

[[MBDyn]]

[[EXUDYN]]

=== 有限要素法ライブラリ・ツールセット ===

[[GetFEM]]

[[DelFEM2]]

[[sparselizard]]

[[ivyFEM]]

=== マルチフィジックス ===
[[Elmer]]

=== 粒子法 ===
[[DualSPHygics]]

[[OpenMPS]]

=== 格子ボルツマン法 ===
[[Palabos]]

[[waLBerla]]

=== 偏微分方程式ソルバ ===

[[FEniCSx]]

=== 可視化 ===
[[Paraview]]

[[PyVista]]

[[Mayavi]]

=== 最適化 ===
[[OpenMDAO]]

[[OpenDA]]

[[Dakota]]

=== クラウド ===

[[SimScale]]

=== ベンチマーク ===
[https://www.cenav.org/ 計算工学ナビ]

[https://feaber.readthedocs.io/ja/latest/ FEABeR]

=== プログラミング ===
[[Python]]

[[C++]]

=== その他 ===

[[物性データベース]]

[[Blender]]

[[Maxima]]

[[REDUCE]]

[https://qiita.com/advent-calendar/2022/opencae オープンCAE Advent Calendar 2022]

[https://adventar.org/calendars/6423 オープンCAE Advent Calendar 2021]

[https://adventar.org/calendars/5192 オープンCAE Advent Calendar 2020]

[https://qiita.com/advent-calendar/2019/opencae-ac2019 オープンCAE Advent Calendar 2019]

[https://qiita.com/advent-calendar/2018/opencae-ac2018 オープンCAE Advent Calendar 2018]

[https://qiita.com/advent-calendar/2017/openfoam OpenFOAM Advent Calendar 2017]

=== オープンCAE ===
[[オープンCAEの系譜]]

[https://www.youtube.com/channel/UCuffpM6BjZWZ4AEDFiQexEg オープンCAE動画チャンネル]

[[各地の勉強会]]

[[勝手にブックレビュー]]

[[オープンCAE名言集]]

=== Wikiについて ===

本wikiはオープンCAE学会が管理しています。
オープンCAE学会については[http://www.opencae.or.jp 公式サイト]を参照してください。

PrePoMaxリリースノート

2024-09-08T10:50:07Z

Mmer547: ページの作成:「[https://prepomax.discourse.group/c/news/9 Newsページ]からの転記 == v2.1.7 == * .dat ファイルリーダーの改善 * BC および荷重の作成中に選択された座標系がハイライト表示されるようになりました。 * 履歴（再生成用）が更新され、解析コマンドと後処理コマンドが含まれるようになりました。再生成はモデルコマンドのみ（解析コマンドと後処理コマンドは再生…」

[https://prepomax.discourse.group/c/news/9 Newsページ]からの転記

== v2.1.7 ==

* .dat ファイルリーダーの改善
* BC および荷重の作成中に選択された座標系がハイライト表示されるようになりました。
* 履歴（再生成用）が更新され、解析コマンドと後処理コマンドが含まれるようになりました。再生成はモデルコマンドのみ（解析コマンドと後処理コマンドは再生成されません）またはすべてのコマンドに対して実行できるようになりました。
* コマンドラインパラメータのサポートが改善されました
* PrePoMaxCmd.exe という追加の .exe ファイルが追加されました。これは PrePoMax をコマンドラインアプリケーションとして起動します。
* PrePoMax 実行ファイルは両方ともコマンドラインパラメータで使用できますが、バッチモードで PrePoMax を実行するには PrePoMaxCmd.exe を使用する必要があります。
* バグ修正

== v2.1.6 ==

* 座標系更新のバグ修正

== v2.1.5 ==

* バグ修正

== v2.1.4 ==

* .dat ファイルのバックリングリーダーのサポートを追加しました
* バージョン 2.1.3 開発版からの選択バグ修正

== v2.1.3 ==

* 履歴出力のエクスポートのサポートを追加しました (結果 → 履歴出力 → エクスポート)
* ジオメトリIDによる選択のサポートを追加しました
* ジオメトリ選択に基づく参照ポイント作成のサポートを追加しました
* ジオメトリ選択に基づく座標系作成のサポートを追加しました
* 座標系のバグ修正

== v2.1.2 ==

* 式で定義されたフィールド出力の作成のサポートを追加しました (結果 → フィールド出力 → 作成)
* 式で定義された履歴出力の作成のサポートを追加しました (結果 → 履歴出力 → 作成)
* ユーザーが作成した履歴出力のフィルターのサポートを追加しました。使用可能なフィルターは、最小、最大、合計、平均です。
* 座標系のバグ修正

== v2.1.1 ==

* FE モデルビューでの座標系の作成のサポートを追加しました (長方形、円筒形)
* 結果ビューでの座標系の作成のサポートを追加しました（長方形、円筒形）
* 結果ビューでの参照ポイントの作成のサポートを追加しました
* 境界条件の作成時に座標系を使用するためのサポートを追加しました
* 集中荷重の作成時に座標系を使用するためのサポートを追加しました
* 表面牽引荷重の作成時に座標系を使用するためのサポートを追加しました
* フィールド出力を別の座標系に変換するサポートを追加しました (結果 → フィールド出力 → 作成)
* バグ修正

== v2.1.0 ==

* 質量セクションのサポートを追加: 点質量と分散質量
* シェルメッシュを厚くする機能を追加
* 選択したサーフェスでソリッドメッシュを分割する機能を追加しました
* .stl ジオメトリモデルの面を削除する機能を追加しました
* Gmsh メッシャー使用時のメッシュ最適化のサポートを追加しました
* ピラミッド要素のサポートを追加
* 新しい色の凡例を追加しました
* .pmxファイルの構造を変更し、より大きなファイルの作成を可能にしました。
* ステップコントロールのサポートを追加
* 圧縮のみのサポートにより、非線形ソリューションを有効化できるようになりました。
* Gmsh がバージョン 4.13 に更新されました

* シンプルな履歴ビューアとエディタを追加
* キーワードエディタはパフォーマンスを改善するために作り直されました
* バグ修正

PrePoMax

2024-09-08T10:45:56Z

Mmer547:

このページではオープンソース構造解析ソフト「PrePoMax」についてまとめていきます。

[https://prepomax.fs.um.si/ 公式サイト]

== インストール ==
公式のバイナリーはWindowsのみです。
公式サイトに行って「Downloads」を左クリックしてください。Zipファイルをダウンロードして解凍してください。新しくできるフォルダーは移動しても構いません。そのフォルダーの中にあるPrePoMax.exeというファイルを左ダブルクリックすると起動します。
PrePoMax.exeというファイルのショートカットをデスクトップに作ると便利だと思います。

== リリースノート ==
[[PrePoMaxリリースノート]]

== 公式動画チュートリアル(英語) ==
公式サイトの「Documentation」からも行けますが、ここにURLを記載します。
[https://www.youtube.com/@MatejBorovinsek Matej Borovinšek YouTube Cannnel]
[https://www.youtube.com/@feanalyst4302 FEAnalyst YouTube Channel]

== 応力解析 ==
[https://qiita.com/Jun_Tatsuno/items/f59d916b98e823341882 PrePoMaxを用いた部品を連結したAssyの応力解析]

[https://qiita.com/Sagittarius_Chiron/items/fd806361ceca4864bc79 PrePoMax使用法解説]

== 固有値解析 ==
[https://qiita.com/Jun_Tatsuno/items/f2bb87eaf3f594b52038 PrePoMaxを用いたモーダル解析]

== 日本語ドキュメント（有志） ==
[https://speakerdeck.com/juntatsuno/prepomax-v1-dot-1-1-maniyuaru PrePoMax v1.1.1 マニュアル]

== 関連書籍 ==
[https://www.amazon.co.jp/%E3%80%8CPrePoMax%E3%80%8D%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E5%AE%9F%E8%B7%B5%E6%A7%8B%E9%80%A0%E8%A7%A3%E6%9E%90-%E6%94%B9%E8%A8%82%E7%89%88-OBOOKS-%E6%9F%B4%E7%94%B0-%E8%89%AF%E4%B8%80/dp/4777522156/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=20HSEZ031ITSU&keywords=PrePoMax&qid=1680697869&s=books&sprefix=prepomax%2Cstripbooks%2C184&sr=1-1 <nowiki>「PrePoMax」ではじめる実践構造解析 [改訂版]</nowiki>]

OpenFOAM v2312リリースノート

2023-12-24T08:21:50Z

Mmer547:

OpenCFDは、2023年12月リリースのOpenFOAM® v2312を発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v2306の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージも多数あります。

Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール

openSUSE Linux: Leap 15.5 用パッケージインストール

Redhat Linuxの亜種: epel 9用のパッケージインストール; Fedora 37

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢があります（詳細）：

Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。

クロスコンパイルによるネイティブ実行ファイル

docker インストール

OpenFOAMのapptainerサポートは、事前にアセンブルされたイメージではなく、記述ファイルによって提供されます：

パッケージング/コンテナ参照

Mac OSXユーザーは、ソースからコンパイルするか、Dockerコンテナを使ってコンパイル済みのパッケージを使用するオプションがあります（詳細）。

== Upgrading ==

=== v2312ユーザーアップグレードガイド ===

=== 挙動の変化 ===

==== デフォルトのEnSightフォーマット ====

* 関数オブジェクトとライターが使用するデフォルトの ensight 出力が、シミュレーション controlDict で指定される \c writeFormat に依存するのではなく、より一貫して ˶c binary format を使用するようになりました。この変更により、foamToEnsight などのユーティリティや、他のファンクション・オブジェクトやライターとの動作がより一貫したものになります。

==== Function object: <code>Lambda2</code> ====
Lambda2関数オブジェクトの出力が、支配方程式の変更、特に符号の反転によって修正されました。その結果、Lambda2のv2312以前のバージョンで観測された負のフィールド値は、v2312リリースでは正のフィールド値になりました（逆も同様）。

=== 名前変更 ===

==== Function object: <code>WeberNumberReacting</code> ====
ラグランジュ関数オブジェクトクラスWeberNumberReactingは、新しいラグランジュ雲関数オブジェクトKinematicWeberNumberとの整合性を確保するため、ReactingWeberNumberと改名された。

=== v2312開発者アップグレードガイド ===

=== 非推奨と削除 ===

==== 削除された項目 ====

* faMesh::operator()が削除され、代わりにmesh()またはthisDb()が使われるようになりました。
* typeGlobal() グローバル関数が is_globalIOobject<Type> traits 構造体に置き換えられました。IOobject::typeHeaderOk との一貫性を保つために、補助的な typeFilePath() グローバル関数が IOobject::typeFilePath のメンバとしてのグローバル関数に取って代わられました。

=== 定義の変更 ===

* ReadFieldsは、格納されたオブジェクトを処理するためのLIFOを実装するためにDynamicListを使用するようになりました。古いLIFOStackインターフェースは、より多くの割り当てとオーバーヘッドを必要とするため、非推奨とマークされています。
* いくつかの IOobjectList::sorted() const-access メソッドを非推奨とし、新しい csorted() メソッドを採用した。これにより、HashTableとのメソッド名の一貫性が保たれ、戻り値の型が明確になります。
* 内部辞書の区切り文字が'.'から'/'に変更され、（fileNameのような）内部処理が簡素化され、辞書名を明確なアドレッシングで使用できるようになった。この変更による副作用は、生の辞書名がコード内で直接解析された場合を除き、特に期待されません。

=== 相続の変化 ===
fvMeshで使われていたデータクラスは、polyMeshレベルのメンバーデータに置き換えられました。開発者にとっては、これは以下の（壊れやすく醜い）コードが確実に壊れることを意味する！
<code>obr.lookupObject<fvMesh>("data") // This was never a good idea</code>

=== 移設されたメソッド ===
ListOps::identityをFoam::identityに昇格させる。int32とint64の両方のバージョンを処理します。

=== コンテナの改良／変更 ===
多くのリリースがそうであるように、基礎となるOpenFOAMコンテナは、様々な方法でアップグレードされ、調整されている。いくつかの焦点は、より多くの場所でC++アルゴリズムを利用することによって、内部のコピー、充填、データ移動を近代化することです。一般的なコード削減とは別に、アルゴリズムへの移行は、将来的に異なる実行モデル（例えば、std::execution::parallel_unsequenced_policy）を提供するのに役立ちます。

==== ハッシュテーブル構造体 ====
HashTableとHashSetのデフォルトのコンストラクタは、本当にゼロ・サイズのコンストラクタに対応するようになり（つまり、割り当てを必要としない）、noexceptでもある。これは、ハッシュセットのリストなどを管理するときに特に便利で役立ちます。移動コンストラクタも同様にnoexceptになった。

* 未使用の HashTable(Istream&, label) コンストラクタが削除されました。

==== HashTableのサイズ改良 ====

* サイズ変更時に、未入力のHashTableをより早く削除する：テーブルが既にクリアされている（つまり、エントリがない）場合、新しいサイズのテーブルを再割り当てする前に、古い内部テーブルを即座に削除することができます。
* メソッド： std::unordered_mapに準じた命名と一般的な動作。resize()メソッドと似たような動作をしますが、容量ではなく要素数が渡されます。さらに、reserve()は、DynamicListやstd::vector、std::stringなどに似た振る舞いをするテーブルの容量を増やすだけです。
<syntaxhighlight>
// old:
labelHashSet set;
set.resize(2*nElems);

// now:
labelHashSet set;
set.reserve(nElems);
</syntaxhighlight>

==== リスト作成／割り当て ====
SLList（単一リンクリスト）からListまたはFixedListの構築または代入は削除されました。moveコンストラクトや代入はまだ残されていますが、次のバージョンまでにはその有用性が失われることが予想されます。

==== リストの読み書き ====
入力サイズが既知でないリストを読み込む場合、これらのブラケット・リストは、単一リンク・リストを使用する代わりに、チャンク単位で読み込まれるようになった。積分型やベクトル空間型（スカラー、ベクトルなど）では、各要素に対する中間アロケーションを避けることができる。

DynamicList::readList()メソッドが完全に実装され、List::readList()にリダイレクトされるようになりました。

=== IOストリームの変化 ===
Ostreamの書き込みメソッド write(const string&) が write(const std::string&) に変更され、中間コピーなしでstd::stringを書き込めるようになった。これは、中間コピーなしで std::string を書き込むことを可能にする。しかし、これは Ostream から派生したクラスに調整が必要になることを意味する。

Ostreamクラスはまた、将来のスパンとstring_viewのサポートに役立つ新しいwriteQuoted(const char* str, std::streamsize len, bool)メソッドを受け取った。

==== メモリーストリームの更新と強化 ====
カバレッジを拡張して、すべての標準ストリームのバリアントを含むようにし、単純にOpenFOAM IOstreamタイプ用にリラップします。これにより、継承パターンが単純化され、icharstream/ocharstreamを他のラッパーでistringstream/ostringstreamのドロップイン置き換えとして再利用できるようになります。

* Classes
** icharstream / ICharStream [old: none / IListStream]
** ocharstream / OCharStream [old: none / OListStream]
** ispanstream / ISpanStream [old: uiliststream / UIListStream]
** ospanstream / OSpanStream [old: none / UOListStream]

ストリーム・バッファ・コンテンツのstd::string_view（c++17）またはspan view（古いc++）をサポート。これにより、フォーマットと再解析が簡単になります。

=== 並列（MPI）処理の変更 ===

==== 削除された機能 ====
実験的なフルNBX PstreamBuffersアルゴリズム（OpenFOAM-v2306で追加）は、ハイブリッドNBX/PEXアプローチと比較して利点が見られなかったため、削除されました。

同様に、実験的な "ダブルノンブロッキング "NBXバージョンも削除された。このアイデアは、非常に大きなデータ転送のための受信のブロッキングを避けることであったが、それは通常、PstreamBuffersが可能にするようなNBX/PEXのハイブリッドアプローチでよりよく達成される。

==== 新機能 ====

===== broadcastList =====
新しいPstream::broadcastList()メソッドは、2段階のプロセスとして連続したコンテンツをブロードキャストする：

# サイズをブロードキャストし、レシーバーリスト用にリサイズする。
# 連続した内容を放送する（空でない場合）

これにより、シリアライズ／デシリアライズのメモリ・オーバーヘッドを回避できるが、ブロードキャスト・コールが追加される。サイズの余分なブロードキャストのトレードオフは、連続した大きなメッシュデータのメモリピークを避けることよりも重要ではないでしょう。

===== mpiAllGather =====
mpiAllGather 関数が拡張され、char 型に限定されていたものが整数型と浮動小数点型も含むようになった。

===== allToAllConsensus =====
Mapを受け取るallToAllConsensus関数は、Mapも返すようになり、使い方が単純化され、送信/再送信パラメータの曖昧さが回避された。このバージョンでは、Mapにゼロ値のデータが存在する場合、そのデータも送信されるようになった。

===== PstreamBuffers =====
registered "センドをサポートし、減少した通信を適切に処理するだけでなく、投機的センドも処理できるようにした。これは、アルゴリズム内でプロセッサ-プロセッサ間の通信が発生する可能性があるが、センドがすべて必要になるかどうか事前にはわからない場合に発生する。この場合、センドは通常通り行われるが、登録されるのは「実際の」センドのみである。すべてのセンドが終了した後、実際にどの情報を（もしあれば）送信する必要があるかを判断することができる。

例えば、<syntaxhighlight>
PstreamBuffers pBufs(UPstream::commsTypes::nonBlocking);

pBufs.initRegisterSend();

for (const polyPatch& pp : patches)
{
const auto* ppp = isA<processorPolyPatch>(pp);
if (ppp)
{
const label nbrProci = ppp->neighbProcNo();

// Gather some patch information...
UOPstream toNbr(nbrProci, pBufs);
toNbr << patchInfo;

// The send is needed if patchInfo is non-empty
pBufs.registerSend(nbrProci, !patchInfo.empty());
}
}

pBufs.finishedSends();

</syntaxhighlight>
新しい PstreamBuffers::finishedSendsNBX() メソッドが追加され、デフォルトの設定パラメータに関係なく、all-to-all ではなくバッファサイズの NBX (ノンブロッキング転送) を指定できるようになった。

=== MPI ネイティブの bitOrOp を拡張する ===

* bitOrOpは複数の値も扱えるようになった。これは例えば、グローバルな状態を追跡するために使用できる：
<syntaxhighlight>
// Encode as 0:empty, 1:uniform, 2:nonuniform, 3:mixed
PackedList<2> uniformity(fields.size());

forAll(fields, i)
{
uniformity.set(i, fields[i].whichUniformity());
}

reduce
(
uniformity.data(),
uniformity.size_data(),
bitOrOp<unsigned>()
);

</syntaxhighlight>

=== MPIリクエスト処理の改善 ===

* UPstream::waitSomeRequests()のスライス/レンジのサポートにより、受信のポーリングが簡素化され、送信から分離できるようになった。
* UPstream::removeRequests(pos、len) を使用して、未処理のリクエストをキャンセル／解放し、未処理のリクエストの内部リストからセグメントを削除する。
* mapDistribute でのリクエスト処理の改善
** 受信してから送信
** 自己送信の受信バッファへの直接コピー
** 送信/再送バッファのPtrListを使った不要な再割り当てを無効にする。

=== グローバルインデックス ===
whichProcID() に代わる失敗しないメソッドとして、新しい findProc() メソッドを含む様々な改良。

C++の最低規格は、2024年にC++11からC++17に引き上げられる予定である。

== Pre-processing ==

=== snappyHexMesh：自動リークパスクロージャーから面を書き込む ===
snappyHexMeshにはメッシュ内の任意の位置とメッシュ外の位置の間のパスとして定義されたサーフェスのリークを自動的に閉じるオプションがあります。このリリースではリークを閉じるために使用された面はpostProcessingディレクトリのファイルに書き込まれます。

下図は、ギャップのある球体（灰色）、スナップされたメッシュライン（青）、リークを閉じる面（赤）からなるテストケースを示しています：

ファイル書き込みフォーマットはsnappyHexMeshDictの新しいエントリーで選択できます：<syntaxhighlight>
//// Format for writing lines. E.g. leak path. Default is vtk format.
//setFormat ensight;

//// Format to use for surfaces. E.g. leak-closure faces. Default is vtk format.
//surfaceFormat vtk;
</syntaxhighlight>Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_gapClosure

Source code

* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C

=== snappyHexMesh：新しい複数の内側ポイント ===
snappyHexMeshのセルゾーンはinsidePointを指定することで作成できます：<syntaxhighlight>
refinementSurfaces
{
..
cellZoneInside insidePoint; // outside/insidePoint
insidePoint (1 1 1); // if (cellZoneInside == insidePoint)
}
</syntaxhighlight>1つのinsidePointではなく、複数のinsidePointが用意された：<syntaxhighlight>
cellZoneInside insidePoints; // outside/insidePoint
insidePoints ((1 1 1)); // if (cellZoneInside == insidePoint)
</syntaxhighlight>下の図では、ジオメトリは2つのボックス（ワイヤーフレーム）で構成され、上のボックスは2つの切り離されたメッシュ領域をカバーしている。赤で示されたセルゾーンは、3つの別々のメッシュ領域を使用して作成されています。checkMeshユーティリティは、切断されたリージョンを表示するために使うことができます。

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/insidePoints

Source code

* $FOAM_SRC/mesh/snappyHexMesh/refinementSurfaces/surfaceZonesInfo.H

=== snappyHexMesh：並列メッシュの負荷分散 ===
snappyHexMeshは並列実行時に自動的にメッシュのバランスをとることができます。それは以下のどちらかになります

* 変更が小さすぎる場合はバランスを取らない - maxLoadUnbalanceまたはmaxCellUnbalance設定を参照。
* maxLocalCells設定を参照してください。

このリリースでは、各ステップでメッシュのアンバランスがプリントされます：<syntaxhighlight>
Layer mesh : cells:353749 faces:1108448 points:406303 unbalance:0.00110248

</syntaxhighlight>精製前のバランスは、セルの重みを与えることで実装されることに注意。各精製されるセルは8ずつカウントされる。しかし、これは単純な分解法、例えば階層的な分解法にのみ有効である。scotch と KaHip メソッドでは、カット数を含む重みを使ってアンバランスを最小化する。

Tutorials

* any parallel snappyHexMesh case

Source code

* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C
* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

Related issues

* Issue 3034

=== snappyHexMesh：レイヤーごとの追加 ===
OpenFOAM v2206リリースでは、snappyHexMeshが拡張され、nOuterIterエントリーを使用して複数パスでレイヤーを追加できるようになりました。ここでは、$FOAM_TUTORIALS/incompressible/pisoFoam/LES/motorBike/motorBikeチュートリアルを出発点として、どのように改良されたレイヤーの追加を実行できるかをデモしたいと思います：<syntaxhighlight>
relativeSizes false; // true

// Per final patch (so not geometry!) the layer information
layers
{
"(lowerWall|motorBike).*"
{
nSurfaceLayers 16;
}
}

// Expansion factor for layer mesh
expansionRatio 1.2;
</syntaxhighlight>重要な設定は、外側の反復回数とメッシュ・モーション・ソルバーである：<syntaxhighlight>
// Overall max number of layer addition iterations
nLayerIter 25;

// Add layers in multiple passes - gives layers a chance to rotate
nOuterIter 4;

meshShrinker displacementMotionSolver;
solver displacementLaplacian;
displacementLaplacianCoeffs
{
diffusivity quadratic inverseDistance (lowerWall upperWall "motorBike*")
}
</syntaxhighlight>メッシュの品質基準を緩めることで、（全体的なメッシュ品質は維持したまま）この複雑な形状でもレイヤーカバレッジを劇的に向上させることができる。

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/addLayersToFaceZone

Source code

* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

=== Nastranサーフェスリーダーの改良 ===
NASTRANパーサーが更新され、PSHELL名の新しいANSA規約に対応しました。これにより、snappyHexMeshなど、より多くの場所でNASTRANファイルを直接使用することができるようになりました。

Source code

* $FOAM_SRC/surfMesh/surfaceFormats/nas/NASsurfaceFormat.C

Issue

* Issue 3009

=== checkMeshユーティリティの改良 ===
checkMesh ユーティリティに writeChecks オプションが追加されました：<syntaxhighlight>
checkMesh -writeChecks <format>

</syntaxhighlight>これにより、メッシュ・チェックのフォーマットを含むファイルが生成される：

* dictionary : OpenFOAM dictionary;
* json : JSON format.

例えば、コマンドを使う：<syntaxhighlight>
checkMesh -allGeometry -allTopology -writeChecks JSON

</syntaxhighlight>motorBikeチュートリアルでは、caseディレクトリにcheckMesh.jsonファイルが生成される：<syntaxhighlight>
{
"maxNonOrth" : 64.9999,
"aveNonOrth" : 9.92427,
"maxSkew" : 9.25719,
"nWarnSkew" : 12,
"minDeterminant" : 0,
"aveDeterminant" : 1.55371,
"thresholdDeterminant" : 0.001,
"nErrorDeterminant" : 1274,
"minFaceWeight" : 0.0216708,
"aveFaceWeight" : 0.465687,
"thresholdFaceWeight" : 0.05,
"nErrorFaceWeight" : 1143,
"minFaceVolumeRatio" : 0.0101126,
"aveFaceVolumeRatio" : 0.846049
}
</syntaxhighlight>Source code

* $FOAM_UTILITIES/mesh/manipulation/checkMesh/checkMesh.C

=== subsetMeshユーティリティの改良 ===
subsetMesh ユーティリティが更新され、通常の -patches 選択を変更する -exclude-patches オプションを受け付けるようになりました。

この変更により、最も近い露出パッチの指定が簡単になりました。

== Numerics ==

=== コミュニティへの貢献随伴形状最適化の改善 ===
形状最適化のための感度微分を計算するためのE-SIとFI定式化間の整合性が改善されました。naca0012/laminar/moment/primalAdjointチュートリアルから取得した、変更前後のコード動作の例を以下に示します：

一貫した点／面の感度マップ

v2306とv2312で計算されたドラッグ感度マップを比較すると、a)新しいポイント-フェイス補間は、生の、つまり平滑化されていない感度でも、より滑らかな結果を生成する。

さらなる改善点は以下の通り：

* 不必要に新しいアドジョイントフィールドを割り当てることなく幾何学的制約を定義するための新しいアドジョイントソルバ（null）と目的関数（geometric）タイプ

* 不等式制約のある最適化問題に取り組むための3つの新しい更新法（ISQP, nullSpace, MMA）
* 設計変数に境界を導入。ボリューメトリックBスプラインの場合、最適化を通してメッシュの品質をより良く保つことができます。
* 最適化ループの収束基準の導入。

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/laminar/multipleConstraints

Guide

* The updated user guide for v2312 can be found here

Source code

* Merge request MR!649
* Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
* Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

* The software was developed by PCOpt/NTUA and FOSS GP
* Integration in collaboration with OpenCFD

=== コミュニティへの貢献トポロジーに基づく新しいアジョイント最適化 ===
OpenFOAM v2312では、空隙率ベースまたはレベルセットアプローチによる新しいトポロジー最適化機能が追加されました。どちらも、設計されたジオメトリをSTLとしてエクスポートする機能を備えており、製造やボディフィットグリッドによる再評価に利用できます。

空隙率ベースのアプローチは、計算領域の非生産的な部分を固めることでブロックする設計変数の場（人工空隙率α）に依存する。得られた解の平滑性を高めるために、正則化方程式を解いて中間場α̃を計算し、次にシャープニング/プロジェクションステップを経てほぼ二値の場βを計算します。後者は、固化した領域（すなわちβ≈1の領域）で流れ解をゼロにするソース項を流れ方程式に導入するために使用されます。上記のプロセスの手順を以下に示す。

次の表は、同じケースの3つの異なるバリエーション、すなわち、Jpt＜Jpttarget制約（右）の下で、総圧力損失（Jpt）の最小化（左）、下部出口と右出口間の体積流量の均等配分制約（Jm）を伴うJptの最小化（中央）、および流れの均一性（Jun）の最大化（右）に対するトポロジー最適化の結果を示している。

ケースは、adjointOptimisationFoam/topologyOptimisation/monoFluidAero/turbulent/1_Inlet_2_Outlet/porosityBased/BPにあります。

次の表は、同様の目的関数と制約関数を持つ3次元多様体のトポロジー最適化の結果を示しています。最初の行は、最適化サイクル中の計算領域の流体部分と固体部分の境界の進行を示し、最後の行は、最適化された3つの形状のSTLファイルを示しています。後者の生成プロセスは自動化されており、各最適化サイクルの終了時に実行されます。これらのSTLファイルは、適切な境界条件によるボディフィットシミュレーションや、その後の形状最適化、さらには製造に使用することができます。

ケースはtopologyOptimisation/monoFluidAero/laminar/3DBoxにあります。

==== 下位互換性 ====
optimisationDict.optimisationの項目が少し変わりました。この変更は、例えば、$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/motorBikeのoptimisationDictを以前のものと比較することで確認できます。

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation

Guide

* The updated user guide for v2312 can be found here

Source code

* Merge request MR!649
* Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
* Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

* The software was developed by PCOpt/NTUA and FOSS GP
* Integration in collaboration with OpenCFD

== Solvers and physical models ==

=== fvOptionsの改良：ポイントの移動 ===
有限体積オプション（fvOptions）フレームワークが改良されました：

* 入力辞書の更新により、セル選択を実行時に更新できるようになりました。
* 空間内を移動する点をモデル化する新しい方法。

最小限の使用例は以下の通り：<syntaxhighlight>
fvOption1
{
// Optional entries
updateSelection true;

...
}

fvOption2
{
// Mandatory entries
selectionMode movingPoints;

movingPoints
{
point1 table
(
// time position
( 0 (0 0 0.75))
( 1 (0 0 0.65))
( 2 (0 0 0.55))
( 3 (0 0 0.45))
( 4 (0 0 0.35))
( 5 (0 0 0.25))
);

point2 (-0.25 -0.25 0.5);
}

...
}
</syntaxhighlight>Source code

* $FOAM_SRC/fvOptions/cellSetOption/cellSetOption.H

Merge request

* Merge request 630

=== 新しい fvOption: マップされたフィールド制約 ===
MapFieldConstraintは、外部メッシュからのソース・フィールドを使用して、<Type>型の指定フィールドに値の制約を課します。ここで、<Type>には{scalar, vector, sphericalTensor, symmTensor, tensor}を指定できます。オプションとして、ソースフィールドは時間経過とともに平行移動または回転させることができます。

考えられる用途は、例えば、移動する電気源の影響をモデル化することである。最小限の使用例を以下に示す：<syntaxhighlight>
MapFieldConstraint1
{
// Mandatory entries
type MapFieldConstraint;
field <word>;
srcMesh <fileName>;
mapMethod <word>;

// Optional entries
consistent <bool>;
patchMapMethod <word>;
transform
{
// Optional entries
position <Function1<vector>>;
origin <vector>;

direction <Function1<vector>>;
normal <vector>;
}

// Conditional entries

// when consistent=false
patchMap <HashTable<word>>; // (<patchSrc> <patchTgt>);
cuttingPatches <wordList>; // (<patchTgt1> ... <patchTgtN>);

// Inherited entries

...
}
</syntaxhighlight>Source code

* $FOAM_SRC/fvOptions/constraints/general/mapFieldConstraint/MapFieldConstraint.H

Merge request

* Merge request 630

=== コミュニティへの貢献：新しい乱流技術委員会サブモジュール ===
OpenFOAMガバナンス内のTurbulence Technical Committeeのネストされたサブモジュールを含む新しいコミュニティサブモジュールが開始されました。このサブモジュールは、公開されている Turbulence Technical Committee のリポジトリでホストされています。

コミュニティ・サブモジュールは、乱流モデリングに関連する学術的・産業的な貢献のホストとして機能し、知識交換の場を作り、この分野とOpenFOAMの両方を発展させるコラボレーションを促進します。

BitbucketやGitHubのようなGitベースのソースコード・リポジトリ・ホスティング・サービスでホストし、このサブモジュールを介してOpenFOAMソフトウェアにリンクすることができます。

このリリースでは、サブモジュールにlibWallModelledLESライブラリーが組み込まれ、壁面モデルによるラージ・エディ・シミュレーション（WMLES）の領域でOpenFOAMの機能が拡張されました。この乱流モデリング手法は、乱流境界層の内部領域の解像度を回避することで、費用対効果の高いLESを可能にします。

Source code

* $WM_PROJECT_DIR/modules/turbulence-community

Attribution

* OpenCFD would like to acknowledge and thank Turbulence Technical Committee members for their contributions and help.

=== 改善されたラグランジュ・ブラウン運動 ===
このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。しかし、特に指定がない限り、（互換性のために）デフォルトの球形分布が引き続き使用されます。

このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。

しかし、特に指定がない限り、適度に小さな時間ステップでは不正確であるにもかかわらず、（互換性のために）デフォルトの球面処理が引き続き使用されます。

三次分布は、球面処理が明示的に無効化されている場合に使用される。例えば<syntaxhighlight>
subModels
{
particleForces
{
sphereDrag;
BrownianMotion
{
lambda 2e-10;
turbulence false;
spherical false;
}
}
...
}
</syntaxhighlight>立方体分布と球形分布の違いは次の図に見られる。

変更の報告、検証、テストはGuanyang Xueの好意によるものである。

Source code

* $FOAM_SRC/lagrangian/turbulence/submodels/Thermodynamic/ParticleForces/BrownianMotion/BrownianMotionForce.H

Issue

* Issue 2922

Merge request 634

== Post-processing ==

=== 新しいAbaqusサンプルセット ===
新しい abaqusMesh セットは、Abaqus メッシュポイント形式を使用してファイルからサンプル位置を導出します。使用例：<syntaxhighlight>
sets
{
cone25 // user-specified set name
{
type abaqusMesh;
file "abaqusMesh.inp";

// Optional entries

// Scale, e.g. mm to m
scale 0.001;

// Search distance when the sample point is not located in a cell
maxDist 0.25;

...
}
}
</syntaxhighlight>Tutorials

* TBA

Source code

* $FOAM_SRC/sampling/sampledSet/abaqus

=== 新しいAbaqusセットライター ===
新しいAbaqusセットライターはOpenFOAMセットデータをAbaqusフォーマットに変換します。使用例<syntaxhighlight>
T
{
type sets;
setFormat abaqus;
fields (T);
sets
{
...
}
}
</syntaxhighlight>オプションの書式オプションは、formatOptions辞書内のabaqusサブ辞書で提供されます：<syntaxhighlight>
formatOptions
{
abaqus
{
format ascii;

// Optional entries

// Custom header: $ entries are substituions
header
(
"** OpenFOAM abaqus output"
"** Project $FOAM_CASE"
"** File $FILE_NAME"
"** $FIELD_NAME Time t=$TIME"
);

// Write geometry in addition to field data
writeGeometry yes;

// Null value when sample value is not found
// Default is scalar::min
nullValue 0;

// Insert additional time sub-directory in the output path
// - yes : postProcessing/<fo-name>/<time>/<file>
// - no : postProcessing/<fo-name>/<file>
useTimeDir no;

// Available when 'useTimeDir' is 'no' to disambiguate file names

// Time base for output file names:
// - 'time' : <base>.inp_<field>.<time>
// - 'iteration' : <base>.inp_<field>.<iteration>
timeBase iteration;

// Optional start counters when using timeBase iteration
writeIndex
(
T 1
);

...
}
}
</syntaxhighlight>Tutorials

* TBA

Source code

* $FOAM_SRC/meshTools/coordSet/writers/abaqus/abaqusCoordSetWriter.C

=== パッチ・シード・セットの改善 ===
patchSeed sampled setがパッチ全体で一様にサンプルシードを計算するようになりました。以前の実装では、顔のインデックスをパッチ全体で一様にサンプリングしていましたが、その副作用として、より小さな顔に偏りがありました。<syntaxhighlight>
streamline5
{
type streamLine;
libs (fieldFunctionObjects);
U U;
fields (U p);
setFormat vtk;
direction forward;
lifeTime 20000;
cloud particleTracks;
seedSampleSet
{
type patchSeed;
axis xyz;
patches ("inlet1");
maxPoints 40;
}
interpolationScheme cellPoint;
trackLength 0.001;
}
</syntaxhighlight>Tutorial

* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike/system/wallBoundedStreamLines

Source code

* $FOAM_SRC/sampling/sampledSet/patchSeed

Merge request

* Merge request 647

=== 新しいケース情報機能オブジェクト ===
新しい caseInfo 関数オブジェクトは、実行時または後処理の一部として、ソルバーとケースの情報を生成します。収集されるデータには以下が含まれます：

* メタデータ：ケース名、パス、タイムディレクトリ数など。
* 辞書エントリ : 任意の入力辞書からすべて/選択したものを抽出
** fvSolutionからUリニアソルバーを取得するには、'solvers/U/solver'などのスコープを使用する。
** はワイルドカードをサポートしている。例えば、fvSolution U ソルバー・キーワードが"(U|k|epsilon) "であった場合。
** include'または'exclude'リストを使用して、含める/除外するエントリ名の選択を制限する。
* メッシュ統計：点、面、セルの数、境界、ゾーン名など。
* 関数オブジェクトの結果：関数オブジェクトの結果のキャッシュ値など

使用例：<syntaxhighlight>
caseInfo1
{
type caseInfo;
libs (utilityFunctionObjects);

writeFormat json; // josn | dictionary

// List of dictionaries - retrieve using 'path' or registered 'name'
dictionaries
{
fvSolution
{
name "fvSolution";

// include all entries by default
}
controlDict
{
path "system/controlDict";
include
(
"application"
"deltaT"
"startTime"
"endTime"
);
}
}

// Extract function object results
functionObjects (pressureDifference sample1);
}
</syntaxhighlight>出力例<syntaxhighlight>
{
"meta" : {
"case" : "heatExchanger",
"path" : "chtMultiRegionSimpleFoam/heatExchanger",
"regions" : ["air", "porous"],
"nTimes" : 7,
"nProc" : 1
},
"regions" : {
"air" : {
"mesh" : {
"nGeometricD" : 3,
"nSolutionD" : 3,
"nPoints" : 252991,
"nFaces" : 739260,
"nCells" : 243000,
"nPatches" : 4,
"pointZones" : [],
"faceZones" : ["rotorBlades", "baffleFaces"],
"cellZones" : ["cylinder", "innerCylinder", "rotor"],
"boundsMin" : [0, 0, 0],
"boundsMax" : [5.000000e-01, 5.000000e-01, 5.000000e-01],
"clouds" : []
},
"boundary" : {
"types" : {
"walls" : "wall",
"inlet" : "patch",
"outlet" : "patch",
"blades" : "wall"
},
"fields" : {
"alphat" : {
"walls" : "compressible::alphatWallFunction",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "compressible::alphatWallFunction"
},
"nut" : {
"walls" : "nutkWallFunction",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "nutkWallFunction"
},
"p" : {
"walls" : "calculated",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "calculated"
...
</syntaxhighlight>Source code

* $FOAM_SRC/functionObjects/utilities/caseInfo

== DMDによる新しい低次モデリング磁場再構成 ==
動的モード分解（DMD）機能は、OpenFOAM v2006で導入され、その後OpenFOAM v2106で拡張されました。このリリースにより、OpenFOAMは、DMDの主な利点の1つである、任意の中間時点や将来の時点におけるCFD計算を必要とせずに、与えられたモードとそれに関連するダイナミクスに基づいて場を生成する機能を習得しました。

この機能により、ユーザーはシミュレーション全体をいくつかのモードとモードダイナミクスに凝縮し、CFD解析を追加することなく、任意の時間における場の生成や将来の状態の予測を行うことができます。

もう一つの潜在的な利点は、ユーザーがシミュレーションを短縮し、大規模なシミュレーションを行うことなく流れ場の将来の状態を予測できることである。これは、より短時間のシミュレーションで得られたモードとモードダイナミクスを使用することで実現できます。

結果の質は、基礎となる縮小モデルの能力と入力データの質に依存することに留意すべきである。再構成結果を改善するためには、流れからモードが正しく抽出されていることを確認する必要がある。

system/ROMfieldsDictを使った最小の例は以下の通り：<syntaxhighlight>
// Mandatory entries
ROMmodel <word>;
field <word>;
object <word>;
deltaT <scalar>;
time <scalar>;
modes <labelList>;
amplitudes <complexList>;
eigenvalues <complexList>;

// Optional entries
startTime <scalar>;
dimensions <dimensionSet>;

// Inherited entries
...
</syntaxhighlight>下の図は、2次元円柱チュートリアルから得られた速度場と、シミュレーションを実行せずにDMDモードとダイナミクスを使用して再構成したものです：

Source code

* $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/createROMfields.C
* $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/ROMmodels/DMD/DMD.H

Tutorial

* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D

References

* Kiewat, M. (2019). Streaming modal decomposition approaches for vehicle aerodynamics. PhD thesis. Munich: Technical University of Munich. URL:mediatum.ub.tum.de/doc/1482652/1482652.pdf

Attribution

* OpenCFD would like to acknowledge and thank Marco Kiewat for his contributions, elaborate suggestions and help, and critical recommendations.

Merge request

* Merge request 639

=== ノイズ・ユーティリティの向上 ===
ノイズユーティリティは、時間情報からのデフォルトの自動計算だけでなく、ユーザー定義のサンプリング周波数（キーワード：sampleFreq）もサポートするようになりました。読みやすさを向上させるため、周波数の上限と下限をminFreqとmaxFreqで指定できるようになりました（以前のキーワードも引き続きサポートされています）。<syntaxhighlight>
// Lower frequency limit, default 25 Hz, former name 'fl'
minFreq 25;

// Upper frequency limit, default 10 kHz, former name 'fu'
maxFreq 10000;

// OPTIONAL - Sample frequency
sampleFreq 100;
</syntaxhighlight>サンプリングされた時間から周波数を計算する際に時間が不均一であると評価された場合、deltaT が非常に小さい場合、不均一性は多くの場合偽のエラーであるため、ユーティリティはエラーではなく警告を発するようになりました。

Source code

* $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
* $FOAM_SRC/randomProcesses/noise/noiseModels/noiseModel/noiseModel.H

Tutorial

* $FOAM_TUTORIALS//incompressible/pimpleFoam/LES/vortexShed

Issue

* Issue 2999

=== エンサイトの出力向上 ===
EnSightライターの時間値は、デフォルトの固定フォーマットと精度を使用する代わりに、ユーザーが指定できるようになりました。例えば<syntaxhighlight>
formatOptions
{
ensight
{
timeFormat general; // Format for time directory names (general | fixed | scientific); default scientific
timePrecision 12; // Default = 5
}
}
</syntaxhighlight>これらの新しいフォーマットオプションは、例えばノイズユーティリティの圧力サンプリングと組み合わせて、小さなタイムステップを使用する場合に特に便利です。

Source code

* $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
* $FOAM_SRC/functionObjects/utilities/ensightWrite/ensightWrite.H

Issue

* Merge request 634

=== 新しいラグランジュ関数オブジェクトウェーバー数 ===
表面張力と比較した粒子の慣性の相対的な重要性を監視するために、ラグランジュ関数オブジェクトWeberNumberが運動学小包に導入されています。

最小限の使用例は以下の通り：<syntaxhighlight>
cloudFunctions
{
KinematicWeberNumber1
{
// Mandatory entries
type WeberNumber;
sigma <scalar>;
}

...
</syntaxhighlight>Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/KinematicWeberNumber/KinematicWeberNumber.H

Tutorial

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk

Merge request

* Merge request 648

=== 空のサーフェス（surfaceFieldValue）の取り扱いが改善されました。 ===
ワークフローによっては、サンプリングされたサーフェスが、シミュレーション中に現れたり消えたりするフェイスゾーンなどの量に依存する場合があります。そのため、空のサーフェスでサーフェスフィールドの値を評価することは、通常、セットアップに重大なエラーがあることを示しますが、このようなことが予想される場合もあります。追加キーワードempty-surfaceにより、空のサーフェスに遭遇したときの動作を指定することができます。

最小限の例：<syntaxhighlight>
surfaceFieldValueFaceZone1
{
type surfaceFieldValue;
libs (fieldFunctionObjects);
...
regionType faceZone;

empty-surface warn; // default | warn | ignore | strict
}
</syntaxhighlight>Source code

* $FOAM_SRC/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.H

Issue

* Issue 2966

== Parallel ==

=== 結合パッチフィールド値の一貫性 ===
結合された制約境界条件、例: プロセッサーとサイクリックは、その内部フィールド値と一致している必要があります。たとえば、プロセッサパッチでは、値フィールドに隣接するプロセッサセルの値が含まれます。つまり、反対側のセルの値がキャッシュされます。他の結合されたパッチフィールドは、ローカルおよび隣接セル値の補間値を値として持つ場合があります。経験則として、セル値を変更するコードはすべて、たとえば、勾配計算では、値の更新を実行するために境界条件を修正する呼び出しを行う必要があります (プロセッサ境界フィールドでのハロースワップに相当します)。ただし、「ローカル」操作の場合、たとえば乗算では、境界条件に値のみがあり、セル値に依存しない場合、これがスキップされることがあります。ほとんどの「通常の」境界条件はこのカテゴリに分類されます。

結合境界条件の場合、プロセッサのパッチフィールドにも適用されますが、たとえば、パッチフィールドには適用されません。環状、環状AMI のバリアント。これにより、中間計算の値が一貫性制約に従わなくなります。

このリリースでは、制約パッチの値がいつでも最新であるように、ローカル操作の後の評価を強制しています。この選択はまだ調査中であり、将来更新される可能性があることに注意してください。

=== patchField の整合性チェックの結合 ===
ビジュアルコードのチェックで、meshWaveメソッドとmeshWaveAddressingメソッドによって返される壁面距離フィールドが平行一貫していないことが確認されました。このようなエラーを発見しやすくするために、オプションで整合性チェックが追加されました：<syntaxhighlight>
DebugSwitches
{
volScalarField::Boundary 1;
volVectorField::Boundary 1;
volSphericalTensorField::Boundary 1;
volSymmTensorField::Boundary 1;
volTensorField::Boundary 1;

areaScalarField::Boundary 1;
areaVectorField::Boundary 1;
areaSphericalTensorField::Boundary 1;
areaSymmTensorField::Boundary 1;
areaTensorField::Boundary 1;
}
</syntaxhighlight>1 を指定するとチェックが有効になり、チェックに失敗すると FatalError が発生する。特に FOAM_ABORT と組み合わせることで、スタックトレースを生成することができます：<syntaxhighlight>
FOAM_ABORT=true mpirun -np 2 simpleFoam -parallel

</syntaxhighlight>デバッグ・スイッチはビットマップとして解釈される：
{| class="wikitable"
!bit
!value(2^bit)
!effect
|-
|0
|1
|ローカル操作ごとにチェックを加える
|-
|1
|2
|プリントの入力と終了をチェックする
|-
|2
|4
|fatalErrorの代わりにwarning
|}
比較の許容誤差はデフォルトで0に設定されている。プロセッサのハロースワップでは、まったく同じ操作がまったく同じ順序で実行されるため、許容誤差の問題はありません。しかし、サイクリックやサイクリックAMIなどの「補間」結合境界条件では、ローカル演算（定数による乗算など）が補間後に実行されるため、若干異なる切り捨て誤差が発生します。この場合、許容誤差をオーバーライドすることができます：<syntaxhighlight>
OptimisationSwitches
{
volScalarField::Boundary::tolerance 1e-10;
// .. and similar for all the other field types ..
}
</syntaxhighlight>

==== 下位互換性 ====
新しい整合性操作は、周期的または周期的AMI境界条件、または結合境界条件を使用する非自明な乱流モデルを使用するケースの動作をわずかに変更します。

オプションとして、etc/controlDictのlocalConsistency設定をオーバーライドすることで、この振る舞いを以前の（一貫性のない！）形に戻すことができる：<syntaxhighlight>
OptimisationSwitches
{
//- Enable enforced consistency of constraint bcs after 'local' operations.
// Default is on. Set to 0/false to revert to <v2306 behaviour
localConsistency 0;
}
</syntaxhighlight>簡単なテストはcyclicAMIパッチを使ったチュートリアル、例えばpipeCyclicチュートリアルです。上記のDebugSwitchでチェックを有効にすると問題なく動作しますが、localConsistencyフラグを無効にすると不整合が検出されます：<syntaxhighlight>
[0] --> FOAM FATAL ERROR: (openfoam-2302 patch=230110)
[0] Field dev(symm(grad(U))) is not evaluated? On patch side1 type cyclicAMI : average of field = ...
</syntaxhighlight>Related issues

* Issue 2783

Source code

* $FOAM_SRC/OpenFOAM/fields/GeometricFields/GeometricField/GeometricBoundaryField.C

Merge request

* Merge request 628

==== ノンブロッキング環状A(C)MI ====
cyclicAMI境界条件は、複数の隣接する面からの面積加重補間を実装します。これらの面はローカルであることも、リモートプロセッサに存在することもあり、並列通信を必要とします。

以前のリリースでは、それぞれのcyclicAMIの評価または線形ソルバーの行列寄与（ローカルでない隣接面の場合）が、独自の通信セットをトリガーし、次のcyclicAMIまたはプロセッサパッチに進む前に、これらの終了を待っていました。このリリースでは、すべての送受信を開始するプロセッサパッチと同様の経路をたどり、ローカル値を更新するためにリモートデータを使用する「消費」フェーズがあります。典型的な境界条件の評価や線形ソルバーの更新は、次のような形になります：

* すべての initEvaluate/initInterfaceMatrixUpdate を行う（結合境界のみ）。プロセッサ、cyclicA(C)MI の場合、これはノンブロッキングの送受信を開始する。
* すべての通信が終了するのを待つ（または、ポーリング（v2306 nPollProcInterfaces）を使用して以下と組み合わせる）。
* すべてのevaluate/updateInterfaceMatrixを行う。これは、受信したデータを使用して、行列解への寄与を計算します。

cyclicA(C)MIからの通信をプロセッサの境界条件とまったく同じ方法で処理することで、ボトルネックが発生する可能性が低くなり、スケーリングが向上することが期待される。さらなる最適化として、ローカル送受信バッファは一度割り当てられ、再利用される。

Source code

* $FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint/cyclicAMI/cyclicAMIFvPatchField.H

Merge request

* Merge request 641

Tutorial

* any case with <code>cyclicAMI</code> or <code>cyclicACMI</code>

==== GAMG : プロセッサ・アグロメレーションにおけるcyclicAMIのサポート ====
GAMGソルバーは、ローカルアグロメレーションに加えて、プロセッサ間で行列を結合することができます（プロセッサアグロメレーション）。これは、コア数が多い場合に有益です：

* 最も粗いレベルを解くコアの数を減らす - 世界的な削減のほとんどは、最も粗いレベルで起こる。
* は、スムージングやプリコンディショニングなど、すべての演算の暗黙性を高める。

このリリースでは、cyclicAMIやcyclicACMIなど、すべての連成境界条件のプロセッサアグロメレーションを可能にするようにフレームワークが拡張されました。

テストとして、以下を比較した。

* 40x10x1のブロック1つ、および
* 2つの20x10x1ブロックがcyclicAMIを使って結合されている。

どちらのケースも4つに分解され、GAMGソルバーとmasterCoarsestプロセッサーのアグロメーターを併用することで、すべての行列がmaster(s)に結合された。<syntaxhighlight>
solvers
{
p
{
solver GAMG;
processorAgglomerator masterCoarsest;
..
}
</syntaxhighlight>

* シングルブロック（つまり、cyclicAMIはなく、プロセッサーフェイスのみ）：
<syntaxhighlight>
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 1.5 2
1 4 50 50 1.5 2
2 1 100 100 0 0
3 1 48 48 0 0
</syntaxhighlight>すべてのプロセッサ面が内部となるため、境界の数（nInterfaces）は0となる。

* 2ブロックの場合（つまり、cyclicAMIとプロセッサフェイス）：
<syntaxhighlight>
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 3 3
1 4 50 50 3 3
2 1 100 100 2 2
3 1 48 48 2 2
</syntaxhighlight>ここでは、2つのcyclicAMIのみが保存されるため、境界の数は3つから2つに減る。

=== Notes ===

* <code>cyclicA(C)MI</code> :
** すべての面がローカルになると、動作は非分散にリセットされる。つまり、操作は追加のコピーなしで、提供されたフィールドに直接適用される。
** 回転変換はまだサポートされていません。これは基本的な制限ではありませんが、変換を考慮するためにステンシルを追加で書き換える必要があります。
* processorCyclic : (オーナーセルと隣接セルが異なるプロセッサ上にあるサイクリック) はまだサポートされていない。これは通常のプロセッサ境界として扱われるため、変換は失われる。processorCyclicはdecomposeParDictでパッチ制約を使うことで回避できることに注意。
<syntaxhighlight>
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (cyclic);
}
}
</syntaxhighlight>

* masterCoarsestのみがテストされているが、コードは他のどのプロセッサー凝集法もサポートするはずである。
* これまでの限られたテストでは、cyclicAMIのプロセッサー集積の利点は示されていない。これは、ボトルネック、例えば、大域的削減の数や暗黙性が問題となる場合にのみ有効である。

Source code

* $FOAM_SRC/OpenFOAM/meshes/lduMesh/lduPrimitiveMesh.C

Merge request

* Merge request 645

=== redistributeParとファイルシステムの改良 ===
このリリースでは、照合ファイル・フォーマットの一般的なサポートが改善され、redistributeParユーティリティの調整も行われました。これらの変更により、照合ファイル形式は以前よりも幅広いワークフローで使用できるようになりました。

これらの変更に加え、分散ファイルシステムによるダイナミックコードの取り扱いが改善された。このようなタイプのシステムでは、動的にコンパイルされたライブラリも対応するサブランクに配布されるようになった。

==== 照合されたインクルードファイルの取り扱いが改善された ====
以前のバージョンでは、"include "ファイルを照合と組み合わせて使用すると、ファイルの内容がランタイムで変更可能なものとして扱われる場合、非常に壊れやすいことがあった。今回、ウォッチド・ファイルの取り扱いが更新され、プロセッサー・ランク間の適切な対応が保証されるようになった。

== Usability ==

=== New verification and validation public repository ===
OpenFOAMソフトウェアの検証と妥当性確認に関するコミュニティへの貢献をホストする新しいパブリックリポジトリが開設されました： OpenFOAM Verification and Validation Repository。

このリポジトリの主な目的は、OpenFOAMコミュニティがソフトウェアの検証と検証の側面を共有、協力、強化するための一元化されたプラットフォームを提供することです。コミュニティの集合的な知識と専門知識を結集することにより、OpenFOAMシミュレーションの全体的な品質を向上させ、数値モデリングのベストプラクティスを推進することを目指しています。

このリリースでは、Taylor-Green渦問題と円形Couette流れが組み込まれ、ケースのセットアップとドキュメンテーションのために提供されたテンプレートの実用的な応用が示されています。

=== コンピレーション ===

=== General ===
OpenFOAMで使用されるC++標準は、GNUコンパイラでもc++14になりました。この変更により、推奨コンパイラの最小バージョンはgcc-7.5.0になりました。

将来のコード移行を支援するため、「より厳しい」非推奨警告を有効にできるようになりました。これは WM_COMPILE_CONTROL 環境変数の +strict エントリでグローバルに、または wmake -strict で一度だけ有効にできます。これは主に開発者向けのオプションと考えることができます（多くの警告を生成する可能性があります）が、モジュールを書くときに便利で面白いかもしれません。

=== MacOS ===
このバージョンには、MacOS上でのコンパイルと実行に関するいくつかの改良が含まれています。

* AppleとARM64のFPE処理の改善（Guanyang Xue氏提供）
* rpathハンドリング
* xcrun サポート

MacOS のコンパイルでは、rpath のサポートがデフォルトで有効になり、Apple SIP (System Integrity Protection) の影響に対する回避策がいくらか減って、これらのシステムでの OpenFOAM の実行が簡単になりました。WM_COMPILE_CONTROL環境変数に~rpathを追加することで、rpath処理を無効にできます。

MacOSコンパイルでは、xcodeツール（xcrunなど）の使用もサポートするようになりました。これらはWM_COMPILE_CONTROL環境変数に+xcrunを追加することで有効になります。見つかると、これらのコンパイル・ルールが使用されます：<syntaxhighlight>
cc := xcrun cc
CC := xcrun c++ -std=c++14
</syntaxhighlight>

=== Clang ===
clangベースのコンパイルで、ldリンカを使用するように明示的に指定できるようになりました（注意：clangがldを使用するかlldを使用するかはインストールに依存します）。リンカの選択は環境変数 WM_COMPILE_CONTROL の対応するエントリで定義されます：<syntaxhighlight>
- `+gold` : use gold linker
- `+link-ld` : use ld linker
- `+lld` : use lld linker
- `+mold` : use mold linker
</syntaxhighlight>

=== OpenMP ===
openmp と no-openmp の扱いが強化された。"+openmp" (wmake -openmp) よりも "~openmp" (wmake -no-openmp) の方が優先されます。

これにより、一般的に+openmpを指定する場合はrobusterとなり、特定のビルド・コンポーネント（スタティック・ライブラリやMPIブリッジ・コードなど）を指定する場合は~openmpとなる。

=== Profiling ===
このバージョンには、Extraeプロファイリング用のフックが含まれています。デフォルトでは、フックは常にOpenFOAMと一緒にビルドされますが、LD_PRELOADによってExtraeが実際にロードされるまで休止しています。これにより、OpenFOAMをその目的専用に再コンパイルすることなく、Extraeのトレースが可能になります。

Josep Pocurull（Barcelona Supercomputing Center）により提供され、exaFOAMプロジェクトの一部として使用されたコード。

Source code

* $FOAM_SRC/OpenFOAM/global/profiling/profilingTrigger.C

Merge request

* Merge request 652

OpenFOAM v2312リリースノート

2023-12-24T08:12:39Z

Mmer547:

OpenCFDは、2023年12月リリースのOpenFOAM® v2312を発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v2306の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージも多数あります。

Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール

openSUSE Linux: Leap 15.5 用パッケージインストール

Redhat Linuxの亜種: epel 9用のパッケージインストール; Fedora 37

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢があります（詳細）：

Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。

クロスコンパイルによるネイティブ実行ファイル

docker インストール

OpenFOAMのapptainerサポートは、事前にアセンブルされたイメージではなく、記述ファイルによって提供されます：

パッケージング/コンテナ参照

Mac OSXユーザーは、ソースからコンパイルするか、Dockerコンテナを使ってコンパイル済みのパッケージを使用するオプションがあります（詳細）。

== Upgrading ==

=== v2312ユーザーアップグレードガイド ===

=== 挙動の変化 ===

==== デフォルトのEnSightフォーマット ====

* 関数オブジェクトとライターが使用するデフォルトの ensight 出力が、シミュレーション controlDict で指定される \c writeFormat に依存するのではなく、より一貫して ˶c binary format を使用するようになりました。この変更により、foamToEnsight などのユーティリティや、他のファンクション・オブジェクトやライターとの動作がより一貫したものになります。

==== Function object: <code>Lambda2</code> ====
Lambda2関数オブジェクトの出力が、支配方程式の変更、特に符号の反転によって修正されました。その結果、Lambda2のv2312以前のバージョンで観測された負のフィールド値は、v2312リリースでは正のフィールド値になりました（逆も同様）。

=== 名前変更 ===

==== Function object: <code>WeberNumberReacting</code> ====
ラグランジュ関数オブジェクトクラスWeberNumberReactingは、新しいラグランジュ雲関数オブジェクトKinematicWeberNumberとの整合性を確保するため、ReactingWeberNumberと改名された。

=== v2312 Developer Upgrade Guide ===

=== Deprecation and Removal ===

==== Removed Items ====

* The <code>faMesh::operator()</code> has been removed in favour of <code>mesh()</code> or <code>thisDb()</code> instead.
* The <code>typeGlobal()</code> global function has been replaced with an <code>is_globalIOobject<Type></code> traits structure for more consistent and easier overriding. The ancillary <code>typeFilePath()</code> global function has been superseded by global function as a member of <code>IOobject::typeFilePath</code> for consistency with <code>IOobject::typeHeaderOk</code>

=== Changes in definition ===

* <code>ReadFields</code> now uses a <code>DynamicList</code> to implement its LIFO for handling stored objects. The older <code>LIFOStack</code> interface is marked as ''deprecated'' since it requires more allocations and overhead.
* Deprecate some <code>IOobjectList::sorted()</code> const-access methods in favour of the new <code>csorted()</code> methods. This provides method name consistency with <code>HashTable</code> and ensures an unambiguous return type.
* The internal dictionary separator has changed from <code>'.'</code> to <code>'/'</code>, which simplifies internal handling (like a fileName) and allows the dictionary name to be used with unambiguous addressing. No particular side-effects of this change are expected, except if the raw dictionary names have been directly reparsed within code.

=== Changes in inheritance ===
The <code>data</code> class used by <code>fvMesh</code> has been replaced by member data at the <code>polyMesh</code> level. For a developer, this means that the following (fragile and ugly) code will now most certainly break!
<code>obr.lookupObject<fvMesh>("data") // This was never a good idea</code>

=== Relocated Methods ===
Promote <code>ListOps::identity</code> to <code>Foam::identity</code> this becoming more frequently used and there is no ambiguity in calling parameters. Handles both int32 and int64 versions.

=== Container improvements / changes ===
As with some many releases, the underlying OpenFOAM containers have been upgraded and tweaked in a variety of ways. Some of the focus has been on modernizing internal copying, filling, moving data by harnessing using C++ algorithms in more places. Apart from general code reduction, the shift to algorithms helps provision for different execution models (eg, <code>std::execution::parallel_unsequenced_policy</code>) in the future.

==== HashTable construct ====
The default constructors for <code>HashTable</code> and <code>HashSet</code> now truly correspond to a zero-size construct (ie, they invoke no allocations) and are also <code>noexcept</code>. This is particularly convenient and useful when managing lists of hash sets etc. The move constructors are also now noexcept as well.

* removed unused <code>HashTable(Istream&, label)</code> constructor.

==== HashTable sizing improvements ====

* earlier deletion of unpopulated HashTable on resizing: If the table is already clear (ie, has no entries), can immediately remove the old internal table before reallocating the newly sized table, which may avoid a needless memory spike.
* reserve() method: Naming and general behaviour as per <code>std::unordered_map</code>. It behaves similarly to the <code>resize()</code> method but is supplied the number of elements instead of the capacity, which can be a more natural way of specifying the storage requirements. Additionally, <code>reserve()</code> will only increase the table capacity for behaviour similar to <code>DynamicList</code> and <code>std::vector</code>, <code>std::string</code> etc.

C++の最低規格は、2024年にC++11からC++17に引き上げられる予定である。

== Pre-processing ==

=== snappyHexMesh：自動リークパスクロージャーから面を書き込む ===
snappyHexMeshにはメッシュ内の任意の位置とメッシュ外の位置の間のパスとして定義されたサーフェスのリークを自動的に閉じるオプションがあります。このリリースではリークを閉じるために使用された面はpostProcessingディレクトリのファイルに書き込まれます。

下図は、ギャップのある球体（灰色）、スナップされたメッシュライン（青）、リークを閉じる面（赤）からなるテストケースを示しています：

ファイル書き込みフォーマットはsnappyHexMeshDictの新しいエントリーで選択できます：<syntaxhighlight>
//// Format for writing lines. E.g. leak path. Default is vtk format.
//setFormat ensight;

//// Format to use for surfaces. E.g. leak-closure faces. Default is vtk format.
//surfaceFormat vtk;
</syntaxhighlight>Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_gapClosure

Source code

* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C

=== snappyHexMesh：新しい複数の内側ポイント ===
snappyHexMeshのセルゾーンはinsidePointを指定することで作成できます：<syntaxhighlight>
refinementSurfaces
{
..
cellZoneInside insidePoint; // outside/insidePoint
insidePoint (1 1 1); // if (cellZoneInside == insidePoint)
}
</syntaxhighlight>1つのinsidePointではなく、複数のinsidePointが用意された：<syntaxhighlight>
cellZoneInside insidePoints; // outside/insidePoint
insidePoints ((1 1 1)); // if (cellZoneInside == insidePoint)
</syntaxhighlight>下の図では、ジオメトリは2つのボックス（ワイヤーフレーム）で構成され、上のボックスは2つの切り離されたメッシュ領域をカバーしている。赤で示されたセルゾーンは、3つの別々のメッシュ領域を使用して作成されています。checkMeshユーティリティは、切断されたリージョンを表示するために使うことができます。

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/insidePoints

Source code

* $FOAM_SRC/mesh/snappyHexMesh/refinementSurfaces/surfaceZonesInfo.H

=== snappyHexMesh：並列メッシュの負荷分散 ===
snappyHexMeshは並列実行時に自動的にメッシュのバランスをとることができます。それは以下のどちらかになります

* 変更が小さすぎる場合はバランスを取らない - maxLoadUnbalanceまたはmaxCellUnbalance設定を参照。
* maxLocalCells設定を参照してください。

このリリースでは、各ステップでメッシュのアンバランスがプリントされます：<syntaxhighlight>
Layer mesh : cells:353749 faces:1108448 points:406303 unbalance:0.00110248

</syntaxhighlight>精製前のバランスは、セルの重みを与えることで実装されることに注意。各精製されるセルは8ずつカウントされる。しかし、これは単純な分解法、例えば階層的な分解法にのみ有効である。scotch と KaHip メソッドでは、カット数を含む重みを使ってアンバランスを最小化する。

Tutorials

* any parallel snappyHexMesh case

Source code

* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C
* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

Related issues

* Issue 3034

=== snappyHexMesh：レイヤーごとの追加 ===
OpenFOAM v2206リリースでは、snappyHexMeshが拡張され、nOuterIterエントリーを使用して複数パスでレイヤーを追加できるようになりました。ここでは、$FOAM_TUTORIALS/incompressible/pisoFoam/LES/motorBike/motorBikeチュートリアルを出発点として、どのように改良されたレイヤーの追加を実行できるかをデモしたいと思います：<syntaxhighlight>
relativeSizes false; // true

// Per final patch (so not geometry!) the layer information
layers
{
"(lowerWall|motorBike).*"
{
nSurfaceLayers 16;
}
}

// Expansion factor for layer mesh
expansionRatio 1.2;
</syntaxhighlight>重要な設定は、外側の反復回数とメッシュ・モーション・ソルバーである：<syntaxhighlight>
// Overall max number of layer addition iterations
nLayerIter 25;

// Add layers in multiple passes - gives layers a chance to rotate
nOuterIter 4;

meshShrinker displacementMotionSolver;
solver displacementLaplacian;
displacementLaplacianCoeffs
{
diffusivity quadratic inverseDistance (lowerWall upperWall "motorBike*")
}
</syntaxhighlight>メッシュの品質基準を緩めることで、（全体的なメッシュ品質は維持したまま）この複雑な形状でもレイヤーカバレッジを劇的に向上させることができる。

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/addLayersToFaceZone

Source code

* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

=== Nastranサーフェスリーダーの改良 ===
NASTRANパーサーが更新され、PSHELL名の新しいANSA規約に対応しました。これにより、snappyHexMeshなど、より多くの場所でNASTRANファイルを直接使用することができるようになりました。

Source code

* $FOAM_SRC/surfMesh/surfaceFormats/nas/NASsurfaceFormat.C

Issue

* Issue 3009

=== checkMeshユーティリティの改良 ===
checkMesh ユーティリティに writeChecks オプションが追加されました：<syntaxhighlight>
checkMesh -writeChecks <format>

</syntaxhighlight>これにより、メッシュ・チェックのフォーマットを含むファイルが生成される：

* dictionary : OpenFOAM dictionary;
* json : JSON format.

例えば、コマンドを使う：<syntaxhighlight>
checkMesh -allGeometry -allTopology -writeChecks JSON

</syntaxhighlight>motorBikeチュートリアルでは、caseディレクトリにcheckMesh.jsonファイルが生成される：<syntaxhighlight>
{
"maxNonOrth" : 64.9999,
"aveNonOrth" : 9.92427,
"maxSkew" : 9.25719,
"nWarnSkew" : 12,
"minDeterminant" : 0,
"aveDeterminant" : 1.55371,
"thresholdDeterminant" : 0.001,
"nErrorDeterminant" : 1274,
"minFaceWeight" : 0.0216708,
"aveFaceWeight" : 0.465687,
"thresholdFaceWeight" : 0.05,
"nErrorFaceWeight" : 1143,
"minFaceVolumeRatio" : 0.0101126,
"aveFaceVolumeRatio" : 0.846049
}
</syntaxhighlight>Source code

* $FOAM_UTILITIES/mesh/manipulation/checkMesh/checkMesh.C

=== subsetMeshユーティリティの改良 ===
subsetMesh ユーティリティが更新され、通常の -patches 選択を変更する -exclude-patches オプションを受け付けるようになりました。

この変更により、最も近い露出パッチの指定が簡単になりました。

== Numerics ==

=== コミュニティへの貢献随伴形状最適化の改善 ===
形状最適化のための感度微分を計算するためのE-SIとFI定式化間の整合性が改善されました。naca0012/laminar/moment/primalAdjointチュートリアルから取得した、変更前後のコード動作の例を以下に示します：

一貫した点／面の感度マップ

v2306とv2312で計算されたドラッグ感度マップを比較すると、a)新しいポイント-フェイス補間は、生の、つまり平滑化されていない感度でも、より滑らかな結果を生成する。

さらなる改善点は以下の通り：

* 不必要に新しいアドジョイントフィールドを割り当てることなく幾何学的制約を定義するための新しいアドジョイントソルバ（null）と目的関数（geometric）タイプ

* 不等式制約のある最適化問題に取り組むための3つの新しい更新法（ISQP, nullSpace, MMA）
* 設計変数に境界を導入。ボリューメトリックBスプラインの場合、最適化を通してメッシュの品質をより良く保つことができます。
* 最適化ループの収束基準の導入。

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/laminar/multipleConstraints

Guide

* The updated user guide for v2312 can be found here

Source code

* Merge request MR!649
* Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
* Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

* The software was developed by PCOpt/NTUA and FOSS GP
* Integration in collaboration with OpenCFD

=== コミュニティへの貢献トポロジーに基づく新しいアジョイント最適化 ===
OpenFOAM v2312では、空隙率ベースまたはレベルセットアプローチによる新しいトポロジー最適化機能が追加されました。どちらも、設計されたジオメトリをSTLとしてエクスポートする機能を備えており、製造やボディフィットグリッドによる再評価に利用できます。

空隙率ベースのアプローチは、計算領域の非生産的な部分を固めることでブロックする設計変数の場（人工空隙率α）に依存する。得られた解の平滑性を高めるために、正則化方程式を解いて中間場α̃を計算し、次にシャープニング/プロジェクションステップを経てほぼ二値の場βを計算します。後者は、固化した領域（すなわちβ≈1の領域）で流れ解をゼロにするソース項を流れ方程式に導入するために使用されます。上記のプロセスの手順を以下に示す。

次の表は、同じケースの3つの異なるバリエーション、すなわち、Jpt＜Jpttarget制約（右）の下で、総圧力損失（Jpt）の最小化（左）、下部出口と右出口間の体積流量の均等配分制約（Jm）を伴うJptの最小化（中央）、および流れの均一性（Jun）の最大化（右）に対するトポロジー最適化の結果を示している。

ケースは、adjointOptimisationFoam/topologyOptimisation/monoFluidAero/turbulent/1_Inlet_2_Outlet/porosityBased/BPにあります。

次の表は、同様の目的関数と制約関数を持つ3次元多様体のトポロジー最適化の結果を示しています。最初の行は、最適化サイクル中の計算領域の流体部分と固体部分の境界の進行を示し、最後の行は、最適化された3つの形状のSTLファイルを示しています。後者の生成プロセスは自動化されており、各最適化サイクルの終了時に実行されます。これらのSTLファイルは、適切な境界条件によるボディフィットシミュレーションや、その後の形状最適化、さらには製造に使用することができます。

ケースはtopologyOptimisation/monoFluidAero/laminar/3DBoxにあります。

==== 下位互換性 ====
optimisationDict.optimisationの項目が少し変わりました。この変更は、例えば、$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/motorBikeのoptimisationDictを以前のものと比較することで確認できます。

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation

Guide

* The updated user guide for v2312 can be found here

Source code

* Merge request MR!649
* Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
* Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

* The software was developed by PCOpt/NTUA and FOSS GP
* Integration in collaboration with OpenCFD

== Solvers and physical models ==

=== fvOptionsの改良：ポイントの移動 ===
有限体積オプション（fvOptions）フレームワークが改良されました：

* 入力辞書の更新により、セル選択を実行時に更新できるようになりました。
* 空間内を移動する点をモデル化する新しい方法。

最小限の使用例は以下の通り：<syntaxhighlight>
fvOption1
{
// Optional entries
updateSelection true;

...
}

fvOption2
{
// Mandatory entries
selectionMode movingPoints;

movingPoints
{
point1 table
(
// time position
( 0 (0 0 0.75))
( 1 (0 0 0.65))
( 2 (0 0 0.55))
( 3 (0 0 0.45))
( 4 (0 0 0.35))
( 5 (0 0 0.25))
);

point2 (-0.25 -0.25 0.5);
}

...
}
</syntaxhighlight>Source code

* $FOAM_SRC/fvOptions/cellSetOption/cellSetOption.H

Merge request

* Merge request 630

=== 新しい fvOption: マップされたフィールド制約 ===
MapFieldConstraintは、外部メッシュからのソース・フィールドを使用して、<Type>型の指定フィールドに値の制約を課します。ここで、<Type>には{scalar, vector, sphericalTensor, symmTensor, tensor}を指定できます。オプションとして、ソースフィールドは時間経過とともに平行移動または回転させることができます。

考えられる用途は、例えば、移動する電気源の影響をモデル化することである。最小限の使用例を以下に示す：<syntaxhighlight>
MapFieldConstraint1
{
// Mandatory entries
type MapFieldConstraint;
field <word>;
srcMesh <fileName>;
mapMethod <word>;

// Optional entries
consistent <bool>;
patchMapMethod <word>;
transform
{
// Optional entries
position <Function1<vector>>;
origin <vector>;

direction <Function1<vector>>;
normal <vector>;
}

// Conditional entries

// when consistent=false
patchMap <HashTable<word>>; // (<patchSrc> <patchTgt>);
cuttingPatches <wordList>; // (<patchTgt1> ... <patchTgtN>);

// Inherited entries

...
}
</syntaxhighlight>Source code

* $FOAM_SRC/fvOptions/constraints/general/mapFieldConstraint/MapFieldConstraint.H

Merge request

* Merge request 630

=== コミュニティへの貢献：新しい乱流技術委員会サブモジュール ===
OpenFOAMガバナンス内のTurbulence Technical Committeeのネストされたサブモジュールを含む新しいコミュニティサブモジュールが開始されました。このサブモジュールは、公開されている Turbulence Technical Committee のリポジトリでホストされています。

コミュニティ・サブモジュールは、乱流モデリングに関連する学術的・産業的な貢献のホストとして機能し、知識交換の場を作り、この分野とOpenFOAMの両方を発展させるコラボレーションを促進します。

BitbucketやGitHubのようなGitベースのソースコード・リポジトリ・ホスティング・サービスでホストし、このサブモジュールを介してOpenFOAMソフトウェアにリンクすることができます。

このリリースでは、サブモジュールにlibWallModelledLESライブラリーが組み込まれ、壁面モデルによるラージ・エディ・シミュレーション（WMLES）の領域でOpenFOAMの機能が拡張されました。この乱流モデリング手法は、乱流境界層の内部領域の解像度を回避することで、費用対効果の高いLESを可能にします。

Source code

* $WM_PROJECT_DIR/modules/turbulence-community

Attribution

* OpenCFD would like to acknowledge and thank Turbulence Technical Committee members for their contributions and help.

=== 改善されたラグランジュ・ブラウン運動 ===
このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。しかし、特に指定がない限り、（互換性のために）デフォルトの球形分布が引き続き使用されます。

このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。

しかし、特に指定がない限り、適度に小さな時間ステップでは不正確であるにもかかわらず、（互換性のために）デフォルトの球面処理が引き続き使用されます。

三次分布は、球面処理が明示的に無効化されている場合に使用される。例えば<syntaxhighlight>
subModels
{
particleForces
{
sphereDrag;
BrownianMotion
{
lambda 2e-10;
turbulence false;
spherical false;
}
}
...
}
</syntaxhighlight>立方体分布と球形分布の違いは次の図に見られる。

変更の報告、検証、テストはGuanyang Xueの好意によるものである。

Source code

* $FOAM_SRC/lagrangian/turbulence/submodels/Thermodynamic/ParticleForces/BrownianMotion/BrownianMotionForce.H

Issue

* Issue 2922

Merge request 634

== Post-processing ==

=== 新しいAbaqusサンプルセット ===
新しい abaqusMesh セットは、Abaqus メッシュポイント形式を使用してファイルからサンプル位置を導出します。使用例：<syntaxhighlight>
sets
{
cone25 // user-specified set name
{
type abaqusMesh;
file "abaqusMesh.inp";

// Optional entries

// Scale, e.g. mm to m
scale 0.001;

// Search distance when the sample point is not located in a cell
maxDist 0.25;

...
}
}
</syntaxhighlight>Tutorials

* TBA

Source code

* $FOAM_SRC/sampling/sampledSet/abaqus

=== 新しいAbaqusセットライター ===
新しいAbaqusセットライターはOpenFOAMセットデータをAbaqusフォーマットに変換します。使用例<syntaxhighlight>
T
{
type sets;
setFormat abaqus;
fields (T);
sets
{
...
}
}
</syntaxhighlight>オプションの書式オプションは、formatOptions辞書内のabaqusサブ辞書で提供されます：<syntaxhighlight>
formatOptions
{
abaqus
{
format ascii;

// Optional entries

// Custom header: $ entries are substituions
header
(
"** OpenFOAM abaqus output"
"** Project $FOAM_CASE"
"** File $FILE_NAME"
"** $FIELD_NAME Time t=$TIME"
);

// Write geometry in addition to field data
writeGeometry yes;

// Null value when sample value is not found
// Default is scalar::min
nullValue 0;

// Insert additional time sub-directory in the output path
// - yes : postProcessing/<fo-name>/<time>/<file>
// - no : postProcessing/<fo-name>/<file>
useTimeDir no;

// Available when 'useTimeDir' is 'no' to disambiguate file names

// Time base for output file names:
// - 'time' : <base>.inp_<field>.<time>
// - 'iteration' : <base>.inp_<field>.<iteration>
timeBase iteration;

// Optional start counters when using timeBase iteration
writeIndex
(
T 1
);

...
}
}
</syntaxhighlight>Tutorials

* TBA

Source code

* $FOAM_SRC/meshTools/coordSet/writers/abaqus/abaqusCoordSetWriter.C

=== パッチ・シード・セットの改善 ===
patchSeed sampled setがパッチ全体で一様にサンプルシードを計算するようになりました。以前の実装では、顔のインデックスをパッチ全体で一様にサンプリングしていましたが、その副作用として、より小さな顔に偏りがありました。<syntaxhighlight>
streamline5
{
type streamLine;
libs (fieldFunctionObjects);
U U;
fields (U p);
setFormat vtk;
direction forward;
lifeTime 20000;
cloud particleTracks;
seedSampleSet
{
type patchSeed;
axis xyz;
patches ("inlet1");
maxPoints 40;
}
interpolationScheme cellPoint;
trackLength 0.001;
}
</syntaxhighlight>Tutorial

* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike/system/wallBoundedStreamLines

Source code

* $FOAM_SRC/sampling/sampledSet/patchSeed

Merge request

* Merge request 647

=== 新しいケース情報機能オブジェクト ===
新しい caseInfo 関数オブジェクトは、実行時または後処理の一部として、ソルバーとケースの情報を生成します。収集されるデータには以下が含まれます：

* メタデータ：ケース名、パス、タイムディレクトリ数など。
* 辞書エントリ : 任意の入力辞書からすべて/選択したものを抽出
** fvSolutionからUリニアソルバーを取得するには、'solvers/U/solver'などのスコープを使用する。
** はワイルドカードをサポートしている。例えば、fvSolution U ソルバー・キーワードが"(U|k|epsilon) "であった場合。
** include'または'exclude'リストを使用して、含める/除外するエントリ名の選択を制限する。
* メッシュ統計：点、面、セルの数、境界、ゾーン名など。
* 関数オブジェクトの結果：関数オブジェクトの結果のキャッシュ値など

使用例：<syntaxhighlight>
caseInfo1
{
type caseInfo;
libs (utilityFunctionObjects);

writeFormat json; // josn | dictionary

// List of dictionaries - retrieve using 'path' or registered 'name'
dictionaries
{
fvSolution
{
name "fvSolution";

// include all entries by default
}
controlDict
{
path "system/controlDict";
include
(
"application"
"deltaT"
"startTime"
"endTime"
);
}
}

// Extract function object results
functionObjects (pressureDifference sample1);
}
</syntaxhighlight>出力例<syntaxhighlight>
{
"meta" : {
"case" : "heatExchanger",
"path" : "chtMultiRegionSimpleFoam/heatExchanger",
"regions" : ["air", "porous"],
"nTimes" : 7,
"nProc" : 1
},
"regions" : {
"air" : {
"mesh" : {
"nGeometricD" : 3,
"nSolutionD" : 3,
"nPoints" : 252991,
"nFaces" : 739260,
"nCells" : 243000,
"nPatches" : 4,
"pointZones" : [],
"faceZones" : ["rotorBlades", "baffleFaces"],
"cellZones" : ["cylinder", "innerCylinder", "rotor"],
"boundsMin" : [0, 0, 0],
"boundsMax" : [5.000000e-01, 5.000000e-01, 5.000000e-01],
"clouds" : []
},
"boundary" : {
"types" : {
"walls" : "wall",
"inlet" : "patch",
"outlet" : "patch",
"blades" : "wall"
},
"fields" : {
"alphat" : {
"walls" : "compressible::alphatWallFunction",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "compressible::alphatWallFunction"
},
"nut" : {
"walls" : "nutkWallFunction",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "nutkWallFunction"
},
"p" : {
"walls" : "calculated",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "calculated"
...
</syntaxhighlight>Source code

* $FOAM_SRC/functionObjects/utilities/caseInfo

== DMDによる新しい低次モデリング磁場再構成 ==
動的モード分解（DMD）機能は、OpenFOAM v2006で導入され、その後OpenFOAM v2106で拡張されました。このリリースにより、OpenFOAMは、DMDの主な利点の1つである、任意の中間時点や将来の時点におけるCFD計算を必要とせずに、与えられたモードとそれに関連するダイナミクスに基づいて場を生成する機能を習得しました。

この機能により、ユーザーはシミュレーション全体をいくつかのモードとモードダイナミクスに凝縮し、CFD解析を追加することなく、任意の時間における場の生成や将来の状態の予測を行うことができます。

もう一つの潜在的な利点は、ユーザーがシミュレーションを短縮し、大規模なシミュレーションを行うことなく流れ場の将来の状態を予測できることである。これは、より短時間のシミュレーションで得られたモードとモードダイナミクスを使用することで実現できます。

結果の質は、基礎となる縮小モデルの能力と入力データの質に依存することに留意すべきである。再構成結果を改善するためには、流れからモードが正しく抽出されていることを確認する必要がある。

system/ROMfieldsDictを使った最小の例は以下の通り：<syntaxhighlight>
// Mandatory entries
ROMmodel <word>;
field <word>;
object <word>;
deltaT <scalar>;
time <scalar>;
modes <labelList>;
amplitudes <complexList>;
eigenvalues <complexList>;

// Optional entries
startTime <scalar>;
dimensions <dimensionSet>;

// Inherited entries
...
</syntaxhighlight>下の図は、2次元円柱チュートリアルから得られた速度場と、シミュレーションを実行せずにDMDモードとダイナミクスを使用して再構成したものです：

Source code

* $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/createROMfields.C
* $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/ROMmodels/DMD/DMD.H

Tutorial

* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D

References

* Kiewat, M. (2019). Streaming modal decomposition approaches for vehicle aerodynamics. PhD thesis. Munich: Technical University of Munich. URL:mediatum.ub.tum.de/doc/1482652/1482652.pdf

Attribution

* OpenCFD would like to acknowledge and thank Marco Kiewat for his contributions, elaborate suggestions and help, and critical recommendations.

Merge request

* Merge request 639

=== ノイズ・ユーティリティの向上 ===
ノイズユーティリティは、時間情報からのデフォルトの自動計算だけでなく、ユーザー定義のサンプリング周波数（キーワード：sampleFreq）もサポートするようになりました。読みやすさを向上させるため、周波数の上限と下限をminFreqとmaxFreqで指定できるようになりました（以前のキーワードも引き続きサポートされています）。<syntaxhighlight>
// Lower frequency limit, default 25 Hz, former name 'fl'
minFreq 25;

// Upper frequency limit, default 10 kHz, former name 'fu'
maxFreq 10000;

// OPTIONAL - Sample frequency
sampleFreq 100;
</syntaxhighlight>サンプリングされた時間から周波数を計算する際に時間が不均一であると評価された場合、deltaT が非常に小さい場合、不均一性は多くの場合偽のエラーであるため、ユーティリティはエラーではなく警告を発するようになりました。

Source code

* $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
* $FOAM_SRC/randomProcesses/noise/noiseModels/noiseModel/noiseModel.H

Tutorial

* $FOAM_TUTORIALS//incompressible/pimpleFoam/LES/vortexShed

Issue

* Issue 2999

=== エンサイトの出力向上 ===
EnSightライターの時間値は、デフォルトの固定フォーマットと精度を使用する代わりに、ユーザーが指定できるようになりました。例えば<syntaxhighlight>
formatOptions
{
ensight
{
timeFormat general; // Format for time directory names (general | fixed | scientific); default scientific
timePrecision 12; // Default = 5
}
}
</syntaxhighlight>これらの新しいフォーマットオプションは、例えばノイズユーティリティの圧力サンプリングと組み合わせて、小さなタイムステップを使用する場合に特に便利です。

Source code

* $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
* $FOAM_SRC/functionObjects/utilities/ensightWrite/ensightWrite.H

Issue

* Merge request 634

=== 新しいラグランジュ関数オブジェクトウェーバー数 ===
表面張力と比較した粒子の慣性の相対的な重要性を監視するために、ラグランジュ関数オブジェクトWeberNumberが運動学小包に導入されています。

最小限の使用例は以下の通り：<syntaxhighlight>
cloudFunctions
{
KinematicWeberNumber1
{
// Mandatory entries
type WeberNumber;
sigma <scalar>;
}

...
</syntaxhighlight>Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/KinematicWeberNumber/KinematicWeberNumber.H

Tutorial

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk

Merge request

* Merge request 648

=== 空のサーフェス（surfaceFieldValue）の取り扱いが改善されました。 ===
ワークフローによっては、サンプリングされたサーフェスが、シミュレーション中に現れたり消えたりするフェイスゾーンなどの量に依存する場合があります。そのため、空のサーフェスでサーフェスフィールドの値を評価することは、通常、セットアップに重大なエラーがあることを示しますが、このようなことが予想される場合もあります。追加キーワードempty-surfaceにより、空のサーフェスに遭遇したときの動作を指定することができます。

最小限の例：<syntaxhighlight>
surfaceFieldValueFaceZone1
{
type surfaceFieldValue;
libs (fieldFunctionObjects);
...
regionType faceZone;

empty-surface warn; // default | warn | ignore | strict
}
</syntaxhighlight>Source code

* $FOAM_SRC/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.H

Issue

* Issue 2966

== Parallel ==

=== 結合パッチフィールド値の一貫性 ===
結合された制約境界条件、例: プロセッサーとサイクリックは、その内部フィールド値と一致している必要があります。たとえば、プロセッサパッチでは、値フィールドに隣接するプロセッサセルの値が含まれます。つまり、反対側のセルの値がキャッシュされます。他の結合されたパッチフィールドは、ローカルおよび隣接セル値の補間値を値として持つ場合があります。経験則として、セル値を変更するコードはすべて、たとえば、勾配計算では、値の更新を実行するために境界条件を修正する呼び出しを行う必要があります (プロセッサ境界フィールドでのハロースワップに相当します)。ただし、「ローカル」操作の場合、たとえば乗算では、境界条件に値のみがあり、セル値に依存しない場合、これがスキップされることがあります。ほとんどの「通常の」境界条件はこのカテゴリに分類されます。

結合境界条件の場合、プロセッサのパッチフィールドにも適用されますが、たとえば、パッチフィールドには適用されません。環状、環状AMI のバリアント。これにより、中間計算の値が一貫性制約に従わなくなります。

このリリースでは、制約パッチの値がいつでも最新であるように、ローカル操作の後の評価を強制しています。この選択はまだ調査中であり、将来更新される可能性があることに注意してください。

=== patchField の整合性チェックの結合 ===
ビジュアルコードのチェックで、meshWaveメソッドとmeshWaveAddressingメソッドによって返される壁面距離フィールドが平行一貫していないことが確認されました。このようなエラーを発見しやすくするために、オプションで整合性チェックが追加されました：<syntaxhighlight>
DebugSwitches
{
volScalarField::Boundary 1;
volVectorField::Boundary 1;
volSphericalTensorField::Boundary 1;
volSymmTensorField::Boundary 1;
volTensorField::Boundary 1;

areaScalarField::Boundary 1;
areaVectorField::Boundary 1;
areaSphericalTensorField::Boundary 1;
areaSymmTensorField::Boundary 1;
areaTensorField::Boundary 1;
}
</syntaxhighlight>1 を指定するとチェックが有効になり、チェックに失敗すると FatalError が発生する。特に FOAM_ABORT と組み合わせることで、スタックトレースを生成することができます：<syntaxhighlight>
FOAM_ABORT=true mpirun -np 2 simpleFoam -parallel

</syntaxhighlight>デバッグ・スイッチはビットマップとして解釈される：
{| class="wikitable"
!bit
!value(2^bit)
!effect
|-
|0
|1
|ローカル操作ごとにチェックを加える
|-
|1
|2
|プリントの入力と終了をチェックする
|-
|2
|4
|fatalErrorの代わりにwarning
|}
比較の許容誤差はデフォルトで0に設定されている。プロセッサのハロースワップでは、まったく同じ操作がまったく同じ順序で実行されるため、許容誤差の問題はありません。しかし、サイクリックやサイクリックAMIなどの「補間」結合境界条件では、ローカル演算（定数による乗算など）が補間後に実行されるため、若干異なる切り捨て誤差が発生します。この場合、許容誤差をオーバーライドすることができます：<syntaxhighlight>
OptimisationSwitches
{
volScalarField::Boundary::tolerance 1e-10;
// .. and similar for all the other field types ..
}
</syntaxhighlight>

==== 下位互換性 ====
新しい整合性操作は、周期的または周期的AMI境界条件、または結合境界条件を使用する非自明な乱流モデルを使用するケースの動作をわずかに変更します。

オプションとして、etc/controlDictのlocalConsistency設定をオーバーライドすることで、この振る舞いを以前の（一貫性のない！）形に戻すことができる：<syntaxhighlight>
OptimisationSwitches
{
//- Enable enforced consistency of constraint bcs after 'local' operations.
// Default is on. Set to 0/false to revert to <v2306 behaviour
localConsistency 0;
}
</syntaxhighlight>簡単なテストはcyclicAMIパッチを使ったチュートリアル、例えばpipeCyclicチュートリアルです。上記のDebugSwitchでチェックを有効にすると問題なく動作しますが、localConsistencyフラグを無効にすると不整合が検出されます：<syntaxhighlight>
[0] --> FOAM FATAL ERROR: (openfoam-2302 patch=230110)
[0] Field dev(symm(grad(U))) is not evaluated? On patch side1 type cyclicAMI : average of field = ...
</syntaxhighlight>Related issues

* Issue 2783

Source code

* $FOAM_SRC/OpenFOAM/fields/GeometricFields/GeometricField/GeometricBoundaryField.C

Merge request

* Merge request 628

==== ノンブロッキング環状A(C)MI ====
cyclicAMI境界条件は、複数の隣接する面からの面積加重補間を実装します。これらの面はローカルであることも、リモートプロセッサに存在することもあり、並列通信を必要とします。

以前のリリースでは、それぞれのcyclicAMIの評価または線形ソルバーの行列寄与（ローカルでない隣接面の場合）が、独自の通信セットをトリガーし、次のcyclicAMIまたはプロセッサパッチに進む前に、これらの終了を待っていました。このリリースでは、すべての送受信を開始するプロセッサパッチと同様の経路をたどり、ローカル値を更新するためにリモートデータを使用する「消費」フェーズがあります。典型的な境界条件の評価や線形ソルバーの更新は、次のような形になります：

* すべての initEvaluate/initInterfaceMatrixUpdate を行う（結合境界のみ）。プロセッサ、cyclicA(C)MI の場合、これはノンブロッキングの送受信を開始する。
* すべての通信が終了するのを待つ（または、ポーリング（v2306 nPollProcInterfaces）を使用して以下と組み合わせる）。
* すべてのevaluate/updateInterfaceMatrixを行う。これは、受信したデータを使用して、行列解への寄与を計算します。

cyclicA(C)MIからの通信をプロセッサの境界条件とまったく同じ方法で処理することで、ボトルネックが発生する可能性が低くなり、スケーリングが向上することが期待される。さらなる最適化として、ローカル送受信バッファは一度割り当てられ、再利用される。

Source code

* $FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint/cyclicAMI/cyclicAMIFvPatchField.H

Merge request

* Merge request 641

Tutorial

* any case with <code>cyclicAMI</code> or <code>cyclicACMI</code>

==== GAMG : プロセッサ・アグロメレーションにおけるcyclicAMIのサポート ====
GAMGソルバーは、ローカルアグロメレーションに加えて、プロセッサ間で行列を結合することができます（プロセッサアグロメレーション）。これは、コア数が多い場合に有益です：

* 最も粗いレベルを解くコアの数を減らす - 世界的な削減のほとんどは、最も粗いレベルで起こる。
* は、スムージングやプリコンディショニングなど、すべての演算の暗黙性を高める。

このリリースでは、cyclicAMIやcyclicACMIなど、すべての連成境界条件のプロセッサアグロメレーションを可能にするようにフレームワークが拡張されました。

テストとして、以下を比較した。

* 40x10x1のブロック1つ、および
* 2つの20x10x1ブロックがcyclicAMIを使って結合されている。

どちらのケースも4つに分解され、GAMGソルバーとmasterCoarsestプロセッサーのアグロメーターを併用することで、すべての行列がmaster(s)に結合された。<syntaxhighlight>
solvers
{
p
{
solver GAMG;
processorAgglomerator masterCoarsest;
..
}
</syntaxhighlight>

* シングルブロック（つまり、cyclicAMIはなく、プロセッサーフェイスのみ）：
<syntaxhighlight>
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 1.5 2
1 4 50 50 1.5 2
2 1 100 100 0 0
3 1 48 48 0 0
</syntaxhighlight>すべてのプロセッサ面が内部となるため、境界の数（nInterfaces）は0となる。

* 2ブロックの場合（つまり、cyclicAMIとプロセッサフェイス）：
<syntaxhighlight>
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 3 3
1 4 50 50 3 3
2 1 100 100 2 2
3 1 48 48 2 2
</syntaxhighlight>ここでは、2つのcyclicAMIのみが保存されるため、境界の数は3つから2つに減る。

=== Notes ===

* <code>cyclicA(C)MI</code> :
** すべての面がローカルになると、動作は非分散にリセットされる。つまり、操作は追加のコピーなしで、提供されたフィールドに直接適用される。
** 回転変換はまだサポートされていません。これは基本的な制限ではありませんが、変換を考慮するためにステンシルを追加で書き換える必要があります。
* processorCyclic : (オーナーセルと隣接セルが異なるプロセッサ上にあるサイクリック) はまだサポートされていない。これは通常のプロセッサ境界として扱われるため、変換は失われる。processorCyclicはdecomposeParDictでパッチ制約を使うことで回避できることに注意。
<syntaxhighlight>
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (cyclic);
}
}
</syntaxhighlight>

* masterCoarsestのみがテストされているが、コードは他のどのプロセッサー凝集法もサポートするはずである。
* これまでの限られたテストでは、cyclicAMIのプロセッサー集積の利点は示されていない。これは、ボトルネック、例えば、大域的削減の数や暗黙性が問題となる場合にのみ有効である。

Source code

* $FOAM_SRC/OpenFOAM/meshes/lduMesh/lduPrimitiveMesh.C

Merge request

* Merge request 645

=== redistributeParとファイルシステムの改良 ===
このリリースでは、照合ファイル・フォーマットの一般的なサポートが改善され、redistributeParユーティリティの調整も行われました。これらの変更により、照合ファイル形式は以前よりも幅広いワークフローで使用できるようになりました。

これらの変更に加え、分散ファイルシステムによるダイナミックコードの取り扱いが改善された。このようなタイプのシステムでは、動的にコンパイルされたライブラリも対応するサブランクに配布されるようになった。

==== 照合されたインクルードファイルの取り扱いが改善された ====
以前のバージョンでは、"include "ファイルを照合と組み合わせて使用すると、ファイルの内容がランタイムで変更可能なものとして扱われる場合、非常に壊れやすいことがあった。今回、ウォッチド・ファイルの取り扱いが更新され、プロセッサー・ランク間の適切な対応が保証されるようになった。

== Usability ==

=== New verification and validation public repository ===
OpenFOAMソフトウェアの検証と妥当性確認に関するコミュニティへの貢献をホストする新しいパブリックリポジトリが開設されました： OpenFOAM Verification and Validation Repository。

このリポジトリの主な目的は、OpenFOAMコミュニティがソフトウェアの検証と検証の側面を共有、協力、強化するための一元化されたプラットフォームを提供することです。コミュニティの集合的な知識と専門知識を結集することにより、OpenFOAMシミュレーションの全体的な品質を向上させ、数値モデリングのベストプラクティスを推進することを目指しています。

このリリースでは、Taylor-Green渦問題と円形Couette流れが組み込まれ、ケースのセットアップとドキュメンテーションのために提供されたテンプレートの実用的な応用が示されています。

=== コンピレーション ===

=== General ===
OpenFOAMで使用されるC++標準は、GNUコンパイラでもc++14になりました。この変更により、推奨コンパイラの最小バージョンはgcc-7.5.0になりました。

将来のコード移行を支援するため、「より厳しい」非推奨警告を有効にできるようになりました。これは WM_COMPILE_CONTROL 環境変数の +strict エントリでグローバルに、または wmake -strict で一度だけ有効にできます。これは主に開発者向けのオプションと考えることができます（多くの警告を生成する可能性があります）が、モジュールを書くときに便利で面白いかもしれません。

=== MacOS ===
このバージョンには、MacOS上でのコンパイルと実行に関するいくつかの改良が含まれています。

* AppleとARM64のFPE処理の改善（Guanyang Xue氏提供）
* rpathハンドリング
* xcrun サポート

MacOS のコンパイルでは、rpath のサポートがデフォルトで有効になり、Apple SIP (System Integrity Protection) の影響に対する回避策がいくらか減って、これらのシステムでの OpenFOAM の実行が簡単になりました。WM_COMPILE_CONTROL環境変数に~rpathを追加することで、rpath処理を無効にできます。

MacOSコンパイルでは、xcodeツール（xcrunなど）の使用もサポートするようになりました。これらはWM_COMPILE_CONTROL環境変数に+xcrunを追加することで有効になります。見つかると、これらのコンパイル・ルールが使用されます：<syntaxhighlight>
cc := xcrun cc
CC := xcrun c++ -std=c++14
</syntaxhighlight>

=== Clang ===
clangベースのコンパイルで、ldリンカを使用するように明示的に指定できるようになりました（注意：clangがldを使用するかlldを使用するかはインストールに依存します）。リンカの選択は環境変数 WM_COMPILE_CONTROL の対応するエントリで定義されます：<syntaxhighlight>
- `+gold` : use gold linker
- `+link-ld` : use ld linker
- `+lld` : use lld linker
- `+mold` : use mold linker
</syntaxhighlight>

=== OpenMP ===
openmp と no-openmp の扱いが強化された。"+openmp" (wmake -openmp) よりも "~openmp" (wmake -no-openmp) の方が優先されます。

これにより、一般的に+openmpを指定する場合はrobusterとなり、特定のビルド・コンポーネント（スタティック・ライブラリやMPIブリッジ・コードなど）を指定する場合は~openmpとなる。

=== Profiling ===
このバージョンには、Extraeプロファイリング用のフックが含まれています。デフォルトでは、フックは常にOpenFOAMと一緒にビルドされますが、LD_PRELOADによってExtraeが実際にロードされるまで休止しています。これにより、OpenFOAMをその目的専用に再コンパイルすることなく、Extraeのトレースが可能になります。

Josep Pocurull（Barcelona Supercomputing Center）により提供され、exaFOAMプロジェクトの一部として使用されたコード。

Source code

* $FOAM_SRC/OpenFOAM/global/profiling/profilingTrigger.C

Merge request

* Merge request 652

OpenFOAM v2312リリースノート

2023-12-24T08:11:10Z

Mmer547:

OpenCFDは、2023年12月リリースのOpenFOAM® v2312を発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v2306の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージも多数あります。

Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール

openSUSE Linux: Leap 15.5 用パッケージインストール

Redhat Linuxの亜種: epel 9用のパッケージインストール; Fedora 37

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢があります（詳細）：

Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。

クロスコンパイルによるネイティブ実行ファイル

docker インストール

OpenFOAMのapptainerサポートは、事前にアセンブルされたイメージではなく、記述ファイルによって提供されます：

パッケージング/コンテナ参照

Mac OSXユーザーは、ソースからコンパイルするか、Dockerコンテナを使ってコンパイル済みのパッケージを使用するオプションがあります（詳細）。

== Upgrading ==

=== v2312ユーザーアップグレードガイド ===

=== 挙動の変化 ===

==== デフォルトのEnSightフォーマット ====

* 関数オブジェクトとライターが使用するデフォルトの ensight 出力が、シミュレーション controlDict で指定される \c writeFormat に依存するのではなく、より一貫して ˶c binary format を使用するようになりました。この変更により、foamToEnsight などのユーティリティや、他のファンクション・オブジェクトやライターとの動作がより一貫したものになります。

==== Function object: <code>Lambda2</code> ====
Lambda2関数オブジェクトの出力が、支配方程式の変更、特に符号の反転によって修正されました。その結果、Lambda2のv2312以前のバージョンで観測された負のフィールド値は、v2312リリースでは正のフィールド値になりました（逆も同様）。

=== 名前変更 ===

==== Function object: <code>WeberNumberReacting</code> ====
ラグランジュ関数オブジェクトクラスWeberNumberReactingは、新しいラグランジュ雲関数オブジェクトKinematicWeberNumberとの整合性を確保するため、ReactingWeberNumberと改名された。

=== v2312 Developer Upgrade Guide ===

C++の最低規格は、2024年にC++11からC++17に引き上げられる予定である。

== Pre-processing ==

=== snappyHexMesh：自動リークパスクロージャーから面を書き込む ===
snappyHexMeshにはメッシュ内の任意の位置とメッシュ外の位置の間のパスとして定義されたサーフェスのリークを自動的に閉じるオプションがあります。このリリースではリークを閉じるために使用された面はpostProcessingディレクトリのファイルに書き込まれます。

下図は、ギャップのある球体（灰色）、スナップされたメッシュライン（青）、リークを閉じる面（赤）からなるテストケースを示しています：

ファイル書き込みフォーマットはsnappyHexMeshDictの新しいエントリーで選択できます：<syntaxhighlight>
//// Format for writing lines. E.g. leak path. Default is vtk format.
//setFormat ensight;

//// Format to use for surfaces. E.g. leak-closure faces. Default is vtk format.
//surfaceFormat vtk;
</syntaxhighlight>Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_gapClosure

Source code

* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C

=== snappyHexMesh：新しい複数の内側ポイント ===
snappyHexMeshのセルゾーンはinsidePointを指定することで作成できます：<syntaxhighlight>
refinementSurfaces
{
..
cellZoneInside insidePoint; // outside/insidePoint
insidePoint (1 1 1); // if (cellZoneInside == insidePoint)
}
</syntaxhighlight>1つのinsidePointではなく、複数のinsidePointが用意された：<syntaxhighlight>
cellZoneInside insidePoints; // outside/insidePoint
insidePoints ((1 1 1)); // if (cellZoneInside == insidePoint)
</syntaxhighlight>下の図では、ジオメトリは2つのボックス（ワイヤーフレーム）で構成され、上のボックスは2つの切り離されたメッシュ領域をカバーしている。赤で示されたセルゾーンは、3つの別々のメッシュ領域を使用して作成されています。checkMeshユーティリティは、切断されたリージョンを表示するために使うことができます。

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/insidePoints

Source code

* $FOAM_SRC/mesh/snappyHexMesh/refinementSurfaces/surfaceZonesInfo.H

=== snappyHexMesh：並列メッシュの負荷分散 ===
snappyHexMeshは並列実行時に自動的にメッシュのバランスをとることができます。それは以下のどちらかになります

* 変更が小さすぎる場合はバランスを取らない - maxLoadUnbalanceまたはmaxCellUnbalance設定を参照。
* maxLocalCells設定を参照してください。

このリリースでは、各ステップでメッシュのアンバランスがプリントされます：<syntaxhighlight>
Layer mesh : cells:353749 faces:1108448 points:406303 unbalance:0.00110248

</syntaxhighlight>精製前のバランスは、セルの重みを与えることで実装されることに注意。各精製されるセルは8ずつカウントされる。しかし、これは単純な分解法、例えば階層的な分解法にのみ有効である。scotch と KaHip メソッドでは、カット数を含む重みを使ってアンバランスを最小化する。

Tutorials

* any parallel snappyHexMesh case

Source code

* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C
* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

Related issues

* Issue 3034

=== snappyHexMesh：レイヤーごとの追加 ===
OpenFOAM v2206リリースでは、snappyHexMeshが拡張され、nOuterIterエントリーを使用して複数パスでレイヤーを追加できるようになりました。ここでは、$FOAM_TUTORIALS/incompressible/pisoFoam/LES/motorBike/motorBikeチュートリアルを出発点として、どのように改良されたレイヤーの追加を実行できるかをデモしたいと思います：<syntaxhighlight>
relativeSizes false; // true

// Per final patch (so not geometry!) the layer information
layers
{
"(lowerWall|motorBike).*"
{
nSurfaceLayers 16;
}
}

// Expansion factor for layer mesh
expansionRatio 1.2;
</syntaxhighlight>重要な設定は、外側の反復回数とメッシュ・モーション・ソルバーである：<syntaxhighlight>
// Overall max number of layer addition iterations
nLayerIter 25;

// Add layers in multiple passes - gives layers a chance to rotate
nOuterIter 4;

meshShrinker displacementMotionSolver;
solver displacementLaplacian;
displacementLaplacianCoeffs
{
diffusivity quadratic inverseDistance (lowerWall upperWall "motorBike*")
}
</syntaxhighlight>メッシュの品質基準を緩めることで、（全体的なメッシュ品質は維持したまま）この複雑な形状でもレイヤーカバレッジを劇的に向上させることができる。

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/addLayersToFaceZone

Source code

* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

=== Nastranサーフェスリーダーの改良 ===
NASTRANパーサーが更新され、PSHELL名の新しいANSA規約に対応しました。これにより、snappyHexMeshなど、より多くの場所でNASTRANファイルを直接使用することができるようになりました。

Source code

* $FOAM_SRC/surfMesh/surfaceFormats/nas/NASsurfaceFormat.C

Issue

* Issue 3009

=== checkMeshユーティリティの改良 ===
checkMesh ユーティリティに writeChecks オプションが追加されました：<syntaxhighlight>
checkMesh -writeChecks <format>

</syntaxhighlight>これにより、メッシュ・チェックのフォーマットを含むファイルが生成される：

* dictionary : OpenFOAM dictionary;
* json : JSON format.

例えば、コマンドを使う：<syntaxhighlight>
checkMesh -allGeometry -allTopology -writeChecks JSON

</syntaxhighlight>motorBikeチュートリアルでは、caseディレクトリにcheckMesh.jsonファイルが生成される：<syntaxhighlight>
{
"maxNonOrth" : 64.9999,
"aveNonOrth" : 9.92427,
"maxSkew" : 9.25719,
"nWarnSkew" : 12,
"minDeterminant" : 0,
"aveDeterminant" : 1.55371,
"thresholdDeterminant" : 0.001,
"nErrorDeterminant" : 1274,
"minFaceWeight" : 0.0216708,
"aveFaceWeight" : 0.465687,
"thresholdFaceWeight" : 0.05,
"nErrorFaceWeight" : 1143,
"minFaceVolumeRatio" : 0.0101126,
"aveFaceVolumeRatio" : 0.846049
}
</syntaxhighlight>Source code

* $FOAM_UTILITIES/mesh/manipulation/checkMesh/checkMesh.C

=== subsetMeshユーティリティの改良 ===
subsetMesh ユーティリティが更新され、通常の -patches 選択を変更する -exclude-patches オプションを受け付けるようになりました。

この変更により、最も近い露出パッチの指定が簡単になりました。

== Numerics ==

=== コミュニティへの貢献随伴形状最適化の改善 ===
形状最適化のための感度微分を計算するためのE-SIとFI定式化間の整合性が改善されました。naca0012/laminar/moment/primalAdjointチュートリアルから取得した、変更前後のコード動作の例を以下に示します：

一貫した点／面の感度マップ

v2306とv2312で計算されたドラッグ感度マップを比較すると、a)新しいポイント-フェイス補間は、生の、つまり平滑化されていない感度でも、より滑らかな結果を生成する。

さらなる改善点は以下の通り：

* 不必要に新しいアドジョイントフィールドを割り当てることなく幾何学的制約を定義するための新しいアドジョイントソルバ（null）と目的関数（geometric）タイプ

* 不等式制約のある最適化問題に取り組むための3つの新しい更新法（ISQP, nullSpace, MMA）
* 設計変数に境界を導入。ボリューメトリックBスプラインの場合、最適化を通してメッシュの品質をより良く保つことができます。
* 最適化ループの収束基準の導入。

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/laminar/multipleConstraints

Guide

* The updated user guide for v2312 can be found here

Source code

* Merge request MR!649
* Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
* Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

* The software was developed by PCOpt/NTUA and FOSS GP
* Integration in collaboration with OpenCFD

=== コミュニティへの貢献トポロジーに基づく新しいアジョイント最適化 ===
OpenFOAM v2312では、空隙率ベースまたはレベルセットアプローチによる新しいトポロジー最適化機能が追加されました。どちらも、設計されたジオメトリをSTLとしてエクスポートする機能を備えており、製造やボディフィットグリッドによる再評価に利用できます。

空隙率ベースのアプローチは、計算領域の非生産的な部分を固めることでブロックする設計変数の場（人工空隙率α）に依存する。得られた解の平滑性を高めるために、正則化方程式を解いて中間場α̃を計算し、次にシャープニング/プロジェクションステップを経てほぼ二値の場βを計算します。後者は、固化した領域（すなわちβ≈1の領域）で流れ解をゼロにするソース項を流れ方程式に導入するために使用されます。上記のプロセスの手順を以下に示す。

次の表は、同じケースの3つの異なるバリエーション、すなわち、Jpt＜Jpttarget制約（右）の下で、総圧力損失（Jpt）の最小化（左）、下部出口と右出口間の体積流量の均等配分制約（Jm）を伴うJptの最小化（中央）、および流れの均一性（Jun）の最大化（右）に対するトポロジー最適化の結果を示している。

ケースは、adjointOptimisationFoam/topologyOptimisation/monoFluidAero/turbulent/1_Inlet_2_Outlet/porosityBased/BPにあります。

次の表は、同様の目的関数と制約関数を持つ3次元多様体のトポロジー最適化の結果を示しています。最初の行は、最適化サイクル中の計算領域の流体部分と固体部分の境界の進行を示し、最後の行は、最適化された3つの形状のSTLファイルを示しています。後者の生成プロセスは自動化されており、各最適化サイクルの終了時に実行されます。これらのSTLファイルは、適切な境界条件によるボディフィットシミュレーションや、その後の形状最適化、さらには製造に使用することができます。

ケースはtopologyOptimisation/monoFluidAero/laminar/3DBoxにあります。

==== 下位互換性 ====
optimisationDict.optimisationの項目が少し変わりました。この変更は、例えば、$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/motorBikeのoptimisationDictを以前のものと比較することで確認できます。

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation

Guide

* The updated user guide for v2312 can be found here

Source code

* Merge request MR!649
* Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
* Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

* The software was developed by PCOpt/NTUA and FOSS GP
* Integration in collaboration with OpenCFD

== Solvers and physical models ==

=== fvOptionsの改良：ポイントの移動 ===
有限体積オプション（fvOptions）フレームワークが改良されました：

* 入力辞書の更新により、セル選択を実行時に更新できるようになりました。
* 空間内を移動する点をモデル化する新しい方法。

最小限の使用例は以下の通り：<syntaxhighlight>
fvOption1
{
// Optional entries
updateSelection true;

...
}

fvOption2
{
// Mandatory entries
selectionMode movingPoints;

movingPoints
{
point1 table
(
// time position
( 0 (0 0 0.75))
( 1 (0 0 0.65))
( 2 (0 0 0.55))
( 3 (0 0 0.45))
( 4 (0 0 0.35))
( 5 (0 0 0.25))
);

point2 (-0.25 -0.25 0.5);
}

...
}
</syntaxhighlight>Source code

* $FOAM_SRC/fvOptions/cellSetOption/cellSetOption.H

Merge request

* Merge request 630

=== 新しい fvOption: マップされたフィールド制約 ===
MapFieldConstraintは、外部メッシュからのソース・フィールドを使用して、<Type>型の指定フィールドに値の制約を課します。ここで、<Type>には{scalar, vector, sphericalTensor, symmTensor, tensor}を指定できます。オプションとして、ソースフィールドは時間経過とともに平行移動または回転させることができます。

考えられる用途は、例えば、移動する電気源の影響をモデル化することである。最小限の使用例を以下に示す：<syntaxhighlight>
MapFieldConstraint1
{
// Mandatory entries
type MapFieldConstraint;
field <word>;
srcMesh <fileName>;
mapMethod <word>;

// Optional entries
consistent <bool>;
patchMapMethod <word>;
transform
{
// Optional entries
position <Function1<vector>>;
origin <vector>;

direction <Function1<vector>>;
normal <vector>;
}

// Conditional entries

// when consistent=false
patchMap <HashTable<word>>; // (<patchSrc> <patchTgt>);
cuttingPatches <wordList>; // (<patchTgt1> ... <patchTgtN>);

// Inherited entries

...
}
</syntaxhighlight>Source code

* $FOAM_SRC/fvOptions/constraints/general/mapFieldConstraint/MapFieldConstraint.H

Merge request

* Merge request 630

=== コミュニティへの貢献：新しい乱流技術委員会サブモジュール ===
OpenFOAMガバナンス内のTurbulence Technical Committeeのネストされたサブモジュールを含む新しいコミュニティサブモジュールが開始されました。このサブモジュールは、公開されている Turbulence Technical Committee のリポジトリでホストされています。

コミュニティ・サブモジュールは、乱流モデリングに関連する学術的・産業的な貢献のホストとして機能し、知識交換の場を作り、この分野とOpenFOAMの両方を発展させるコラボレーションを促進します。

BitbucketやGitHubのようなGitベースのソースコード・リポジトリ・ホスティング・サービスでホストし、このサブモジュールを介してOpenFOAMソフトウェアにリンクすることができます。

このリリースでは、サブモジュールにlibWallModelledLESライブラリーが組み込まれ、壁面モデルによるラージ・エディ・シミュレーション（WMLES）の領域でOpenFOAMの機能が拡張されました。この乱流モデリング手法は、乱流境界層の内部領域の解像度を回避することで、費用対効果の高いLESを可能にします。

Source code

* $WM_PROJECT_DIR/modules/turbulence-community

Attribution

* OpenCFD would like to acknowledge and thank Turbulence Technical Committee members for their contributions and help.

=== 改善されたラグランジュ・ブラウン運動 ===
このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。しかし、特に指定がない限り、（互換性のために）デフォルトの球形分布が引き続き使用されます。

このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。

しかし、特に指定がない限り、適度に小さな時間ステップでは不正確であるにもかかわらず、（互換性のために）デフォルトの球面処理が引き続き使用されます。

三次分布は、球面処理が明示的に無効化されている場合に使用される。例えば<syntaxhighlight>
subModels
{
particleForces
{
sphereDrag;
BrownianMotion
{
lambda 2e-10;
turbulence false;
spherical false;
}
}
...
}
</syntaxhighlight>立方体分布と球形分布の違いは次の図に見られる。

変更の報告、検証、テストはGuanyang Xueの好意によるものである。

Source code

* $FOAM_SRC/lagrangian/turbulence/submodels/Thermodynamic/ParticleForces/BrownianMotion/BrownianMotionForce.H

Issue

* Issue 2922

Merge request 634

== Post-processing ==

=== 新しいAbaqusサンプルセット ===
新しい abaqusMesh セットは、Abaqus メッシュポイント形式を使用してファイルからサンプル位置を導出します。使用例：<syntaxhighlight>
sets
{
cone25 // user-specified set name
{
type abaqusMesh;
file "abaqusMesh.inp";

// Optional entries

// Scale, e.g. mm to m
scale 0.001;

// Search distance when the sample point is not located in a cell
maxDist 0.25;

...
}
}
</syntaxhighlight>Tutorials

* TBA

Source code

* $FOAM_SRC/sampling/sampledSet/abaqus

=== 新しいAbaqusセットライター ===
新しいAbaqusセットライターはOpenFOAMセットデータをAbaqusフォーマットに変換します。使用例<syntaxhighlight>
T
{
type sets;
setFormat abaqus;
fields (T);
sets
{
...
}
}
</syntaxhighlight>オプションの書式オプションは、formatOptions辞書内のabaqusサブ辞書で提供されます：<syntaxhighlight>
formatOptions
{
abaqus
{
format ascii;

// Optional entries

// Custom header: $ entries are substituions
header
(
"** OpenFOAM abaqus output"
"** Project $FOAM_CASE"
"** File $FILE_NAME"
"** $FIELD_NAME Time t=$TIME"
);

// Write geometry in addition to field data
writeGeometry yes;

// Null value when sample value is not found
// Default is scalar::min
nullValue 0;

// Insert additional time sub-directory in the output path
// - yes : postProcessing/<fo-name>/<time>/<file>
// - no : postProcessing/<fo-name>/<file>
useTimeDir no;

// Available when 'useTimeDir' is 'no' to disambiguate file names

// Time base for output file names:
// - 'time' : <base>.inp_<field>.<time>
// - 'iteration' : <base>.inp_<field>.<iteration>
timeBase iteration;

// Optional start counters when using timeBase iteration
writeIndex
(
T 1
);

...
}
}
</syntaxhighlight>Tutorials

* TBA

Source code

* $FOAM_SRC/meshTools/coordSet/writers/abaqus/abaqusCoordSetWriter.C

=== パッチ・シード・セットの改善 ===
patchSeed sampled setがパッチ全体で一様にサンプルシードを計算するようになりました。以前の実装では、顔のインデックスをパッチ全体で一様にサンプリングしていましたが、その副作用として、より小さな顔に偏りがありました。<syntaxhighlight>
streamline5
{
type streamLine;
libs (fieldFunctionObjects);
U U;
fields (U p);
setFormat vtk;
direction forward;
lifeTime 20000;
cloud particleTracks;
seedSampleSet
{
type patchSeed;
axis xyz;
patches ("inlet1");
maxPoints 40;
}
interpolationScheme cellPoint;
trackLength 0.001;
}
</syntaxhighlight>Tutorial

* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike/system/wallBoundedStreamLines

Source code

* $FOAM_SRC/sampling/sampledSet/patchSeed

Merge request

* Merge request 647

=== 新しいケース情報機能オブジェクト ===
新しい caseInfo 関数オブジェクトは、実行時または後処理の一部として、ソルバーとケースの情報を生成します。収集されるデータには以下が含まれます：

* メタデータ：ケース名、パス、タイムディレクトリ数など。
* 辞書エントリ : 任意の入力辞書からすべて/選択したものを抽出
** fvSolutionからUリニアソルバーを取得するには、'solvers/U/solver'などのスコープを使用する。
** はワイルドカードをサポートしている。例えば、fvSolution U ソルバー・キーワードが"(U|k|epsilon) "であった場合。
** include'または'exclude'リストを使用して、含める/除外するエントリ名の選択を制限する。
* メッシュ統計：点、面、セルの数、境界、ゾーン名など。
* 関数オブジェクトの結果：関数オブジェクトの結果のキャッシュ値など

使用例：<syntaxhighlight>
caseInfo1
{
type caseInfo;
libs (utilityFunctionObjects);

writeFormat json; // josn | dictionary

// List of dictionaries - retrieve using 'path' or registered 'name'
dictionaries
{
fvSolution
{
name "fvSolution";

// include all entries by default
}
controlDict
{
path "system/controlDict";
include
(
"application"
"deltaT"
"startTime"
"endTime"
);
}
}

// Extract function object results
functionObjects (pressureDifference sample1);
}
</syntaxhighlight>出力例<syntaxhighlight>
{
"meta" : {
"case" : "heatExchanger",
"path" : "chtMultiRegionSimpleFoam/heatExchanger",
"regions" : ["air", "porous"],
"nTimes" : 7,
"nProc" : 1
},
"regions" : {
"air" : {
"mesh" : {
"nGeometricD" : 3,
"nSolutionD" : 3,
"nPoints" : 252991,
"nFaces" : 739260,
"nCells" : 243000,
"nPatches" : 4,
"pointZones" : [],
"faceZones" : ["rotorBlades", "baffleFaces"],
"cellZones" : ["cylinder", "innerCylinder", "rotor"],
"boundsMin" : [0, 0, 0],
"boundsMax" : [5.000000e-01, 5.000000e-01, 5.000000e-01],
"clouds" : []
},
"boundary" : {
"types" : {
"walls" : "wall",
"inlet" : "patch",
"outlet" : "patch",
"blades" : "wall"
},
"fields" : {
"alphat" : {
"walls" : "compressible::alphatWallFunction",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "compressible::alphatWallFunction"
},
"nut" : {
"walls" : "nutkWallFunction",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "nutkWallFunction"
},
"p" : {
"walls" : "calculated",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "calculated"
...
</syntaxhighlight>Source code

* $FOAM_SRC/functionObjects/utilities/caseInfo

== DMDによる新しい低次モデリング磁場再構成 ==
動的モード分解（DMD）機能は、OpenFOAM v2006で導入され、その後OpenFOAM v2106で拡張されました。このリリースにより、OpenFOAMは、DMDの主な利点の1つである、任意の中間時点や将来の時点におけるCFD計算を必要とせずに、与えられたモードとそれに関連するダイナミクスに基づいて場を生成する機能を習得しました。

この機能により、ユーザーはシミュレーション全体をいくつかのモードとモードダイナミクスに凝縮し、CFD解析を追加することなく、任意の時間における場の生成や将来の状態の予測を行うことができます。

もう一つの潜在的な利点は、ユーザーがシミュレーションを短縮し、大規模なシミュレーションを行うことなく流れ場の将来の状態を予測できることである。これは、より短時間のシミュレーションで得られたモードとモードダイナミクスを使用することで実現できます。

結果の質は、基礎となる縮小モデルの能力と入力データの質に依存することに留意すべきである。再構成結果を改善するためには、流れからモードが正しく抽出されていることを確認する必要がある。

system/ROMfieldsDictを使った最小の例は以下の通り：<syntaxhighlight>
// Mandatory entries
ROMmodel <word>;
field <word>;
object <word>;
deltaT <scalar>;
time <scalar>;
modes <labelList>;
amplitudes <complexList>;
eigenvalues <complexList>;

// Optional entries
startTime <scalar>;
dimensions <dimensionSet>;

// Inherited entries
...
</syntaxhighlight>下の図は、2次元円柱チュートリアルから得られた速度場と、シミュレーションを実行せずにDMDモードとダイナミクスを使用して再構成したものです：

Source code

* $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/createROMfields.C
* $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/ROMmodels/DMD/DMD.H

Tutorial

* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D

References

* Kiewat, M. (2019). Streaming modal decomposition approaches for vehicle aerodynamics. PhD thesis. Munich: Technical University of Munich. URL:mediatum.ub.tum.de/doc/1482652/1482652.pdf

Attribution

* OpenCFD would like to acknowledge and thank Marco Kiewat for his contributions, elaborate suggestions and help, and critical recommendations.

Merge request

* Merge request 639

=== ノイズ・ユーティリティの向上 ===
ノイズユーティリティは、時間情報からのデフォルトの自動計算だけでなく、ユーザー定義のサンプリング周波数（キーワード：sampleFreq）もサポートするようになりました。読みやすさを向上させるため、周波数の上限と下限をminFreqとmaxFreqで指定できるようになりました（以前のキーワードも引き続きサポートされています）。<syntaxhighlight>
// Lower frequency limit, default 25 Hz, former name 'fl'
minFreq 25;

// Upper frequency limit, default 10 kHz, former name 'fu'
maxFreq 10000;

// OPTIONAL - Sample frequency
sampleFreq 100;
</syntaxhighlight>サンプリングされた時間から周波数を計算する際に時間が不均一であると評価された場合、deltaT が非常に小さい場合、不均一性は多くの場合偽のエラーであるため、ユーティリティはエラーではなく警告を発するようになりました。

Source code

* $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
* $FOAM_SRC/randomProcesses/noise/noiseModels/noiseModel/noiseModel.H

Tutorial

* $FOAM_TUTORIALS//incompressible/pimpleFoam/LES/vortexShed

Issue

* Issue 2999

=== エンサイトの出力向上 ===
EnSightライターの時間値は、デフォルトの固定フォーマットと精度を使用する代わりに、ユーザーが指定できるようになりました。例えば<syntaxhighlight>
formatOptions
{
ensight
{
timeFormat general; // Format for time directory names (general | fixed | scientific); default scientific
timePrecision 12; // Default = 5
}
}
</syntaxhighlight>これらの新しいフォーマットオプションは、例えばノイズユーティリティの圧力サンプリングと組み合わせて、小さなタイムステップを使用する場合に特に便利です。

Source code

* $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
* $FOAM_SRC/functionObjects/utilities/ensightWrite/ensightWrite.H

Issue

* Merge request 634

=== 新しいラグランジュ関数オブジェクトウェーバー数 ===
表面張力と比較した粒子の慣性の相対的な重要性を監視するために、ラグランジュ関数オブジェクトWeberNumberが運動学小包に導入されています。

最小限の使用例は以下の通り：<syntaxhighlight>
cloudFunctions
{
KinematicWeberNumber1
{
// Mandatory entries
type WeberNumber;
sigma <scalar>;
}

...
</syntaxhighlight>Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/KinematicWeberNumber/KinematicWeberNumber.H

Tutorial

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk

Merge request

* Merge request 648

=== 空のサーフェス（surfaceFieldValue）の取り扱いが改善されました。 ===
ワークフローによっては、サンプリングされたサーフェスが、シミュレーション中に現れたり消えたりするフェイスゾーンなどの量に依存する場合があります。そのため、空のサーフェスでサーフェスフィールドの値を評価することは、通常、セットアップに重大なエラーがあることを示しますが、このようなことが予想される場合もあります。追加キーワードempty-surfaceにより、空のサーフェスに遭遇したときの動作を指定することができます。

最小限の例：<syntaxhighlight>
surfaceFieldValueFaceZone1
{
type surfaceFieldValue;
libs (fieldFunctionObjects);
...
regionType faceZone;

empty-surface warn; // default | warn | ignore | strict
}
</syntaxhighlight>Source code

* $FOAM_SRC/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.H

Issue

* Issue 2966

== Parallel ==

=== 結合パッチフィールド値の一貫性 ===
結合された制約境界条件、例: プロセッサーとサイクリックは、その内部フィールド値と一致している必要があります。たとえば、プロセッサパッチでは、値フィールドに隣接するプロセッサセルの値が含まれます。つまり、反対側のセルの値がキャッシュされます。他の結合されたパッチフィールドは、ローカルおよび隣接セル値の補間値を値として持つ場合があります。経験則として、セル値を変更するコードはすべて、たとえば、勾配計算では、値の更新を実行するために境界条件を修正する呼び出しを行う必要があります (プロセッサ境界フィールドでのハロースワップに相当します)。ただし、「ローカル」操作の場合、たとえば乗算では、境界条件に値のみがあり、セル値に依存しない場合、これがスキップされることがあります。ほとんどの「通常の」境界条件はこのカテゴリに分類されます。

結合境界条件の場合、プロセッサのパッチフィールドにも適用されますが、たとえば、パッチフィールドには適用されません。環状、環状AMI のバリアント。これにより、中間計算の値が一貫性制約に従わなくなります。

このリリースでは、制約パッチの値がいつでも最新であるように、ローカル操作の後の評価を強制しています。この選択はまだ調査中であり、将来更新される可能性があることに注意してください。

=== patchField の整合性チェックの結合 ===
ビジュアルコードのチェックで、meshWaveメソッドとmeshWaveAddressingメソッドによって返される壁面距離フィールドが平行一貫していないことが確認されました。このようなエラーを発見しやすくするために、オプションで整合性チェックが追加されました：<syntaxhighlight>
DebugSwitches
{
volScalarField::Boundary 1;
volVectorField::Boundary 1;
volSphericalTensorField::Boundary 1;
volSymmTensorField::Boundary 1;
volTensorField::Boundary 1;

areaScalarField::Boundary 1;
areaVectorField::Boundary 1;
areaSphericalTensorField::Boundary 1;
areaSymmTensorField::Boundary 1;
areaTensorField::Boundary 1;
}
</syntaxhighlight>1 を指定するとチェックが有効になり、チェックに失敗すると FatalError が発生する。特に FOAM_ABORT と組み合わせることで、スタックトレースを生成することができます：<syntaxhighlight>
FOAM_ABORT=true mpirun -np 2 simpleFoam -parallel

</syntaxhighlight>デバッグ・スイッチはビットマップとして解釈される：
{| class="wikitable"
!bit
!value(2^bit)
!effect
|-
|0
|1
|ローカル操作ごとにチェックを加える
|-
|1
|2
|プリントの入力と終了をチェックする
|-
|2
|4
|fatalErrorの代わりにwarning
|}
比較の許容誤差はデフォルトで0に設定されている。プロセッサのハロースワップでは、まったく同じ操作がまったく同じ順序で実行されるため、許容誤差の問題はありません。しかし、サイクリックやサイクリックAMIなどの「補間」結合境界条件では、ローカル演算（定数による乗算など）が補間後に実行されるため、若干異なる切り捨て誤差が発生します。この場合、許容誤差をオーバーライドすることができます：<syntaxhighlight>
OptimisationSwitches
{
volScalarField::Boundary::tolerance 1e-10;
// .. and similar for all the other field types ..
}
</syntaxhighlight>

==== 下位互換性 ====
新しい整合性操作は、周期的または周期的AMI境界条件、または結合境界条件を使用する非自明な乱流モデルを使用するケースの動作をわずかに変更します。

オプションとして、etc/controlDictのlocalConsistency設定をオーバーライドすることで、この振る舞いを以前の（一貫性のない！）形に戻すことができる：<syntaxhighlight>
OptimisationSwitches
{
//- Enable enforced consistency of constraint bcs after 'local' operations.
// Default is on. Set to 0/false to revert to <v2306 behaviour
localConsistency 0;
}
</syntaxhighlight>簡単なテストはcyclicAMIパッチを使ったチュートリアル、例えばpipeCyclicチュートリアルです。上記のDebugSwitchでチェックを有効にすると問題なく動作しますが、localConsistencyフラグを無効にすると不整合が検出されます：<syntaxhighlight>
[0] --> FOAM FATAL ERROR: (openfoam-2302 patch=230110)
[0] Field dev(symm(grad(U))) is not evaluated? On patch side1 type cyclicAMI : average of field = ...
</syntaxhighlight>Related issues

* Issue 2783

Source code

* $FOAM_SRC/OpenFOAM/fields/GeometricFields/GeometricField/GeometricBoundaryField.C

Merge request

* Merge request 628

==== ノンブロッキング環状A(C)MI ====
cyclicAMI境界条件は、複数の隣接する面からの面積加重補間を実装します。これらの面はローカルであることも、リモートプロセッサに存在することもあり、並列通信を必要とします。

以前のリリースでは、それぞれのcyclicAMIの評価または線形ソルバーの行列寄与（ローカルでない隣接面の場合）が、独自の通信セットをトリガーし、次のcyclicAMIまたはプロセッサパッチに進む前に、これらの終了を待っていました。このリリースでは、すべての送受信を開始するプロセッサパッチと同様の経路をたどり、ローカル値を更新するためにリモートデータを使用する「消費」フェーズがあります。典型的な境界条件の評価や線形ソルバーの更新は、次のような形になります：

* すべての initEvaluate/initInterfaceMatrixUpdate を行う（結合境界のみ）。プロセッサ、cyclicA(C)MI の場合、これはノンブロッキングの送受信を開始する。
* すべての通信が終了するのを待つ（または、ポーリング（v2306 nPollProcInterfaces）を使用して以下と組み合わせる）。
* すべてのevaluate/updateInterfaceMatrixを行う。これは、受信したデータを使用して、行列解への寄与を計算します。

cyclicA(C)MIからの通信をプロセッサの境界条件とまったく同じ方法で処理することで、ボトルネックが発生する可能性が低くなり、スケーリングが向上することが期待される。さらなる最適化として、ローカル送受信バッファは一度割り当てられ、再利用される。

Source code

* $FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint/cyclicAMI/cyclicAMIFvPatchField.H

Merge request

* Merge request 641

Tutorial

* any case with <code>cyclicAMI</code> or <code>cyclicACMI</code>

==== GAMG : プロセッサ・アグロメレーションにおけるcyclicAMIのサポート ====
GAMGソルバーは、ローカルアグロメレーションに加えて、プロセッサ間で行列を結合することができます（プロセッサアグロメレーション）。これは、コア数が多い場合に有益です：

* 最も粗いレベルを解くコアの数を減らす - 世界的な削減のほとんどは、最も粗いレベルで起こる。
* は、スムージングやプリコンディショニングなど、すべての演算の暗黙性を高める。

このリリースでは、cyclicAMIやcyclicACMIなど、すべての連成境界条件のプロセッサアグロメレーションを可能にするようにフレームワークが拡張されました。

テストとして、以下を比較した。

* 40x10x1のブロック1つ、および
* 2つの20x10x1ブロックがcyclicAMIを使って結合されている。

どちらのケースも4つに分解され、GAMGソルバーとmasterCoarsestプロセッサーのアグロメーターを併用することで、すべての行列がmaster(s)に結合された。<syntaxhighlight>
solvers
{
p
{
solver GAMG;
processorAgglomerator masterCoarsest;
..
}
</syntaxhighlight>

* シングルブロック（つまり、cyclicAMIはなく、プロセッサーフェイスのみ）：
<syntaxhighlight>
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 1.5 2
1 4 50 50 1.5 2
2 1 100 100 0 0
3 1 48 48 0 0
</syntaxhighlight>すべてのプロセッサ面が内部となるため、境界の数（nInterfaces）は0となる。

* 2ブロックの場合（つまり、cyclicAMIとプロセッサフェイス）：
<syntaxhighlight>
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 3 3
1 4 50 50 3 3
2 1 100 100 2 2
3 1 48 48 2 2
</syntaxhighlight>ここでは、2つのcyclicAMIのみが保存されるため、境界の数は3つから2つに減る。

=== Notes ===

* <code>cyclicA(C)MI</code> :
** すべての面がローカルになると、動作は非分散にリセットされる。つまり、操作は追加のコピーなしで、提供されたフィールドに直接適用される。
** 回転変換はまだサポートされていません。これは基本的な制限ではありませんが、変換を考慮するためにステンシルを追加で書き換える必要があります。
* processorCyclic : (オーナーセルと隣接セルが異なるプロセッサ上にあるサイクリック) はまだサポートされていない。これは通常のプロセッサ境界として扱われるため、変換は失われる。processorCyclicはdecomposeParDictでパッチ制約を使うことで回避できることに注意。
<syntaxhighlight>
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (cyclic);
}
}
</syntaxhighlight>

* masterCoarsestのみがテストされているが、コードは他のどのプロセッサー凝集法もサポートするはずである。
* これまでの限られたテストでは、cyclicAMIのプロセッサー集積の利点は示されていない。これは、ボトルネック、例えば、大域的削減の数や暗黙性が問題となる場合にのみ有効である。

Source code

* $FOAM_SRC/OpenFOAM/meshes/lduMesh/lduPrimitiveMesh.C

Merge request

* Merge request 645

=== redistributeParとファイルシステムの改良 ===
このリリースでは、照合ファイル・フォーマットの一般的なサポートが改善され、redistributeParユーティリティの調整も行われました。これらの変更により、照合ファイル形式は以前よりも幅広いワークフローで使用できるようになりました。

これらの変更に加え、分散ファイルシステムによるダイナミックコードの取り扱いが改善された。このようなタイプのシステムでは、動的にコンパイルされたライブラリも対応するサブランクに配布されるようになった。

==== 照合されたインクルードファイルの取り扱いが改善された ====
以前のバージョンでは、"include "ファイルを照合と組み合わせて使用すると、ファイルの内容がランタイムで変更可能なものとして扱われる場合、非常に壊れやすいことがあった。今回、ウォッチド・ファイルの取り扱いが更新され、プロセッサー・ランク間の適切な対応が保証されるようになった。

== Usability ==

=== New verification and validation public repository ===
OpenFOAMソフトウェアの検証と妥当性確認に関するコミュニティへの貢献をホストする新しいパブリックリポジトリが開設されました： OpenFOAM Verification and Validation Repository。

このリポジトリの主な目的は、OpenFOAMコミュニティがソフトウェアの検証と検証の側面を共有、協力、強化するための一元化されたプラットフォームを提供することです。コミュニティの集合的な知識と専門知識を結集することにより、OpenFOAMシミュレーションの全体的な品質を向上させ、数値モデリングのベストプラクティスを推進することを目指しています。

このリリースでは、Taylor-Green渦問題と円形Couette流れが組み込まれ、ケースのセットアップとドキュメンテーションのために提供されたテンプレートの実用的な応用が示されています。

=== コンピレーション ===

=== General ===
OpenFOAMで使用されるC++標準は、GNUコンパイラでもc++14になりました。この変更により、推奨コンパイラの最小バージョンはgcc-7.5.0になりました。

将来のコード移行を支援するため、「より厳しい」非推奨警告を有効にできるようになりました。これは WM_COMPILE_CONTROL 環境変数の +strict エントリでグローバルに、または wmake -strict で一度だけ有効にできます。これは主に開発者向けのオプションと考えることができます（多くの警告を生成する可能性があります）が、モジュールを書くときに便利で面白いかもしれません。

=== MacOS ===
このバージョンには、MacOS上でのコンパイルと実行に関するいくつかの改良が含まれています。

* AppleとARM64のFPE処理の改善（Guanyang Xue氏提供）
* rpathハンドリング
* xcrun サポート

MacOS のコンパイルでは、rpath のサポートがデフォルトで有効になり、Apple SIP (System Integrity Protection) の影響に対する回避策がいくらか減って、これらのシステムでの OpenFOAM の実行が簡単になりました。WM_COMPILE_CONTROL環境変数に~rpathを追加することで、rpath処理を無効にできます。

MacOSコンパイルでは、xcodeツール（xcrunなど）の使用もサポートするようになりました。これらはWM_COMPILE_CONTROL環境変数に+xcrunを追加することで有効になります。見つかると、これらのコンパイル・ルールが使用されます：<syntaxhighlight>
cc := xcrun cc
CC := xcrun c++ -std=c++14
</syntaxhighlight>

=== Clang ===
clangベースのコンパイルで、ldリンカを使用するように明示的に指定できるようになりました（注意：clangがldを使用するかlldを使用するかはインストールに依存します）。リンカの選択は環境変数 WM_COMPILE_CONTROL の対応するエントリで定義されます：<syntaxhighlight>
- `+gold` : use gold linker
- `+link-ld` : use ld linker
- `+lld` : use lld linker
- `+mold` : use mold linker
</syntaxhighlight>

=== OpenMP ===
openmp と no-openmp の扱いが強化された。"+openmp" (wmake -openmp) よりも "~openmp" (wmake -no-openmp) の方が優先されます。

これにより、一般的に+openmpを指定する場合はrobusterとなり、特定のビルド・コンポーネント（スタティック・ライブラリやMPIブリッジ・コードなど）を指定する場合は~openmpとなる。

=== Profiling ===
このバージョンには、Extraeプロファイリング用のフックが含まれています。デフォルトでは、フックは常にOpenFOAMと一緒にビルドされますが、LD_PRELOADによってExtraeが実際にロードされるまで休止しています。これにより、OpenFOAMをその目的専用に再コンパイルすることなく、Extraeのトレースが可能になります。

Josep Pocurull（Barcelona Supercomputing Center）により提供され、exaFOAMプロジェクトの一部として使用されたコード。

Source code

* $FOAM_SRC/OpenFOAM/global/profiling/profilingTrigger.C

Merge request

* Merge request 652

OpenFOAM v2312リリースノート

2023-12-24T08:08:36Z

Mmer547: ページの作成:「OpenCFDは、2023年12月リリースのOpenFOAM® v2312を発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v2306の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。 OpenFOAMはOpenCFDによってGPLライセンスの下で配布されてい…」

OpenCFDは、2023年12月リリースのOpenFOAM® v2312を発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v2306の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージも多数あります。

Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール

openSUSE Linux: Leap 15.5 用パッケージインストール

Redhat Linuxの亜種: epel 9用のパッケージインストール; Fedora 37

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢があります（詳細）：

Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。

クロスコンパイルによるネイティブ実行ファイル

docker インストール

OpenFOAMのapptainerサポートは、事前にアセンブルされたイメージではなく、記述ファイルによって提供されます：

パッケージング/コンテナ参照

Mac OSXユーザーは、ソースからコンパイルするか、Dockerコンテナを使ってコンパイル済みのパッケージを使用するオプションがあります（詳細）。

== Pre-processing ==

=== snappyHexMesh：自動リークパスクロージャーから面を書き込む ===
snappyHexMeshにはメッシュ内の任意の位置とメッシュ外の位置の間のパスとして定義されたサーフェスのリークを自動的に閉じるオプションがあります。このリリースではリークを閉じるために使用された面はpostProcessingディレクトリのファイルに書き込まれます。

下図は、ギャップのある球体（灰色）、スナップされたメッシュライン（青）、リークを閉じる面（赤）からなるテストケースを示しています：

ファイル書き込みフォーマットはsnappyHexMeshDictの新しいエントリーで選択できます：<syntaxhighlight>
//// Format for writing lines. E.g. leak path. Default is vtk format.
//setFormat ensight;

//// Format to use for surfaces. E.g. leak-closure faces. Default is vtk format.
//surfaceFormat vtk;
</syntaxhighlight>Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_gapClosure

Source code

* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C

=== snappyHexMesh：新しい複数の内側ポイント ===
snappyHexMeshのセルゾーンはinsidePointを指定することで作成できます：<syntaxhighlight>
refinementSurfaces
{
..
cellZoneInside insidePoint; // outside/insidePoint
insidePoint (1 1 1); // if (cellZoneInside == insidePoint)
}
</syntaxhighlight>1つのinsidePointではなく、複数のinsidePointが用意された：<syntaxhighlight>
cellZoneInside insidePoints; // outside/insidePoint
insidePoints ((1 1 1)); // if (cellZoneInside == insidePoint)
</syntaxhighlight>下の図では、ジオメトリは2つのボックス（ワイヤーフレーム）で構成され、上のボックスは2つの切り離されたメッシュ領域をカバーしている。赤で示されたセルゾーンは、3つの別々のメッシュ領域を使用して作成されています。checkMeshユーティリティは、切断されたリージョンを表示するために使うことができます。

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/insidePoints

Source code

* $FOAM_SRC/mesh/snappyHexMesh/refinementSurfaces/surfaceZonesInfo.H

=== snappyHexMesh：並列メッシュの負荷分散 ===
snappyHexMeshは並列実行時に自動的にメッシュのバランスをとることができます。それは以下のどちらかになります

* 変更が小さすぎる場合はバランスを取らない - maxLoadUnbalanceまたはmaxCellUnbalance設定を参照。
* maxLocalCells設定を参照してください。

このリリースでは、各ステップでメッシュのアンバランスがプリントされます：<syntaxhighlight>
Layer mesh : cells:353749 faces:1108448 points:406303 unbalance:0.00110248

</syntaxhighlight>精製前のバランスは、セルの重みを与えることで実装されることに注意。各精製されるセルは8ずつカウントされる。しかし、これは単純な分解法、例えば階層的な分解法にのみ有効である。scotch と KaHip メソッドでは、カット数を含む重みを使ってアンバランスを最小化する。

Tutorials

* any parallel snappyHexMesh case

Source code

* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C
* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

Related issues

* Issue 3034

=== snappyHexMesh：レイヤーごとの追加 ===
OpenFOAM v2206リリースでは、snappyHexMeshが拡張され、nOuterIterエントリーを使用して複数パスでレイヤーを追加できるようになりました。ここでは、$FOAM_TUTORIALS/incompressible/pisoFoam/LES/motorBike/motorBikeチュートリアルを出発点として、どのように改良されたレイヤーの追加を実行できるかをデモしたいと思います：<syntaxhighlight>
relativeSizes false; // true

// Per final patch (so not geometry!) the layer information
layers
{
"(lowerWall|motorBike).*"
{
nSurfaceLayers 16;
}
}

// Expansion factor for layer mesh
expansionRatio 1.2;
</syntaxhighlight>重要な設定は、外側の反復回数とメッシュ・モーション・ソルバーである：<syntaxhighlight>
// Overall max number of layer addition iterations
nLayerIter 25;

// Add layers in multiple passes - gives layers a chance to rotate
nOuterIter 4;

meshShrinker displacementMotionSolver;
solver displacementLaplacian;
displacementLaplacianCoeffs
{
diffusivity quadratic inverseDistance (lowerWall upperWall "motorBike*")
}
</syntaxhighlight>メッシュの品質基準を緩めることで、（全体的なメッシュ品質は維持したまま）この複雑な形状でもレイヤーカバレッジを劇的に向上させることができる。

Tutorials

* $FOAM_TUTORIALS/mesh/snappyHexMesh/addLayersToFaceZone

Source code

* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

=== Nastranサーフェスリーダーの改良 ===
NASTRANパーサーが更新され、PSHELL名の新しいANSA規約に対応しました。これにより、snappyHexMeshなど、より多くの場所でNASTRANファイルを直接使用することができるようになりました。

Source code

* $FOAM_SRC/surfMesh/surfaceFormats/nas/NASsurfaceFormat.C

Issue

* Issue 3009

=== checkMeshユーティリティの改良 ===
checkMesh ユーティリティに writeChecks オプションが追加されました：<syntaxhighlight>
checkMesh -writeChecks <format>

</syntaxhighlight>これにより、メッシュ・チェックのフォーマットを含むファイルが生成される：

* dictionary : OpenFOAM dictionary;
* json : JSON format.

例えば、コマンドを使う：<syntaxhighlight>
checkMesh -allGeometry -allTopology -writeChecks JSON

</syntaxhighlight>motorBikeチュートリアルでは、caseディレクトリにcheckMesh.jsonファイルが生成される：<syntaxhighlight>
{
"maxNonOrth" : 64.9999,
"aveNonOrth" : 9.92427,
"maxSkew" : 9.25719,
"nWarnSkew" : 12,
"minDeterminant" : 0,
"aveDeterminant" : 1.55371,
"thresholdDeterminant" : 0.001,
"nErrorDeterminant" : 1274,
"minFaceWeight" : 0.0216708,
"aveFaceWeight" : 0.465687,
"thresholdFaceWeight" : 0.05,
"nErrorFaceWeight" : 1143,
"minFaceVolumeRatio" : 0.0101126,
"aveFaceVolumeRatio" : 0.846049
}
</syntaxhighlight>Source code

* $FOAM_UTILITIES/mesh/manipulation/checkMesh/checkMesh.C

=== subsetMeshユーティリティの改良 ===
subsetMesh ユーティリティが更新され、通常の -patches 選択を変更する -exclude-patches オプションを受け付けるようになりました。

この変更により、最も近い露出パッチの指定が簡単になりました。

== Numerics ==

=== コミュニティへの貢献随伴形状最適化の改善 ===
形状最適化のための感度微分を計算するためのE-SIとFI定式化間の整合性が改善されました。naca0012/laminar/moment/primalAdjointチュートリアルから取得した、変更前後のコード動作の例を以下に示します：

一貫した点／面の感度マップ

v2306とv2312で計算されたドラッグ感度マップを比較すると、a)新しいポイント-フェイス補間は、生の、つまり平滑化されていない感度でも、より滑らかな結果を生成する。

さらなる改善点は以下の通り：

* 不必要に新しいアドジョイントフィールドを割り当てることなく幾何学的制約を定義するための新しいアドジョイントソルバ（null）と目的関数（geometric）タイプ

* 不等式制約のある最適化問題に取り組むための3つの新しい更新法（ISQP, nullSpace, MMA）
* 設計変数に境界を導入。ボリューメトリックBスプラインの場合、最適化を通してメッシュの品質をより良く保つことができます。
* 最適化ループの収束基準の導入。

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/laminar/multipleConstraints

Guide

* The updated user guide for v2312 can be found here

Source code

* Merge request MR!649
* Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
* Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

* The software was developed by PCOpt/NTUA and FOSS GP
* Integration in collaboration with OpenCFD

=== コミュニティへの貢献トポロジーに基づく新しいアジョイント最適化 ===
OpenFOAM v2312では、空隙率ベースまたはレベルセットアプローチによる新しいトポロジー最適化機能が追加されました。どちらも、設計されたジオメトリをSTLとしてエクスポートする機能を備えており、製造やボディフィットグリッドによる再評価に利用できます。

空隙率ベースのアプローチは、計算領域の非生産的な部分を固めることでブロックする設計変数の場（人工空隙率α）に依存する。得られた解の平滑性を高めるために、正則化方程式を解いて中間場α̃を計算し、次にシャープニング/プロジェクションステップを経てほぼ二値の場βを計算します。後者は、固化した領域（すなわちβ≈1の領域）で流れ解をゼロにするソース項を流れ方程式に導入するために使用されます。上記のプロセスの手順を以下に示す。

次の表は、同じケースの3つの異なるバリエーション、すなわち、Jpt＜Jpttarget制約（右）の下で、総圧力損失（Jpt）の最小化（左）、下部出口と右出口間の体積流量の均等配分制約（Jm）を伴うJptの最小化（中央）、および流れの均一性（Jun）の最大化（右）に対するトポロジー最適化の結果を示している。

ケースは、adjointOptimisationFoam/topologyOptimisation/monoFluidAero/turbulent/1_Inlet_2_Outlet/porosityBased/BPにあります。

次の表は、同様の目的関数と制約関数を持つ3次元多様体のトポロジー最適化の結果を示しています。最初の行は、最適化サイクル中の計算領域の流体部分と固体部分の境界の進行を示し、最後の行は、最適化された3つの形状のSTLファイルを示しています。後者の生成プロセスは自動化されており、各最適化サイクルの終了時に実行されます。これらのSTLファイルは、適切な境界条件によるボディフィットシミュレーションや、その後の形状最適化、さらには製造に使用することができます。

ケースはtopologyOptimisation/monoFluidAero/laminar/3DBoxにあります。

==== 下位互換性 ====
optimisationDict.optimisationの項目が少し変わりました。この変更は、例えば、$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/motorBikeのoptimisationDictを以前のものと比較することで確認できます。

Tutorials

* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation

Guide

* The updated user guide for v2312 can be found here

Source code

* Merge request MR!649
* Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
* Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

* The software was developed by PCOpt/NTUA and FOSS GP
* Integration in collaboration with OpenCFD

== Solvers and physical models ==

=== fvOptionsの改良：ポイントの移動 ===
有限体積オプション（fvOptions）フレームワークが改良されました：

* 入力辞書の更新により、セル選択を実行時に更新できるようになりました。
* 空間内を移動する点をモデル化する新しい方法。

最小限の使用例は以下の通り：<syntaxhighlight>
fvOption1
{
// Optional entries
updateSelection true;

...
}

fvOption2
{
// Mandatory entries
selectionMode movingPoints;

movingPoints
{
point1 table
(
// time position
( 0 (0 0 0.75))
( 1 (0 0 0.65))
( 2 (0 0 0.55))
( 3 (0 0 0.45))
( 4 (0 0 0.35))
( 5 (0 0 0.25))
);

point2 (-0.25 -0.25 0.5);
}

...
}
</syntaxhighlight>Source code

* $FOAM_SRC/fvOptions/cellSetOption/cellSetOption.H

Merge request

* Merge request 630

=== 新しい fvOption: マップされたフィールド制約 ===
MapFieldConstraintは、外部メッシュからのソース・フィールドを使用して、<Type>型の指定フィールドに値の制約を課します。ここで、<Type>には{scalar, vector, sphericalTensor, symmTensor, tensor}を指定できます。オプションとして、ソースフィールドは時間経過とともに平行移動または回転させることができます。

考えられる用途は、例えば、移動する電気源の影響をモデル化することである。最小限の使用例を以下に示す：<syntaxhighlight>
MapFieldConstraint1
{
// Mandatory entries
type MapFieldConstraint;
field <word>;
srcMesh <fileName>;
mapMethod <word>;

// Optional entries
consistent <bool>;
patchMapMethod <word>;
transform
{
// Optional entries
position <Function1<vector>>;
origin <vector>;

direction <Function1<vector>>;
normal <vector>;
}

// Conditional entries

// when consistent=false
patchMap <HashTable<word>>; // (<patchSrc> <patchTgt>);
cuttingPatches <wordList>; // (<patchTgt1> ... <patchTgtN>);

// Inherited entries

...
}
</syntaxhighlight>Source code

* $FOAM_SRC/fvOptions/constraints/general/mapFieldConstraint/MapFieldConstraint.H

Merge request

* Merge request 630

=== コミュニティへの貢献：新しい乱流技術委員会サブモジュール ===
OpenFOAMガバナンス内のTurbulence Technical Committeeのネストされたサブモジュールを含む新しいコミュニティサブモジュールが開始されました。このサブモジュールは、公開されている Turbulence Technical Committee のリポジトリでホストされています。

コミュニティ・サブモジュールは、乱流モデリングに関連する学術的・産業的な貢献のホストとして機能し、知識交換の場を作り、この分野とOpenFOAMの両方を発展させるコラボレーションを促進します。

BitbucketやGitHubのようなGitベースのソースコード・リポジトリ・ホスティング・サービスでホストし、このサブモジュールを介してOpenFOAMソフトウェアにリンクすることができます。

このリリースでは、サブモジュールにlibWallModelledLESライブラリーが組み込まれ、壁面モデルによるラージ・エディ・シミュレーション（WMLES）の領域でOpenFOAMの機能が拡張されました。この乱流モデリング手法は、乱流境界層の内部領域の解像度を回避することで、費用対効果の高いLESを可能にします。

Source code

* $WM_PROJECT_DIR/modules/turbulence-community

Attribution

* OpenCFD would like to acknowledge and thank Turbulence Technical Committee members for their contributions and help.

=== 改善されたラグランジュ・ブラウン運動 ===
このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。しかし、特に指定がない限り、（互換性のために）デフォルトの球形分布が引き続き使用されます。

このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。

しかし、特に指定がない限り、適度に小さな時間ステップでは不正確であるにもかかわらず、（互換性のために）デフォルトの球面処理が引き続き使用されます。

三次分布は、球面処理が明示的に無効化されている場合に使用される。例えば<syntaxhighlight>
subModels
{
particleForces
{
sphereDrag;
BrownianMotion
{
lambda 2e-10;
turbulence false;
spherical false;
}
}
...
}
</syntaxhighlight>立方体分布と球形分布の違いは次の図に見られる。

変更の報告、検証、テストはGuanyang Xueの好意によるものである。

Source code

* $FOAM_SRC/lagrangian/turbulence/submodels/Thermodynamic/ParticleForces/BrownianMotion/BrownianMotionForce.H

Issue

* Issue 2922

Merge request 634

== Post-processing ==

=== 新しいAbaqusサンプルセット ===
新しい abaqusMesh セットは、Abaqus メッシュポイント形式を使用してファイルからサンプル位置を導出します。使用例：<syntaxhighlight>
sets
{
cone25 // user-specified set name
{
type abaqusMesh;
file "abaqusMesh.inp";

// Optional entries

// Scale, e.g. mm to m
scale 0.001;

// Search distance when the sample point is not located in a cell
maxDist 0.25;

...
}
}
</syntaxhighlight>Tutorials

* TBA

Source code

* $FOAM_SRC/sampling/sampledSet/abaqus

=== 新しいAbaqusセットライター ===
新しいAbaqusセットライターはOpenFOAMセットデータをAbaqusフォーマットに変換します。使用例<syntaxhighlight>
T
{
type sets;
setFormat abaqus;
fields (T);
sets
{
...
}
}
</syntaxhighlight>オプションの書式オプションは、formatOptions辞書内のabaqusサブ辞書で提供されます：<syntaxhighlight>
formatOptions
{
abaqus
{
format ascii;

// Optional entries

// Custom header: $ entries are substituions
header
(
"** OpenFOAM abaqus output"
"** Project $FOAM_CASE"
"** File $FILE_NAME"
"** $FIELD_NAME Time t=$TIME"
);

// Write geometry in addition to field data
writeGeometry yes;

// Null value when sample value is not found
// Default is scalar::min
nullValue 0;

// Insert additional time sub-directory in the output path
// - yes : postProcessing/<fo-name>/<time>/<file>
// - no : postProcessing/<fo-name>/<file>
useTimeDir no;

// Available when 'useTimeDir' is 'no' to disambiguate file names

// Time base for output file names:
// - 'time' : <base>.inp_<field>.<time>
// - 'iteration' : <base>.inp_<field>.<iteration>
timeBase iteration;

// Optional start counters when using timeBase iteration
writeIndex
(
T 1
);

...
}
}
</syntaxhighlight>Tutorials

* TBA

Source code

* $FOAM_SRC/meshTools/coordSet/writers/abaqus/abaqusCoordSetWriter.C

=== パッチ・シード・セットの改善 ===
patchSeed sampled setがパッチ全体で一様にサンプルシードを計算するようになりました。以前の実装では、顔のインデックスをパッチ全体で一様にサンプリングしていましたが、その副作用として、より小さな顔に偏りがありました。<syntaxhighlight>
streamline5
{
type streamLine;
libs (fieldFunctionObjects);
U U;
fields (U p);
setFormat vtk;
direction forward;
lifeTime 20000;
cloud particleTracks;
seedSampleSet
{
type patchSeed;
axis xyz;
patches ("inlet1");
maxPoints 40;
}
interpolationScheme cellPoint;
trackLength 0.001;
}
</syntaxhighlight>Tutorial

* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike/system/wallBoundedStreamLines

Source code

* $FOAM_SRC/sampling/sampledSet/patchSeed

Merge request

* Merge request 647

=== 新しいケース情報機能オブジェクト ===
新しい caseInfo 関数オブジェクトは、実行時または後処理の一部として、ソルバーとケースの情報を生成します。収集されるデータには以下が含まれます：

* メタデータ：ケース名、パス、タイムディレクトリ数など。
* 辞書エントリ : 任意の入力辞書からすべて/選択したものを抽出
** fvSolutionからUリニアソルバーを取得するには、'solvers/U/solver'などのスコープを使用する。
** はワイルドカードをサポートしている。例えば、fvSolution U ソルバー・キーワードが"(U|k|epsilon) "であった場合。
** include'または'exclude'リストを使用して、含める/除外するエントリ名の選択を制限する。
* メッシュ統計：点、面、セルの数、境界、ゾーン名など。
* 関数オブジェクトの結果：関数オブジェクトの結果のキャッシュ値など

使用例：<syntaxhighlight>
caseInfo1
{
type caseInfo;
libs (utilityFunctionObjects);

writeFormat json; // josn | dictionary

// List of dictionaries - retrieve using 'path' or registered 'name'
dictionaries
{
fvSolution
{
name "fvSolution";

// include all entries by default
}
controlDict
{
path "system/controlDict";
include
(
"application"
"deltaT"
"startTime"
"endTime"
);
}
}

// Extract function object results
functionObjects (pressureDifference sample1);
}
</syntaxhighlight>出力例<syntaxhighlight>
{
"meta" : {
"case" : "heatExchanger",
"path" : "chtMultiRegionSimpleFoam/heatExchanger",
"regions" : ["air", "porous"],
"nTimes" : 7,
"nProc" : 1
},
"regions" : {
"air" : {
"mesh" : {
"nGeometricD" : 3,
"nSolutionD" : 3,
"nPoints" : 252991,
"nFaces" : 739260,
"nCells" : 243000,
"nPatches" : 4,
"pointZones" : [],
"faceZones" : ["rotorBlades", "baffleFaces"],
"cellZones" : ["cylinder", "innerCylinder", "rotor"],
"boundsMin" : [0, 0, 0],
"boundsMax" : [5.000000e-01, 5.000000e-01, 5.000000e-01],
"clouds" : []
},
"boundary" : {
"types" : {
"walls" : "wall",
"inlet" : "patch",
"outlet" : "patch",
"blades" : "wall"
},
"fields" : {
"alphat" : {
"walls" : "compressible::alphatWallFunction",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "compressible::alphatWallFunction"
},
"nut" : {
"walls" : "nutkWallFunction",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "nutkWallFunction"
},
"p" : {
"walls" : "calculated",
"inlet" : "calculated",
"outlet" : "calculated",
"blades" : "calculated"
...
</syntaxhighlight>Source code

* $FOAM_SRC/functionObjects/utilities/caseInfo

== DMDによる新しい低次モデリング磁場再構成 ==
動的モード分解（DMD）機能は、OpenFOAM v2006で導入され、その後OpenFOAM v2106で拡張されました。このリリースにより、OpenFOAMは、DMDの主な利点の1つである、任意の中間時点や将来の時点におけるCFD計算を必要とせずに、与えられたモードとそれに関連するダイナミクスに基づいて場を生成する機能を習得しました。

この機能により、ユーザーはシミュレーション全体をいくつかのモードとモードダイナミクスに凝縮し、CFD解析を追加することなく、任意の時間における場の生成や将来の状態の予測を行うことができます。

もう一つの潜在的な利点は、ユーザーがシミュレーションを短縮し、大規模なシミュレーションを行うことなく流れ場の将来の状態を予測できることである。これは、より短時間のシミュレーションで得られたモードとモードダイナミクスを使用することで実現できます。

結果の質は、基礎となる縮小モデルの能力と入力データの質に依存することに留意すべきである。再構成結果を改善するためには、流れからモードが正しく抽出されていることを確認する必要がある。

system/ROMfieldsDictを使った最小の例は以下の通り：<syntaxhighlight>
// Mandatory entries
ROMmodel <word>;
field <word>;
object <word>;
deltaT <scalar>;
time <scalar>;
modes <labelList>;
amplitudes <complexList>;
eigenvalues <complexList>;

// Optional entries
startTime <scalar>;
dimensions <dimensionSet>;

// Inherited entries
...
</syntaxhighlight>下の図は、2次元円柱チュートリアルから得られた速度場と、シミュレーションを実行せずにDMDモードとダイナミクスを使用して再構成したものです：

Source code

* $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/createROMfields.C
* $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/ROMmodels/DMD/DMD.H

Tutorial

* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D

References

* Kiewat, M. (2019). Streaming modal decomposition approaches for vehicle aerodynamics. PhD thesis. Munich: Technical University of Munich. URL:mediatum.ub.tum.de/doc/1482652/1482652.pdf

Attribution

* OpenCFD would like to acknowledge and thank Marco Kiewat for his contributions, elaborate suggestions and help, and critical recommendations.

Merge request

* Merge request 639

=== ノイズ・ユーティリティの向上 ===
ノイズユーティリティは、時間情報からのデフォルトの自動計算だけでなく、ユーザー定義のサンプリング周波数（キーワード：sampleFreq）もサポートするようになりました。読みやすさを向上させるため、周波数の上限と下限をminFreqとmaxFreqで指定できるようになりました（以前のキーワードも引き続きサポートされています）。<syntaxhighlight>
// Lower frequency limit, default 25 Hz, former name 'fl'
minFreq 25;

// Upper frequency limit, default 10 kHz, former name 'fu'
maxFreq 10000;

// OPTIONAL - Sample frequency
sampleFreq 100;
</syntaxhighlight>サンプリングされた時間から周波数を計算する際に時間が不均一であると評価された場合、deltaT が非常に小さい場合、不均一性は多くの場合偽のエラーであるため、ユーティリティはエラーではなく警告を発するようになりました。

Source code

* $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
* $FOAM_SRC/randomProcesses/noise/noiseModels/noiseModel/noiseModel.H

Tutorial

* $FOAM_TUTORIALS//incompressible/pimpleFoam/LES/vortexShed

Issue

* Issue 2999

=== エンサイトの出力向上 ===
EnSightライターの時間値は、デフォルトの固定フォーマットと精度を使用する代わりに、ユーザーが指定できるようになりました。例えば<syntaxhighlight>
formatOptions
{
ensight
{
timeFormat general; // Format for time directory names (general | fixed | scientific); default scientific
timePrecision 12; // Default = 5
}
}
</syntaxhighlight>これらの新しいフォーマットオプションは、例えばノイズユーティリティの圧力サンプリングと組み合わせて、小さなタイムステップを使用する場合に特に便利です。

Source code

* $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
* $FOAM_SRC/functionObjects/utilities/ensightWrite/ensightWrite.H

Issue

* Merge request 634

=== 新しいラグランジュ関数オブジェクトウェーバー数 ===
表面張力と比較した粒子の慣性の相対的な重要性を監視するために、ラグランジュ関数オブジェクトWeberNumberが運動学小包に導入されています。

最小限の使用例は以下の通り：<syntaxhighlight>
cloudFunctions
{
KinematicWeberNumber1
{
// Mandatory entries
type WeberNumber;
sigma <scalar>;
}

...
</syntaxhighlight>Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/KinematicWeberNumber/KinematicWeberNumber.H

Tutorial

* $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk

Merge request

* Merge request 648

=== 空のサーフェス（surfaceFieldValue）の取り扱いが改善されました。 ===
ワークフローによっては、サンプリングされたサーフェスが、シミュレーション中に現れたり消えたりするフェイスゾーンなどの量に依存する場合があります。そのため、空のサーフェスでサーフェスフィールドの値を評価することは、通常、セットアップに重大なエラーがあることを示しますが、このようなことが予想される場合もあります。追加キーワードempty-surfaceにより、空のサーフェスに遭遇したときの動作を指定することができます。

最小限の例：<syntaxhighlight>
surfaceFieldValueFaceZone1
{
type surfaceFieldValue;
libs (fieldFunctionObjects);
...
regionType faceZone;

empty-surface warn; // default | warn | ignore | strict
}
</syntaxhighlight>Source code

* $FOAM_SRC/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.H

Issue

* Issue 2966

== Parallel ==

=== 結合パッチフィールド値の一貫性 ===
結合された制約境界条件、例: プロセッサーとサイクリックは、その内部フィールド値と一致している必要があります。たとえば、プロセッサパッチでは、値フィールドに隣接するプロセッサセルの値が含まれます。つまり、反対側のセルの値がキャッシュされます。他の結合されたパッチフィールドは、ローカルおよび隣接セル値の補間値を値として持つ場合があります。経験則として、セル値を変更するコードはすべて、たとえば、勾配計算では、値の更新を実行するために境界条件を修正する呼び出しを行う必要があります (プロセッサ境界フィールドでのハロースワップに相当します)。ただし、「ローカル」操作の場合、たとえば乗算では、境界条件に値のみがあり、セル値に依存しない場合、これがスキップされることがあります。ほとんどの「通常の」境界条件はこのカテゴリに分類されます。

結合境界条件の場合、プロセッサのパッチフィールドにも適用されますが、たとえば、パッチフィールドには適用されません。環状、環状AMI のバリアント。これにより、中間計算の値が一貫性制約に従わなくなります。

このリリースでは、制約パッチの値がいつでも最新であるように、ローカル操作の後の評価を強制しています。この選択はまだ調査中であり、将来更新される可能性があることに注意してください。

=== patchField の整合性チェックの結合 ===
ビジュアルコードのチェックで、meshWaveメソッドとmeshWaveAddressingメソッドによって返される壁面距離フィールドが平行一貫していないことが確認されました。このようなエラーを発見しやすくするために、オプションで整合性チェックが追加されました：<syntaxhighlight>
DebugSwitches
{
volScalarField::Boundary 1;
volVectorField::Boundary 1;
volSphericalTensorField::Boundary 1;
volSymmTensorField::Boundary 1;
volTensorField::Boundary 1;

areaScalarField::Boundary 1;
areaVectorField::Boundary 1;
areaSphericalTensorField::Boundary 1;
areaSymmTensorField::Boundary 1;
areaTensorField::Boundary 1;
}
</syntaxhighlight>1 を指定するとチェックが有効になり、チェックに失敗すると FatalError が発生する。特に FOAM_ABORT と組み合わせることで、スタックトレースを生成することができます：<syntaxhighlight>
FOAM_ABORT=true mpirun -np 2 simpleFoam -parallel

</syntaxhighlight>デバッグ・スイッチはビットマップとして解釈される：
{| class="wikitable"
!bit
!value(2^bit)
!effect
|-
|0
|1
|ローカル操作ごとにチェックを加える
|-
|1
|2
|プリントの入力と終了をチェックする
|-
|2
|4
|fatalErrorの代わりにwarning
|}
比較の許容誤差はデフォルトで0に設定されている。プロセッサのハロースワップでは、まったく同じ操作がまったく同じ順序で実行されるため、許容誤差の問題はありません。しかし、サイクリックやサイクリックAMIなどの「補間」結合境界条件では、ローカル演算（定数による乗算など）が補間後に実行されるため、若干異なる切り捨て誤差が発生します。この場合、許容誤差をオーバーライドすることができます：<syntaxhighlight>
OptimisationSwitches
{
volScalarField::Boundary::tolerance 1e-10;
// .. and similar for all the other field types ..
}
</syntaxhighlight>

==== 下位互換性 ====
新しい整合性操作は、周期的または周期的AMI境界条件、または結合境界条件を使用する非自明な乱流モデルを使用するケースの動作をわずかに変更します。

オプションとして、etc/controlDictのlocalConsistency設定をオーバーライドすることで、この振る舞いを以前の（一貫性のない！）形に戻すことができる：<syntaxhighlight>
OptimisationSwitches
{
//- Enable enforced consistency of constraint bcs after 'local' operations.
// Default is on. Set to 0/false to revert to <v2306 behaviour
localConsistency 0;
}
</syntaxhighlight>簡単なテストはcyclicAMIパッチを使ったチュートリアル、例えばpipeCyclicチュートリアルです。上記のDebugSwitchでチェックを有効にすると問題なく動作しますが、localConsistencyフラグを無効にすると不整合が検出されます：<syntaxhighlight>
[0] --> FOAM FATAL ERROR: (openfoam-2302 patch=230110)
[0] Field dev(symm(grad(U))) is not evaluated? On patch side1 type cyclicAMI : average of field = ...
</syntaxhighlight>Related issues

* Issue 2783

Source code

* $FOAM_SRC/OpenFOAM/fields/GeometricFields/GeometricField/GeometricBoundaryField.C

Merge request

* Merge request 628

==== ノンブロッキング環状A(C)MI ====
cyclicAMI境界条件は、複数の隣接する面からの面積加重補間を実装します。これらの面はローカルであることも、リモートプロセッサに存在することもあり、並列通信を必要とします。

以前のリリースでは、それぞれのcyclicAMIの評価または線形ソルバーの行列寄与（ローカルでない隣接面の場合）が、独自の通信セットをトリガーし、次のcyclicAMIまたはプロセッサパッチに進む前に、これらの終了を待っていました。このリリースでは、すべての送受信を開始するプロセッサパッチと同様の経路をたどり、ローカル値を更新するためにリモートデータを使用する「消費」フェーズがあります。典型的な境界条件の評価や線形ソルバーの更新は、次のような形になります：

* すべての initEvaluate/initInterfaceMatrixUpdate を行う（結合境界のみ）。プロセッサ、cyclicA(C)MI の場合、これはノンブロッキングの送受信を開始する。
* すべての通信が終了するのを待つ（または、ポーリング（v2306 nPollProcInterfaces）を使用して以下と組み合わせる）。
* すべてのevaluate/updateInterfaceMatrixを行う。これは、受信したデータを使用して、行列解への寄与を計算します。

cyclicA(C)MIからの通信をプロセッサの境界条件とまったく同じ方法で処理することで、ボトルネックが発生する可能性が低くなり、スケーリングが向上することが期待される。さらなる最適化として、ローカル送受信バッファは一度割り当てられ、再利用される。

Source code

* $FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint/cyclicAMI/cyclicAMIFvPatchField.H

Merge request

* Merge request 641

Tutorial

* any case with <code>cyclicAMI</code> or <code>cyclicACMI</code>

==== GAMG : プロセッサ・アグロメレーションにおけるcyclicAMIのサポート ====
GAMGソルバーは、ローカルアグロメレーションに加えて、プロセッサ間で行列を結合することができます（プロセッサアグロメレーション）。これは、コア数が多い場合に有益です：

* 最も粗いレベルを解くコアの数を減らす - 世界的な削減のほとんどは、最も粗いレベルで起こる。
* は、スムージングやプリコンディショニングなど、すべての演算の暗黙性を高める。

このリリースでは、cyclicAMIやcyclicACMIなど、すべての連成境界条件のプロセッサアグロメレーションを可能にするようにフレームワークが拡張されました。

テストとして、以下を比較した。

* 40x10x1のブロック1つ、および
* 2つの20x10x1ブロックがcyclicAMIを使って結合されている。

どちらのケースも4つに分解され、GAMGソルバーとmasterCoarsestプロセッサーのアグロメーターを併用することで、すべての行列がmaster(s)に結合された。<syntaxhighlight>
solvers
{
p
{
solver GAMG;
processorAgglomerator masterCoarsest;
..
}
</syntaxhighlight>

* シングルブロック（つまり、cyclicAMIはなく、プロセッサーフェイスのみ）：
<syntaxhighlight>
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 1.5 2
1 4 50 50 1.5 2
2 1 100 100 0 0
3 1 48 48 0 0
</syntaxhighlight>すべてのプロセッサ面が内部となるため、境界の数（nInterfaces）は0となる。

* 2ブロックの場合（つまり、cyclicAMIとプロセッサフェイス）：
<syntaxhighlight>
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 3 3
1 4 50 50 3 3
2 1 100 100 2 2
3 1 48 48 2 2
</syntaxhighlight>ここでは、2つのcyclicAMIのみが保存されるため、境界の数は3つから2つに減る。

=== Notes ===

* <code>cyclicA(C)MI</code> :
** すべての面がローカルになると、動作は非分散にリセットされる。つまり、操作は追加のコピーなしで、提供されたフィールドに直接適用される。
** 回転変換はまだサポートされていません。これは基本的な制限ではありませんが、変換を考慮するためにステンシルを追加で書き換える必要があります。
* processorCyclic : (オーナーセルと隣接セルが異なるプロセッサ上にあるサイクリック) はまだサポートされていない。これは通常のプロセッサ境界として扱われるため、変換は失われる。processorCyclicはdecomposeParDictでパッチ制約を使うことで回避できることに注意。
<syntaxhighlight>
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (cyclic);
}
}
</syntaxhighlight>

* masterCoarsestのみがテストされているが、コードは他のどのプロセッサー凝集法もサポートするはずである。
* これまでの限られたテストでは、cyclicAMIのプロセッサー集積の利点は示されていない。これは、ボトルネック、例えば、大域的削減の数や暗黙性が問題となる場合にのみ有効である。

Source code

* $FOAM_SRC/OpenFOAM/meshes/lduMesh/lduPrimitiveMesh.C

Merge request

* Merge request 645

=== redistributeParとファイルシステムの改良 ===
このリリースでは、照合ファイル・フォーマットの一般的なサポートが改善され、redistributeParユーティリティの調整も行われました。これらの変更により、照合ファイル形式は以前よりも幅広いワークフローで使用できるようになりました。

これらの変更に加え、分散ファイルシステムによるダイナミックコードの取り扱いが改善された。このようなタイプのシステムでは、動的にコンパイルされたライブラリも対応するサブランクに配布されるようになった。

==== 照合されたインクルードファイルの取り扱いが改善された ====
以前のバージョンでは、"include "ファイルを照合と組み合わせて使用すると、ファイルの内容がランタイムで変更可能なものとして扱われる場合、非常に壊れやすいことがあった。今回、ウォッチド・ファイルの取り扱いが更新され、プロセッサー・ランク間の適切な対応が保証されるようになった。

== Usability ==

=== New verification and validation public repository ===
OpenFOAMソフトウェアの検証と妥当性確認に関するコミュニティへの貢献をホストする新しいパブリックリポジトリが開設されました： OpenFOAM Verification and Validation Repository。

このリポジトリの主な目的は、OpenFOAMコミュニティがソフトウェアの検証と検証の側面を共有、協力、強化するための一元化されたプラットフォームを提供することです。コミュニティの集合的な知識と専門知識を結集することにより、OpenFOAMシミュレーションの全体的な品質を向上させ、数値モデリングのベストプラクティスを推進することを目指しています。

このリリースでは、Taylor-Green渦問題と円形Couette流れが組み込まれ、ケースのセットアップとドキュメンテーションのために提供されたテンプレートの実用的な応用が示されています。

=== コンピレーション ===

=== General ===
OpenFOAMで使用されるC++標準は、GNUコンパイラでもc++14になりました。この変更により、推奨コンパイラの最小バージョンはgcc-7.5.0になりました。

将来のコード移行を支援するため、「より厳しい」非推奨警告を有効にできるようになりました。これは WM_COMPILE_CONTROL 環境変数の +strict エントリでグローバルに、または wmake -strict で一度だけ有効にできます。これは主に開発者向けのオプションと考えることができます（多くの警告を生成する可能性があります）が、モジュールを書くときに便利で面白いかもしれません。

=== MacOS ===
このバージョンには、MacOS上でのコンパイルと実行に関するいくつかの改良が含まれています。

* AppleとARM64のFPE処理の改善（Guanyang Xue氏提供）
* rpathハンドリング
* xcrun サポート

MacOS のコンパイルでは、rpath のサポートがデフォルトで有効になり、Apple SIP (System Integrity Protection) の影響に対する回避策がいくらか減って、これらのシステムでの OpenFOAM の実行が簡単になりました。WM_COMPILE_CONTROL環境変数に~rpathを追加することで、rpath処理を無効にできます。

MacOSコンパイルでは、xcodeツール（xcrunなど）の使用もサポートするようになりました。これらはWM_COMPILE_CONTROL環境変数に+xcrunを追加することで有効になります。見つかると、これらのコンパイル・ルールが使用されます：<syntaxhighlight>
cc := xcrun cc
CC := xcrun c++ -std=c++14
</syntaxhighlight>

=== Clang ===
clangベースのコンパイルで、ldリンカを使用するように明示的に指定できるようになりました（注意：clangがldを使用するかlldを使用するかはインストールに依存します）。リンカの選択は環境変数 WM_COMPILE_CONTROL の対応するエントリで定義されます：<syntaxhighlight>
- `+gold` : use gold linker
- `+link-ld` : use ld linker
- `+lld` : use lld linker
- `+mold` : use mold linker
</syntaxhighlight>

=== OpenMP ===
openmp と no-openmp の扱いが強化された。"+openmp" (wmake -openmp) よりも "~openmp" (wmake -no-openmp) の方が優先されます。

これにより、一般的に+openmpを指定する場合はrobusterとなり、特定のビルド・コンポーネント（スタティック・ライブラリやMPIブリッジ・コードなど）を指定する場合は~openmpとなる。

=== Profiling ===
このバージョンには、Extraeプロファイリング用のフックが含まれています。デフォルトでは、フックは常にOpenFOAMと一緒にビルドされますが、LD_PRELOADによってExtraeが実際にロードされるまで休止しています。これにより、OpenFOAMをその目的専用に再コンパイルすることなく、Extraeのトレースが可能になります。

Josep Pocurull（Barcelona Supercomputing Center）により提供され、exaFOAMプロジェクトの一部として使用されたコード。

Source code

* $FOAM_SRC/OpenFOAM/global/profiling/profilingTrigger.C

Merge request

* Merge request 652

OpenFOAM

2023-12-24T07:26:43Z

Mmer547: /* リリースノート */

このページではOpenFOAMについてまとめていきます。

== リリースノート ==

'''OpenCFD'''

[[OpenFOAM v2312リリースノート|OpenFOAM v2312 リリースノート]]

[[OpenFOAM v2306リリースノート|OpenFOAM v2306 リリースノート]]

[[OpenFOAM v2212 リリースノート]]

[[OpenFOAM v2206 リリースノート]]

[[OpenFOAM v2112 リリースノート]]

[[OpenFOAM v2106 リリースノート]]

[https://www.notion.so/OF2012-3625e0d8029b40bda20fafe481dcbd95 OpenFOAM v2012 リリースノート]

[[OpenFOAM v2006 リリースノート]]

[[OpenFOAM v1912 リリースノート]]

[[OpenFOAM v1906 リリースノート]]

[[OpenFOAM v1812 リリースノート]]

[[OpenFOAM v1806 リリースノート]]

'''The OpenFOAM Foundation'''

[[OpenFOAM 11 リリースノート]]

[[OpenFOAM 10 リリースノート]]

[[OpenFOAM 9|OpenFOAM 9 リリースノート]]

[[OpenFOAM 8 リリースノート]]

[[OpenFOAM v7 リリースノート]]

[[OpenFOAM v6.0 リリースノート]]

[[OpenFOAM 4.0 リリースノート]]

[[OpenFOAM 3.0.0 リリースノート]]

[[OpenFOAM 2.4.0 リリースノート]]

==スターティングガイド==
[[OpenFOAMについて]]

[[OpenFOAMのインストール]]

[https://qiita.com/mmer547/items/e63d4cf76ea2fea659b2 チュートリアルケースの実行]

[https://qiita.com/mmer547/items/24b8491bf9776c3a27db OpenFOAMで入力できる項目の調べ方]

[https://qiita.com/mmer547/items/e4b13100e15508981a85 OpenFOAMの$FOAM変数]

==困った時は？==
[https://qiita.com/mmer547/items/7c7c257dcaf2efbc730b OpenFOAM Google Groupに投稿する際に抑えるポイント]

[https://qiita.com/mmer547/items/6b041536e2ac5dd17721 OpenFOAMで計算するネタがない時の探し方]

[[OpenFOAMのエラーメッセージの対応]]

==プリプロセス==

===形状作成===

[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%EF%BC%9A%E5%BD%A2%E7%8A%B6%E4%BD%9C%E6%88%90 形状作成ツールまとめ]

===メッシュ===
[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%E3%81%AE%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A3%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 OpenFOAMのメッシャーについて]

[[メッシュ作成:blockMesh]]

[[メッシュ作成:snappyHexMesh]]

[[メッシュ作成:cfMesh]]

[https://qiita.com/mmer547/items/9fca38b8e8eadc869bb8 SalomeでOpenFOAMのメッシュを用意する方法]

===境界条件===
[[境界条件]]

==ソルバ==
[[simpleFoamについて]]

[[ExecutionTimeとClockTimeについて]]

[https://scrapbox.io/opencae-kansai-memo/SIMPLEC%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E8%A8%88%E7%AE%97%E5%AE%9F%E8%A1%8C%EF%BC%88OpenFOAM3.0.1%EF%BC%89 SIMPLECを使用した計算実行（OpenFOAM3.0.1）]

===並列計算の実行方法===

[[decomposeParDictの中身]]

===エラーメッセージ===
[[v1806のエラーメッセージ]]

==ポストプロセス==
[[ログファイルから残差ログを抽出]]

[https://qiita.com/mmer547/items/e463235ddb93f08db68a OpenFOAMのpostProcessについて]

==チュートリアルケース==
[[チュートリアルケース|チュートリアルケース一覧]]

==カスタマイズ==
[https://qiita.com/mmer547/items/2997bf8c71fe1e2423c9 OpenFOAM ソースコードの探し方]

==その他==
[https://scrapbox.io/opencae-kansai-memo/foam-extend_4.0%E3%82%92Bash_on_Ubuntu_on_Windows%E3%81%AB%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB foam-extend 4.0をBash on Ubuntu on Windowsにインストール]

[https://scrapbox.io/opencae-kansai-memo/ESI_Windows%E7%89%88OpenFOAM%E3%81%AE%E5%B0%8E%E5%85%A5 ESI Windows版OpenFOAMの導入]

[https://gitlab.com/OpenCAE/Supercomputer-OpenFOAM-Training/-/wikis/home スーパーコンピュータOpenFOAM講習会]

== 関連サービス ==
=== プリプロセス ===
[https://www.xsim.info/products/products.html XSim.Work]

== 関連書籍 ==

[https://www.amazon.co.jp/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEDEXCS-OpenFOAM%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E9%87%8E%E6%9D%91-%E6%82%A6%E6%B2%BB/dp/4621306138/ref=sr_1_5?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-5 オープンCAEのためのDEXCS for OpenFOAMハンドブック]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E7%AC%AC2%E7%89%88-%E4%B8%80%E8%88%AC%E7%A4%BE%E5%9B%A3%E6%B3%95%E4%BA%BA%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691025/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-1 OpenFOAMによる熱移動と流れの数値解析(第2版) ]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AE%E6%AD%A9%E3%81%8D%E6%96%B9-%E6%8A%80%E8%A1%93%E3%81%AE%E6%B3%89%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%EF%BC%88NextPublishing%EF%BC%89-%E5%B7%9D%E7%95%91-%E7%9C%9F%E4%B8%80/dp/4844379526/ref=sr_1_6?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-6　OpenFOAMの歩き方]

[https://www.amazon.co.jp/OpenFOAM%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%83%86%E3%83%A9%E3%83%90%E3%82%A4%E3%83%88/dp/4627691610/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-2 OpenFOAMライブラリリファレンス]

[https://www.amazon.co.jp/OpenFOAM%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-Tomislav-Mari%C2%B4c/dp/4627670915/ref=sr_1_3?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-3 OpenFOAMプログラミング]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691017/ref=sr_1_4?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-4 OpenFOAMによる熱移動と流れの数値解析]

オープンCAEの系譜

2023-12-09T03:20:54Z

Mmer547:

オープンCAEの歴史をまとめていきたいと思います。適当に追記願います。

{| class="wikitable"
|+オープンCAEの系譜
|-
!scope="col"|年月
!scope="col"|起こった出来事・イベント
|-
|2023/12
|オープンCAE学会がオープンCAEシンポジウム2023（横浜）開催
|-
|2023/11
|
|-
|2023/10
|
|-
|2023/09
|オープンCAE学会がOpenFOAM GPUトレーニング2023（オンライン）を開催
オープンCAE学会がオープンCAEサマースクール2023(9/1~3、逗子)を開催
|-
|2023/08
|
|-
|2023/07
|オープンCAE学会がオープンCAE講習会(オンライン)を開催
|-
|2023/06
|オープンCAE学会がオープンCAE講習会(オンライン)を開催
|-
|2023/05
|
|-
|2023/04
|
|-
|2023/03
|
|-
|2023/02
|
|-
|2023/01
|
|-
|2022/12
|
|-
|2022/11
|
|-
|2022/10
|
|-
|2022/09
|オープンCAE学会がオープンCAEシンポジウム2022（岡山理科大学）を開催
田辺賞該当者なし
|-
|2022/08
|
|-
|2022/07
|
|-
|2022/06
|
|-
|2022/05
|
|-
|2022/04
|
|-
|2022/03
|
|-
|2022/02
|
|-
|2022/01
|
|-
|2021/12
|オープンCAE学会がオープンCAEシンポジウム2021（オンライン）を開催
田辺賞該当者なし
|-
|2021/11
|
|-
|2021/10
|
|-
|2021/09
|
|-
|2021/08
|
|-
|2021/07
|
|-
|2021/06
|
|-
|2021/05
|
|-
|2021/04
|
|-
|2021/03
|
|-
|2021/02
|
|-
|2021/01
|
|-
|2020/12
|オープンCAE学会がオープンCAE・FrontISTR合同シンポジウム2020（オンライン）を開催
田辺賞該当者なし
|-
|2020/11
|
|-
|2020/10
|
|-
|2020/09
|
|-
|2020/08
|
|-
|2020/07
|
|-
|2020/06
|
|-
|2020/05
|
|-
|2020/04
|
|-
|2020/03
|
|-
|2020/02
|
|-
|2020/01
|
|-
|2019/12
|オープンCAE学会がオープンCAEシンポジウム2019（大阪）を開催 野村さん田辺賞受賞
|-
|2019/11
|
|-
|2019/10
|
|-
|2019/9
|オープンCAE学会がオープンCAEサマースクール2019を開催
|-
|2019/8
|2019/8/1　はじめての「SonyNNC」 (I・O BOOKS)
|-
|2019/7
|
|-
|2019/6
|オープンCAE学会が2019年6月21日オープンCAEトレーニング（東京）を開催
|-
|2019/5
|
|-
|2019/4
|
|-
|2019/3
|オープンCAE学会が2019年3月29日オープンCAE講習会（富山）を開催
|-
|2019/2
|
|-
|2019/1
|
|-
|2018/12
|オープンCAE学会がオープンCAEシンポジウム2018（川崎）を開催 
2018/12/1　基礎からのFreeCAD (I・O BOOKS) 増補改訂版発売
|-
|2018/11
|
|-
|2018/10
|
|-
|2018/9
|2018/9/1　「PrePoMax」ではじめる実践構造解析 (I・O BOOKS)
|-
|2018/8
|オープンCAE学会がオープンCAEサマースクール2018を開催
|-
|2018/7
|
|-
|2018/6
|オープンCAE学会が2018年6月22日オープンCAEトレーニング（東京）を開催
|-
|2018/5
|
|-
|2018/4
|
|-
|2018/3
|
|-
|2018/2
|
|-
|2018/1
|
|-
|2017/12
|オープンCAE学会がオープンCAEシンポジウム2017（名古屋）を開催
|-
|2017/11
|（2017/11/25～26）オープンCAEもくもく合宿開催
|-
|2017/10
|
|-
|2017/9
|オープンCAE学会が2017年9月8日(金)～10日(日)オープンCAEサマースクール2017を開催
|-
|2017/8
|
|-
|2017/7
|
|-
|2017/6
|オープンCAE学会が2017年6月23日(金): 2017年6月23日オープンCAE講習会（東京）を開催
|-
|2017/5
|
|-
|2017/4
|2017/4/3　オープンCAEで学ぶ構造解析入門: ―DEXCS-WinXistrの活用―　発売
|-
|2017/3
|
|-
|2017/2
|
|-
|2017/1
|
|-
|2016/12
|
|-
|2016/11
|2016年11月24日（木）〜26日(土）：オープンCAEシンポジウム2016（東京）
|-
|2016/10
|
|-
|2016/9
|
|-
|2016/8
|2016年8月26日(金)～28日(日)オープンCAEサマースクール2016
|-
|2016/7
|
|-
|2016/6
|2016年6月24日(金): 2016年6月24日オープンCAE講習会（東京） 2016/6/17　OpenFOAMによる熱移動と流れの数値解析　発売
|-
|2016/5
|
|-
|2016/4
|
|-
|2016/3
|2016年3月11日(金): 2016年3月11日オープンCAE講習会（長野）
|-
|2016/2
|2016/2　オープンCAE「Salome‐Meca」構造解析―「弾塑性」「接触」解析編 (I・O BOOKS)　発売
|-
|2016/1
|2016/1　基礎からのFreeCAD (I・O BOOKS) 　発売
|-
|2015/12
|
|-
|2015/11
|2015年11月27日（金）～28日（土） : オープンCAEシンポジウム2015（富山）
|-
|2015/10
|
|-
|2015/9
|
|-
|2015/8
|2015年8月28日(金)～30日(日)オープンCAEサマースクール2015
|-
|2015/7
|
|-
|2015/6
|
|-
|2015/5
|2015年5月30日(土): 平成27年度定時社員総会・オープンCAE講習会 (東京)
|-
|2015/4
|
|-
|2015/3
|2015年3月21日(土): 2015年3月21日オープンCAE講習会（岡山）
|-
|2015/2
|
|-
|2015/1
|
|-
|2014/12
|
|-
|2014/11
|2014年11月13日（木）～14日（金） : オープンCAEシンポジウム2014（東京）
|-
|2014/10
|
|-
|2014/9
|2014/9/1　オープンCAE「Salome‐Meca」構造解析―「固有値」「熱伝導」解析編 (I・O BOOKS) 発売
|-
|2014/8
|2014年8月29日(金)～31日(日)オープンCAEサマースクール2014
|-
|2014/7
|
|-
|2014/6
|2014年6月21日(土): 平成26年度定時社員総会・オープンCAE講習会 (東京)
|-
|2014/5
|
|-
|2014/4
|
|-
|2014/3
|
|-
|2014/2
|2014/2/1　オープンCAE「Salome‐Meca」ではじめる構造解析 (I・O BOOKS) 発売
|-
|2014/1
|
|-
|2013/12
|2013年12月5日（木）～6日（金） : オープンCAEシンポジウム2013（大阪）
|-
|2013/11
|
|-
|2013/10
|
|-
|2013/9
|2013年9月28日(土): 2013年9月28日OpenFOAM臨時講習会 (東京) 2013年9月6日(金)～8日(日)オープンCAEサマースクール2013
|-
|2013/8
|
|-
|2013/7
|
|-
|2013/6
|2013年6月20日（木）～21日（金） : オープンCAEワークショップ2013（東京）
|-
|2013/5
|
|-
|2013/4
|
|-
|2013/3
|
|-
|2013/2
|
|-
|2013/1
|オープンCAE勉強会＠関西、幹事が2代目に交代 OpenFOAM勉強会 for beginner @関西がオープンCAE勉強会@関西に名称変更
|-
|2012/12
|2012年12月14 日（金）～ 15日（土） : オープンCAEシンポジウム2012（岐阜）
|-
|2012/11
|
|-
|2012/10
|
|-
|2012/9
|
|-
|2012/8
|
|-
|2012/7
|2012年7月21日(土) 第1回オープンCAE勉強会＠広島開催
|-
|2012/6
|2012年6月8日（金）～9日（土） : オープンCAEワークショップ2012（東京)
|-
|2012/5
|2012/05/19　オープンCAE勉強会＠富山（第1回）開催
|-
|2012/4
|
|-
|2012/3
|
|-
|2012/2
|
|-
|2012/1
|
|-
|2011/12
|2011年12月1日（木）～2日（金）: オープンCAEシンポジウム2011 （東京）
|-
|2011/11
|
|-
|2011/10
|
|-
|2011/9
|
|-
|2011/8
|
|-
|2011/7
|
|-
|2011/6
|オープンCAE学会が2011年6月26日（日）: オープンCAEワークショップ2011（東京）を開催
|-
|2011/5
|
|-
|2011/4
|
|-
|2011/3
|
|-
|2011/2
|2011/2/1　はじめてのオープンCAE (I・O BOOKS)発売
|-
|2011/1
|平成２３年１月２９日第１回オープンＣＡＥ勉強会【岐阜】開催
|-
|2010/12
|(2010/12/18)第１回OpenFOAM勉強会 for beginner @関西開催 オープンCAE学会が2010年12月5日（日）: オープンCAEシンポジウム2010（東京）を開催
|-
|2010/11
|
|-
|2010/10
|
|-
|2010/9
|
|-
|2010/8
|2010年8月8日（日）: 平成22年度オープンCAE夏季講習会（岐阜） 2010年8月6日（金）: 平成22年度オープンCAE夏季臨時講習会（東京）
|-
|2010/7
|
|-
|2010/6
|2010/06/27 OpenFOAM勉強会 for beginner [第1回]開催
|-
|2010/5
|オープンCAE学会が2010年5月14日（金）: 平成22年度オープンCAEワークショップ・定時社員総会（東京）を開催
|-
|2010/4
|
|-
|2010/3
|
|-
|2010/2
|
|-
|2010/1
|
|-
|2009/12
|
|-
|2009/11
|オープンCAE学会が2009年11月7日（土）: 第二回オープンソースCAEワークショップ（東京）を開催
|-
|2009/10
|
|-
|2009/9
|
|-
|2009/8
|
|-
|2009/7
|
|-
|2009/6
|
|-
|2009/5
|オープンCAE学会が2009年5月13日（水）: 第一回OpenFOAM講習会を開催
|-
|2009/4
|
|-
|2009/3
|
|-
|2009/2
|
|-
|2009/1
|
|-
|2008/12
|
|-
|2008/11
|オープンCAE学会が2008年11月13日（木）: 第一回オープンソースCAEワークショップ（東京）を開催
|-
|2008/10
|
|-
|2008/9
|
|-
|2008/8
|
|-
|2008/7
|
|-
|2008/6
|
|-
|2008/5
|
|-
|2008/4
|
|-
|2008/3
|
|-
|2008/2
|
|-
|2008/1
|
|}

オープンCAEの系譜

2023-12-09T03:11:07Z

Mmer547:

オープンCAEの歴史をまとめていきたいと思います。適当に追記願います。

{| class="wikitable"
|+オープンCAEの系譜
|-
!scope="col"|年月
!scope="col"|起こった出来事・イベント
|-
|2023/12
|
|-
|2023/11
|
|-
|2023/10
|
|-
|2023/09
|
|-
|2023/08
|
|-
|2023/07
|
|-
|2023/06
|
|-
|2023/05
|
|-
|2023/04
|
|-
|2023/03
|
|-
|2023/02
|
|-
|2023/01
|
|-
|2022/12
|
|-
|2022/11
|
|-
|2022/10
|
|-
|2022/09
|
|-
|2022/08
|
|-
|2022/07
|
|-
|2022/06
|
|-
|2022/05
|
|-
|2022/04
|
|-
|2022/03
|
|-
|2022/02
|
|-
|2022/01
|
|-
|2021/12
|
|-
|2021/11
|
|-
|2021/10
|
|-
|2021/09
|
|-
|2021/08
|
|-
|2021/07
|
|-
|2021/06
|
|-
|2021/05
|
|-
|2021/04
|
|-
|2021/03
|
|-
|2021/02
|
|-
|2021/01
|
|-
|2020/12
|
|-
|2020/11
|
|-
|2020/10
|
|-
|2020/09
|
|-
|2020/08
|
|-
|2020/07
|
|-
|2020/06
|
|-
|2020/05
|
|-
|2020/04
|
|-
|2020/03
|
|-
|2020/02
|
|-
|2020/01
|
|-
|2019/12
|2019年12月19日（木）〜21日（土）：オープンCAEシンポジウム2019（大阪） 野村さん田辺賞受賞
|-
|2019/11
|
|-
|2019/10
|
|-
|2019/9
|2019年9月6日(金)～9月8日(日)オープンCAEサマースクール2019
|-
|2019/8
|2019/8/1　はじめての「SonyNNC」 (I・O BOOKS)
|-
|2019/7
|
|-
|2019/6
|2019年6月21日(金): 2019年6月21日オープンCAEトレーニング（東京）
|-
|2019/5
|
|-
|2019/4
|
|-
|2019/3
|2019年3月29日(金)-30日(土): 2019年3月29日オープンCAE講習会（富山）
|-
|2019/2
|
|-
|2019/1
|
|-
|2018/12
|2018年12月6日（木）〜8日（土）：オープンCAEシンポジウム2018（川崎） 
2018/12/1　基礎からのFreeCAD (I・O BOOKS) 増補改訂版発売
|-
|2018/11
|
|-
|2018/10
|
|-
|2018/9
|2018/9/1　「PrePoMax」ではじめる実践構造解析 (I・O BOOKS)
|-
|2018/8
|2018年8月31日(金)～9月2日(日)オープンCAEサマースクール2018
|-
|2018/7
|
|-
|2018/6
|2018年6月22日(金): 2018年6月22日オープンCAEトレーニング（東京）
|-
|2018/5
|
|-
|2018/4
|
|-
|2018/3
|
|-
|2018/2
|
|-
|2018/1
|
|-
|2017/12
|2017年12月7日（木）〜9日（土）: オープンCAEシンポジウム2017（名古屋）
|-
|2017/11
|（2017/11/25～26）オープンCAEもくもく合宿開催
|-
|2017/10
|
|-
|2017/9
|2017年9月8日(金)～10日(日)オープンCAEサマースクール2017
|-
|2017/8
|
|-
|2017/7
|
|-
|2017/6
|2017年6月23日(金): 2017年6月23日オープンCAE講習会（東京）
|-
|2017/5
|
|-
|2017/4
|2017/4/3　オープンCAEで学ぶ構造解析入門: ―DEXCS-WinXistrの活用―　発売
|-
|2017/3
|
|-
|2017/2
|
|-
|2017/1
|
|-
|2016/12
|
|-
|2016/11
|2016年11月24日（木）〜26日(土）：オープンCAEシンポジウム2016（東京）
|-
|2016/10
|
|-
|2016/9
|
|-
|2016/8
|2016年8月26日(金)～28日(日)オープンCAEサマースクール2016
|-
|2016/7
|
|-
|2016/6
|2016年6月24日(金): 2016年6月24日オープンCAE講習会（東京） 2016/6/17　OpenFOAMによる熱移動と流れの数値解析　発売
|-
|2016/5
|
|-
|2016/4
|
|-
|2016/3
|2016年3月11日(金): 2016年3月11日オープンCAE講習会（長野）
|-
|2016/2
|2016/2　オープンCAE「Salome‐Meca」構造解析―「弾塑性」「接触」解析編 (I・O BOOKS)　発売
|-
|2016/1
|2016/1　基礎からのFreeCAD (I・O BOOKS) 　発売
|-
|2015/12
|
|-
|2015/11
|2015年11月27日（金）～28日（土） : オープンCAEシンポジウム2015（富山）
|-
|2015/10
|
|-
|2015/9
|
|-
|2015/8
|2015年8月28日(金)～30日(日)オープンCAEサマースクール2015
|-
|2015/7
|
|-
|2015/6
|
|-
|2015/5
|2015年5月30日(土): 平成27年度定時社員総会・オープンCAE講習会 (東京)
|-
|2015/4
|
|-
|2015/3
|2015年3月21日(土): 2015年3月21日オープンCAE講習会（岡山）
|-
|2015/2
|
|-
|2015/1
|
|-
|2014/12
|
|-
|2014/11
|2014年11月13日（木）～14日（金） : オープンCAEシンポジウム2014（東京）
|-
|2014/10
|
|-
|2014/9
|2014/9/1　オープンCAE「Salome‐Meca」構造解析―「固有値」「熱伝導」解析編 (I・O BOOKS) 発売
|-
|2014/8
|2014年8月29日(金)～31日(日)オープンCAEサマースクール2014
|-
|2014/7
|
|-
|2014/6
|2014年6月21日(土): 平成26年度定時社員総会・オープンCAE講習会 (東京)
|-
|2014/5
|
|-
|2014/4
|
|-
|2014/3
|
|-
|2014/2
|2014/2/1　オープンCAE「Salome‐Meca」ではじめる構造解析 (I・O BOOKS) 発売
|-
|2014/1
|
|-
|2013/12
|2013年12月5日（木）～6日（金） : オープンCAEシンポジウム2013（大阪）
|-
|2013/11
|
|-
|2013/10
|
|-
|2013/9
|2013年9月28日(土): 2013年9月28日OpenFOAM臨時講習会 (東京) 2013年9月6日(金)～8日(日)オープンCAEサマースクール2013
|-
|2013/8
|
|-
|2013/7
|
|-
|2013/6
|2013年6月20日（木）～21日（金） : オープンCAEワークショップ2013（東京）
|-
|2013/5
|
|-
|2013/4
|
|-
|2013/3
|
|-
|2013/2
|
|-
|2013/1
|オープンCAE勉強会＠関西、幹事が2代目に交代 OpenFOAM勉強会 for beginner @関西がオープンCAE勉強会@関西に名称変更
|-
|2012/12
|2012年12月14 日（金）～ 15日（土） : オープンCAEシンポジウム2012（岐阜）
|-
|2012/11
|
|-
|2012/10
|
|-
|2012/9
|
|-
|2012/8
|
|-
|2012/7
|2012年7月21日(土) 第1回オープンCAE勉強会＠広島開催
|-
|2012/6
|2012年6月8日（金）～9日（土） : オープンCAEワークショップ2012（東京)
|-
|2012/5
|2012/05/19　オープンCAE勉強会＠富山（第1回）開催
|-
|2012/4
|
|-
|2012/3
|
|-
|2012/2
|
|-
|2012/1
|
|-
|2011/12
|2011年12月1日（木）～2日（金）: オープンCAEシンポジウム2011 （東京）
|-
|2011/11
|
|-
|2011/10
|
|-
|2011/9
|
|-
|2011/8
|
|-
|2011/7
|
|-
|2011/6
|2011年6月26日（日）: オープンCAEワークショップ2011（東京）
|-
|2011/5
|
|-
|2011/4
|
|-
|2011/3
|
|-
|2011/2
|2011/2/1　はじめてのオープンCAE (I・O BOOKS)発売
|-
|2011/1
|平成２３年１月２９日第１回オープンＣＡＥ勉強会【岐阜】開催
|-
|2010/12
|(2010/12/18)第１回OpenFOAM勉強会 for beginner @関西開催 2010年12月5日（日）: オープンCAEシンポジウム2010（東京）
|-
|2010/11
|
|-
|2010/10
|
|-
|2010/9
|
|-
|2010/8
|2010年8月8日（日）: 平成22年度オープンCAE夏季講習会（岐阜） 2010年8月6日（金）: 平成22年度オープンCAE夏季臨時講習会（東京）
|-
|2010/7
|
|-
|2010/6
|2010/06/27 OpenFOAM勉強会 for beginner [第1回]開催
|-
|2010/5
|2010年5月14日（金）: 平成22年度オープンCAEワークショップ・定時社員総会（東京）
|-
|2010/4
|
|-
|2010/3
|
|-
|2010/2
|
|-
|2010/1
|
|-
|2009/12
|
|-
|2009/11
|2009年11月7日（土）: 第二回オープンソースCAEワークショップ（東京）
|-
|2009/10
|
|-
|2009/9
|
|-
|2009/8
|
|-
|2009/7
|
|-
|2009/6
|
|-
|2009/5
|2009年5月13日（水）: 第一回OpenFOAM講習会
|-
|2009/4
|
|-
|2009/3
|
|-
|2009/2
|
|-
|2009/1
|
|-
|2008/12
|
|-
|2008/11
|2008年11月13日（木）: 第一回オープンソースCAEワークショップ（東京）
|-
|2008/10
|
|-
|2008/9
|
|-
|2008/8
|
|-
|2008/7
|
|-
|2008/6
|
|-
|2008/5
|
|-
|2008/4
|
|-
|2008/3
|
|-
|2008/2
|
|-
|2008/1
|
|}

Visual Studio Code Extensionについて

2023-11-30T12:47:49Z

Mmer547: ページの作成:「OpenRadioss-helperという名前で公開されているExtensionがある。機能としてはインプットカードのハイライト表示と入力補助になる。 https://marketplace.visualstudio.com/items?itemName=mmer547.openradioss-helper」

OpenRadioss-helperという名前で公開されているExtensionがある。

機能としてはインプットカードのハイライト表示と入力補助になる。

https://marketplace.visualstudio.com/items?itemName=mmer547.openradioss-helper

OpenRadioss

2023-11-30T12:44:56Z

Mmer547: /* スターティングガイド */

{| class=wikitable style="font-family:serif;background-color:#f5f6ff ; margin:1em;"
|-
|
Altair Radiossは、動的負荷がかかる非線形性の高い問題に対する製品性能の評価と最適化を支援する、業界で実績のある解析ソリューションです。30年以上にわたり、Altair Radiossはデジタル設計プロセスの合理化と最適化、費用のかかる物理テストの迅速かつ効率的なシミュレーションへの置き換え、設計最適化の反復のスピードアップを実現し、ユーザーと組織が製品品質の向上、コスト削減、開発サイクルの短縮を達成できるよう支援しています。(公式サイト<ref>https://www.openradioss.org/</ref>より)
|}

== スターティングガイド ==

[[OpenRadiossのインストール]]

[[OpenRadiossの計算実行]]

[[計算結果のVTK変換]]

[[LS-Dynaフォーマットについて]]

[[Radiossインプットカードについて]]

[[Visual Studio Code Extensionについて]]

== TIPS ==
[https://hammamania.tech/c7fbed6839c14e66ba004eae97bfe58c ParaViewでPartごとに結果を表示する方法]

== 公式Example ==

=== in OpenRadioss Block Format ===

[[Bird Strike on Windshield]]

[[INIVOL and Fluid Structure Interaction (Drop Container)]]

[[Fan Blade Rotation Initialization and Impact]]

[[Blow molding with Advanced Mass Scaling (AMS).]]

[[Ice Cube]]

[[Spring-back]]

[[Yaris impact on pole at 40km/h]]

[[Bumper Beam]]

[[Tensile Test (Radioss Block Format)]]

[[Tensile Test Example Tutorial Using Gmsh]]

[[Football (Soccer) Shots]]

[[Cell Phone Drop Test]]

[[Rubber ‘O-Ring’ Seal Installation]]

=== in LS-DYNA key format ===

[[Example LS-DYNA Format Models]]

[[Camry Impact Model in LS-DYNA format]]

[[Tensile Test Model in LS-DYNA format ]]

== ドキュメント ==

[https://2022.help.altair.com/2022.1/hwsolvers/rad/index.htm Radioss online help]

[https://2022.help.altair.com/2022/hwsolvers/ja_jp/rad/index.htm Radioss 2022 日本語ヘルプ（オンライン）]

[https://2022.help.altair.com/2022/simulation/pdfs/radopen/AltairRadioss_2022_ReferenceGuide.pdf Altair Radioss 2022 Reference Guide]

[https://2022.help.altair.com/2022/hwsolvers/ja_jp/pdf/AltairRadioss_2022_Reference.pdf Radioss 2022 日本語リファレンスガイド]

[https://2022.help.altair.com/2022/simulation/pdfs/radopen/AltairRadioss_2022_UserGuide.pdf Altair Radioss 2022 User Guide]

[https://2022.help.altair.com/2022/hwsolvers/ja_jp/pdf/AltairRadioss_2022_UserGuide.pdf Radioss 2022 日本語ユーザーガイド]

[https://2022.help.altair.com/2022/simulation/pdfs/radopen/AltairRadioss_2022_TheoryManual.pdf Altair Radioss 2022 Theory Manual]

[https://2022.help.altair.com/2022/hwsolvers/ja_jp/pdf/AltairRadioss_2022_Example.pdf Radioss 2022 日本語例題集]

== その他参考になるドキュメント ==

[https://www.dynasupport.com/manuals LS-DYNA manuals]

[https://www.dynaexamples.com LS-DYNA Examples]

[https://www.lstc.com/lspp/ LS-PrePost Online Documentation]

[http://groups.google.com/group/ls-prepost LS-PrePost User Group]

OpenRadiossのインストール

2023-11-30T10:36:14Z

Mmer547:

WindowsでLinux版を使用する場合はWSL<ref>https://learn.microsoft.com/ja-jp/windows/wsl/install</ref>を使用する。
== Linuxでバイナリ版のインストール人 ==

Ubuntuでのみ確認済み。

Githubのページから～linux64.zipをダウンロードして、解凍する。

[https://github.com/OpenRadioss/OpenRadioss/releases OpenRadioss Github]

/optなどに解凍する。

== Windowsでバイナリ版のインストールをしたい人 ==

Githubのページから～Win64.zipをダウンロードして、任意の場所に解凍する。

[https://github.com/OpenRadioss/OpenRadioss/releases OpenRadioss Github]

並列計算を実行する場合は、Intel MPI Libraryを次のリンクから入手してインストールする。

[https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html#mpi Intel MPI Library]

== ソースコードコンパイルしたい人 ==
下記公式ドキュメントを見ながら実行するとコンパイルできる。

[https://github.com/OpenRadioss/OpenRadioss/blob/main/HOWTO.md How to Build OpenRadioss]

[https://getwelsim.medium.com/explore-openradioss-the-worlds-first-enterprise-grade-open-source-explicit-dynamics-solver-i-b4c7931a48ed Explore the enterprise-grade open-source solver OpenRadioss I : build in Linux]

== Apple Silicon Macにインストールしたい人（非公式） ==
Apptainer imageでの導入について書かれた記事あり。

https://www.epeters.io/containerized-openradioss-macos

==注記==

メインページ

2023-11-29T06:10:22Z

Mmer547: /* その他 */

オープンCAEWikiにようこそ！

本wikiはオープンソースCAEソフトウェアについての情報まとめています。
クローズドなwikiではありません。
ご編集されたい方はアカウントをご登録ください。

なお、内容はオープンCAEに関連するものでお願いします。

=== オープンCAEの前提知識 ===

[[Linux]]

[[解析用語]]

=== CAD ===
[[FreeCAD]]

=== メッシャー ===
[[Netgen]]

[[Gmsh]]

=== 流体 ===
[[OpenFOAM]]

[[SU2]]

=== 構造 ===
[[FrontISTR]]

[[Salome-Meca]]

[[CalculiX]]

[[PrePoMax]]

[[StressRefine]]

[[FEBio]]

[[PlantFEM]]

[[OpenRadioss]]

=== MBD(モデルベースデザイン) ===
[[OpenModelica]]

=== 機構解析 ===

[[MBDyn]]

[[EXUDYN]]

=== 有限要素法ライブラリ・ツールセット ===

[[GetFEM]]

[[DelFEM2]]

[[sparselizard]]

[[ivyFEM]]

=== マルチフィジックス ===
[[Elmer]]

=== 粒子法 ===
[[DualSPHygics]]

[[OpenMPS]]

=== 格子ボルツマン法 ===
[[Palabos]]

[[waLBerla]]

=== 偏微分方程式ソルバ ===

[[FEniCSx]]

=== 可視化 ===
[[Paraview]]

[[Mayavi]]

=== 最適化 ===
[[OpenMDAO]]

[[OpenDA]]

[[Dakota]]

=== クラウド ===

[[SimScale]]

=== ベンチマーク ===
[https://www.cenav.org/ 計算工学ナビ]

[https://feaber.readthedocs.io/ja/latest/ FEABeR]

=== プログラミング ===
[[Python]]

[[C++]]

=== その他 ===

[[物性データベース]]

[[Blender]]

[[Maxima]]

[[REDUCE]]

[https://qiita.com/advent-calendar/2022/opencae オープンCAE Advent Calendar 2022]

[https://adventar.org/calendars/6423 オープンCAE Advent Calendar 2021]

[https://adventar.org/calendars/5192 オープンCAE Advent Calendar 2020]

[https://qiita.com/advent-calendar/2019/opencae-ac2019 オープンCAE Advent Calendar 2019]

[https://qiita.com/advent-calendar/2018/opencae-ac2018 オープンCAE Advent Calendar 2018]

[https://qiita.com/advent-calendar/2017/openfoam OpenFOAM Advent Calendar 2017]

=== オープンCAE ===
[[オープンCAEの系譜]]

[https://www.youtube.com/channel/UCuffpM6BjZWZ4AEDFiQexEg オープンCAE動画チャンネル]

[[各地の勉強会]]

[[勝手にブックレビュー]]

[[オープンCAE名言集]]

=== Wikiについて ===

本wikiはオープンCAE学会が管理しています。
オープンCAE学会については[http://www.opencae.or.jp 公式サイト]を参照してください。

OpenFOAM 11 リリースノート

2023-09-09T13:01:44Z

Mmer547: ページの作成:「OpenFOAM Foundationは、OpenFOAMオープンソースCFDツールボックスのバージョン11のリリースを発表します。バージョン11では、1993年のicoFoam以来OpenFOAMに不可欠な従来のアプリケーション・ソルバとは対照的に、クラスとして記述されたモジュラー・ソルバを導入しました。モジュール型ソルバーは、メンテナンスと拡張がよりシンプルになり、多領域シミ…」

OpenFOAM Foundationは、OpenFOAMオープンソースCFDツールボックスのバージョン11のリリースを発表します。バージョン11では、1993年のicoFoam以来OpenFOAMに不可欠な従来のアプリケーション・ソルバとは対照的に、クラスとして記述されたモジュラー・ソルバを導入しました。モジュール型ソルバーは、メンテナンスと拡張がよりシンプルになり、多領域シミュレーション、例えば、共役伝熱（CHT）、多相流など、あらゆるタイプの流れに柔軟に対応します。すべてが後方互換性を持っています： 2) simpleFoamなどの古いアプリケーション・ソルバを起動すると、非圧縮流体モジュールを単一領域で実行するスクリプトが実行されます。

OpenFOAM 11には次のようなハイライトがあります。

* モジュール式ソルバー：クラスベースのソルバーにより、多地域シミュレーションなどの柔軟性を向上。
* Multiphase: multiphaseEulerモジュールの一貫性と保存性が大幅に改善されました。
* 輸送：熱伝導率の異方性を追加。
* 熱物理学：入力ファイルのキーワードにおけるプロパティ名の指定を標準化した。
* 熱伝導：領域間の熱伝導のための簡略化された臨界境界条件。
* 粒子追跡：粒子のサイズ分布に対する一般化された統計分布。
* 液体フィルム：質量を節約し、他のモデルに統合する完全な置換。
* メッシュ：ダイナミック・メッシュ機能の再設計とNCCの統合。
* ファンクションオブジェクト：フィールド平均化と可視化ファンクションオブジェクトの改良。
* モデルと制約：多数の新しいモデルと制約。
* 境界条件：マッピング条件を統合し、MRF条件を導入。
* ケース設定：新しいfoamToCアプリケーションは、OpenFOAMのモデルとオプションをリストアップします。
* プログラミング：新しい有限体積関数とアルゴリズムシーケンスの改良。
* 964件のコードコミット、133件の問題解決。
* ISO/IEC 14882:2011 (C++14): GCC v5.5+、Clang v16+でテスト済み（v10+でも動作するはず）。

ParaView 5.10.1には、LLVM/Galliumアクセラレーション付きのMesaが含まれており、（サポートされている）グラフィックカードがないシステムにも対応しています：

* Ubuntu Linux: Ubuntu 20.04、22.04、23.04用のパッケージインストール；
* その他のLinux：Dockerコンテナによるインストール、またはソースコードからのコンパイル；
* Windows 10: Windows Subsystem for LinuxとUbuntuパックを使用したインストール；
* macOS: Dockerコンテナによるインストール。

OpenFOAM 11 Source Packは、適切なLinuxプラットフォームでコンパイルできます。

== モジュール式ソルバー ==

* 一般的なアプリケーション: foamRunは新しいモジュラーソルバをロードする一般的なCFDアプリケーションです[ commit 968e60 ]。foamMultiRunアプリケーションは異なるメッシュ領域で異なるモジュラーソルバを実行することができ、共役熱伝導などの複雑な連成問題に対応する汎用ツールを提供します[ commit 968e60 ]。foamPostProcessユーティリティは新しいモジュラーソルバをサポートするpostProcessユーティリティの新しい一般的な置き換えです[ commit 4001d2 ]。
* 非圧縮性および圧縮性ソルバー：流体、isoThermalFluid、multicomponentFluid、solidモジュールソルバは、rhoSimpleFoam、rhoPimpleFoam、buoyantFoamからreactingFoamなど多くの従来のソルバーを複製します[ commit 968e60 ]。非圧縮流体モジュールソルバは、pimpleFoam、pisoFoam、simpleFoamを複製します[ commit ca8918 ]。
* 体積流体(VoF)を含む多相： compressibleVoFモジュラーソルバはcompressibleInterFoamを複製し[ commit f77119 ]、fvModelsを通してキャビテーションをシミュレートすることができます。非圧縮性二相流のための非圧縮性VoFモジュールソルバーは、interFoamを置き換えるもので、多領域シミュレーションに使用することができます[ commit 851c93 ]。VoFを使用した非圧縮性非混和流体用の非圧縮性MultiphaseVoFモジュラーソルバーはmultiphaseInterFoamを置き換え、マルチリージョンシミュレーションで使用することができます[ commit ffdb21 ]。compressibleMultiphaseVoF モジュラーソルバーは compressibleMultiphaseInterFoam を置き換えるもので、多領域シミュレーションで使用することができます [ commit 64e1e4 ]。
* 他の混相ソルバー multiphaseEulerモジュールソルバーは、オプションのソース、パーティクル、フィルムモデリングなどを追加するためにfvModelsを使用し、multiphaseEulerFoamを置き換えます[ commit cec035 ]。 incompressibleDenseParticleFluidモジュラーソルバはdenseParticleFoamを置き換えます[ commit e40198 ]充填された領域の境界でパターンをずらすことなく、連続相の一貫した安定した速度を提供するために、面安定化で位相抗力を計算します[ commit 2b74f9 ]。新しい非圧縮DriftFluxモジュールソルバがdriftFluxFoamを置き換えます[ commit b949c2 ]。
* 燃焼ソルバー XiFoamに代わって、圧縮性予混合/部分予混合燃焼のためのXiFluidモジュール式ソルバーが追加され、マルチリージョンシミュレーションで使用できるようになりました[ commit b7ea5f ]。
* 衝撃の捕捉 rhoCentralFoamソルバーが再編成されました[ commit 3055b1 ]。オプションでメッシュトポロジーの変更、負荷分散、メッシュモーションを含む衝撃捕捉を伴う圧縮性流体用のshockFluidモジュールソルバーに置き換えられました[ commit fe5a99 ]。shockFluidモジュールはrhoUとrhoEを保存しながらrho、U、eを解きます[ commit 9fadb7 ]。
* その他のソルバー movingMeshモジュラー・ソルバは、moveMeshの代わりにdynamicMeshDictファイルで指定されたmover、topoChanger、distributorを実行します。functionsモジュラー・ソルバーは、postProcessアプリケーションと-postProcessオプション、特にscalarTransportFoamソルバーを複製して、指定されたソルバーの関数オブジェクトを実行します[ commit 8de6cd ]。
* 粒子ソルバー： particleFoamとrhoParticleFoamアプリケーションソルバーは、それぞれincompressibleFluidとisothermalFluidモジュラーソルバーの上で、fvModelでfunctionsモジュラーソルバーを実行することで複製されるようになりました[ commit fbda1d ]。
* 固体ソルバー固体応力解析のためのsolidDisplacementモジュール・ソルバは、solidDisplacementFoamとsolidEquilibriumDisplacementFoamを置き換えるもので、FSI[ commit 55be80 ]などの多領域シミュレーションで使用できます。
* フィルムソルバ新しいisothermalFilmソルバーモジュールは等温液体膜を保守的にシミュレーションし、標準モデリングとのインターフェイスを提供します[ commit dcbd54 ]。isothermalFilmから派生した新しいフィルムソルバモジュールは、エネルギーと熱伝導を計算し、共役熱伝導を計算するために既存の境界条件を使用することができます[ commit 796cfb ]。
* 数値計算： isothermalFluidモジュラーソルバで浮力圧力の緩和不足が改善されました[ commit c22a5a ]。特殊なSRF(単一参照フレーム)ソルバーを使用したシミュレーションが、MRF(複数参照フレーム)機能を持つ標準ソルバーを使用して完全に再現できるようになりました[ commit 160ee6 ]。compressibleVoFモジュラーソルバに混合物温度の補正式が追加され、エネルギーを節約できるようになりました[ commit 74b302 ]。

== 多相 ==

* モデリング coupledMultiphaseTemperature境界条件は、共役伝熱のためのオイラー・オイラー混相シミュレーションの相温度を結合します[ commit a7d40a ]。圧縮性混相流のために、特定のtwoPhaseChangeModelコードがより一般的なVoFCavitation fvModelに置き換えられ、将来的に他の相変化モデルや界面操作モデルに拡張できるようになりました[ commit 9dc91e ]。multiphaseEulerソルバーに、例えば充填床での沸騰のための固定相のwallBoiling熱伝達モデルが追加されました[ commit 32edc4 ]。圧縮性VoFおよびmultiphaseEulerソルバー用の新しい斉藤キャビテーションモデルが、平面界面での蒸発/凝縮の理論に基づいた物質移動速度を使用するようになりました。[コミット 2f9f8b ]。
* 多相反応（VTTフィンランドと）：新しいwallBoilingProperties関数オブジェクトが壁面沸騰に関連するデータを書き出します[ commit 0da491 ]。multiphaseEulerFoam の粒状材料のジョンソン-ジャクソン部分スリップ境界条件を修正しました。壁沸騰モデルからJayatilleke熱壁関数の重複を削除しました。壁面沸騰で温度外挿がより物理的になり、y+が低い領域でより安定になりました[ commit f6342a ]。壁面沸騰が改良され、境界温度をすべての相で均一に保つために流体相間で指定された熱流束を配分するuniformFixedMultiphaseHeatFlux境界条件が追加されました[ commit 377080 ]。混相流での沸騰がより安定し、エネルギーが節約され、正確になりました[ commit 132111 ]。
* multiphaseEuler ソルバー multiphaseEulerソルバーのセルベースの運動量アルゴリズムが大幅に更新され、一貫性と保存性が改善されました。陰解法による位相分率補正式に単一の拡散係数を追加し、位相分率の和が1になるようにしました[ commit e8078c ]。ドラッグテーブルと仮想質量テーブルがオンデマンドで作成されるようになり、ストレージと計算コストが削減されました [ commit ede5ec ]。抗力と伝熱係数の計算を改善しました[ commit f67445 ]。
* チュートリアル新しいfloatingObjectWavesケースは，waveForcing fvModelによって生成された平均流のない波による浮遊物体の運動を示します．多相シミュレーションのためのfvSchemesの仕様の簡素化 [ commit 1c2f61 ]。

== 輸送モデリング ==

* MomentumTransportModels： lambdaThixotropic 粘性モデルには、オプションでBingham塑性降伏応力[ commit 3b1e46 ]が含まれています。
* ThermophysicalTransportModels：新しい solidThermophysicalTransportModel は固体の熱物理輸送モデルを提供し、異方的な熱伝導率をサポートします[ commit cdaaa6 ]。異方性熱伝導率を持つ境界での熱流束計算を修正しました[ commit 01d2c6 ]。異方性熱伝導率κにオプションのboundaryAlignedスイッチを追加し、κの主方向を固体境界に合わせるようにしました [ commit d26e0f ]。
* 乱流： Jayatilleke wall functionの計算を改善しました。

== 熱物理モデリング ==

* 熱力学： fvSolution, 境界条件などの入力ファイルキーワードにおける熱物性名の指定を簡略化し、標準化しました [ commit 87a0b8 ]。新しいconstSolidThermoが一様および非一様な熱物性値指定をサポートしました[ commit 714e13 ]。constSolidThermoを使用した特性は、非一様なフィールドとして表現するか、ゾーンに基づいて表現することによって、領域全体で変化させることができます[ commit a25f99 ]。
* 輸送：熱物理学的輸送を再設計し、領域間および外部境界の境界条件をよりシンプルに、拡張可能に、メンテナンスしやすくしました[ commit 5af541 ]。constAnisoSolidThermo熱物性クラスを使用して異方性熱伝導率を指定できるようになりました[ commit 5c296c ]。
* 設定：熱物性辞書の名前に正規表現が使えるようになりました [ commit 523333 ]。
* 化学：化学積分において、化学種ソースが質量を保存するようになりました[ commit 3d59ed ]。adjustTimeStepToChemistry関数とadjustTimeStepToCombustion関数は反応プロセスに合わせて時間ステップを調整します[ commit 7c684b ]。moleFraction関数は質量分率をモル分率に変換し、massFractionはその逆に変換します[ commit 1b80fd ]。

== 熱伝達 ==

* 数値計算 compressibleInterPhaseThermophysicalTransportModelは、compressibleVoFモジュラーソルバを使用した混相流による共役熱伝達を可能にします。
* 境界条件：臨界境界条件をよりシンプルで合理的な名前にすることで、熱伝導のシミュレーションがより簡単になります[ commit 5c01fe ]。
* 例新しいcircuitBoardCoolingチュートリアルケースは、3Dサーマルバッフル[ commit 3f33f3 ]による共役熱伝達への効果的なアプローチを示しています。

== パーティクルとトラッキング ==

* トラッキング：ラグランジュパーティクルの境界相互作用が制約境界で修正されました[ commit 6ccaf6 ]。メッシュ間のマッピングを使用してトポロジーが変更された場合にパーティクルがマッピングされるようになりました[ commit 03b061 ]。
* 射出：粒子(ラグランジュ)機能において、サブサイクルを削除し、インジェクションの動作を改善しました[ commit 06e29c ]。統計分布が一般化され、パーティクルのサイズ分布に使用されるようになりました[ commit cae419 ]。新しいuniformParcelSizeコントロールがパーティクルの固定数、体積、表面積にパーセルサイズを基づかせるようになりました[ commit 0d2fd7 ]。
* 設定：任意のシミュレーションに粒子をプラグインするのに役立つ、雲モデル用のサンプルfvModelsファイルを追加しました[ commit 399ea8 ]。
* モデリング： MPPICの近似補正トラックを予測器-補正器スキームに置き換え、メモリ使用量を削減し、トラッキング時間と関連するパーセル特性へのアドホックな補正を回避しました[ commit ca0003 ]。
* データ収集：粒子のフラックス（数、体積、質量）はCloudFunctionObjects [ commit f69b9f ] で計算できます。

== 液体フィルム ==

* 概要 isothermalFilmとフィルムソルバモジュールは、現在削除されているsurfaceFilmModelsライブラリを置き換えるものです。新しいアプローチはより柔軟で、ガス流、ラグランジュ雲、VoF、CHTなどの他の領域との結合が可能です。
* フィルム-流体界面： filmVoFTransferとVoFFilmTransfer fvModelsはフィルムとVoF領域の間で動作し、フィルムが十分に厚い場合はフィルムをVoF相に移動させ、VoFフィルムが薄すぎる場合はその逆を行う[ commit 72b876 ]。
* フィルムと粒子の相互作用：パーティクルは、流体 cloudProperties ファイルで cloudFilmTransfer surfaceFilmModel を指定し、filmCloudTransfer fvModel をフィルムに適用することで、表面のフィルムに移動することができます[ commit a2ad71 ]。filmCloudTransferのfvModelに、反転した表面や曲率分離からの滴下によってフィルムから粒子（パーセル）に流体を転送するオプションの排出モデルが追加されました[ commit 2cf8f6 ]。
* 境界条件： mappedFilmPressure境界条件は流体領域からフィルム領域に圧力をマッピングします[ commit 12decc ]。新しいfilmSurfaceVelocity境界条件は、隣接する流体領域によって課されるせん断からフィルム表面の速度を評価します[ commit 423fa5 ]。
* 例 rivuletBoxのサンプルケースは、アルミニウムパネル、小滴を形成する流体の膜、自然対流で流れる周囲の空気の間の熱伝達を実証しています[ commit cee34f ]。

== Meshes ==

* 一般： allGeometryオプションを使用すると、checkMeshは非整形カップル(NCC)のカバレッジを書き出します[ commit 095f4b ]。
* 生成： extrudeRegionToMesh ユーティリティで intrude オプションを使用してフィルムメッシュを生成できるようになりました [ commit f85026 ]。
* 非形式結合：非形式結合(NCC)は任意メッシュインターフェース(AMI)を置き換えるもので、回転する形状やメッシュの非整合領域などに対して、拘束された保守的な数値計算を提供します[ commit f4ac5f ]。メッシュ間のトポロジーの変更に対応するNon-conformal couplingを追加しました[ commit 3ec358 ]。createNonConformalCouples ユーティリティに -fields オプションを追加し、フィールドファイルに非整形カップルに関連するパッチエントリを追加するようにしました [ commit 2db562 ]。Non-Conformalカップルを "stitched "することで、Paraviewなどで補間されたフィールドデータを視覚化する際に不連続性を回避できるようになりました。メッシュからメッシュへのマッピングを含むケースで動作するようにNCCを修正しました[ commit 919972 ]。非共形結合が2次の時間スキームをサポート [ commit a4ca75 ]。多重回転フレーム(MRF)が非共形結合(NCC)と互換性を持つようになりました [ commit a430d0 ]。
* その他新しい rigidBodyPoints functionObject は剛体上の点の動きを追跡します [ commit 386588 ]。メッシュの動きとトポロジーの変更に伴う古いフィールドの更新と削除を一般化 [ commit 30eb5e ]。
* マッピング：メッシュ間のマッピング機能が大幅にリファクタリングされました [ commit 582438 ]。メッシュの再配分がパーティクルを処理できるようになりました [ commit 8f7ae7 ]。共形および非共形インターフェースの両方に対するパッチ間マッピングのロバスト性が改善されました [ commit 020361 ]。メッシュ間マッピングと mapFieldsPar ユーティリティを合理化しました [ commit f95eb5 ]。
* 分解と再配布： reconstructParユーティリティは分解されたメッシュをフィールドと同様に再構築するようになったので、reconstructParMeshユーティリティは必要なくなり削除されました[ commit c3ab70 ]。

== 機能オブジェクト ==

* 一般：マルチリージョンシミュレーションでメッシュ領域に適用される関数オブジェクトが標準パスにファイルを書き込むようになりました[ commit 5b11f5 ]。新しいstopAtTimeStep関数オブジェクトが、時間ステップが指定したレベル以下になった場合にシミュレーションを停止するようになりました[ commit 4974cc ]。
* サンプリング： triSurfaceAverage関数オブジェクトは、指定された三角形サーフェス上のフィールドの平均を計算します[ commit c5d70f ]。 cutPolyは、新しい多面体切断ルーチンと、既存のツールよりもロバストで高速な等値面アルゴリズムを提供します[ commit 723f52 ]。
* メッシュ：新しい checkMesh functionObject は動的メッシュの場合のメッシュの品質をレポートします [ commit 36e834 ]。
* フィールド： fieldAverage 関数オブジェクトは構築時に存在しないフィールドを平均化できるようになり、メッシュのトポロジーが変化するケースでも再スタート時に動作するようになりました [ commit 3e8b97 ]。新しいvolAverageとvolIntegrateパッケージ関数オブジェクトはフィールドの体積加重平均と体積積分を便利に処理できます[ commit 5c7131 ]。

== モデルと制約 ==

* 一般： fvModel 関数オブジェクトを使用して、controlDict ファイルから fvModel を設定できるようになりました [ commit 9f6eac ]。また、#includeModel および #includeConstraint ディレクティブは、controlDict ファイルの functions サブディクショナリから fvModel および fvConstraints をインクルードできるようになりました [ commit 3a269e ]。関数オブジェクト、fvModel、fvConstraint の名前と、関連する出力ディレクトリを name キーワードで指定できるようになりました [ commit dc85d5 ]。regionTypeとselectionModeに代わって、selectキーワードがセル、面、点のコレクションを指定するのに使われるようになりました[ commit 295223 ]。zeroDimensionalFixedPressure fvModelとfvConstraintがゼロ次元の場合の圧力拘束を維持するようになりました[ commit 9cdd2a ]。
* fvModels： surfaceFilms fvModelは、surfaceFilm（単数）モデルを置き換えることで、潜在的に異なる仕様の複数のフィルムをサポートします[ commit b1de50 ]。新しいwaveForcing fvModelは、ドメインインレットで適用することなく、任意の方向に動くように設定できる表面波を生成します[ commit 562925 ]。densityConstraintSourceとpressureConstraintSource fvModelは0次元シミュレーションに膨張/収縮、または質量ソース/シンクを含めることができます[ commit 644a59 ]また、0次元シミュレーションを簡素化するために設定なしで単位立方体形状を生成するzeroDimensionalMeshユーティリティが追加されました[ commit 099505 ]。massSource fvModelは負の質量流量が指定された場合に質量を除去します[ commit d7e330 ]。heatTransfer fvModel が多相シミュレーションの個々の相に適用できるようになりました [ commit 3736bc ]。
* fvConstraints：新しい束縛fvConstraintは、スカラー・フィールドが指定された最小値以下になった場合にそのフィールドを束縛します[ commit 1a17ce ]。

== 一般的な境界条件 ==

* Pressure: waveSurfacePressure境界条件がisothermalFluidとfluid modularソルバーでポテンシャル自由表面流を解くように更新され、potentialFreeSurfaceFoamソルバーは廃止されました[ commit 897658 ]。
* 速度 MRFslip 境界条件はMRF(多基準フレーム)またはSRF(単一基準フレーム)の場合に移動フレームと一緒に回転するスリップウォールに使用できます[ commit ef9566 ]。回転速度(rad/s)を表すomegaエントリは、ユーザーが1分あたりの回転数でデータを入力したい場合、rpmに置き換えることができます[ commit 2da5ed ]。
* 一般： mappedPatch 境界条件は別のフィールドや別のパッチからのデータを適用します。新しい samePatch スイッチは同じパッチからのフィールドデータに対して単純化します [ commit 320e70 ]。autoMapとrmapに代わり、単一のmap関数が境界条件クラスでパッチ間のマッピングを行うようになりました [ commit 38e8e7 ]。

== ケース構成 ==

* データ可視化： foamSequenceVTKFiles スクリプトは、異なる画像シーケンスで同じ名前のファイルを処理するようになりました [ commit 7f17fc ]。
* ケースの初期化：関数ソルバーは、別のソルバーによって初期化されたフィールドに基づいて関数オブジェクトを実行します。フィールドデータが読み込まれる時間は、controlDictファイルのsubSolverTimeエントリによって任意に設定できるようになりました[ commit 714291 ]。結果はcontrolDictで指定されたwriteIntervalの倍数で、開始時間またはオプションのbeginTime項目で設定された時間から書き出されます[ commit 0fa46e ]。新しいsnappyHexMeshConfigユーティリティがsnappyHexMeshでメッシュを作成するために入力ファイルを事前設定します[ commit c25529 ]。
* コード入力：特に#codeStreamディレクティブを使用した入力ファイルのキーワード値エントリを生成するのに便利です[ commit d1cb13 ]。codeStreamと#calcで構築された辞書エントリは型付き変数を便利に使用できるようになり、ベクトル、テンソル、リスト、フィールドなどでの計算が可能になりました [ commit b2d4f2 ]。新しい#calcIncludeディレクティブは、数学関数をインクルードするなど、#calc用のヘッダファイルをロードすることができます[ commit 0de23d ]。入力ファイル用の #calc ディレクティブで、代替の #{ ... #} 区切り文字を使用できるようになりました [ commit 8611db ]。calcによる複数行のエントリは、#codeStreamをエミュレートしつつ、よりシンプルな構文で、入力ファイルにより有用なコード化されたエントリを可能にします [ commit 441b60 ]。
* モデルとオプションの検索: 新しいfoamToCアプリケーションは "目次 "を印刷し、報告し、ユーザーがモデルを見つけ、異なるモデルのオプションをリストアップすることを可能にします[ commit f978ff ]; それは正規表現検索に基づいた機能をリストアップすることができます[ commit db7ea4 ]。

== プログラミング ==

* その他の数値計算新しいfvm::LaplacianCorrection関数により、熱輸送の実装がより効率的でシンプルになりました。熱物理学的輸送特性は輸送方程式を含まないため、時間ステップの最初に計算されるようになりました[ commit ce42eb ]。輸送方程式を解かない計算の場合、運動量輸送特性は時間ステップの最初に計算されるようになりました[ commit d9ba28 ]。fvc::flux()関数をテンプレート化し、ベクトル流束をサポート [ commit 42c35a ]。新しいfvm::divc関数は、指定されたフラックスの発散を含む明示的なソースを持つ行列と、fluxRequired設定に従ってキャッシュされたフラックスを返します[ commit 1182d3 ]。ddtCorrを多重回転フレーム(MRF)で拡張し、数値振動の原因となる圧力、速度、フラックス間のデカップリングを回避しました[ commit e98dcc ]。連続性を確保するためにフラックスを補正するCorrectPhi関数にいくつかの改良が加えられました; これらはVoFや他の多相ソルバーにとって特に重要です[ commit e66484 ]。
* フィールド： GeometricField<Type、fvPatchField、volMesh>とGeometricField<Type、fvsPatchField、surfaceMesh>はよりシンプルなVolField<Type>とSurfaceField<Type>型定義に置き換えられました[ commits 73c562 ]。
* functionObject、fvModel、fvConstraint を使用する場合、可能であれば関連するライブラリが自動的にロードされるようになりました [ commit 0b8c17 ]。

OpenFOAM 10 リリースノート

2023-09-09T12:55:52Z

Mmer547: ページの作成:「 OpenFOAM Foundationは、オープンソースCFDツールボックスOpenFOAMのバージョン10のリリースを発表します。バージョン10は、OpenFOAM開発版のスナップショットで、持続可能な開発により、常にリリース可能です。使いやすさ、ロバスト性、拡張性が厳しく要求される中、新機能と既存コードの大幅な改良を提供します。 OpenFOAM 10には、次のような重要な…」

OpenFOAM Foundationは、オープンソースCFDツールボックスOpenFOAMのバージョン10のリリースを発表します。バージョン10は、OpenFOAM開発版のスナップショットで、持続可能な開発により、常にリリース可能です。使いやすさ、ロバスト性、拡張性が厳しく要求される中、新機能と既存コードの大幅な改良を提供します。

OpenFOAM 10には、次のような重要な開発が含まれています。

* 多相：モデルの追加、多相ソルバーのパフォーマンスとロバスト性の向上。
* トランスポート：プロパティを単一の physicalProperties ファイルに統合。
* 熱物理：導電率の取り扱いを改善し、ドキュメントを追加。
* 熱伝導：共役熱伝導における熱結合の改善。
* パーティクルトラッキング：雲のfvModelを使ったソルバーにプラグインできるようになりました。
* 反応：化学では、熱膨張を考慮して質量分率を求める。
* 並列化：負荷分散、分解、再分配のための新しいフレームワーク。
* メッシュ：snappyHexMesh、blockMesh、その他のツールの全般的な改善
* ダイナミックメッシュ：AMIに代わる回転ジオメトリ用の非整合結合（NCC）。
* 動的リメッシング：エンジンを含むメッシュモーションのためのメッシュ間マッピング。
* ファンクションオブジェクト：サンプリングのためのより効率的な出力、および新しいフィールド計算。
* モデルと制約：メッシュケースの移動とファンクションオブジェクトでの動作が可能になりました。
* 境界条件：圧力、速度、温度の新しい一般条件。
* ケース・コンフィギュレーション：カスタマイズされた時間の尺度を提供するためにuserTimeを作成。
* 計算：壁までの距離計算、時間処理、I/Oの改善。
* 約635件のコードコミット、161件の問題解決。
* ISO/IEC 14882:2011 (C++14): GCC v5.4+、Clang v10+でテスト済み（v6+でも動作するはず）。

OpenFOAM 10は、以下のプラットフォーム用にパッケージ化されています。（サポートされている）グラフィックス・カードがないシステムでは、ParaView 5.6（LLVM/Galliumアクセラレーション付きMesaを含む）[2023年1月更新：ParaView 5.10.1（LLVM/Galliumアクセラレーション付きMesaを含む）]。

* Ubuntu Linux: packaged installation for Ubuntu 18.04 20.04 and 22.04 [ ''22.10 added Jan 2023'' ];
* その他のLinux：Dockerコンテナによるインストール、またはソースコードからのコンパイル；
* Windows 10: Windows Subsystem for LinuxとUbuntuパックを使用したインストール；
* macOS: Dockerコンテナによるインストール。

OpenFOAM 10 Source Packは、適切なLinuxプラットフォームでコンパイルできます。

== 多相 ==

* モデリング：表面波を（波長の代わりに）周期を入力して指定できるようになりました[ commit 559fe8 ]。また、境界での流れの反転が可能になったので、波はどの方向でも、平均流がゼロでも指定できるようになりました[ commit 1c4868 ]。液体の蒸発モデリングに凝縮スイッチを追加 [ commit cc3b25 ]。multiphaseEulerFoamのサブモデルのブレンドが3相以上のシミュレーションのために拡張されました[ commit 428c54 ]。driftFluxFoamのコロイド分散に対する新しいQuemada粘度モデル [ commit f4b497 ]。driftFluxFoamのMRFによる遠心加速度を修正しました。driftFluxFoamに凝集懸濁液のMichaels and Bolgerモデルを追加。driftFluxFoamで、流れの曲率が連続相からの分散相の分離に物理的に影響するようになりました[ commit 620cbe ]。
* Reacting Multiphase (VTT FinlandおよびHZDR Dresden-Rossendorfとの共同研究)： Liao et alの合体および分解モデルを追加しました[ commit fe9829 ]。新しいモーメント関数オブジェクトがポピュレーションバランス法で計算された粒度分布の平均特性を計算します[ commit 36c565 ]。multiphaseEulerFoamに固体粒子の合体および破壊モデルを追加しました[ commit b4bcb2 ]。母集団バランス法における膨張の計算を改善しました[ commit 376b51 ]。
* パフォーマンス/数値計算： compressibleInterFoamの温度方程式はデフォルトでは全内部エネルギーに基づいて定式化されますが、totalInternalEnergyをfalseに設定することで内部エネルギーに基づいて定式化することができます[ commit 12dc41 ]。 compressibleMultiphaseInterFoamがfvModelsとfvConstraintsをサポートするようになりました[ commit 13b782 ]。相率 alpha → 0 の場合の多相ケースの安定化が改善されました[ commit 3df883 ]。新しいphaseStabilisedおよびphaseStabilisedSnGrad補間スキームが、位相分率が1e-3より小さい場合に有界形式に戻すことにより、貧弱なメッシュ上での多相EulerFoamの実行を安定化させるようになりました[ commit 7b3631 ]。
* チュートリアル固体粒子の合体および破壊を示す90°曲がり管内の流れのチュートリアル例（Kasper Gram Bilde、HZDR Dresden-Rossendorf との共同研究） [ commit 0999cd ]。

== 輸送モデリング ==

* 一般：非圧縮性、圧縮性、単一相、多相、単一領域、多領域の流れに対して、特に単一の physicalProperties ファイルによる流体特性の指定を統合しました[ commit 65ef2c ]。
* MomentumTransportModels：燃焼のチュートリアルで、輸送特性を計算するためのWilke混合則を示すようになりました[ commit 393023 ]。新しい Andrade モデルが液体の動的粘性と熱伝導率の自然対数を計算するようになりました[ commit 26f0e4 ]。
* ThermophysicalTransportModels： listThermophysicalTransportModelsオプションを指定してソルバーを実行すると、熱物理輸送モデルをリストアップできるようになりました。
* 乱流：新しいVoFTurbulenceDamping fvModelはVoF界面で乱流減衰を適用します[ commit 4f9694 ]。mixtureKEpsilonモデルのεmフィールドにεmWallFunctionを追加しました[ commit 3bac21 ]。レイノルズ応力(R)乱流モデルにおいて、Rと速度Uの結合が改善され、ダクト内の二次流れを示す新しいチュートリアルが追加されました[ commit a34604 ]。

== 熱物理モデリング ==

* 熱力学：状態方程式 [ commit c86c64 ]、熱力学 [ commit b3e02d ]、輸送モデル [ commit 8dbbe1 ]のヘッダードキュメントを拡張。状態方程式に体積熱膨張係数の関数を追加 [ commit 2d7a57 ]。熱力学は熱拡散率 alpha ではなく熱伝導率 kappa を熱輸送の基本パラメータとして保存するようになりました [ commit cc96ab ]。
* 輸送： const輸送モデルで、プランドル数の代わりに導電率を指定できるようになりました[ commit cd1f69 ]。

== 熱伝達 ==

* 数値計算共役熱伝達において、新しいnEcorrループが流体と固体領域間の熱結合が支配的なケースを改善します[ commit f52d86 ]。buoyantSimpleFoamとbuoyantPimpleFoamは、圧縮性流体の定常または過渡の浮力乱流ソルバーbuoyantFoamに統合されました[ commit d40ecd ]。

== パーティクルとトラッキング ==

* ソルバー雲fvModelは、非圧縮性ソルバーと圧縮性ソルバーの両方で、様々なレベルの結合でシミュレーションに粒子を追加することができます[ commit 5f1146 ]、例を参照してください[ commit 24a359 ]。
* トラッキング：トラッキングのロバスト性を改善し、ハングアップ、ゼロ除算、浮動小数点エラーを防止しました [ commit 5272e4 ]。

== 反応する流れ ==

* 化学：化学モデルは熱膨張に伴う反応速度の変化を考慮するため、濃度ではなく質量分率を解くようになりました[ commit 4f0dfc ]。In-Situ Adaptive Tabulation (ISAT) 化学モデルがリファクタリングされ改善されました[ commit 8145de ]。
* 燃焼： fixedTemperature 制約を使用した着火の例を追加しました [ commit 19b3b2 ]。
* 集計： in-situ adaptive tabulation (ISAT) に関するいくつかの問題を修正しました[ commit 011397 ]。

== 平行移動 ==

* ロードバランシング：一般的なCPUロードバランサーのプロトタイプがローカルセルの計算負荷に基づいてメッシュを並列に再分配します。新しいfvMeshDistributorsライブラリはシミュレーション中のメッシュの並列再配布、特にロードバランシングを提供します[ commit bf5f05 ]。
* 分解と再配分： fvMesh 内に新しいフレームワークを作成し、ロードバランシングなどの実行時のメッシュ再分配を扱えるようにしました [ commit 687996 ]。負荷分散のためのメッシュ再分配をサポートするためにMeshObjectsに新しいdistribute関数を追加しました[ commit a0ac78 ]。並列ケース用のメッシュの分解と再分配のための個別のコントロールを導入 [ commit f97f63 ]。Zoltanライブラリを使用した新しい並列メッシュ再配分 [ commit 340856 ]。2次時間スキームで実行される移動メッシュケースが再配分によって実行できるようになりました[ commit 97eee8 ]。
* 最適化： MULESのリミッター計算の並列効率が改善されました[ commit 8cc05a ]。 decomposeParが最小IOのために最適化され、時変メッシュのシーケンスを分解できるように修正されました[ commit 399545 ]。

== メッシュ ==

* 一般：メッシュ生成時に fvMesh と fvSolution ファイルが不要になりました [ commit ddbf2d ]。メッシュデータは、メッシュの動きとトポロジーの変更が発生した場合にのみ、時間ディレクトリに書き込まれるようになりました [ commit b439fc ]。
* snappyHexMesh：バッフルを持つ複数のlocationInMeshの処理を修正しました[ commit 115144 ]。addLayersがオフの時、addLayersControlsサブ辞書をsnappyHexMeshDictファイルから完全に削除できるようになりました[ commit d87a93 ]。
* blockMesh：境界パッチ内で指定されていないブロック面は、defaultPatchエントリで名前とタイプを指定できるデフォルトパッチに集められます[ commit 99cfbd ]。
* 操作： topoSetユーティリティは非推奨となったsetSetユーティリティを完全に置き換え [ commit 8d887e ]、入力ファイルの構文を簡略化 [ commit 6a657c ]。Zoltan ライブラリを使用した並列ケースでメッシュのリナンバリングを有効にしました [ commit d90f42 ]。createPatch ユーティリティ [ commit 930207 ] と createBaffles ユーティリティが単純化されました [ commit f93300 ]。topoSet で、指定した回転を使用する rotatedBoxToCell ソースによりシンプルな入力オプションを追加しました [ commit c18039 ]。
* 変換： Fluent3DMeshToFoamメッシュコンバーターがFluentバージョンR2021用に更新されました[ commit 318f78 ]。
* サーフェスジオメトリ： transformPointsとsurfaceTransformPointsの新しい構文を説明する-helpオプションが追加されました。

== ダイナミック・メッシュ ==

* ノンコンフォーマルカップリング Non-Conformal Coupling (NCC)は、特に、回転するジオメトリをシミュレートする場合など、1つ以上の領域が移動する場合に、信頼性が低く、不正確なAMIとACMI機能に代わって、独立したメッシュで領域の領域を接続します[ commit 569fa3 ]。AMI、ACMI、リピートAMIのすべてのチュートリアル例がNon-Conformal Couplingを使用するように変更されました。ACMI と Repeat AMI は信頼性が低いので OpenFOAM から削除され、Non-Conformal Coupling に置き換えられました。AMI は v10 リリースまで残りますが、その後削除されます。[コミット b4b8b2 ]。
* その他 moveDynamicMeshユーティリティはmoveMeshに改名され、同名のユーティリティは廃止されました[ commit 31da3a ]。シミュレーションがトポロジカルメッシュの変更リストを受けられるようになりました[ commit 45428b ]。剛体力学に回転ジョイントを追加しました。例えば、移動する船にプロペラを組み合わせるために使用します [ commit 0289f3 ]。

Non-Conformal Coupling の詳細については、"OpenFOAM Non-Conformal Coupling" および "Using NCC in OpenFOAM" を参照してください。

== ダイナミック・リ・メッシング ==

* マッピング： mapFields ユーティリティのコードを簡素化しました [ commit 08b7a9 ]。最新のmesh-to-mesh mappingでは、トポロジーやジオメトリの変更、メッシュの精密化および精密化解除などを管理するために、事前に生成されたメッシュのセットを使用できます [ commit 47b0cd ]。メッシュ間マッピングが並列実行時のメッシュ間の分解の変更をサポートするようになりました [ commit f0e693 ]。
* エンジン：エンジンシミュレーション用の新しいエンジンとlayeredEngine fvMeshMoverを追加しました [ commit 941ea1 ]XiFoamで使用されるようになり、XiEngineFoamは冗長になりました [ commit 8f14b6 ]。エンジンfvMeshMoverのエンジンバルブとピストン機能をリファクタリングしました [ commit 49faf0 ]。rhoPimpleFoamとエンジンfvMeshMoverは反応なしでエンジンをシミュレーションすることができ、coldEngineFoamソルバーを冗長化します [ commit 640cd6 ]。同様にreactingFoamは化学反応ありのエンジン計算をシミュレーションすることができ、engineFoamソルバーを冗長化します [ commit facc36 ]。

== ファンクション・オブジェクト ==

* サンプリング：サンプルのサーフェスはすべてのフィールドデータを1つのファイルに書き出すようになり、ビジュアライゼーションの後処理を簡素化し、サーフェスジオメトリデータの重複を避けることでディスク容量を削減しました [ commit 261ce0 ]。CSVフォーマットの書き込みを改善しました。サンプリングデータにおいて、トラッキングが現在の時間レベルで確実に実行されるようになりました[ commit 41b73e ]。ストリームラインが周期境界を越えて伝播するようになりました [ commit 701fc2 ]。サンプリングとストリームラインを改良し、無駄なファイル書き込みを減らし、サンプリング・セグメントと並列化の信頼性を高め、インターフェイスを改善しました[ commit 25a6d0 ]。新しいlayerAverage関数オブジェクトがpostChannelポスト処理ユーティリティを置き換えます[ commit 053eed ]。layerAverage関数オブジェクトを書き換えて、例えばカーブしたパイプのような複雑な形状の変化にも対応できるようにしました [ commit d5820b ]。
* 視覚化：サーフェス関数オブジェクトにwriteEmptyオプションを追加し、特にアニメーションを生成する際のisoSurfacesに空のファイルを書き出すようにしました[ commit 2d1428 ]。
* フィールド： confort関数オブジェクトはドラフトレートを計算するために拡張されています[ commit 19950f ]。scalarTransport関数オブジェクトは、特に拡散がなく、圧縮または(M)PLICスキームを使用してシャープな界面が維持されている場合に、境界性を確保するためにMULESを使用するオプションを含んでいます[ commit aa6c04 ]。wallShearStress関数オブジェクトが多相系での指定相の壁せん断応力を処理できるようになりました[ commit e6acc7 ]。 wallHeatFlux 関数オブジェクトが多相系で指定した相の壁熱流束を計算できるようになりました [ commit 7d4dca ]。

パッケージ化された機能オブジェクトの最新リストについては、ユーザーガイドを参照： 6.2 後処理 CLI を参照してください。

== モデルと制約 ==

* 一般： fvModelsとfvConstraintsにメッシュモーション用のアップデートを追加しました[ commit 19bdfa ]。 fvModelsとfvConstraintsは方程式を解く関数オブジェクト、例えばscalarTransport、スカラー場のモデルと制約を提供する関数オブジェクトと連動できるようになりました[ commit 987d59 ]。
* fvModels： actuationDisk fvModelが多相ソルバーで動作するようになり [ commit 96de80 ]、ディスクの向きをサポートするようになりました [ commit 991489 ]。時間ステップをfvModelで制限できるようになりました[ commit e478bb ]。新しいinterfaceTurbulenceDamping fvModelが相界面付近の乱流の減衰を提供するようになりました[ commit 898924 ]また、phaseTurbulenceStabilisation fvModelが相率→0の場合に相の乱流特性を安定させるようになりました[ commit 9925df ]。
* fvConstraints： limitTemperature fvConstraintが、compressibleInterFoamのような、エネルギー方程式の解変数として温度を使用するソルバーに対応しました[ commit fb53b9 ]。limitPressure fvConstraintに制限圧力場を指定するオプションを追加しました[ commit 3b3127 ]。limitVelocity fvConstraintをより一般的なlimitMagに置き換えました。

== 一般的な境界条件 ==

* Pressure: 新しい transonicEntrainmentPressure 境界条件は、ユーザーが指定できるマッハ数 [ commit 63ef6f ] から始まる超音速流出とゼロ勾配に向かってブレンドすることにより、出口境界 [ commit d10f22 ] で超音速ジェットをサポートします。totalPressure境界条件は、フリーストリームで指定できる外部接線速度[ commit a36082 ]で確実に機能します[ commit ba5612 ]。
* 速度：新しいmovingWallSlipVelocity境界条件は、動く壁のスリップ条件を提供します[ commit 80c1a6 ]。 flowRateInletVelocity 境界条件で、層流境界層と乱流境界層に対応するオプションの流速プロファイルと、平均流速に基づく流速指定を選択できるようになりました[ commit 8bb48d ]。
* 温度 externalWallHeatFluxTemperature 境界条件は、複数の熱源、すなわちパワー、フラックス、伝達係数を同時に設定できるようになりました[ commit 373c49 ]。
* 一般：テンソルの回転周期変換を修正しました。

== Case Configuration ==

* データ可視化： foamCreateVideoに新しいオプションが追加され、動画の開始時や終了時に一時停止ができるようになった [ commit c70a7b ]。
* ケースの初期化： userTimeの概念を一般化し、controlDictで設定することで、実行時間をカスタマイズされた時間の尺度に変換することができます。例えば、データI/Oのためのクランク角などです。engineTimeは、標準ソルバーにエンジンシミュレーションを統合するためのさらなるステップとして、設定可能なengine userTimeに置き換えられました。

== Programming and Computation ==

* データ入力：オブジェクトファイルの存在をチェックし、オブジェクトを構築することなくヘッダをチェックできるIOobjectの新しいtypeIOobject [ commit b91233 ]。I/Oにおけるファイルパスの取り扱いを合理化した[ commit cc9233 ]。
* その他の数値計算: cpuTimeがPOSIX clock()関数を使用するようになり、分解能が向上しました[ commit 01f075 ]。圧縮性ソルバーで圧力方程式の計算開始時の密度予測を標準化しました [ commit 468954 ]。meshWave機能の重複コードを削除し[ commit 20ef80 ]、最も近い壁までの距離計算で使用される変換インターフェイスによる計算を単純化しました[ commit 4e0577 ]。壁までの距離の計算がプロセッサーや周期的な境界でより一貫したものになり、計算の精度をより細かく制御できるようになりました [ commit 9d702d ]。
* コンパイル： GCC コンパイラ v11 [ commit d83c87 ] と OneAPI Intel コンパイラ [ commit 37108e ] のサポートを追加しました。

OpenFOAM

2023-09-09T12:48:58Z

Mmer547:

このページではOpenFOAMについてまとめていきます。

== リリースノート ==

'''OpenCFD'''

[[OpenFOAM v2306リリースノート|OpenFOAM v2306 リリースノート]]

[[OpenFOAM v2212 リリースノート]]

[[OpenFOAM v2206 リリースノート]]

[[OpenFOAM v2112 リリースノート]]

[[OpenFOAM v2106 リリースノート]]

[https://www.notion.so/OF2012-3625e0d8029b40bda20fafe481dcbd95 OpenFOAM v2012 リリースノート]

[[OpenFOAM v2006 リリースノート]]

[[OpenFOAM v1912 リリースノート]]

[[OpenFOAM v1906 リリースノート]]

[[OpenFOAM v1812 リリースノート]]

[[OpenFOAM v1806 リリースノート]]

'''The OpenFOAM Foundation'''

[[OpenFOAM 11 リリースノート]]

[[OpenFOAM 10 リリースノート]]

[[OpenFOAM 9|OpenFOAM 9 リリースノート]]

[[OpenFOAM 8 リリースノート]]

[[OpenFOAM v7 リリースノート]]

[[OpenFOAM v6.0 リリースノート]]

[[OpenFOAM 4.0 リリースノート]]

[[OpenFOAM 3.0.0 リリースノート]]

[[OpenFOAM 2.4.0 リリースノート]]

==スターティングガイド==
[[OpenFOAMについて]]

[[OpenFOAMのインストール]]

[https://qiita.com/mmer547/items/e63d4cf76ea2fea659b2 チュートリアルケースの実行]

[https://qiita.com/mmer547/items/24b8491bf9776c3a27db OpenFOAMで入力できる項目の調べ方]

[https://qiita.com/mmer547/items/e4b13100e15508981a85 OpenFOAMの$FOAM変数]

==困った時は？==
[https://qiita.com/mmer547/items/7c7c257dcaf2efbc730b OpenFOAM Google Groupに投稿する際に抑えるポイント]

[https://qiita.com/mmer547/items/6b041536e2ac5dd17721 OpenFOAMで計算するネタがない時の探し方]

[[OpenFOAMのエラーメッセージの対応]]

==プリプロセス==

===形状作成===

[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%EF%BC%9A%E5%BD%A2%E7%8A%B6%E4%BD%9C%E6%88%90 形状作成ツールまとめ]

===メッシュ===
[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%E3%81%AE%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A3%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 OpenFOAMのメッシャーについて]

[[メッシュ作成:blockMesh]]

[[メッシュ作成:snappyHexMesh]]

[[メッシュ作成:cfMesh]]

[https://qiita.com/mmer547/items/9fca38b8e8eadc869bb8 SalomeでOpenFOAMのメッシュを用意する方法]

===境界条件===
[[境界条件]]

==ソルバ==
[[simpleFoamについて]]

[[ExecutionTimeとClockTimeについて]]

[https://scrapbox.io/opencae-kansai-memo/SIMPLEC%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E8%A8%88%E7%AE%97%E5%AE%9F%E8%A1%8C%EF%BC%88OpenFOAM3.0.1%EF%BC%89 SIMPLECを使用した計算実行（OpenFOAM3.0.1）]

===並列計算の実行方法===

[[decomposeParDictの中身]]

===エラーメッセージ===
[[v1806のエラーメッセージ]]

==ポストプロセス==
[[ログファイルから残差ログを抽出]]

[https://qiita.com/mmer547/items/e463235ddb93f08db68a OpenFOAMのpostProcessについて]

==チュートリアルケース==
[[チュートリアルケース|チュートリアルケース一覧]]

==カスタマイズ==
[https://qiita.com/mmer547/items/2997bf8c71fe1e2423c9 OpenFOAM ソースコードの探し方]

==その他==
[https://scrapbox.io/opencae-kansai-memo/foam-extend_4.0%E3%82%92Bash_on_Ubuntu_on_Windows%E3%81%AB%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB foam-extend 4.0をBash on Ubuntu on Windowsにインストール]

[https://scrapbox.io/opencae-kansai-memo/ESI_Windows%E7%89%88OpenFOAM%E3%81%AE%E5%B0%8E%E5%85%A5 ESI Windows版OpenFOAMの導入]

[https://gitlab.com/OpenCAE/Supercomputer-OpenFOAM-Training/-/wikis/home スーパーコンピュータOpenFOAM講習会]

== 関連サービス ==
=== プリプロセス ===
[https://www.xsim.info/products/products.html XSim.Work]

== 関連書籍 ==

[https://www.amazon.co.jp/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEDEXCS-OpenFOAM%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E9%87%8E%E6%9D%91-%E6%82%A6%E6%B2%BB/dp/4621306138/ref=sr_1_5?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-5 オープンCAEのためのDEXCS for OpenFOAMハンドブック]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E7%AC%AC2%E7%89%88-%E4%B8%80%E8%88%AC%E7%A4%BE%E5%9B%A3%E6%B3%95%E4%BA%BA%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691025/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-1 OpenFOAMによる熱移動と流れの数値解析(第2版) ]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AE%E6%AD%A9%E3%81%8D%E6%96%B9-%E6%8A%80%E8%A1%93%E3%81%AE%E6%B3%89%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%EF%BC%88NextPublishing%EF%BC%89-%E5%B7%9D%E7%95%91-%E7%9C%9F%E4%B8%80/dp/4844379526/ref=sr_1_6?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-6　OpenFOAMの歩き方]

[https://www.amazon.co.jp/OpenFOAM%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%83%86%E3%83%A9%E3%83%90%E3%82%A4%E3%83%88/dp/4627691610/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-2 OpenFOAMライブラリリファレンス]

[https://www.amazon.co.jp/OpenFOAM%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-Tomislav-Mari%C2%B4c/dp/4627670915/ref=sr_1_3?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-3 OpenFOAMプログラミング]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691017/ref=sr_1_4?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-4 OpenFOAMによる熱移動と流れの数値解析]

OpenFOAM 8 リリースノート

2023-09-09T12:47:40Z

Mmer547: ページの作成:「OpenFOAM Foundationは、オープンソースCFDツールボックスOpenFOAMのバージョン8のリリースを発表します。バージョン8は、OpenFOAM開発版のスナップショットであり、持続可能な開発により、常にリリース可能です。バージョン8は、ユーザビリティ、ロバスト性、拡張性が厳しく要求される中、新機能と既存コードの大幅な改良を提供します。 OpenFOAM 8には…」

OpenFOAM Foundationは、オープンソースCFDツールボックスOpenFOAMのバージョン8のリリースを発表します。バージョン8は、OpenFOAM開発版のスナップショットであり、持続可能な開発により、常にリリース可能です。バージョン8は、ユーザビリティ、ロバスト性、拡張性が厳しく要求される中、新機能と既存コードの大幅な改良を提供します。

OpenFOAM 8には、次のような重要な開発が含まれています。

* マルチフェーズ：インターフェイス捕捉のための選択可能な補間、PLIC方式。
* 多相反応：統合多相EulerFoamソルバーとモデル開発。
* 輸送: 新しい MomentumTransportModels と ThermophysicalTransportModels ライブラリ。
* 熱物理学：熱力学と状態方程式モデル、データ入力、リファクタリング。
* サーフェスフィルム：大幅な性能向上と表面処理の改善。
* 熱伝導：数値計算とケース設定の改善、新しい熱的快適性のモデル化。
* パーティクルトラッキング：非結合ソルバーの名称変更、トラッキング効率の向上、インジェクション。
* その他のモデル：過渡/定常状態ソルバー、境界条件、反応。
* メッシュ：snappyHexMeshとblockMeshの改良、面中心の計算、サイクリックパッチ。
* 機能オブジェクト：可視化／フィールド、滞留時間、コンフィギュレーションの改善。
* ケース・コンフィギュレーション：新しいコンフィギュレーション／初期化ツール、コード化された Function1.
* 計算：データI/Oの改善、フィールドキャッシング、Armプロセッサーのサポート。
* 約710件のコードコミット、200件以上の問題解決
* ISO/IEC 14882:2011 (C++11): GCC v5.4+、Clang v3.8+、Intel ICC v18.0+でテスト済み。

ParaView 5.6.0（LLVM/Galliumアクセラレーション付きMesaを含む）は、（サポートされている）グラフィックカードがないシステム用にパッケージ化されています：

* Ubuntu Linux: Ubuntu 16.04、18.04、20.04用のパッケージインストール；
* その他のLinux：Dockerコンテナによるインストール、またはソースコードからのコンパイル；
* Windows 10: Windows Subsystem for LinuxとUbuntuパックを使用したインストール；
* macOS: Dockerコンテナによるインストール。

OpenFOAM 8 Source Packは、適切なLinuxプラットフォームでコンパイルできます。

== 一般多相 ==

* モデリング新しい界面捕捉フレームワークにより、fvSchemesで二相流の補間法を指定できるようになりました[ commit fa79ba ]。多相界面ハンドリングのための新しい補間スキームファミリーは、区分線形界面計算(PLIC) [ commit 1611e0 ]に基づいています。[詳細情報: "OpenFOAM における界面捕捉" ]。
* 性能/数値計算： mixtureKEpsilonモデルにおける気泡生成乱流の位相分率リミッターにより、気泡が存在しない場合のスプリアス乱流生成を回避 [ commit f84708 ]。多相VoFの制御パラメータを一元化しました[ commit 8af31c ]。
* 後処理: phaseMap関数オブジェクトは複数のフェーズに対して単一のフェーズマップフィールドを書き込みます[ commit 35a04f ]。

== 反応する多相 ==

==== VTTフィンランドおよびHZDRドレスデン・ローゼンドルフとともに ====

* 統合されたmultiphaseEulerFoam: reactingMultiphaseEulerFoam、twoPhaseEulerFoam、reactingTwoPhaseEulerFoamを複製し置き換える。反応がオフの場合、"古い "multiphaseEulerFoamが再現されます[ commit b83245 ]。位相方程式が解かれない参照相を指定することができ、"古い"(reacting)TwoPhaseEulerFoamが再現されます[ commit d1170c ]。
* 位相運動量：暗黙的な相圧力の取り扱いを改善し、粒子床における充填のシミュレーションをよりロバストかつ安定的に行えるようになりました[ commit 3fbd9a ]また、充填床における性能を改善しました[ commit ba6b55 ]。運動論モデルを任意の一対の相に一般化しました[ commit 01f4fa ]。
* その他の相モデリング：熱力学、反応、種分率の補正の順序を改善 [ commit 89023d ]。相の速度とフラックスが全体の混合物に対応するように修正 [ commit 27ce5a ]、およびMRF計算 [ commit 658b0c ]。反応相の多成分拡散モデリングをサポートするコード構造を追加 [ commit 854dae ]。
* 相変化：熱相変化と境界条件 [ commit 94a5e0 ]。物質移動プロセスの修正[ commit df6835 ]、相ペアの保存とその界面組成モデルの指定の改善[ commit 474962 ]。
* 人口バランス：分散相にフラクタル形状を追加 [ commit cfbb38 ]。物質移動速度とソース項の同期化 [ commit cebc40 ]。PrinceBlanch合体モデルに層流せん断を追加 [ commit 6ad711 ]。
* インターフェース分散相の粒子について、単位体積あたりの表面積を保存することができます[ commit 8df44a ]。飽和モデルを相のペアに対して指定することができるようになり、異なる界面や壁の異なる相で複数の伝熱過程をシミュレートすることができるようになりました[ commit aedb44 ]。Alberto Passalaqua氏による流動層シミュレーション用の新しいガン熱伝達モデル [ commit 8e2402 ]。alphatWallBoilingWallFunction境界条件を完全に定義しました[ commit 4d0661 ]。
* 反応：新しいsurfaceArrheniusReactionRateモデルは、単位体積あたりの表面積の関数である反応速度を提供します[ commit 8c9e46 ]。
* 乱流: kOmegaSSTSato モデルが完全に動作するようになりました [ commit 8ce466 ]. yPlus が特定のフェーズに対して計算できるようになりました [ commit 02dcff ]. 乱流分散モデルの力を面フラックスから計算 [ commit 124c70 ]。乱流分散モデルを修正 [ commit 64da7a ]。
* 数値計算：粒子圧の数値処理が改善され、流動床などのシミュレーションが大幅に高速化されました[ commit da429d ]。
* 境界条件：相ごとに適用される外部および連成伝熱境界条件 [ commit b494e5 ].
* チュートリアル: bubblePipe [ commit 2be90f ]. 改良されたチュートリアルでコード修復をテスト [ commit 474962 ]。新しい damBreak4Phase チュートリアルでインターフェースのキャプチャをデモ [ commit 89439a ]。

== 輸送モデリング ==

* MomentumTransportModels：新しいライブラリは、非圧縮性/圧縮性ニュートン、非ニュートン、粘弾性層流、レイノルズ平均、乱流のラージエディシミュレーションのための運動量方程式のせん断応力を一般化します。
* ThermophysicalTransportModels:複雑なエネルギーと化学種の輸送モデル、特に多成分拡散を可能にするために作られた新しいライブラリ [ commit 25b348 ]。divjとj関数は物質輸送のための新しいインターフェイスを提供します [ commit b4cf40 ]。
* 乱流： SpalartAllmaras DESモデルにおいて、一時的な場の保存を減らし、LES領域の書き込みを可能にしました[ commit 4a810c ]。kkLOmega乱流モデルの安定性を改善しました[ commit 3c64dc ]。乱流による質量拡散率を熱拡散率とは別に乱流のプランドル数とシュミット数で指定できるようになりました[ commit 86f2c6 ]。
* 粘弾性： PTT (Phan-Thien-Tanner) 粘性モデル [ commit 99982d ] およびマルチモード粘弾性モデル [ commit a7eb35 ]。
* 種：種が表面に堆積するための新しい吸着境界条件 [ commit bcc867 ]。

== 熱物理モデリング ==

* 熱力学：熱物理モデリングに分別エンタルピー関数を追加 [ commit 086034 ]。標準状態の混合物のGibbs自由エネルギーを計算するGstd関数を追加 [ commit 73c6f9 ]。液体用の新しい熱物性クラスが追加され、各物性の関数と係数が入力ファイルを通して設定されるようになりました [ commit 375e1f ]。 heSolidThermo 熱物性モデルが更新され、修正された状態係数混合方程式を使用するようになりました [ commit c909bd ]。
* 状態方程式: rPolynomial (逆多項式) が液体と固体のデータによくフィットし、混合種の係数の計算をサポート [ commit 481797 ]。状態方程式の係数混合を大幅に修正しました[ commit c8d434 ]。比熱容量が圧力一定か体積一定かによって状態方程式からエントロピーのための別々の関数を作成 [ commit fa9ccc ]。
* データ入力：熱物性を指定するための一様でないテーブル、高速アドレス指定で最適化 [ commit 73a594 ]。状態方程式、熱力学、輸送モデル用の温度の関数表 [ commit 4c2fae ]。
* リファクタリング：熱物理モデルをインスタンス化するためのマクロを書き換え、2,500行のコードを削減 [ commit fe8908 ]。反応物/生成物燃焼混合物から純粋種に基づく混合物を分離 [ commit 80f15b ]。種の特性、例えば絶対エンタルピーをセルレベルではなくフィールドレベルで評価するフレームワークを追加 [ commit e695df ]。

== 表面フィルム ==

* パフォーマンス： 100%保守的に書き換え、30倍高速化 [ commit 0ad918 ]。内部コーナーがある場合の静水圧問題を修正 [ commit 131a9f ]。高い表面張力での収束性[ commit 68a384 ]と安定性[ commit 7d03ae ]を大幅に改善。強い密度勾配をサポートし、表面コーナーでの以前のエラーを克服 [ commit f6688b ]。
* 表面：表面速度が放物線プロファイルを仮定するように修正 [ commit 2b82c3 ]。表面速度と壁速度の取り扱いを合理化、単純化しました[ commit 663970 ]。
* モデル：チキソトロピックモデルを修正 [ commit 9025e2 ]、ビンガム塑性降伏応力のオプションを追加 [ commit 3d7031 ]。

== 熱伝達 ==

* ケースのセットアップ： chtMultiRegionFoam [ commit a9ddd7 ]に流体や固体の領域を持たないケースのサポートを追加しました。
* 数値計算：共役伝熱ソルバーで固体のエンタルピーをエネルギーに変更しました[ commit c109be ]。伝熱および浮力ソルバーにオプションの圧力参照pRefを追加しました。
* 浮力駆動フロー: Tobias Holzmann氏との共同作業により、DIN ISO EN 7730:2005に基づく熱的快適性のための快適性関数オブジェクトを追加しました [ commit 280c05 ]。buoyantPimpleFoamにメッシュの移動/変更機能を追加しました[ commit 38fff7 ]。

== パーティクルとトラッキング ==

* ソルバー：非結合ソルバー particleFoam と rhoParticleFoam [ commit 9fd917 ] と関数オブジェクト particles [ commit 9fd917 ] の名前を変更しました。
* トラッキング：特にストリームラインなどの後処理において、メッシュが動く場合の効率が向上しました。
* 注入： Rosin-Rammler粒子分布モデルのクリッピングを改善しました[ commit 8604c1 ]。CellZoneInjection のセル間のパーティクル分布を修正しました [ commit b507f3 ]。
* モデリング：エトヴェシュ数の計算を修正 [ commit aab3a2 ]。放射線散乱に影響する粒子雲の散乱を修正 [ commit 7e6528 ]。

== Other Modelling ==

* ソルバー： rhoPimpleFoamはrhoSimpleFoamと同じ結果を定常時間スキームで生成し、rhoReactingFoamもSIMPLE操作をサポートするように更新されました[ commit 97cda4 ]。高速での圧縮性流れソルバーのアルゴリズムを改良しました。solidDisplacementFoamが標準的な熱伝導境界条件を使用できるように、標準的な固体熱物理モデリングを使用するように修正しました[ commit 640027 ]。
* 境界条件(BC)：新しいentrainmentPressureは、totalPressureが失敗することがある外部境界での優れた安定性を提供します[ commit 6c887b ]。freestreamVelocityの収束が改善されました[ commit f7bcc1 ]. flowWithOpenBoundaryチュートリアルは開いた境界での条件を探索します[ commit 197b14 ]. pressureInletOutletVelocity 境界条件のオプションの tangentialVelocity が時間変化するようになりました [ commit d9fc45 ]。
* 反応： reactingMixtureをリファクタリングし、反応のリストが反応から派生しないようにしました [ commit 3dc362 ]。singleStepReactingMixtureの機能をsingleStepCombustionクラス内に移動し、反応スキームのインスタンス化をリファクタリングする第一歩としました [ commit b8fcd1 ]。chemistryModel、reactions、ODESolverの反応速度を評価するすべての関数にindex引数を追加しました[ commit 2d0f45 ]。
* 剛体力学： SeongMo Yeonとの外力拘束 [ commit 278ba8 ].
* ソース semiImplicitSource fvOption は方程式のソース項を設定するためのもので、スカラー、ベクトル、テンソルに対して一般化され [ commit b6f91d ]、時変関数を可能にする Function1 をサポートしています [ commit 95b5ef ]。

== メッシュ ==

* snappyHexMesh：例えば小さな隙間の場合 [ commit 4c08b4 ] 、surfaceFeatures [ commit 509f15 ] によって計算されたサーフェスの近さを使用して、サーフェスフィーチャー間のスパンに基づいてリファインメントを制御できるようになりました。
* blockMesh：新しい構文により、角度と軸を使用した円弧の指定が可能になりました [ commit 73d253 ]。ブロック面の向きのチェックを改善 [ commit 471810 ]。
* 数値計算：面中心の計算が修正され、歪んだセルでの収束が改善されました。magFaceAreas()関数による低レベルメッシュの変更をprimitiveMeshに追加しました[ commit 19d4f1 ]。
* 結合（巡回）パッチ：トランスフォームの合理化 [ commit 4f0e38 ] およびリファクタリング [ commit 03207b ] を行い、重複した不完全な実装を置き換えた [ commit 87bce8 ]。transformPosition 関数をリファクタリングし、コードの重複を減らし、関連するエラーを取り除きました [ commit 50d135 ]。回転変換の自動計算を改善し [ commit 7010a8 ]、あいまいな代入を削除 [ commit ba52c4 ]。
* メッシュモーション：メッシュのアンリファインメントによるフィールドのセルフマッピングを修正 [ commit 22bba4 ]。
* リージョン平面に最も近い面を選択する topoSet の新しいソース planeToFaceZone [ commit 14e7db ]。

== ファンクション・オブジェクト ==

* 可視化： isoSurface処理でサーフェスの浸食を避けるための修正 [ commit 916d0a ] と、頂点除去のレベルを制御するisoSurfaceのフィルタリングオプション [ commit 916d0a ] を追加。
* フィールド： fieldAverage 関数オブジェクトのインターフェースの改善 [ commit c60cef ] と設定の簡素化 [ commit 0177c7 ]。新しい faceZoneAverage パッケージ化された関数オブジェクトはフェイスゾーン上のフィールドの平均を計算します [ commit 84a126 ]。 shearStress 関数オブジェクトは体積せん断応力を出力します [ commit c57ffd ]。コアとなるvolFieldValue関数オブジェクトにオプションの重みフィールドを追加しました。
* 滞留時間：滞留時間を測定する年齢関数オブジェクトは、fvOptions [ commit 73503b ]をサポートし、オプションで拡散と収束のコントロールがあります（Tobias Holzmannと） [ commit a2a74c ]。
* 設定：時刻 "0 "のデータを提供するためにシミュレーション開始時に実行するオプション [ commit 2ebed5 ]。マルチリージョンの場合のファンクションオブジェクトファイルの検索を改善しました[ commit 435b89 ]。設定ファイルなしで（例えば後処理のために）関数オブジェクトを素早く実行するためのフィールドパラメーターの取り扱いが改善されました [ commit ad12d3 ]。

== ケース構成 ==

* データの可視化： ParaViewリーダーモジュールがサーフェスおよびポイントフィールド[ commit b7c064 ]とボリューム内部フィールド[ commit 67d3a8 ]を可視化できるようになりました; foamToVTKもボリューム内部フィールドをサポートするようになりました[ commit 53e845 ]。foamToVTK で、低レベル書き込み関数を合理化して 3x コードの重複を削除 [ commit 9ff1e2 ]。バイナリ VTK ファイル [ commit 622f47 ] とサンプルサーフェスファイル [ commit 84759e ] の書き込みをサポート。
* 大文字小文字の初期化：マクロ($)展開を使用して入力ファイルの異なる辞書レベルのデータにアクセスするための新しい "スラッシュ"(/)構文 [ commit a7b842 ] 入力ファイルへの絶対パスのサポートを含む [ commit b7c0cd ] チュートリアル、テンプレートケース、foamDictionaryへの更新 [ commit 26187d ]. aerofoilNACA0012チュートリアルの迎角設定による例示的なcodeStream例 [ commit 17f110 ]。
* ケース管理： patchSummary ユーティリティがフィールドに適用された境界条件に関する完全な情報を提供するようになりました [ commit 107b5d ]。foamDictionary において、インクルードされたファイルとマクロの展開がデフォルトで無効になりました [ commit c1edb0 ]。 foamCloneCase に並列分解ケースと追加ファイルのオプションが追加されました [ commit f06e13 ]。
* Function1:コード化されたFunction1により、時間変化するパラメータなどのFunction1をコードで設定できます [ commit 0dd2e9 ]。テーブルと定数関数を読み込むための3つの標準フォーマット [ commit 0d9786 ]. reverseRampは任意のFunction1のランプを1から0に反転できます [ commit 8756e8 ].

== プログラミングと計算 ==

* データ入力: readScalar(dict.lookup("name")) を dict.lookup<scalar>("name") に簡略化 [ commit 5eaf74 ]。辞書エントリの解析と処理に関する大規模なメンテナンスが行われ、コードがより堅牢で一貫性があり、拡張可能になりました [ コミット 4d8981 ]。複数行の引数リストを含む入力設定の構文を改善した [ commit 7dc08e ]。
* フィールドとディメンション：フィールドなどの一時的なオブジェクトをキャッシュし、データのさらなる処理と書き込みを可能にしました [ commit fdf121 ]特にフィールドデータ、例えばコード診断のためのモデルソース項や数値リミッターなど [ commit 30cceb ]。dimensionedConstants クラスを大幅に単純化しました [ commit 9513ad ]。
* アーキテクチャ： Arm ベースのプロセッサ用のコンパイルルールが追加されました [ commit ed9e42 ]。
* その他の数値計算：関数オブジェクトによって解かれるフィールド（例えばスカラー輸送フィールド）を時間/反復ループの収束テストに含めることができるようになりました [ commit c6089a ]。

OpenFOAM v1912 リリースノート

2023-09-09T12:42:25Z

Mmer547: /* Parallel */

OpenCFDは、OpenFOAM® v1912の2019年12月リリースを発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v1906の機能を拡張しています。新機能は、OpenCFDのお客様がスポンサーとなった開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMは、OpenCFDによってGPLライセンスの下で配布されています：

* Linuxシステム上でコンパイル可能なソースコード
* Linuxシステム用のコンパイル済みバイナリのインストール
* Mac OS Xシステム用のコンパイル済みバイナリのインストール
* MS Windows インストーラ
* Bash on Ubuntu on Windows (MS Windows 10用)

コードを入手するには、ダウンロード手順を参照してください。

開発用リポジトリは一般に公開されています。これらのメインリポジトリはバグフィックスや新機能で定期的に更新され、最近のメンテナンスでサイズが800MB以上からmasterブランチの200MB程度に大幅に縮小されました。

== Upgrading ==

* ユーザー向けのヘルプは、ユーザーアップグレードガイドに記載されています。
* 開発者向けのヘルプは、開発者向けアップグレードガイドで提供されています。
* また、典型的なイディオムの理解を深めるために、コーディングパターンに関する文書も作成しました。私たちは喜んでコンテンツを取り込みます！

== Pre-processing ==

=== 新しい式の構文 ===
OpenFOAM-v1912は、swak4Foam（Bernhard Gschaider）によって開拓されたアイデアを使用した式を実装しています。これは、swak4Foam（Bernard Gschaider）によって開発されたアイデアを使用しています。この追加は、辞書構文、文字列評価、境界条件、セットフィールドなど、OpenFOAMのさまざまな部分に浸透しており、今後の発展が期待されます。

例えば、式は、正規文字列展開に数学的評価を埋め込むことを可能にします：<syntaxhighlight lang="bash">
#include "<system>/sampling${{ round(${flowRate:-5} * 100) }}";
</syntaxhighlight>その中核となるのが、このエクスプレッション機能である：

* SQLiteプロジェクトのLemon Parser Generator - <nowiki>https://www.sqlite.org/lemon.html</nowiki> を参照。
* Ragelステートマシン・コンパイラ - <nowiki>http://www.colm.net/open-source/ragel/</nowiki> を参照。

'''Source code'''

$FOAM_SRC/OpenFOAM/include/m4

$FOAM_SRC/src/OpenFOAM/expressions

$FOAM_SRC/src/finiteVolume/expressions

=== 辞書のインライン表現 ===
辞書入力に関する大きな変更点は、式の追加に関連する新しい#evalディレクティブである。多くの場合、#evalは#calcを直接置き換えることができ、速度を大幅に向上させることができる。比較として、以下の10回の評価では、#calcでは16秒かかったのに対し、#evalでは0.02秒しかかからなかった。

この機能は辞書の見方を変えるだろう。<syntaxhighlight lang="bash">
kgh 700;
split 0.4;
inlet1

{
type flowRateInletVelocity;
massFlowRate constant #eval{ $split * $kgh / 3600 };
}

inlet2
{
type flowRateInletVelocity;
massFlowRate constant #eval{ (1-$split) * $kgh / 3600 };

}
</syntaxhighlight>さらなる例は、v1912ユーザーアップグレードガイドに記載されています。

'''Source code'''

$FOAM_SRC/OpenFOAM/db/dictionary/functionEntries/evalEntry

'''Tutorial'''

これまで#calcを使用していたチュートリアルはすべて#evalを使用するようになりました。

=== 新しい式ベースの setFields ユーティリティ ===
この式は、setExprFieldsとsetExprBoundaryFieldsという新しいユーティリティをサポートしており、似たような名前のswak4Foamのファンキーなユーティリティと同じような役割を果たします。

setExprFieldsは、フィールドの設定に図形と選択を使う代わりに、条件と式の組み合わせを使う。条件が有効な場合にのみ、式の結果が適用される。例えば、以下のようにすると、定義されたゾーン内の温度が調整される：<syntaxhighlight lang="bash">
expressions

(

T
{
field T;
dimensions [0 0 0 1 0 0 0];
constants
{
centre (0.21 0 0.01);
}
variables
(
"radius = 0.1"
);
condition
#{
// Within the radius
(mag(pos() - $[(vector)constants.centre]) < radius)
// but only +ve y!
&& bool(pos((pos() - $[(vector)constants.centre]).y()))
#};
expression
#{
300
+ 200 * (1 - mag(pos() - $[(vector)constants.centre]) / radius)
#};
}

);
</syntaxhighlight>setExprBoundaryFieldsユーティリティは、バウンダリ・フィールド・エントリをカスタムで変更するための同様の目的を果たす。

'''Tutorials'''

$FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/TJunctionAverage

=== '''PDRFoam用の新しいセットフィールド・ユーティリティ''' ===
新しいPDRsetFieldsユーティリティはPDRFoamソルバーで使用する閉塞のテンソル抵抗を計算します。ジオメトリはPDRsetFieldsDictファイルを使ってプリミティブ形状の形で入力されます：<syntaxhighlight lang="bash">
// Data dictionary for PDRsetFields

// Replace by the relevant names

obsFileDir "<case>/geometry";

obsFileNames (obstaclesDict);

// legacyObsSpec true;

//

// obsFileNames (position.obs base.obs);
</syntaxhighlight>障害物は、obsFileNamesエントリーの下にリストされた個別のファイルで提供される。以下のような様々なタイプの障害物がサポートされている：

* cylinder
* diagonal beam
* cuboid
* grating
* louvre
* patch

以下に障害物の例を示す：

; Source code
: $FOAM_UTILITIES//utilities/preProcessing/PDRsetFields
; Tutorial
: $FOAM_UTILITIES/combustion/PDRFoam/pipeLattice

=== checkMeshから出力される壁の距離 ===
checkMesh ユーティリティのオプション -writeAllFields が拡張され、壁距離をフィールド wallDistance として書き込むようになりました。これは、system/fvSchemes辞書で壁距離法が選択されていることを必要とします：<syntaxhighlight lang="bash">
wallDist
{
method meshWave;
}
</syntaxhighlight>wallDistanceは壁パッチのSMALL(1e-15)に設定され、paraFoamなどで後処理することができます：

; Source code
: $FOAM_UTILITIES/mesh/manipulation/checkMesh

== snappyHexMesh : 細いギャップを自動的に閉じる ==
複雑な形状のメッシュを作成する際、ユーザがメッシュを必要としない薄いギャップがあるかもしれません。このリリースではsnappyHexMeshは面毎、面領域毎にメッシュするギャップの最小サイズを指定するblockLevelを指定することができます。この指定されたサイズより小さいギャップ内のセルは削除されます（その結果、ギャップ内のセルはなくなります）。

この拡張機能は以下の構文で有効になる：<syntaxhighlight lang="bash">
refinementSurfaces
{
"gap.*"
{
// Surface-wise min and max refinement level
level (2 2);

// From cell level 2 onwards start checking
// for opposite surfaces
blockLevel 2;
}
}
</syntaxhighlight>blockLevel 設定は以下を決定する。

* ギャップ検知にサーフェスが全く使用されていないかどうか。
* 理想的なギャップの大きさ：2 * cellize; ここで、cellize は初期セルサイズから blockLevel を何倍かにリファインして決定される。

全てのサーフェス精密化snappyHexMeshの後、シェル/ボリュームの精密化の前に、全てのセルについて最も近い2つのサーフェスを決定します。もしセルが

* 2つの面の間、または同じ面の切り離された領域
* であり、対向点間の距離はギャップサイズより小さい。

の場合、セルは削除される。

チュートリアルのopposite_wallsは、薄いギャップを形成する2つの表面を持つ単純なブロックです。

; Tutorial
: $FOAM_TUTORIALS/mesh/snappyHexMesh/opposite˙walls

== 数値 ==

=== 新しい随伴形状最適化 ===
アジョイント・ライブラリは、自動化された形状最適化ループを可能にする新機能で強化されている。

これは、OpenFOAMのガバナンス・フレームワークの下、OpenFOAM-v1906でリリースされたアジョイント最適化ツールの続編です。

体積Bスプラインに基づくパラメータ化スキームが導入され、その制御点は最適化ループにおける設計変数として機能する（下記参照）。ボリューメトリックBスプラインボックスの制御点は、直交座標または円筒座標で定義できます。

ループ全体（流体方程式とアジョイント方程式の解法，感度導関数の計算，設計変数とメッシュの更新）は，adjointOptimisationFoam ソルバー内で実行されます．設計変数を更新するために，BFGS のような一般的な準ニュートン法や，SQP や拘束射影のような拘束を扱える方法など，多くの方法が実装されています．

; Source code
: $FOAM_SOLVERS/incompressible/adjointOptimisationFoam $FOAM_SRC/optimisation/adjointOptimisation/adjoint
; Examples
: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam
; Attribution
: このソフトウェアはPCOpt/NTUAとFOSS GPによって開発され、以下の人々からの貢献があった。
:* Dr Evangelos Papoutsis-Kiachagias,
:* Konstantinos Gkaragounis,
:* Professor Kyriakos Giannakoglou,
:* Dr Andrew Heather
; References
:* E.M. Papoutsis-Kiachagias, N. Magoulas, J. Mueller, C. Othmer, K.C. Giannakoglou: ’Noise Reduction in Car Aerodynamics using a Surrogate Objective Function and the Continuous Adjoint Method with Wall Functions’, Computers & Fluids, 122:223-232, 2015
:* E. M. Papoutsis-Kiachagias, V. G. Asouti, K. C. Giannakoglou, K. Gkagkas, S. Shimokawa, E. Itakura: Multi-point aerodynamic shape optimization of cars based on continuous adjoint, Structural and Multidisciplinary Optimization, 59(2):675694, 2019
; Integration
: コードはOpenCFDとNTUAが共同で統合した。

=== 新しい重み付き磁束補間スキーム ===
新しいweightedFlux補間スキームは、重み付けされたフラックスを用いる線形スキームである。

次のような一般的なフラックスの場合：

の面値を必要とするガウスの定理を用いて勾配を計算する。これは次のように計算される：

どこ:

* φi is the cell value
* φfis the face value
*
* σi is the diffusivity coefficient

不連続の場合、線形補間は正しくないフラックスを生成する。weightedFlux補間スキームは、Tの調和補間と組み合わせて以下のように使用される。<syntaxhighlight lang="bash">
laplacianSchemes
{
laplacian(DT,T) Gauss harmonic corrected;
}

gradSchemes
{
grad(T) Gauss weightedFlux sigma;
}
</syntaxhighlight>上記の例では、以下のように滑らかな温度と熱流束のプロファイルが得られる：

; Source code
: $FOAM_SRC/finiteVolume/interpolation/surfaceInterpolation/schemes/weightedFlux
; Tutorial
: $FOAM_TUTORIALS/verificationAndValidation/schemes/weigthedFluxExample
; Attribution
: このスキームはノルベルト・ウェーバーの寄稿によるものである。
; References
:* Weber, N.; Beckstein, P.; Galindo, V.; Starace, M.; Weier, T.: Electro-vortex flow simulation using coupled meshes, Computers and Fluids 168(2018) 101-109
:* For more details see the Issue tracker

=== 混合精度モードでのジオメトリ処理の改善 ===
OpenFOAM-v1906で導入された混合精度モード(SPDP)により、倍精度で実行する場合に比べ、大幅なスピードアップとメモリ要件の削減が可能になります。

混合精度モードでは、線形ソルバーだけが倍精度で動作する。他の機能はすべて単精度で実行されます。これにより、例えばcheckMeshを使用した場合、完全に有効なクローズドセルがオープンセルとして表示される可能性があります。単精度(SP)で実行すると、以下のようなレポートが表示されます：<syntaxhighlight lang="bash">
***Boundary openness (3.77976e-07 3.97566e-06 -2.26237e-08) possible hole in boundary description.
</syntaxhighlight>このバージョンでは、倍精度計算が次のように拡張されています。

* 面の中心と面積、セルの中心と体積の計算。実際の結果はまだ単精度で保存されていることに注意してください。
* ほとんどのcheckMeshの合計、例えばオープンセルの上。
* すべてのフィールドベースの合計（sum）。

これらの変更はSPDPモードにのみ影響することに注意。前の例では、次のように報告されている：

境界の開き (-6.31099e-11 -3.99859e-11 -3.747e-10) OK.

; Source code
: $FOAM_SRC/src/OpenFOAM/meshes/primitiveMesh/primitiveMeshCellCentresAndVols.C $FOAM_SRC/src/OpenFOAM/meshes/primitiveMesh/primitiveMeshFaceCentresAndAreas.C

== ソルバーと物理モデル ==

=== 新しいインターフェイス追跡ダイナミック・メッシュ ===
このリリースには、foam-extendプロジェクトのムービングメッシュインターフェーストラッキングライブラリが統合されています。OpenFOAM v1912への移植は、Zeljko Tukovic (FMENA, Zagreb)がOpenCFD Ltd.と共同で行いました。

基本的な機能は、interfaceTrackingFvMeshクラスによって実装されています。自由表面における運動学的および動的条件は、速度と圧力のカスタム境界条件によって課されます。界面追跡計算は、標準的なpimpleFoamソルバーを使用して実行されます。

下の例は、汚染され、擾乱を受けた液滴の濃度と形状の変化を示している。

; Source code
: $FOAM_SRC/dynamicFaMesh/interfaceTrackingFvMesh
; Tutorial
: $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contactAngleCavity $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contaminatedDroplet2D
; References
: Z. Tukovic and H. Jasak. A moving mesh finite volume interface tracking method for surface tension dominated interfacial fluid flow. Computers & fluids. 55 (2012) 70-84.
; Attribution
: Code written and contributed by Zeljko Tukovic

=== 新しい6自由度（DoF）機能 ===

===== 新しいlinearSpringDamper拘束モデル =====
6自由度ライブラリには、新しいlinearSpringDamperモデルが含まれています。

これはスプリングダンパーシステムで、アンカーとrefAttachmentPt間の距離がrestLengthを超えたときに「ソフトな」ロープ拘束として機能する。

ロープがたるんでいるときは、体に力はかからない。dynamicMeshDictでの指定は以下の通り：<syntaxhighlight lang="bash">
restraints
{
chain
{
sixDoFRigidBodyMotionRestraint linearSpringDamper;
refAttachmentPt (3.7 4.2 4.5);
anchor table
(
(0 (3.7 4.2 6.5))
(2 (4.7 4.2 6.5))
(6 (5.7 4.2 4.5))
(8 (6.7 4.2 4.5))
);
psi 1;
wn 8.28;
numberOfChains 4;
restLength 2;
}
}
</syntaxhighlight>どこだ？

* refAttachmentPtはソリッドオブジェクトへのアタッチメントポイントです。
* anchorはロープのアンカーで、Function1の時間依存の項目として指定される。
* psiは減衰比。
* wnは、システムの減衰していない固有振動数である。
* numberOfChainsは、ボディに取り付けられているチェーンの数。
* restLength はロープの残りの長さ。

システムの減衰と剛性は次のように計算される：

注：psiとwnは、柔らかいロープの挙動をモデル化するために、過減衰系に対して設定されるべきである。

; Source code
: $FOAM_SRC/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/restraints/linearSpringDamper

===== 新しいソフト・ウォール・サスペンション =====
新しいソフトウォールモデルは、壁法線方向のアンカーとrefAttachmentPt間の距離が負になったときに「ソフト」な壁として機能するダンパー-線形-バネ拘束です。

ロープがたるんでいるときは、体に力はかからない。dynamicMeshDictでの指定は以下の通り：<syntaxhighlight lang="bash">
restraints
{
upperWall
{
type softWall;
body floatingObject;
anchor (0.5 0.5 0.7);
refAttachmentPt (0.5 0.5 0.58);
wallNormal (0 0 -1);
psi 2.0;
C 0.01;
}
}
</syntaxhighlight>どこ:

* refAttachmentPtは、ソリッドオブジェクトへのアタッチメントポイントです。
* アンカーはロープの錨である。
* psiは減衰比
* wallNormal は壁の法線方向
* Cはモデル定数

システムの減衰と剛性は次のように計算される：

; Source code
: $FOAM_SRC/rigidBodyDynamics/restraints/softWall

===== オーバーセットされたダイナミックメッシュのための新しいマルチモーション機能 =====
オーバーセット・ダイナミック・メッシュが複数のモーション・タイプを扱えるようになりました。これにより、ユーザーは異なるモーション・ソルバーのアクションで異なるオブジェクトを動かすことができます。

一例を挙げよう：

* $FOAM_TUTORIALS/multiphase/overInterDyMFoam/floatingBodyWithSpring

dynamicMeshDict辞書の中で、dynamicOversetFvMeshは2つのモーション・ソルバーを持っています：

* 新しいdrivenLinearMotionを使ったsolidBody（下記参照）
* sixDoFRigidBodyMotion

チュートリアルでは、2つのモーション・ソルバーが異なるセルセットに適用される。

cubeという名前のソルバーは、モーション・ソルバーsixDoFRigidBodyMotionを使用するfloatingObjectです。新しいキーワードCofGvelocityは、drivenLinearMotionソルバーで使用するオブジェクトの重心速度を書き込む。

新しいdrivenLinearMotionモーションソルバは剛体タイプで、エントリーCofGvelocityに従って点を移動します。このチュートリアルでは、オーバーセット計算の背景メッシュに対応するc0セルセットに適用します。

drivenLinearMotionは、オーバーセット計算の "inset "領域で、与えられたオブジェクトに "追従する "背景メッシュを設定することができます。これは、オブジェクトの予想される変位が大きい場合にメッシュサイズを小さくするのに役立ちます。

; Tutorial
: $FOAM_TUTORIALS/multiphase/overInterDyMFoam/floatingBodyWithSpring

=== 新しい平行放射モデル ===

===== fvDOM用の新しい平行太陽ビームモデル =====
fvDOM放射モデルに、太陽外部負荷からの外部ビームのサポートが追加されました。この効果はfvDOMモデルの光線に追加され、radiationProperties辞書の新しい項目useExternalBeamをtrueに設定することで有効になります。

fvDOMの光線立体角は、角度離散化に従って最適な光線方向と一致するように回転される。

線源のエネルギー・スペクトルを得るには、以下のエントリーを使用する：<syntaxhighlight lang="bash">
spectralDistribution (2 1)
</syntaxhighlight>注：spectralDistributionのバンド数は、吸収率モデルのバンド数と一致する必要があります。つまり、boundaryRadiationPropertiesのmultiBandAbsorptionです：<syntaxhighlight lang="bash">
type opaqueDiffusive;
wallAbsorptionEmissionModel
{
type multiBandAbsorption;
absorptivity (0.3 0.7);
emissivity (0.3 0.7);
};
</syntaxhighlight>輻射境界条件の例では、不透明な拡散壁と、2つのバンドを用いたマルチバンド吸収モデルを指定しています。

コリメートモデルは、solarLoad放射モデルと併用しないでください。

コリメートモデルは、太陽計算機を使用して太陽の方向とエネルギー束を導きます。標準モデルは、solarLoad放射モデルと同様に使用できます。

; Source code
: $FOAM_SRC/thermophysicalModels/radiation/radiationModels/fvDOM

===== 新しいマルチバンドゾーン吸収発光モデル =====
新しいmultiBandZoneAbsorptionEmissionモデルは、領域内の不均一な吸収率および放射率フィールドの使用を可能にします。例えば、2つのバンドモデルの場合：<syntaxhighlight lang="bash">
multiBandZoneAbsorptionEmissionCoeffs
{
absorptivity (0.01 0.01);
emissivity (0.01 0.01);
zones
{
absorptivity ("trees" (20 20));
emissivity ("trees" (20 20));
}
}
</syntaxhighlight>この例では、背景メッシュに(0.01 0.01)、樹木というゾーンに(20 20)の吸収率を設定している。

; Source code
: $FOAM_SRC/thermophysicalModels/radiation/submodels/absorptionEmissionModel/absorptionEmissionModel/multiBandZoneAbsorptionEmission
; Tutorial
: $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/solarBeamWithTrees

=== 新しい多相乱流安定化 ===
乱流の運動エネルギーは、非圧縮VOFソルバーにおいて、表面波下のほぼポテンシャル流領域において、位相界面および水柱全体で過剰に予測される。

この挙動は、乱流運動エネルギー方程式と乱流粘性場に補正を適用する新しいmultiphaseStabilizedTurbulence fvOptionを使用して補正されます。

を使って指定する：<syntaxhighlight lang="bash">
multiphaseStabilizedTurbulence1
{
type multiphaseStabilizedTurbulence;
active yes;
multiphaseStabilizedTurbulenceCoeffs

{
// Optional coefficients
lambda2 0.1; // A value of 0 sets the nut correction to 0
Cmu 0.09; // from k-epsilon model
C 1.51; // model coefficient from k-omega model
alpha 1.36; // 1/Prt
}
}
</syntaxhighlight>

; Source code
: $FOAM_SRC/fvOptions/sources/derived/multiphaseStabilizedTurbulence
; References
:* Devolder, B., Rauwoens, P., and Troch, P. (2017). Application of a buoyancy-modified k-w SST turbulence model to simulate wave run-up around a monopile subjected to regular waves using OpenFOAM. Coastal Engineering, 125, 81-94.
:* Larsen, B.E. and Fuhrman, D.R. (2018). On the over-production of turbulence beneath surface waves in Reynolds-averaged Navier-Stokes models J. Fluid Mech, 853, 419-460
; Attribution
:* OpenCFDによる実装
:* Turbulence Technical Committee、およびBjarke Eltard-LarsenとDavid Fuhrman（デンマーク工科大学）による有益な議論とコードテストに感謝する。

=== 新しいk-epsilon-phit-f乱流モデル ===
Laurenceら, 2005）の研究に基づき、kEpsilonPhitFと名付けられた楕円緩和関数を用いた新しい3輸送方程式線形渦粘性RANS乱流クロージャーモデルが実装されました。

kEpsilonPhitFは、(Durbin, 1995)のv2-f手法に由来するkEpsilonベースのモデルである。v2-f手法の主な利点は、渦粘性モデルの最小限の定式化を維持しながら、線形渦粘性モデルとレイノルズ応力方程式モデルの中間を提供することであると報告されています。このことは、壁面距離や低レイノルズ数型の修正を行うことなく、壁面に向かって壁面法線速度スケールが放物線状に減衰することをシミュレーションに依存せずに再現できることに現れています。

しかし、v2-fモデルの大半は、特に壁境界において、v2場とf場の連成の定式化により、分離解法アルゴリズムでは数値的に厳しいことが判明した。

この欠点にもかかわらず、v2-fモデルは、さまざまな非平衡／非局所効果を示す流れ、強い圧力勾配、分離、衝突を伴う流れ、熱伝達を含む乱流場への変動圧力の影響など、幅広い一般的な流れの特性をうまく再現することが確認されている。

LienとKalitzin, 2001）によるv2-fモデル（すなわちOpenFOAMのv2fモデル）は、分離計算を可能にするためにオリジナルのv2-fモデルを再定義したものであるが、モデルの忠実度に関する多くの欠点が文献に報告されている。

v2-f手法の欠点を克服するために、v2-f手法は(Hanjali et al., 2004)と(Laurence et al., 2005)によって再評価され、同時に、スケールを等価な無次元形式に変換することによって、すなわち数値的な剛性を低減することによって再評価された。これらの変種は、オリジナルのv2-fモデルの理論的なモデルの忠実性を保持しながら、数値的なロバスト性と格子異常に対する鈍感性を提供すると考えられた。

kEpsilonPhitFモデルはベータ段階であることにご注意ください。今後、モデルの内部的な変更が行われる可能性もありますし、行われない可能性もあります。さらに、OpenFOAMで利用可能なv2fモデルは、kEpsilonPhitFまたは他のv2-fモデルのバリエーションに取って代わられる予定です。

kEpsilonPhitFモデルの実装は，平滑壁平面流路流（），ゼロ圧力勾配乱流平板，2次元後向きステップ，流路内2次元丘の正準流によって検証された．

例として、3つの検証プロットを以下に示す：

モデル方程式、実装、使用法に関するより詳細な情報は、（拡張コードガイドのkEpsilonPhitFセクション）にあります。

; Source code
: $FOAM_SRC/TurbulenceModels/turbulenceModels/RAS/kEpsilonPhitF
; Tutorial
: $FOAM_TUTORIALS/incompressible/simpleFoam/RAS/bump2D
; Attribution
: OpenCFD は、有益な議論と有益な示唆を与えてくれた Mirza Popovac 博士 (オーストリア工科大学) に感謝したい。

=== 雪崩モデリング・モジュールの更新 ===
冬が近づくにつれ、雪崩モデリング・モジュールでは、RAMMSモデル（Christen et al, 2010）の実装やMedinaモデルの安定性の改善など、巻き込みモデルの更新が行われた。

; Source code
: <nowiki>https://develop.openfoam.com/Development/openfoammodules/avalanche</nowiki>
; Attribution
: The avalanche code is developed by Matti Rauter

=== 液体の新しい状態方程式 ===
液体と固体のための逆多項式状態方程式rPolynomialはopenfoam.orgから統合され、以下の形式を持つ：

新しいオプションは、thermophysicalProperties辞書で次のように指定される：<syntaxhighlight lang="bash">
thermoType
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState rPolynomial; // new entry
specie specie;
energy sensibleInternalEnergy;
}

mixture
{
specie
{
molWeight 18.0;
}

equationOfState
{
// Coefficients for the reciprocal polynomial equation of state
C (0.001278 -2.1055e-06 3.9689e-09 4.3772e-13 -2.0225e-16);
}

thermodynamics
{
Cp 4195;
Hf 0;
}

transport
{
mu 3.645e-4;
Pr 2.289;
}
}
</syntaxhighlight>

; Source code
: $FOAM_SRC/src/thermophysicalModels/specie/equationOfState/rPolynomial
; Tutorial
: $FOAM_TUTORIALS/multiphase/compressibleInterFoam/laminar/depthCharge3D/constant/thermophysicalProperties.water
; Attribution
: モデルはopenfoam.orgから統合された。

== 境界条件 ==

=== ニューウェーブ・モデル ===
このリリースでは、OpenFOAM v1812で導入されたwaveMaker条件を拡張し、パドルの数を選択して3次元波を生成します。3次元フラップ波生成の例を以下に示します。

; Source code
: $FOAM_SRC/waveModels/derivedPointPatchFields/waveMaker
; Examples
: $FOAM_TUTORIALS/multiphase/interFoam/laminar/waves/waveMakerMultiPaddleFlap $FOAM_TUTORIALS/multiphase/interFoam/laminar/waves/waveMakerMultiPaddlePiston
; Attribution
: これらの拡張機能はEnvironmental Hydraulics Institute IHCantabriaから提供されたもので、コミットd0c5662172を参照：ガブリエル・バラハス
; Integration
: このコードは OpenCFD によって統合されました - マージリクエスト 317 を参照してください。

=== 新しい式に基づく境界条件 ===
式が境界条件を満たす場所： exprFixedValue境界条件とexprMixed境界条件。

これらの境界条件は、値、勾配、分数を式としてサポートする。例えば<syntaxhighlight lang="bash">
outlet1
{
type exprFixedValue;
value $internalField;
valueExpr "0.5*(pInlet + pOutlet2)";
variables
(
"pInletinlet = weightAverage(p)"
"pOutlet2outlet2 = p"
);
}
</syntaxhighlight>

; Tutorials
: $FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/TJunctionAverage

=== 新しいスケール境界条件ラッパー ===
これは、任意の（固定値）境界条件に、時間または空間で変化するスケーリングを追加するためのラッパーです。uniformFixedValueのすべての機能が追加されています。下の例では、patch エントリを使用して指定された標準的な fixedValue 境界条件を変更し、scale エントリに従ってスケールを適用します。<syntaxhighlight lang="bash">
<patchName>
{
type scaledFixedValue;
scale table
(
( 0 0)
( 1.0 1.0)
(100.0 1.0)
);

patch
{
type fixedValue;
value uniform (15 0 0);
}
}
</syntaxhighlight>スケールの項目はPatchFunction1であり、以下のような複数のオプションがある：

* constant
* csvFile
* mappedFile
* polynomial
* sampled
* scale
* sine
* square
* table
* tableFile
* uniformValue

; Source code
: $FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/scaledFixedValue

== 後処理 ==

=== パーティクルの後処理の改善 ===

===== クラウドパッチ相互作用モデル =====
オプションでwriteToFileエントリーを使用して、パッチ相互作用の統計情報、例えば、くっついたり、逃げたりした粒子の数と質量をファイルに書き込みます。例として、localInteraction粒子パッチ相互作用モデルを使用する場合、新しいエントリーを次のように追加することができます：<syntaxhighlight lang="bash">
localInteractionCoeffs
{
patches

(
"(walls|cyc.*)"
{
type rebound;
}

"inlet|outlet"
{
type escape;
}
);

// New optional entry
writeToFile yes;
}
</syntaxhighlight>

===== クラウド機能オブジェクト =====
空の場合、またはエントリーが指定されていない場合は、すべてのフィールドが書き込まれます（後方互換性を維持するため）。<syntaxhighlight lang="bash">
patchPostProcessing1
{
type patchPostProcessing;
// Optional new entry
fields (position "U.*" d T nParticle);
maxStoredParcels 20;
patches
(
cycLeft_half0
cycLeft_half1
);
}
</syntaxhighlight>

; Tutorial
: $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter

=== 新しい双方向パーティクル・ストリームライン ===
StreamLinesとwallBoundedStreamLines関数オブジェクトが拡張され、シードポイントからの双方向トラッキングが可能になりました。さらに、wallBoundedStreamlines関数オブジェクトが境界面ごとに複数のトラックをサポートするようになりました。

この新機能は、（以前のリリースのtrackForwardフラグの代わりに）新しいdirectionキーワードで有効にすることができる：<syntaxhighlight lang="bash">
U U;
direction bidirectional; // or forward/backward
fields (U p);
</syntaxhighlight>次の画像は、2組のファンクションオブジェクトが必要だった以前の動作を示している：

; Source code
: $FOAM_SRC/functionObjects/field/streamLine

=== サーフェス関数オブジェクトへの新しい距離 ===
新しいsurfaceDistance関数オブジェクトは、指定されたジオメトリまでの距離を示すフィールド（volScalarField）を生成します。これは、メッシュの解像度が不十分で隙間にメッシュが入らないなどのメッシュの問題を検出するために使用できます。

* サーフェスの指定は、snappyHexMeshおよびfoamyHexMeshと互換性のあるジオメトリ・エントリを介して行われます。
* 特定のサーフェスに限定せず、あらゆるサーフェスで最も近いサーフェスを見つける。
* デフォルトでは、すべてのセル・センターについて最も近いセルも見つける。これはオプションのdoCells booleanフラグをオフにすることで抑制できる。
* 境界上の値は、面の中心からの距離になります。

system/surfaceDistance辞書のサンプル：<syntaxhighlight lang="bash">
surfaceDistance
{
// Where to load it from
libs (fieldFunctionObjects);
type surfaceDistance;
geometry
{
motorBike.obj
{
type triSurfaceMesh;
}
}
}
</syntaxhighlight>これは、例えばpostProcessで使用できる：<syntaxhighlight lang="bash">
postProcess -func surfaceDistance
</syntaxhighlight>

; Source code
: $FOAM_SRC/functionObjects/field/surfaceDistance

== パラレル ==

=== ファイル修正スキューを更新 ===
複数のノードで並列ケースを実行する場合、プロセッサーのディレクトリは通常、NFSなどのネットワーク・ファイリング・システムを使用してアクセスされる。この場合、例えば辞書の変更を確認するために、自明でない待ち時間が発生する可能性があります。この目的のために、etc/controlDictに<syntaxhighlight lang="bash">
fileModificationSkew 10;
</syntaxhighlight>これは、辞書が変更されたとみなされるまでのファイル変更時間差の秒数である。2つ目の使用法は、#codeStream辞書エントリやコード化されたfunctionObjectなど、動的にコンパイルされたコードでの使用です。ここでは、dynamicCode/サブディクショナリ内の結果ライブラリが使用可能になるまでの待ち時間である。ただし、場合によってはファイルサーバーに大きな遅延が発生することがあるため、このfileModificationSkewは予想される最大値に設定する必要があります。

このリリースでは動作が変更され、以下のコントロールが追加されました。<syntaxhighlight lang="bash">
maxFileModificationPolls 100;
</syntaxhighlight>これは、fileModificationSkew 秒待ってからチェックする回数の最大値である。この動作により、fileModificationSkewをもっと低い値（最小1）に設定できるようになった。

上記の問題は、NFSでマウントされたディスクとマルチノードで実行する場合にのみ関係する。シングルノードの実行では、すべてのコアのファイルが一貫して表示されるため、マスターがコードのコンパイルを終了した場合、スレーブにも同じコードが表示されます。

例えば、異なるコアに異なるルートを使用する分散実行については、$FOAM_TUTORIALS/IO/fileHandlerチュートリアルを参照してください。ここでは、コードはすべてのコアでコンパイルされる必要があるので、同期の問題はありません。

=== ADIOS2ファンクションオブジェクトの更新 ===
adiosWrite関数オブジェクトは、パラレルIO用のADIOS2ライブラリを使用するように書き換えられ、通常のOpenFOAMモジュールとして利用できるようになりました。

この実装はチェックポイントとリスタートをサポートしている。

HPC技術委員会の活動の一環として実施される予定である。

== 携帯性 ==

==== 新しいバイナリファイルの互換性 ====
OpenFOAM-v1912 は、OpenFOAM のコンパイルが混在するワークフローをサポートするために、異なる精度またはラベルサイズのバイナリ読み込みを処理するようになりました。

そのようなワークフローのひとつは次のようなものだ：

* snappyHexMeshを使った倍精度メッシュ。
* 空力用の単精度（メモリ帯域幅を削減するため）
* 化学（倍精度）を使ったさらなる計算

必要なサイズ情報がヘッダーに含まれていれば、バイナリ形式のOpenFOAMファイルでも可能です。例えば<syntaxhighlight lang="bash">
FoamFile
{
version 2.0;
format binary;
arch "LSB;label=32;scalar=64";
class vectorField;
object points;
}
</syntaxhighlight>OpenFOAM-v1612 以降で生成されたバイナリファイルには、すでにこの情報が含まれており、使用することができます。

64ビットのラベル幅を32ビットのラベル幅にするなど、データ範囲を狭める場合、範囲のオーバーフローは切り捨てられることに注意。

OpenFOAM v1912 リリースノート

2023-09-09T12:39:59Z

Mmer547: ページの作成:「OpenCFDは、OpenFOAM® v1912の2019年12月リリースを発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v1906の機能を拡張しています。新機能は、OpenCFDのお客様がスポンサーとなった開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。 OpenFOAMは、OpenCFDによってGPLライセンスの下で配布されていま…」

OpenCFDは、OpenFOAM® v1912の2019年12月リリースを発表いたします。このリリースは、コードの多くの領域にわたってOpenFOAM-v1906の機能を拡張しています。新機能は、OpenCFDのお客様がスポンサーとなった開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMは、OpenCFDによってGPLライセンスの下で配布されています：

* Linuxシステム上でコンパイル可能なソースコード
* Linuxシステム用のコンパイル済みバイナリのインストール
* Mac OS Xシステム用のコンパイル済みバイナリのインストール
* MS Windows インストーラ
* Bash on Ubuntu on Windows (MS Windows 10用)

コードを入手するには、ダウンロード手順を参照してください。

開発用リポジトリは一般に公開されています。これらのメインリポジトリはバグフィックスや新機能で定期的に更新され、最近のメンテナンスでサイズが800MB以上からmasterブランチの200MB程度に大幅に縮小されました。

== Upgrading ==

* ユーザー向けのヘルプは、ユーザーアップグレードガイドに記載されています。
* 開発者向けのヘルプは、開発者向けアップグレードガイドで提供されています。
* また、典型的なイディオムの理解を深めるために、コーディングパターンに関する文書も作成しました。私たちは喜んでコンテンツを取り込みます！

== Pre-processing ==

=== 新しい式の構文 ===
OpenFOAM-v1912は、swak4Foam（Bernhard Gschaider）によって開拓されたアイデアを使用した式を実装しています。これは、swak4Foam（Bernard Gschaider）によって開発されたアイデアを使用しています。この追加は、辞書構文、文字列評価、境界条件、セットフィールドなど、OpenFOAMのさまざまな部分に浸透しており、今後の発展が期待されます。

例えば、式は、正規文字列展開に数学的評価を埋め込むことを可能にします：<syntaxhighlight lang="bash">
#include "<system>/sampling${{ round(${flowRate:-5} * 100) }}";
</syntaxhighlight>その中核となるのが、このエクスプレッション機能である：

* SQLiteプロジェクトのLemon Parser Generator - <nowiki>https://www.sqlite.org/lemon.html</nowiki> を参照。
* Ragelステートマシン・コンパイラ - <nowiki>http://www.colm.net/open-source/ragel/</nowiki> を参照。

'''Source code'''

$FOAM_SRC/OpenFOAM/include/m4

$FOAM_SRC/src/OpenFOAM/expressions

$FOAM_SRC/src/finiteVolume/expressions

=== 辞書のインライン表現 ===
辞書入力に関する大きな変更点は、式の追加に関連する新しい#evalディレクティブである。多くの場合、#evalは#calcを直接置き換えることができ、速度を大幅に向上させることができる。比較として、以下の10回の評価では、#calcでは16秒かかったのに対し、#evalでは0.02秒しかかからなかった。

この機能は辞書の見方を変えるだろう。<syntaxhighlight lang="bash">
kgh 700;
split 0.4;
inlet1

{
type flowRateInletVelocity;
massFlowRate constant #eval{ $split * $kgh / 3600 };
}

inlet2
{
type flowRateInletVelocity;
massFlowRate constant #eval{ (1-$split) * $kgh / 3600 };

}
</syntaxhighlight>さらなる例は、v1912ユーザーアップグレードガイドに記載されています。

'''Source code'''

$FOAM_SRC/OpenFOAM/db/dictionary/functionEntries/evalEntry

'''Tutorial'''

これまで#calcを使用していたチュートリアルはすべて#evalを使用するようになりました。

=== 新しい式ベースの setFields ユーティリティ ===
この式は、setExprFieldsとsetExprBoundaryFieldsという新しいユーティリティをサポートしており、似たような名前のswak4Foamのファンキーなユーティリティと同じような役割を果たします。

setExprFieldsは、フィールドの設定に図形と選択を使う代わりに、条件と式の組み合わせを使う。条件が有効な場合にのみ、式の結果が適用される。例えば、以下のようにすると、定義されたゾーン内の温度が調整される：<syntaxhighlight lang="bash">
expressions

(

T
{
field T;
dimensions [0 0 0 1 0 0 0];
constants
{
centre (0.21 0 0.01);
}
variables
(
"radius = 0.1"
);
condition
#{
// Within the radius
(mag(pos() - $[(vector)constants.centre]) < radius)
// but only +ve y!
&& bool(pos((pos() - $[(vector)constants.centre]).y()))
#};
expression
#{
300
+ 200 * (1 - mag(pos() - $[(vector)constants.centre]) / radius)
#};
}

);
</syntaxhighlight>setExprBoundaryFieldsユーティリティは、バウンダリ・フィールド・エントリをカスタムで変更するための同様の目的を果たす。

'''Tutorials'''

$FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/TJunctionAverage

=== '''PDRFoam用の新しいセットフィールド・ユーティリティ''' ===
新しいPDRsetFieldsユーティリティはPDRFoamソルバーで使用する閉塞のテンソル抵抗を計算します。ジオメトリはPDRsetFieldsDictファイルを使ってプリミティブ形状の形で入力されます：<syntaxhighlight lang="bash">
// Data dictionary for PDRsetFields

// Replace by the relevant names

obsFileDir "<case>/geometry";

obsFileNames (obstaclesDict);

// legacyObsSpec true;

//

// obsFileNames (position.obs base.obs);
</syntaxhighlight>障害物は、obsFileNamesエントリーの下にリストされた個別のファイルで提供される。以下のような様々なタイプの障害物がサポートされている：

* cylinder
* diagonal beam
* cuboid
* grating
* louvre
* patch

以下に障害物の例を示す：

; Source code
: $FOAM_UTILITIES//utilities/preProcessing/PDRsetFields
; Tutorial
: $FOAM_UTILITIES/combustion/PDRFoam/pipeLattice

=== checkMeshから出力される壁の距離 ===
checkMesh ユーティリティのオプション -writeAllFields が拡張され、壁距離をフィールド wallDistance として書き込むようになりました。これは、system/fvSchemes辞書で壁距離法が選択されていることを必要とします：<syntaxhighlight lang="bash">
wallDist
{
method meshWave;
}
</syntaxhighlight>wallDistanceは壁パッチのSMALL(1e-15)に設定され、paraFoamなどで後処理することができます：

; Source code
: $FOAM_UTILITIES/mesh/manipulation/checkMesh

== snappyHexMesh : 細いギャップを自動的に閉じる ==
複雑な形状のメッシュを作成する際、ユーザがメッシュを必要としない薄いギャップがあるかもしれません。このリリースではsnappyHexMeshは面毎、面領域毎にメッシュするギャップの最小サイズを指定するblockLevelを指定することができます。この指定されたサイズより小さいギャップ内のセルは削除されます（その結果、ギャップ内のセルはなくなります）。

この拡張機能は以下の構文で有効になる：<syntaxhighlight lang="bash">
refinementSurfaces
{
"gap.*"
{
// Surface-wise min and max refinement level
level (2 2);

// From cell level 2 onwards start checking
// for opposite surfaces
blockLevel 2;
}
}
</syntaxhighlight>blockLevel 設定は以下を決定する。

* ギャップ検知にサーフェスが全く使用されていないかどうか。
* 理想的なギャップの大きさ：2 * cellize; ここで、cellize は初期セルサイズから blockLevel を何倍かにリファインして決定される。

全てのサーフェス精密化snappyHexMeshの後、シェル/ボリュームの精密化の前に、全てのセルについて最も近い2つのサーフェスを決定します。もしセルが

* 2つの面の間、または同じ面の切り離された領域
* であり、対向点間の距離はギャップサイズより小さい。

の場合、セルは削除される。

チュートリアルのopposite_wallsは、薄いギャップを形成する2つの表面を持つ単純なブロックです。

; Tutorial
: $FOAM_TUTORIALS/mesh/snappyHexMesh/opposite˙walls

== 数値 ==

=== 新しい随伴形状最適化 ===
アジョイント・ライブラリは、自動化された形状最適化ループを可能にする新機能で強化されている。

これは、OpenFOAMのガバナンス・フレームワークの下、OpenFOAM-v1906でリリースされたアジョイント最適化ツールの続編です。

体積Bスプラインに基づくパラメータ化スキームが導入され、その制御点は最適化ループにおける設計変数として機能する（下記参照）。ボリューメトリックBスプラインボックスの制御点は、直交座標または円筒座標で定義できます。

ループ全体（流体方程式とアジョイント方程式の解法，感度導関数の計算，設計変数とメッシュの更新）は，adjointOptimisationFoam ソルバー内で実行されます．設計変数を更新するために，BFGS のような一般的な準ニュートン法や，SQP や拘束射影のような拘束を扱える方法など，多くの方法が実装されています．

; Source code
: $FOAM_SOLVERS/incompressible/adjointOptimisationFoam $FOAM_SRC/optimisation/adjointOptimisation/adjoint
; Examples
: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam
; Attribution
: このソフトウェアはPCOpt/NTUAとFOSS GPによって開発され、以下の人々からの貢献があった。
:* Dr Evangelos Papoutsis-Kiachagias,
:* Konstantinos Gkaragounis,
:* Professor Kyriakos Giannakoglou,
:* Dr Andrew Heather
; References
:* E.M. Papoutsis-Kiachagias, N. Magoulas, J. Mueller, C. Othmer, K.C. Giannakoglou: ’Noise Reduction in Car Aerodynamics using a Surrogate Objective Function and the Continuous Adjoint Method with Wall Functions’, Computers & Fluids, 122:223-232, 2015
:* E. M. Papoutsis-Kiachagias, V. G. Asouti, K. C. Giannakoglou, K. Gkagkas, S. Shimokawa, E. Itakura: Multi-point aerodynamic shape optimization of cars based on continuous adjoint, Structural and Multidisciplinary Optimization, 59(2):675694, 2019
; Integration
: コードはOpenCFDとNTUAが共同で統合した。

=== 新しい重み付き磁束補間スキーム ===
新しいweightedFlux補間スキームは、重み付けされたフラックスを用いる線形スキームである。

次のような一般的なフラックスの場合：

の面値を必要とするガウスの定理を用いて勾配を計算する。これは次のように計算される：

どこ:

* φi is the cell value
* φfis the face value
*
* σi is the diffusivity coefficient

不連続の場合、線形補間は正しくないフラックスを生成する。weightedFlux補間スキームは、Tの調和補間と組み合わせて以下のように使用される。<syntaxhighlight lang="bash">
laplacianSchemes
{
laplacian(DT,T) Gauss harmonic corrected;
}

gradSchemes
{
grad(T) Gauss weightedFlux sigma;
}
</syntaxhighlight>上記の例では、以下のように滑らかな温度と熱流束のプロファイルが得られる：

; Source code
: $FOAM_SRC/finiteVolume/interpolation/surfaceInterpolation/schemes/weightedFlux
; Tutorial
: $FOAM_TUTORIALS/verificationAndValidation/schemes/weigthedFluxExample
; Attribution
: このスキームはノルベルト・ウェーバーの寄稿によるものである。
; References
:* Weber, N.; Beckstein, P.; Galindo, V.; Starace, M.; Weier, T.: Electro-vortex flow simulation using coupled meshes, Computers and Fluids 168(2018) 101-109
:* For more details see the Issue tracker

=== 混合精度モードでのジオメトリ処理の改善 ===
OpenFOAM-v1906で導入された混合精度モード(SPDP)により、倍精度で実行する場合に比べ、大幅なスピードアップとメモリ要件の削減が可能になります。

混合精度モードでは、線形ソルバーだけが倍精度で動作する。他の機能はすべて単精度で実行されます。これにより、例えばcheckMeshを使用した場合、完全に有効なクローズドセルがオープンセルとして表示される可能性があります。単精度(SP)で実行すると、以下のようなレポートが表示されます：<syntaxhighlight lang="bash">
***Boundary openness (3.77976e-07 3.97566e-06 -2.26237e-08) possible hole in boundary description.
</syntaxhighlight>このバージョンでは、倍精度計算が次のように拡張されています。

* 面の中心と面積、セルの中心と体積の計算。実際の結果はまだ単精度で保存されていることに注意してください。
* ほとんどのcheckMeshの合計、例えばオープンセルの上。
* すべてのフィールドベースの合計（sum）。

これらの変更はSPDPモードにのみ影響することに注意。前の例では、次のように報告されている：

境界の開き (-6.31099e-11 -3.99859e-11 -3.747e-10) OK.

; Source code
: $FOAM_SRC/src/OpenFOAM/meshes/primitiveMesh/primitiveMeshCellCentresAndVols.C $FOAM_SRC/src/OpenFOAM/meshes/primitiveMesh/primitiveMeshFaceCentresAndAreas.C

== ソルバーと物理モデル ==

=== 新しいインターフェイス追跡ダイナミック・メッシュ ===
このリリースには、foam-extendプロジェクトのムービングメッシュインターフェーストラッキングライブラリが統合されています。OpenFOAM v1912への移植は、Zeljko Tukovic (FMENA, Zagreb)がOpenCFD Ltd.と共同で行いました。

基本的な機能は、interfaceTrackingFvMeshクラスによって実装されています。自由表面における運動学的および動的条件は、速度と圧力のカスタム境界条件によって課されます。界面追跡計算は、標準的なpimpleFoamソルバーを使用して実行されます。

下の例は、汚染され、擾乱を受けた液滴の濃度と形状の変化を示している。

; Source code
: $FOAM_SRC/dynamicFaMesh/interfaceTrackingFvMesh
; Tutorial
: $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contactAngleCavity $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contaminatedDroplet2D
; References
: Z. Tukovic and H. Jasak. A moving mesh finite volume interface tracking method for surface tension dominated interfacial fluid flow. Computers & fluids. 55 (2012) 70-84.
; Attribution
: Code written and contributed by Zeljko Tukovic

=== 新しい6自由度（DoF）機能 ===

===== 新しいlinearSpringDamper拘束モデル =====
6自由度ライブラリには、新しいlinearSpringDamperモデルが含まれています。

これはスプリングダンパーシステムで、アンカーとrefAttachmentPt間の距離がrestLengthを超えたときに「ソフトな」ロープ拘束として機能する。

ロープがたるんでいるときは、体に力はかからない。dynamicMeshDictでの指定は以下の通り：<syntaxhighlight lang="bash">
restraints
{
chain
{
sixDoFRigidBodyMotionRestraint linearSpringDamper;
refAttachmentPt (3.7 4.2 4.5);
anchor table
(
(0 (3.7 4.2 6.5))
(2 (4.7 4.2 6.5))
(6 (5.7 4.2 4.5))
(8 (6.7 4.2 4.5))
);
psi 1;
wn 8.28;
numberOfChains 4;
restLength 2;
}
}
</syntaxhighlight>どこだ？

* refAttachmentPtはソリッドオブジェクトへのアタッチメントポイントです。
* anchorはロープのアンカーで、Function1の時間依存の項目として指定される。
* psiは減衰比。
* wnは、システムの減衰していない固有振動数である。
* numberOfChainsは、ボディに取り付けられているチェーンの数。
* restLength はロープの残りの長さ。

システムの減衰と剛性は次のように計算される：

注：psiとwnは、柔らかいロープの挙動をモデル化するために、過減衰系に対して設定されるべきである。

; Source code
: $FOAM_SRC/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/restraints/linearSpringDamper

===== 新しいソフト・ウォール・サスペンション =====
新しいソフトウォールモデルは、壁法線方向のアンカーとrefAttachmentPt間の距離が負になったときに「ソフト」な壁として機能するダンパー-線形-バネ拘束です。

ロープがたるんでいるときは、体に力はかからない。dynamicMeshDictでの指定は以下の通り：<syntaxhighlight lang="bash">
restraints
{
upperWall
{
type softWall;
body floatingObject;
anchor (0.5 0.5 0.7);
refAttachmentPt (0.5 0.5 0.58);
wallNormal (0 0 -1);
psi 2.0;
C 0.01;
}
}
</syntaxhighlight>どこ:

* refAttachmentPtは、ソリッドオブジェクトへのアタッチメントポイントです。
* アンカーはロープの錨である。
* psiは減衰比
* wallNormal は壁の法線方向
* Cはモデル定数

システムの減衰と剛性は次のように計算される：

; Source code
: $FOAM_SRC/rigidBodyDynamics/restraints/softWall

===== オーバーセットされたダイナミックメッシュのための新しいマルチモーション機能 =====
オーバーセット・ダイナミック・メッシュが複数のモーション・タイプを扱えるようになりました。これにより、ユーザーは異なるモーション・ソルバーのアクションで異なるオブジェクトを動かすことができます。

一例を挙げよう：

* $FOAM_TUTORIALS/multiphase/overInterDyMFoam/floatingBodyWithSpring

dynamicMeshDict辞書の中で、dynamicOversetFvMeshは2つのモーション・ソルバーを持っています：

* 新しいdrivenLinearMotionを使ったsolidBody（下記参照）
* sixDoFRigidBodyMotion

チュートリアルでは、2つのモーション・ソルバーが異なるセルセットに適用される。

cubeという名前のソルバーは、モーション・ソルバーsixDoFRigidBodyMotionを使用するfloatingObjectです。新しいキーワードCofGvelocityは、drivenLinearMotionソルバーで使用するオブジェクトの重心速度を書き込む。

新しいdrivenLinearMotionモーションソルバは剛体タイプで、エントリーCofGvelocityに従って点を移動します。このチュートリアルでは、オーバーセット計算の背景メッシュに対応するc0セルセットに適用します。

drivenLinearMotionは、オーバーセット計算の "inset "領域で、与えられたオブジェクトに "追従する "背景メッシュを設定することができます。これは、オブジェクトの予想される変位が大きい場合にメッシュサイズを小さくするのに役立ちます。

; Tutorial
: $FOAM_TUTORIALS/multiphase/overInterDyMFoam/floatingBodyWithSpring

=== 新しい平行放射モデル ===

===== fvDOM用の新しい平行太陽ビームモデル =====
fvDOM放射モデルに、太陽外部負荷からの外部ビームのサポートが追加されました。この効果はfvDOMモデルの光線に追加され、radiationProperties辞書の新しい項目useExternalBeamをtrueに設定することで有効になります。

fvDOMの光線立体角は、角度離散化に従って最適な光線方向と一致するように回転される。

線源のエネルギー・スペクトルを得るには、以下のエントリーを使用する：<syntaxhighlight lang="bash">
spectralDistribution (2 1)
</syntaxhighlight>注：spectralDistributionのバンド数は、吸収率モデルのバンド数と一致する必要があります。つまり、boundaryRadiationPropertiesのmultiBandAbsorptionです：<syntaxhighlight lang="bash">
type opaqueDiffusive;
wallAbsorptionEmissionModel
{
type multiBandAbsorption;
absorptivity (0.3 0.7);
emissivity (0.3 0.7);
};
</syntaxhighlight>輻射境界条件の例では、不透明な拡散壁と、2つのバンドを用いたマルチバンド吸収モデルを指定しています。

コリメートモデルは、solarLoad放射モデルと併用しないでください。

コリメートモデルは、太陽計算機を使用して太陽の方向とエネルギー束を導きます。標準モデルは、solarLoad放射モデルと同様に使用できます。

; Source code
: $FOAM_SRC/thermophysicalModels/radiation/radiationModels/fvDOM

===== 新しいマルチバンドゾーン吸収発光モデル =====
新しいmultiBandZoneAbsorptionEmissionモデルは、領域内の不均一な吸収率および放射率フィールドの使用を可能にします。例えば、2つのバンドモデルの場合：<syntaxhighlight lang="bash">
multiBandZoneAbsorptionEmissionCoeffs
{
absorptivity (0.01 0.01);
emissivity (0.01 0.01);
zones
{
absorptivity ("trees" (20 20));
emissivity ("trees" (20 20));
}
}
</syntaxhighlight>この例では、背景メッシュに(0.01 0.01)、樹木というゾーンに(20 20)の吸収率を設定している。

; Source code
: $FOAM_SRC/thermophysicalModels/radiation/submodels/absorptionEmissionModel/absorptionEmissionModel/multiBandZoneAbsorptionEmission
; Tutorial
: $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/solarBeamWithTrees

=== 新しい多相乱流安定化 ===
乱流の運動エネルギーは、非圧縮VOFソルバーにおいて、表面波下のほぼポテンシャル流領域において、位相界面および水柱全体で過剰に予測される。

この挙動は、乱流運動エネルギー方程式と乱流粘性場に補正を適用する新しいmultiphaseStabilizedTurbulence fvOptionを使用して補正されます。

を使って指定する：<syntaxhighlight lang="bash">
multiphaseStabilizedTurbulence1
{
type multiphaseStabilizedTurbulence;
active yes;
multiphaseStabilizedTurbulenceCoeffs

{
// Optional coefficients
lambda2 0.1; // A value of 0 sets the nut correction to 0
Cmu 0.09; // from k-epsilon model
C 1.51; // model coefficient from k-omega model
alpha 1.36; // 1/Prt
}
}
</syntaxhighlight>

; Source code
: $FOAM_SRC/fvOptions/sources/derived/multiphaseStabilizedTurbulence
; References
:* Devolder, B., Rauwoens, P., and Troch, P. (2017). Application of a buoyancy-modified k-w SST turbulence model to simulate wave run-up around a monopile subjected to regular waves using OpenFOAM. Coastal Engineering, 125, 81-94.
:* Larsen, B.E. and Fuhrman, D.R. (2018). On the over-production of turbulence beneath surface waves in Reynolds-averaged Navier-Stokes models J. Fluid Mech, 853, 419-460
; Attribution
:* OpenCFDによる実装
:* Turbulence Technical Committee、およびBjarke Eltard-LarsenとDavid Fuhrman（デンマーク工科大学）による有益な議論とコードテストに感謝する。

=== 新しいk-epsilon-phit-f乱流モデル ===
Laurenceら, 2005）の研究に基づき、kEpsilonPhitFと名付けられた楕円緩和関数を用いた新しい3輸送方程式線形渦粘性RANS乱流クロージャーモデルが実装されました。

kEpsilonPhitFは、(Durbin, 1995)のv2-f手法に由来するkEpsilonベースのモデルである。v2-f手法の主な利点は、渦粘性モデルの最小限の定式化を維持しながら、線形渦粘性モデルとレイノルズ応力方程式モデルの中間を提供することであると報告されています。このことは、壁面距離や低レイノルズ数型の修正を行うことなく、壁面に向かって壁面法線速度スケールが放物線状に減衰することをシミュレーションに依存せずに再現できることに現れています。

しかし、v2-fモデルの大半は、特に壁境界において、v2場とf場の連成の定式化により、分離解法アルゴリズムでは数値的に厳しいことが判明した。

この欠点にもかかわらず、v2-fモデルは、さまざまな非平衡／非局所効果を示す流れ、強い圧力勾配、分離、衝突を伴う流れ、熱伝達を含む乱流場への変動圧力の影響など、幅広い一般的な流れの特性をうまく再現することが確認されている。

LienとKalitzin, 2001）によるv2-fモデル（すなわちOpenFOAMのv2fモデル）は、分離計算を可能にするためにオリジナルのv2-fモデルを再定義したものであるが、モデルの忠実度に関する多くの欠点が文献に報告されている。

v2-f手法の欠点を克服するために、v2-f手法は(Hanjali et al., 2004)と(Laurence et al., 2005)によって再評価され、同時に、スケールを等価な無次元形式に変換することによって、すなわち数値的な剛性を低減することによって再評価された。これらの変種は、オリジナルのv2-fモデルの理論的なモデルの忠実性を保持しながら、数値的なロバスト性と格子異常に対する鈍感性を提供すると考えられた。

kEpsilonPhitFモデルはベータ段階であることにご注意ください。今後、モデルの内部的な変更が行われる可能性もありますし、行われない可能性もあります。さらに、OpenFOAMで利用可能なv2fモデルは、kEpsilonPhitFまたは他のv2-fモデルのバリエーションに取って代わられる予定です。

kEpsilonPhitFモデルの実装は，平滑壁平面流路流（），ゼロ圧力勾配乱流平板，2次元後向きステップ，流路内2次元丘の正準流によって検証された．

例として、3つの検証プロットを以下に示す：

モデル方程式、実装、使用法に関するより詳細な情報は、（拡張コードガイドのkEpsilonPhitFセクション）にあります。

; Source code
: $FOAM_SRC/TurbulenceModels/turbulenceModels/RAS/kEpsilonPhitF
; Tutorial
: $FOAM_TUTORIALS/incompressible/simpleFoam/RAS/bump2D
; Attribution
: OpenCFD は、有益な議論と有益な示唆を与えてくれた Mirza Popovac 博士 (オーストリア工科大学) に感謝したい。

=== 雪崩モデリング・モジュールの更新 ===
冬が近づくにつれ、雪崩モデリング・モジュールでは、RAMMSモデル（Christen et al, 2010）の実装やMedinaモデルの安定性の改善など、巻き込みモデルの更新が行われた。

; Source code
: <nowiki>https://develop.openfoam.com/Development/openfoammodules/avalanche</nowiki>
; Attribution
: The avalanche code is developed by Matti Rauter

=== 液体の新しい状態方程式 ===
液体と固体のための逆多項式状態方程式rPolynomialはopenfoam.orgから統合され、以下の形式を持つ：

新しいオプションは、thermophysicalProperties辞書で次のように指定される：<syntaxhighlight lang="bash">
thermoType
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState rPolynomial; // new entry
specie specie;
energy sensibleInternalEnergy;
}

mixture
{
specie
{
molWeight 18.0;
}

equationOfState
{
// Coefficients for the reciprocal polynomial equation of state
C (0.001278 -2.1055e-06 3.9689e-09 4.3772e-13 -2.0225e-16);
}

thermodynamics
{
Cp 4195;
Hf 0;
}

transport
{
mu 3.645e-4;
Pr 2.289;
}
}
</syntaxhighlight>

; Source code
: $FOAM_SRC/src/thermophysicalModels/specie/equationOfState/rPolynomial
; Tutorial
: $FOAM_TUTORIALS/multiphase/compressibleInterFoam/laminar/depthCharge3D/constant/thermophysicalProperties.water
; Attribution
: モデルはopenfoam.orgから統合された。

== 境界条件 ==

=== ニューウェーブ・モデル ===
このリリースでは、OpenFOAM v1812で導入されたwaveMaker条件を拡張し、パドルの数を選択して3次元波を生成します。3次元フラップ波生成の例を以下に示します。

; Source code
: $FOAM_SRC/waveModels/derivedPointPatchFields/waveMaker
; Examples
: $FOAM_TUTORIALS/multiphase/interFoam/laminar/waves/waveMakerMultiPaddleFlap $FOAM_TUTORIALS/multiphase/interFoam/laminar/waves/waveMakerMultiPaddlePiston
; Attribution
: これらの拡張機能はEnvironmental Hydraulics Institute IHCantabriaから提供されたもので、コミットd0c5662172を参照：ガブリエル・バラハス
; Integration
: このコードは OpenCFD によって統合されました - マージリクエスト 317 を参照してください。

=== 新しい式に基づく境界条件 ===
式が境界条件を満たす場所： exprFixedValue境界条件とexprMixed境界条件。

これらの境界条件は、値、勾配、分数を式としてサポートする。例えば<syntaxhighlight lang="bash">
outlet1
{
type exprFixedValue;
value $internalField;
valueExpr "0.5*(pInlet + pOutlet2)";
variables
(
"pInletinlet = weightAverage(p)"
"pOutlet2outlet2 = p"
);
}
</syntaxhighlight>

; Tutorials
: $FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/TJunctionAverage

=== 新しいスケール境界条件ラッパー ===
これは、任意の（固定値）境界条件に、時間または空間で変化するスケーリングを追加するためのラッパーです。uniformFixedValueのすべての機能が追加されています。下の例では、patch エントリを使用して指定された標準的な fixedValue 境界条件を変更し、scale エントリに従ってスケールを適用します。<syntaxhighlight lang="bash">
<patchName>
{
type scaledFixedValue;
scale table
(
( 0 0)
( 1.0 1.0)
(100.0 1.0)
);

patch
{
type fixedValue;
value uniform (15 0 0);
}
}
</syntaxhighlight>スケールの項目はPatchFunction1であり、以下のような複数のオプションがある：

* constant
* csvFile
* mappedFile
* polynomial
* sampled
* scale
* sine
* square
* table
* tableFile
* uniformValue

; Source code
: $FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/scaledFixedValue

== 後処理 ==

=== パーティクルの後処理の改善 ===

===== クラウドパッチ相互作用モデル =====
オプションでwriteToFileエントリーを使用して、パッチ相互作用の統計情報、例えば、くっついたり、逃げたりした粒子の数と質量をファイルに書き込みます。例として、localInteraction粒子パッチ相互作用モデルを使用する場合、新しいエントリーを次のように追加することができます：<syntaxhighlight lang="bash">
localInteractionCoeffs
{
patches

(
"(walls|cyc.*)"
{
type rebound;
}

"inlet|outlet"
{
type escape;
}
);

// New optional entry
writeToFile yes;
}
</syntaxhighlight>

===== クラウド機能オブジェクト =====
空の場合、またはエントリーが指定されていない場合は、すべてのフィールドが書き込まれます（後方互換性を維持するため）。<syntaxhighlight lang="bash">
patchPostProcessing1
{
type patchPostProcessing;
// Optional new entry
fields (position "U.*" d T nParticle);
maxStoredParcels 20;
patches
(
cycLeft_half0
cycLeft_half1
);
}
</syntaxhighlight>

; Tutorial
: $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter

=== 新しい双方向パーティクル・ストリームライン ===
StreamLinesとwallBoundedStreamLines関数オブジェクトが拡張され、シードポイントからの双方向トラッキングが可能になりました。さらに、wallBoundedStreamlines関数オブジェクトが境界面ごとに複数のトラックをサポートするようになりました。

この新機能は、（以前のリリースのtrackForwardフラグの代わりに）新しいdirectionキーワードで有効にすることができる：<syntaxhighlight lang="bash">
U U;
direction bidirectional; // or forward/backward
fields (U p);
</syntaxhighlight>次の画像は、2組のファンクションオブジェクトが必要だった以前の動作を示している：

; Source code
: $FOAM_SRC/functionObjects/field/streamLine

=== サーフェス関数オブジェクトへの新しい距離 ===
新しいsurfaceDistance関数オブジェクトは、指定されたジオメトリまでの距離を示すフィールド（volScalarField）を生成します。これは、メッシュの解像度が不十分で隙間にメッシュが入らないなどのメッシュの問題を検出するために使用できます。

* サーフェスの指定は、snappyHexMeshおよびfoamyHexMeshと互換性のあるジオメトリ・エントリを介して行われます。
* 特定のサーフェスに限定せず、あらゆるサーフェスで最も近いサーフェスを見つける。
* デフォルトでは、すべてのセル・センターについて最も近いセルも見つける。これはオプションのdoCells booleanフラグをオフにすることで抑制できる。
* 境界上の値は、面の中心からの距離になります。

system/surfaceDistance辞書のサンプル：<syntaxhighlight lang="bash">
surfaceDistance
{
// Where to load it from
libs (fieldFunctionObjects);
type surfaceDistance;
geometry
{
motorBike.obj
{
type triSurfaceMesh;
}
}
}
</syntaxhighlight>これは、例えばpostProcessで使用できる：<syntaxhighlight lang="bash">
postProcess -func surfaceDistance
</syntaxhighlight>

; Source code
: $FOAM_SRC/functionObjects/field/surfaceDistance

== Parallel ==

=== Updated file modification skew ===
When running a parallel case on multiple nodes the processor directories are usually accessed using a network filing system, e.g. NFS. This might have a non-trivial amount of latency to see changes to e.g. dictionaries. For this purpose there is in etc/controlDict

fileModificationSkew 10;

which is the number of seconds of file-modification-time difference before a dictionary is seen as having been changed. The second use is in dynamically compiled code, e.g. through the #codeStream dictionary entry or coded functionObject. Here it is the amount of time waiting for the resulting library in the dynamicCode/ sub-dictionary to become available. However, in some cases the file server might have a large delay so this fileModificationSkew has to be set to the maximum expected value.

In this release the behaviour has been changed in that there is an additional control

maxFileModificationPolls 100;

which is the maximum number of times the code checks after waiting fileModificationSkew seconds. With this behaviour the fileModificationSkew can now be set to a much lower value (minimum 1).

This above problem is only relevant for NFS mounted disks and multi-node runs. Single-node runs will have a consistent view of the files for all cores so if the master has finished compiling the code the slaves will see the same code.

For distributed runs, e.g. using different roots for different cores - see the $FOAM_TUTORIALS/IO/fileHandler tutorial. Here the code needs to be compiled on all cores anyway so there should be no synchronisation problem.

=== Updated ADIOS2 function object ===
The adiosWrite function object has been rewritten to use the ADIOS2 library for parallel IO and is now available as a regular OpenFOAM module

The implementation supports checkpointing and restart read more...

More tests at scale are required and will be conducted as part of the activities of the HPC Technical Committee

== Portability ==

==== New binary file compatibility ====
OpenFOAM-v1912 now handles binary reading of different precision or label sizes to support workflows with mixed compilations of OpenFOAM.

One such workflow could be the following:

* Meshing with snappyHexMesh in double precision.
* Single precision for aerodynamics (for reduced memory bandwidth)
* Further calculation with chemistry (double precision)

This is now possible with binary formatted OpenFOAM files, provided that they contain the necessary size information in their header. For example,

FoamFile

{

version 2.0;

format binary;

arch "LSB;label=32;scalar=64";

class vectorField;

object points;

}

Binary files generated with OpenFOAM-v1612 and later will already contain this information and can be used.

Note that when narrowing the data range e.g. 64-bit label width to 32-bit label width, any range overflows will be truncated.

OpenFOAM v2306リリースノート

2023-09-09T09:07:16Z

Mmer547:

OpenCFDは、OpenFOAM® v2306の2023年6月リリースを発表します。このリリースは、コードの多くの領域にわたってOpenFOAM-v2212の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージも多数あります。

* Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール
* openSUSE Linux: Leap15.5用パッケージインストール
* Redhat Linux: epel-9 用パッケージ・インストール; Fedora 37

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢があります（詳細）：

* Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。
* クロスコンパイルされたネイティブ実行ファイル
* docker インストール

OpenFOAMのapptainerサポートは、事前にアセンブルされたイメージではなく、記述ファイルによって提供されます。

* パッケージング/コンテナ参照

Mac OSXユーザーは、ソースからコンパイルするか、Dockerコンテナを使ってコンパイル済みのパッケージを使用するオプションがあります（詳細）。

== アップグレード ==

=== 省略と削除 ===

==== 境界条件 ====
exprFixed境界条件とexprMixed境界条件に、ランタイム非推奨の警告が表示されるようになりました。同じ機能（およびそれ以上）は、それぞれuniformFixedValue境界条件とuniformMixed境界条件で利用できます。

=== 名前変更 ===

=== ファンクションオブジェクト：patchPostProcessingとpatchParticleHistogram ===
ラグランジュ関数オブジェクトpatchPostProcessingとpatchParticleHistogramは、わかりやすさと理解を深めるために、それぞれparticlePostProcessingとparticleHistogramに名称が変更されました。

=== 入力辞書 ===
不必要な丸め誤差や精度低下を避けるため、#calcと#evalの固定フォーマットと精度制限が削除された。式が評価される際の文字列展開がより一貫したものになるはずです。

==== 表現 ====

* パッチ式で、face()/area()と書く代わりに、normal()を使って単位法線を求めることができるようになりました。

==== 関数オブジェクト: electricPotential ====
電場（E）の計算と出力は、以前のキーワード writeDerivedFields に代わって、オプションのキーワード electricField を使用することで有効または無効にすることができます。また、電場（E）の名前は、新しいキーワード E で指定できるようになりました。

==== 関数オブジェクト: yPlus, wallShearStress ====
yPlusとwallShearStressの両方で、オプションのwriteFieldsフラグが追加され、ボリュームフィールドの出力を無効にできるようになりました。これは、ログに記録された情報のみに関心がある場合に、ディスク容量を節約し、速度を向上させるのに便利です。

=== パラレル ===

==== FOAM_IORANKSの柔軟な取り扱い ====

* は、従来のOpenFOAMのリストと同様に、プレーンなリスト(スペースまたはカンマ区切り)も受け付けます。これにより、ジョブスクリプトでの引数の取り扱いが簡単になります。例えば
<syntaxhighlight lang="bash">
simpleFoam -ioRanks 0,4,8 ...

</syntaxhighlight>対<syntaxhighlight lang="bash">
simpleFoam -ioRanks '(0 4 8)' ...

</syntaxhighlight>ホストごとにIOランクを選択することも可能である：<syntaxhighlight lang="bash">
simpleFoam -ioRanks host ...
</syntaxhighlight>

==== MPIスレッドのコマンドライン指定 ====

* MPI_THREAD_MULTIPLE を持つことは、通常、パフォーマンス上好ましくないが、リンクされたライブラリがMPI_THREAD_MULTIPLE を期待する場合には必要な場合もある。mpi-threads コマンドラインオプションを使用すると、MPI_THREAD_MULTIPLE を明示的に指定することができます。

==== parProfilingの詳細 ====
parProfilingは、より詳細な情報を得るために、異なるMPIオペレーションをより分離するようになった：

* ブロードキャスト・タイムとリデュース／ギャザー／スキャッター・タイムを分離
* 一般的な待ち時間とすべての待ち時間の比較
* リクエストの時間/カウントを他のカウントと分離して、呼び出しカウントをサポートする（他のカウントがマスクされないようにするため）。

=== 有限面積の改善 ===
最小エッジ長のチェックがより一貫性を持ち、小さなエッジの存在下でもロバスターとなった。2次元テンソルの逆変換の取り扱いが改善され，有限面積における最小二乗法がロバスターになった．

=== メッシュ生成 ===

==== makeFaMesh ====
スター "接続の中心や、パッチ面が実際にはバッフルであるために発生する、多重接続された有限面積のエッジを処理するためのヒューリスティックが追加された。

直列の場合、これらの内部エッジはモデル化という点ではかなり疑わしいが、プロセッサーのドメインにまたがって分割されると、かなりの問題を引き起こす。接続性を一意に決定するのに十分な情報があるとは限らないが、エッジを結合するための何らかの救済措置はしばしば可能である。余分な "ぶら下がった "エッジは無視パッチに追いやられ、別々に扱われるようになります。

これらのヒューリスティックは、遭遇したいくつかの問題を解決するものではあるが、さらなる研究が必要である。

=== メッシュチェック／後処理 ===

==== checkMesh ====

* checkMeshとmakeFaMeshにグローバルトポロジーチェックを追加し、境界パッチがエッジ間で多重接続されている場合にそれを検出するようにした。
* checkMeshの新しい-write-edgesオプション：トポロジー的に問題のあるエッジをディスクに書き出すことができます。この新機能は有用な診断補助となります（特に、不正なエッジがあっても壊れにくい有限面積メッシュの場合）。

==== foamToVTK ====
foamToVTKを-no-internalおよび-no-boundaryオプションで実行すると、フィールドの読み込みと報告がすべて抑制され、速度が大幅に向上する。

フィールドを用いた通常の変換では、ロードされたボリュームフィールドは点補間で再利用するために一時的にキャッシュされる。これにより、入力IOが削減され、実行時間が改善される。

== 前処理 ==

=== snappyHexMesh：過剰なバランシングの回避 ===
snappyHexMeshはセルを並列に精錬する際に自動的にメッシュのバランスを取ります。snappyHexMeshDict入力ファイルのcastellatedMeshControlsセクションの新しいコントロールはこの処理を調整するために使用することができます：

* maxCellUnbalance : [オプション] 絶対的なアンバランス開始トリガー。セル数が少ない場合に、最初の洗練反復でバランシングを回避するために使用される。トリガー値はバランシングをスキップするために使用される：
** どのプロセッサでも、新しく追加されたセルの数 <= maxCellUnbalance の場合
** いずれかのプロセッサの場合：（プロセッサの新しいセル数 - 理想的なセル数） <= maxCellUnbalance
* balanceAtEnd : [オプション] maxCellUnbalanceエントリーがメッシュのアンバランスを引き起こす可能性があるため、メッシュが完全にリファインされた後に強制的にバランシングを行う。
* (existing) maxLoadUnbalance : ある程度のアンバランスを許容する。

これらの追加制御を用いることで、コア数が多い場合、キャステレーション段階で大幅なスピードアップが実現した。なお、スナッピングとレイヤー追加フェーズは影響を受けない。

Source code

* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver

Merge request

* MR!607

=== checkMeshの改良 ===
checkMeshは自動的にプロセッサ・パッチのレポートをフィルタリングしますが、そのプロパティは有用です。このリリースでは、プロセッサ・パッチのフィルタリングは並列実行のみに制限されています。
例として、シリアルで走る：
<code>checkMesh -case processor0 -allTopology -allGeometry</code>
報告：
<code>Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology Bounding box
front 2275 2399 ok (non-closed singly connected) (-0.572 -1 0.007621454194) (-0.17456 1 0.02497405934)
..
procBoundary0to1 101 204 ok (non-closed singly connected) (-0.19184 -1 -0.008375915288) (-0.17456 1 0.008375915288)
".*" 4796 4798 ok (closed singly connected) (-0.572 -1 -0.02497405934) (-0.17456 1 0.02497405934)</code>
個々のプロセッサ境界のレポートに注意してください。これは、全体の境界面のエントリ（".*"）にも含まれます。並列実行の場合、v2212と同様に、プロセッサパッチはリストと全体の境界面から除外されます。

Source code

* $FOAM_UTILITIES/mesh/manipulation/checkMesh

Issue tracker

* !698

== 数値 ==

=== finiteAreaの新しいキャッシュグラデーションメカニズム ===
もともと有限体積フレームワークで利用可能だった）勾配キャッシング・メカニズムが、有限面積フレームワークにも適用された。
有効にすると、従属フィールドが変更されたときにのみ勾配フィールドが計算され、後で再利用できるようにメッシュデータベースのメモリに保存されるため、追加コストのかかる再評価を省くことができます。

system/faSolutionファイルでの使用例を以下に示す：
<code>cache
{
grad(h);
grad(Us);
}</code>
Source code

* $FOAM_SRC/finiteArea/finiteArea/gradSchemes/faGradScheme/faGradScheme.H

Merge request

* MR!611

=== 新しい並列プリコンディショナ ===
新しいプリコンディショナdistributedDILU, distributedDICは、DILU, DICプリコンディショナにRed-Black型の並列動作のバリエーションを追加したものである。これらの新しいプリコンディショナは、GAMGソルバーの最も粗いレベルを解くのに特に有用である：
<code>p
{
solver GAMG;
// Explicit specify solver for coarse-level correction to override
// preconditioner
coarsestLevelCorr
{
solver PCG;
preconditioner distributedDIC;
}
} </code>
コア数が非常に大きい場合、スケーリングのボトルネックは、最も粗いレベルの解における大域的な削減となる可能性があり、分散プリコンディショナーは、（追加のハロースワップを犠牲にして）掃引量と削減量を減らすことができる。4096コアの大規模な場合：

この性能上の利点は、タイミングに表れている：
{| class="wikitable"
!preconditioner
!Execution time
|-
|DIC
|8687s
|-
|distributedDIC
|6326s
|}
分散型プリコンディショナの使用は、一般に、計算が大域的なリダクションに束縛される場合にのみ意味を持つことに注意してください。非分散型と比較すると、ハロースイープを追加する代償として、CGスイープ回数（および削減回数）を減らすことができます。少ないコア数では、これは有益ではないかもしれない。CG掃引の回数がとにかく少ない場合、例えば相対公差で解く場合も同様です。

同じ戦略は、他の結合境界条件、例えばサイクリック、サイクリックAMIにも適用できる。前方ループでは、'owner'パッチに対する'neighbor'の効果が含まれ、後方ループではその逆の効果が含まれます。これはcoupledスイッチで切り替えます（デフォルトはon）：
<code>solver PCG;
preconditioner distributedDIC;
coupled false; // do not precondition across non-processor coupled</code>
cyclicAMIの場合、2つのサイドが異なるプロセッサー上に排他的に存在するか、まったく分散されていない必要があるという制限がある。

新しいプリコンディショナーは構築するのにかなりコストがかかるため、線形ソルバー内部にキャッシュされる。これは、GAMG内部の最も粗いレベルの補正ソルバーにのみ影響する。

Source code

* $FOAM_SRC/meshTools/matrices/lduMatrix/preconditioners/distributedDILUPreconditioner/distributedDILUPreconditioner.H
* $FOAM_SRC/meshTools/matrices/lduMatrix/preconditioners/distributedDILUPreconditioner/distributedDICPreconditioner.H

References

* Yousef Saad, Iterative Methods for Sparse Linear Systems (2nd edition)

Merge request

* MR!608

=== 新しいFPCG線形ソルバー ===
PCG線形ソルバーの新しいドロップイン代替であるFPCGは、1掃引あたりの削減回数を3回から2回に削減します。これにより、特にGAMG線形ソルバーで最も粗いレベルを解くときに、並列削減がボトルネックになる可能性のあるコア数が大きい場合に、並列スケーリングが改善されるはずです。
このソルバーは、リダクションの数と追加ストレージ/パイプライン量のトレードオフを提供します。これは、ハロースワップとリダクションをオーバーラップさせるPPCGソルバーと比較することができます（しかし、追加のストレージが必要です）。

FPCGは、1つの余分なプリコンディショニングステップを必要とするため、より複雑なプリコンディショナー（例えばGAMG）にとってはあまり有益でない可能性があることに注意されたい。

Attribution

* OpenCFD would like to acknowledge and thank Alon Zameret of Toga Networks for providing the code and elaborate discussions.

Source code

* $FOAM_SRC/matrices/lduMatrix/solvers/FPCG/FPCG.C

Merge request

* MR!601

=== テンソル反転の処理の改善 ===
テンソルの逆変換は、例えば最小二乗法計算に必要であり、テンソルの値が面内、例えば本質的に2Dである場合には特に厄介です。このような場合は、「安全な」逆変換アプローチによって処理されるようになり、擬似逆変換のようなコストのかかるオーバーヘッドなしにロバスト性が追加されます。この変更は、主にいくつかの有限面積スキームのロバスト性に影響します。

=== メッシュセル/ポイント計算の改善（高速化） ===
セルからポイント、またはポイントからセルへのアドレッシングの情報は、異なるアルゴリズムに必要とされる。このタイプのアドレッシングは計算するのに比較的コストがかかるので、可能な限りキャッシュされ、不足するアドレッシングを導き出すために再利用される。
これは通常1回限りのコストであるが、キャッシュされた値を無効にするようなトポロジーの変更を伴うメッシュでは、より大きな要因になる可能性がある。アドレッシングを再構築するための更新されたアプローチは、速度を1.4倍から2.4倍に向上させる。

Attribution

* OpenCFD would like to acknowledge and thank Toga Networks for providing the code and elaborate discussions.
* issue 2715
* MR!596

== ソルバーと物理モデル ==

=== 改良されたvanDriest LESデルタモデル ===
vanDriest LESデルタモデルでは、最も近い壁の特性（y*）が局所的な長さスケールを計算するために使用されます。以前のリリースでは、これらの壁のプロパティは、壁の距離（meshWave）を計算するために同じメカニズムを使用して輸送されていました。このリリースでは、アドレッシングは一度計算され、最も近い壁の情報を直接取得できるようにキャッシュされます。これにより、（余分なストレージを必要としますが）大きなメッシュで非常に大きなスピードアップが得られます。さらに、同じアドレッシングは、fvSchemesの新しいmeshWaveAddressing wallDistメソッドを使用して、壁の距離自体にも使用できます：
<code>wallDist
{
method meshWaveAddressing;

// Fetch the nearest wall normal
nRequired true;

// Optional entry delaying wall distance update to every n steps
// Default is 1 (update every step)
updateInterval 5;
} </code>
次の画像は、ExaFoamプロジェクトの一環として実証された、これらの改善による強力なスケーリング性能を示している：

Source code

* $FOAM_SRC/TurbulenceModels/turbulenceModels/LES/LESdeltas/vanDriestDelta

Resolved bugs

* !2648

=== 新しいラグランジュ粒子力クーロン ===
新しいクーロン有限体積オプション(fvOption)は、電場を評価するためのelectricPotential関数オブジェクトの本質的な基礎的な変更とともに、直径に基づいて粒子に作用する静電気力のモデルを提供します。カップリングは現在一方通行です。
最低限の使用例を以下に示す：
<code>subModels
{
solution
{
interpolationSchemes
{
<Ename> <interpolationScheme>; // Electric field name
}
}

particleForces
{
Coulomb
{
q <Function1<scalar>>; // Electric charge of particles
E <word>; // Electric field
}
}
}</code>
Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/ParticleForces/Coulomb

Merge request

* MR!602

=== 新しいfvOption：fanMomentumSource ===
新しいfanMomentumSource有限体積オプション（fvOption）は、流れに対するファンの作用を表現する運動量ソースを追加します。
まず、セルゾーンを囲む上流側の面を通過する流量が計算される。上流側の面は流れ方向と周囲の面ゾーンを用いて自動的に決定される。続いて、流量の関数としてのファン圧力曲線とファン（測定部）の厚さから圧力勾配を求める。

最小限の使用例は以下の通り：
<code>fan
{
// Mandatory entries
type fanMomentumSource;
fanCurve <Function1<scalar>>;
flowDir <vector>;
thickness <scalar>;
cellZone <word>;
faceZone <word>;

// Optional entries
gradient <scalar>;
rho <scalar>;
U <word>;

// Inherited entries
selectionMode <word>;
...
}</code>

Source code

* $FOAM_SRC/fvOptions/sources/derived/fanMomentumSource

Merge request

* MR!604

Attribution

* OpenCFD would like to acknowledge and thank Vuko Vukcevic of SimScale GmbH for providing the code and elaborate discussions.

=== 新しい fvOption: limitTurbulenceViscosity。 ===
新しいlimitTurbulenceViscosity有限体積オプション(fvOption)は、計算の安定性を高める乱流粘度nutを制限するメカニズムを提供します。
乱流粘性場は、層流粘性に係数を乗じた上限値を適用することで、指定された領域内で補正される：

最小限の使用例は以下の通り：
<code>limitTurbulenceViscosity1
{
// Mandatory entries
type limitTurbulenceViscosity;

// Optional entries
nut nut;
c 1e5;

// Inherited entries
...
}</code>
Source code

* $FOAM_SRC/fvOptions/corrections/limitTurbulenceViscosity

=== 改良された剛体運動拘束：軸 ===
軸拘束は、ボディが固定軸の周りにしか回転できないような方向制限を課します。これは、例えばバタフライバルブをモデル化するために、最小回転角度と最大回転角度を追加することで強化されました。
さらに、すべての剛体運動制約がランタイムで調整可能になった。

最小限の使用例は以下の通り：

<code>constraints
{
constrainRotation1
{
sixDoFRigidBodyMotionConstraint axis;
axis <vector>;

// Optional entries
maxClockwiseTheta <Function1<scalar>>;
maxCounterclockwiseTheta <Function1<scalar>>;
thetaUnits <word>;
referenceOrientation <tensor>;
}
}</code>
Source code

* $FOAM_SRC/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/constraints/axis

Merge request

* MR!613

== 境界条件 ==

==== 新しい境界条件：鏡面放射 ====
fvDOM放射モデルは、新しいspecularRadiation境界条件を使用して、軸対称および対称面セットアップに適用できるようになりました。
この境界条件の最小限の例を以下に示す：
<code>{
// Mandatory entries
type specularRadiation;

// Optional entries
interpolate <bool>;

// Inherited entries
patchType <word>;
...
} </code>
下図は、4つの異なる形状の内部無次元入射放射の観点から条件を検証したものである：

Source code

* $FOAM_SRC/thermophysicalModels/radiation/derivedFvPatchFields/specularRadiation

References

* Standard model:
** Kumar, P., & Eswaran, V. (2013). A methodology to solve 2D and axisymmetric radiative transfer problems using a general 3D solver. Journal of heat transfer, 135(12). DOI:10.1115/1.4024674

Merge request

* MR!610

Attribution

* OpenCFD would like to acknowledge and thank Hitachi Energy for sponsoring the development, and Bernardo Galletti and Marcelo Buffoni for elaborate discussions.

=== 新ユニフォーム混合コンディション ===
新しいuniformMixed境界条件は、既存のuniformFixedValue境界条件とuniformFixedGradient境界条件を補完するものです。
この条件は混合境界条件を定義するために使用され、値を定義するために関数を使用する。
<code>{
type uniformMixed;
uniformValue constant 0.2;
uniformGradient constant 0.2;
uniformValueFraction
{
type sine;
...
}
}</code>
しかし、境界条件は遅延定義を許可しているため、uniformValueまたはuniformGradientの一方だけを定義し、他のエントリーを暗黙的に定義することも可能である。

uniformMixedで使用される関数には式も含まれるため、この新しい境界条件は、将来非推奨となり削除される既存のexprMixed境界条件のより柔軟な形として使用することができる。

Source code

* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformMixed

Tutorial

* $FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/TJunctionAverage/0/U

=== 新しい有限領域境界条件 ===
有限面積計算でuniformFixedValue、uniformFixedGradient、uniformMixed境界条件が使用できるようになりました。
これらの境界条件はFinite Areaに関数と式のサポートを追加します。timeVaryingUniformFixedValue境界条件は非推奨となり、将来削除される予定です。

Source code

* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformFixedValue
* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformFixedGradient
* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformMixed

== 後処理 ==

=== ラグランジュ関数オブジェクトの改良 ===
ラグランジアン・クラウド・ファンクション・オブジェクトは複数のアップデートを受けた：

* patchPostProcessingとpatchParticleHistogramは、それぞれの機能をよりよく反映させるために、それぞれparticlePostProcessingとparticleHistogramという名前に変更されました；
* writeFileサポートが追加され、ファイル出力の制御が改善された。
* faceZoneのサポートが追加され、パーティクル収集のコントロールが向上しました。

最低限の使用例を以下に示す：

<code>ParticlePostProcessing1
{
// Mandatory entries
type particlePostProcessing;
maxStoredParcels <scalar>;

// Optional entries
fields (<wordRes>);

// Conditional entries

// Option-1
patches (<wordRes>);

// Option-2
faceZones (<wordRes>);

// Inherited entries
// writeFile entries
...
}

particleHistogram1
{
// Mandatory entries
type particleHistogram;
nBins <label>;
min <scalar>;
max <scalar>;
maxStoredParcels <scalar>;

// Conditional entries

// Option-1
patches (<wordRes>);

// Option-2
faceZones (<wordRes>);

// Inherited entries
// writeFile entries
...
}</code>
Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticleHistogram
* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticlePostProcessing

Merge request

* MR!595

=== 改良されたファンクション・オブジェクト：力とforceCoeffs ===
力とforceCoeffs関数オブジェクトは、実行時間を短縮するために最適化されました。
テストによると、以前は複数の力とforceCoeffs関数オブジェクトを使用すると、主に速度勾配の計算とさまざまな内部フィールドに対して実行される冗長な計算が原因で、総実行時間が2～10％の範囲でスローダウンしていた。

例えば、simpleCarチュートリアルのテストでは、速度勾配をキャッシュすることで補完した場合、力関数オブジェクトの実行時間が約3分の1に短縮されることが実証された。

Source code

* $FOAM_SRC/functionObjects/forces/forces
* $FOAM_SRC/functionObjects/forces/forceCoeffs

Merge request

* MR!598

== パラレル ==

=== parProfiling 関数オブジェクトの改良 ===
並列プロファイリング関数オブジェクト parProfiling の拡張により、プロファイリングを線形ソルバーに制限することができます。この関数オブジェクトは，controlDictで次のように指定します．
<code>functions
{
// Run parProfiling
profiling
{
libs (utilityFunctionObjects);
#includeEtc "caseDicts/profiling/parallel.cfg"
detail 2;
}
}</code>
これは、fvSolutionファイル内の新しいparProfilingラッパー・ソルバーの形をとります：
<code>solvers
{
p
{
solver parProfiling;
baseSolver PCG;
preconditioner DIC;
tolerance 1e-06;
relTol 0.05;
}
}</code>
上記の例では、PCG線形ソルバーに対してのみparProfiling関数オブジェクトを有効にしています。この拡張は、GAMGソルバー内の最も粗いレベルの線形ソルバーの効果を見るときに特に便利です。

典型的な出力だ：
<code>parProfiling:
reduce : avg = 72.7133s
min = 2.37s (processor 0)
max = 88.29s (processor 4)
all-all : avg = 14.9633s
min = 11.04s (processor 5)
max = 17.18s (processor 4)</code>
例えば、20台のプロセッサーを使ったキャビティ・リッド・ドライブ・チュートリアルのように、異なる線形ソルバーの効果を調べるには、両方を組み合わせることが非常に有効です：

PCG の parProfiling 出力：
<code>reduce : ..
..
counts 20(14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875)</code>
FPCG の parProfiling 出力：
<code>reduce : ..
..
counts 20(11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914)</code>
Source code

* $FOAM_SRC/functionObjects/utilities/parProfiling/parProfilingSolver.H

Tutorial

* $FOAM_TUTORIALS/IO/cavity_parProfiling

Merge request

* MR!603

=== スコッチ - マルチレベル分解をサポート ===
multiLevel分解法は、ノード内（より高速な通信を使用）よりもノード間カット（低速な通信を使用）の量を優先的に制限するために使用することができる。この機能は、重みのセットを指定することで、スコッチ（ptscotchではない）分解法にネイティブに存在するようになった：
<code>method scotch;
numberOfSubdomains 2048;
coeffs
{
// Divide into 64 nodes, each of 32 cores
domains (64 32);
// Inside a nodes the communication weight is 1% of that inbetween nodes
domainWeights (1 0.01);
}</code>
あるいは、そのレベルの重みを1として、第1レベルの分解を省略することもできる：
<code>method scotch;
numberOfSubdomains 2048;
coeffs
{
// Divide into 2048/32=64 nodes
domains (32);
// Inside a node the communication weight is 1% of that inbetween nodes
domainWeights (0.01);
} </code>
下の画像は、20x20の単純なメッシュを32分割したものである：

マルチレベル・メソッドと比較すると、次のようになる。

* multiLevelサブセットは、各第1レベルの分解を第2レベルに分解する。セル数が多くなると、これがボトルネックになる。
* multiLevelメソッドで時々起こるような、過剰な数のプロセッサ・パッチを作成することを避けることができる。

残念なことに、この機能は外部のptscotchライブラリには実装されていない。いったん利用できるようになれば、ptscotch分解メソッドに追加するのは簡単だ。

Source code

* $FOAM_SRC/parallel/decompose/scotchDecomp/scotchDecomp.C

Merge request

* MR!599

=== ノンブロッキング線形ソルバー ===
並列で実行する場合、線形ソルバーは、受信したデータを使用して境界条件（'インターフェース'）を更新する前に、すべての通信が終了するのを待ちます。このため、通信の1つが他の通信より遅い場合、ボトルネックになることがあります。例えば、接続が遅い、インターフェイスの面が多いなどです。
これを避けるために、インターフェイスのポーリングを有効にし、インターフェイスが「ready」になったときにインターフェイスの更新を実行するnPollProcInterfaces最適化スイッチが導入された。このスイッチは、一定の反復回数（その後にブロッキング待ちが続く）か、ポーリングのみの場合は「-1」（新機能）である：

etc/controlDictまたはローカルシステム/controlDictで、nPollProcInterfacesを-1に設定する：
<code>OptimisationSwitches
{
// Fixed or infinite (-1) number of polling iterations
nPollProcInterfaces -1;
}</code>
一般論として：

* 十分なローカルワークがある場合、つまりプロセッサインターフェースの解を追加する場合、通信とオーバーラップさせることに意味がある場合に使用する。GAMGの最も粗いレベルでは、これは当てはまらない。
* プロセッサ・インターフェースの最小サイズと最大サイズ、つまり面の数に大きな差がある場合に使用する。これは、幾何学的分解法などではあり得るが、スコッチなどの位相分解法では一般的ではない。

大きな欠点は、解の追加順序が非決定的になり、例えば、pitzDaily非圧縮チュートリアルを（悪い）ソルバーの組み合わせで実行すると、切り捨て誤差に影響することです：
<code>p
{
solver PCG;
preconditioner diagonal;

tolerance 1e-06;
relTol 0.1;
}</code>
は、100回の繰り返しで顕著な解の違いを生み出す：

* ポーリングなし:

<code>diagonalPCG: Solving for p, Initial residual = 0.012452, Final residual = 0.0012432, No Iterations 162</code>

* ポーリング:

<code>diagonalPCG: Solving for p, Initial residual = 0.012544, Final residual = 0.0012536, No Iterations 301</code>

=== マスターコースター凝集の改善 ===
多くのコアでGAMGを実行する場合、PCGなどの最も粗いレベルのソルバーがスケーリングのボトルネックになる可能性があります。これを回避する1つの方法は、粗いレベルの行列をより少ない、あるいは1つのプロセッサに集約することです。これは、プロセッサの行列を集めて、プロセッサ間の境界をすべて内部の面に置き換えた、単一の大きな行列を作成するものです。これにより、通信は回避されるが、この凝集行列を解くプロセッサの計算コストが増加する。例えば、元の凝集が10000個のプロセッサで1セルまでだった場合、凝集した行列は少なくとも10000個のセルを持つことになり、これを解くことがボトルネックになる可能性がある。
この開発では、masterCoarsestプロセッサーのアグロメレーションは、ローカルアグロメレーションを再スタートして、10000セルをより少ないセルに戻すことができる。この新しい動作はfvSolutionの新しいパラメータnCellsInMasterLevelによってトリガーされる。
<code>p
{
solver GAMG;
..
smoother GaussSeidel;

//- Local agglomeration parameters
nCellsInCoarsestLevel 1;

//- Processor-agglomeration parameters
processorAgglomerator masterCoarsest;
//- Optionally agglomerate after processor-agglomeration
nCellsInMasterLevel 1;
}</code>

==== 結果 ====
単純なテストケースとして、pitzDailyチュートリアルを15プロセッサで並列実行するように修正しました（分解方法としてscotchを使用）。masterCoarsestを使用し、凝集の再起動を行わない場合、最初の反復は次のようになります。

<code>DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0788583, No Iterations 6
DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0150588, No Iterations 6
..
DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0105486, No Iterations 6
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0759038, No Iterations 24</code>
nCellsInMasterLevel 1：

<code>DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0, No Iterations 1
DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 1.11661e-16, No Iterations 1
..
DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0, No Iterations 1
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0799836, No Iterations 24</code>
Source code

* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGProcAgglomerations/masterCoarsestGAMGProcAgglomeration/masterCoarsestGAMGProcAgglomeration.H

Merge request

* MR!600

=== 並列（MPI）処理の全般的な変更 ===
最近のexaFOAMの活動から得られた知見により、OpenFOAMのPstreamライブラリ（MPIインターフェース）の低レベルの改良と、コードベース全体の通信ボトルネックを低減するためのアルゴリズムとコードの変更が多数行われました。しかし、これらの変更のほとんどは、大規模シミュレーションにおいてのみ効果が現れます。アルゴリズムの変更の一部は*プレビュー*の変更とみなされるため、デフォルトでは有効ではなく、設定スイッチによって有効になります。
コード開発者向けに、MPIリクエストとコミュニケータの取り扱いが拡張され、独自の並列アルゴリズムを書く際に、より柔軟に対応できるようになりました。ノンブロッキングコンセンサス交換(NBX)を使ったサイズ交換の取り扱いが、全対全交換のドロップイン置き換えとして提供されます。

== ユーザビリティ ==

=== 新しい文書システム ===
以前の拡張コードガイドはDoxygenベースのシステムからnanocベースのシステム（Gitlab.comで使われているのと同じシステム）に移行され、コミュニティ貢献のために公開されました。新しいコンテンツはhttps://doc.openfoam.com：

* v2306: <nowiki>https://doc.openfoam.com/2306/</nowiki>
* v2212: <nowiki>https://doc.openfoam.com/2212/</nowiki> (old release)

このサイトは新しいルック＆フィールで、クイックスタート、多くの新しい境界条件、熱物理モデル、ノイズを含むツールなど、大幅なコンテンツ更新が行われた！

コンテンツはhttps://gitlab.com/openfoam/documentation。継続的に進化しており、さらなるアップデートが予定されている。

プルリクエストも喜んでお受けします！
=== 表現の変更 ===
式の評価関数にnormal()が追加されました。これはメッシュ面の単位法線を返すもので、face()/area()より少ない操作でよりロバストなものとなります。

OpenFOAM v2306リリースノート

2023-09-09T09:06:53Z

Mmer547: /* Upgrading */

OpenCFD is pleased to announce the June 2023 release of OpenFOAM® v2306. This release extends OpenFOAM-v2212 features across many areas of the code. The new functionality represents development sponsored by OpenCFD's customers, internally funded developments, and integration of features and changes from the OpenFOAM community.

OpenFOAM is distributed by OpenCFD under the GPL License. In addition to source code packages suitable for compilation on a variety of Linux and other POSIX systems, this release also has a number of pre-compiled binary packages

* Ubuntu Linux: packaged installation for Ubuntu 22.04 (LTS), 20.04 (LTS), 18.04 (LTS), 23.04, 22.10
* openSUSE Linux: packaged installation for Leap15.5
* Redhat Linux variants: packaged installation for epel-9; Fedora 37

Windows users have three options for pre-compiled packages (more information):

* Using Windows Subsystem for Linux (based on Ubuntu, openSUSE etc.)
* Native executables with cross-compiled
* A docker installation

OpenFOAM apptainer support is provided via description files rather than pre-assembled images

* See packaging/containers

Mac OSX users have the option to compile from source, or use Docker containers for pre-compiled packages (more information).

OpenCFDは、OpenFOAM® v2306の2023年6月リリースを発表します。このリリースは、コードの多くの領域にわたってOpenFOAM-v2212の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージも多数あります。

* Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール
* openSUSE Linux: Leap15.5用パッケージインストール
* Redhat Linux: epel-9 用パッケージ・インストール; Fedora 37

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢があります（詳細）：

* Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。
* クロスコンパイルされたネイティブ実行ファイル
* docker インストール

OpenFOAMのapptainerサポートは、事前にアセンブルされたイメージではなく、記述ファイルによって提供されます。

* パッケージング/コンテナ参照

Mac OSXユーザーは、ソースからコンパイルするか、Dockerコンテナを使ってコンパイル済みのパッケージを使用するオプションがあります（詳細）。

== アップグレード ==

=== 省略と削除 ===

==== 境界条件 ====
exprFixed境界条件とexprMixed境界条件に、ランタイム非推奨の警告が表示されるようになりました。同じ機能（およびそれ以上）は、それぞれuniformFixedValue境界条件とuniformMixed境界条件で利用できます。

=== 名前変更 ===

=== ファンクションオブジェクト：patchPostProcessingとpatchParticleHistogram ===
ラグランジュ関数オブジェクトpatchPostProcessingとpatchParticleHistogramは、わかりやすさと理解を深めるために、それぞれparticlePostProcessingとparticleHistogramに名称が変更されました。

=== 入力辞書 ===
不必要な丸め誤差や精度低下を避けるため、#calcと#evalの固定フォーマットと精度制限が削除された。式が評価される際の文字列展開がより一貫したものになるはずです。

==== 表現 ====

* パッチ式で、face()/area()と書く代わりに、normal()を使って単位法線を求めることができるようになりました。

==== 関数オブジェクト: electricPotential ====
電場（E）の計算と出力は、以前のキーワード writeDerivedFields に代わって、オプションのキーワード electricField を使用することで有効または無効にすることができます。また、電場（E）の名前は、新しいキーワード E で指定できるようになりました。

==== 関数オブジェクト: yPlus, wallShearStress ====
yPlusとwallShearStressの両方で、オプションのwriteFieldsフラグが追加され、ボリュームフィールドの出力を無効にできるようになりました。これは、ログに記録された情報のみに関心がある場合に、ディスク容量を節約し、速度を向上させるのに便利です。

=== パラレル ===

==== FOAM_IORANKSの柔軟な取り扱い ====

* は、従来のOpenFOAMのリストと同様に、プレーンなリスト(スペースまたはカンマ区切り)も受け付けます。これにより、ジョブスクリプトでの引数の取り扱いが簡単になります。例えば
<syntaxhighlight lang="bash">
simpleFoam -ioRanks 0,4,8 ...

</syntaxhighlight>対<syntaxhighlight lang="bash">
simpleFoam -ioRanks '(0 4 8)' ...

</syntaxhighlight>ホストごとにIOランクを選択することも可能である：<syntaxhighlight lang="bash">
simpleFoam -ioRanks host ...
</syntaxhighlight>

==== MPIスレッドのコマンドライン指定 ====

* MPI_THREAD_MULTIPLE を持つことは、通常、パフォーマンス上好ましくないが、リンクされたライブラリがMPI_THREAD_MULTIPLE を期待する場合には必要な場合もある。mpi-threads コマンドラインオプションを使用すると、MPI_THREAD_MULTIPLE を明示的に指定することができます。

==== parProfilingの詳細 ====
parProfilingは、より詳細な情報を得るために、異なるMPIオペレーションをより分離するようになった：

* ブロードキャスト・タイムとリデュース／ギャザー／スキャッター・タイムを分離
* 一般的な待ち時間とすべての待ち時間の比較
* リクエストの時間/カウントを他のカウントと分離して、呼び出しカウントをサポートする（他のカウントがマスクされないようにするため）。

=== 有限面積の改善 ===
最小エッジ長のチェックがより一貫性を持ち、小さなエッジの存在下でもロバスターとなった。2次元テンソルの逆変換の取り扱いが改善され，有限面積における最小二乗法がロバスターになった．

=== メッシュ生成 ===

==== makeFaMesh ====
スター "接続の中心や、パッチ面が実際にはバッフルであるために発生する、多重接続された有限面積のエッジを処理するためのヒューリスティックが追加された。

直列の場合、これらの内部エッジはモデル化という点ではかなり疑わしいが、プロセッサーのドメインにまたがって分割されると、かなりの問題を引き起こす。接続性を一意に決定するのに十分な情報があるとは限らないが、エッジを結合するための何らかの救済措置はしばしば可能である。余分な "ぶら下がった "エッジは無視パッチに追いやられ、別々に扱われるようになります。

これらのヒューリスティックは、遭遇したいくつかの問題を解決するものではあるが、さらなる研究が必要である。

=== メッシュチェック／後処理 ===

==== checkMesh ====

* checkMeshとmakeFaMeshにグローバルトポロジーチェックを追加し、境界パッチがエッジ間で多重接続されている場合にそれを検出するようにした。
* checkMeshの新しい-write-edgesオプション：トポロジー的に問題のあるエッジをディスクに書き出すことができます。この新機能は有用な診断補助となります（特に、不正なエッジがあっても壊れにくい有限面積メッシュの場合）。

==== foamToVTK ====
foamToVTKを-no-internalおよび-no-boundaryオプションで実行すると、フィールドの読み込みと報告がすべて抑制され、速度が大幅に向上する。

フィールドを用いた通常の変換では、ロードされたボリュームフィールドは点補間で再利用するために一時的にキャッシュされる。これにより、入力IOが削減され、実行時間が改善される。

== 前処理 ==

=== snappyHexMesh：過剰なバランシングの回避 ===
snappyHexMeshはセルを並列に精錬する際に自動的にメッシュのバランスを取ります。snappyHexMeshDict入力ファイルのcastellatedMeshControlsセクションの新しいコントロールはこの処理を調整するために使用することができます：

* maxCellUnbalance : [オプション] 絶対的なアンバランス開始トリガー。セル数が少ない場合に、最初の洗練反復でバランシングを回避するために使用される。トリガー値はバランシングをスキップするために使用される：
** どのプロセッサでも、新しく追加されたセルの数 <= maxCellUnbalance の場合
** いずれかのプロセッサの場合：（プロセッサの新しいセル数 - 理想的なセル数） <= maxCellUnbalance
* balanceAtEnd : [オプション] maxCellUnbalanceエントリーがメッシュのアンバランスを引き起こす可能性があるため、メッシュが完全にリファインされた後に強制的にバランシングを行う。
* (existing) maxLoadUnbalance : ある程度のアンバランスを許容する。

これらの追加制御を用いることで、コア数が多い場合、キャステレーション段階で大幅なスピードアップが実現した。なお、スナッピングとレイヤー追加フェーズは影響を受けない。

Source code

* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver

Merge request

* MR!607

=== checkMeshの改良 ===
checkMeshは自動的にプロセッサ・パッチのレポートをフィルタリングしますが、そのプロパティは有用です。このリリースでは、プロセッサ・パッチのフィルタリングは並列実行のみに制限されています。
例として、シリアルで走る：
<code>checkMesh -case processor0 -allTopology -allGeometry</code>
報告：
<code>Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology Bounding box
front 2275 2399 ok (non-closed singly connected) (-0.572 -1 0.007621454194) (-0.17456 1 0.02497405934)
..
procBoundary0to1 101 204 ok (non-closed singly connected) (-0.19184 -1 -0.008375915288) (-0.17456 1 0.008375915288)
".*" 4796 4798 ok (closed singly connected) (-0.572 -1 -0.02497405934) (-0.17456 1 0.02497405934)</code>
個々のプロセッサ境界のレポートに注意してください。これは、全体の境界面のエントリ（".*"）にも含まれます。並列実行の場合、v2212と同様に、プロセッサパッチはリストと全体の境界面から除外されます。

Source code

* $FOAM_UTILITIES/mesh/manipulation/checkMesh

Issue tracker

* !698

== 数値 ==

=== finiteAreaの新しいキャッシュグラデーションメカニズム ===
もともと有限体積フレームワークで利用可能だった）勾配キャッシング・メカニズムが、有限面積フレームワークにも適用された。
有効にすると、従属フィールドが変更されたときにのみ勾配フィールドが計算され、後で再利用できるようにメッシュデータベースのメモリに保存されるため、追加コストのかかる再評価を省くことができます。

system/faSolutionファイルでの使用例を以下に示す：
<code>cache
{
grad(h);
grad(Us);
}</code>
Source code

* $FOAM_SRC/finiteArea/finiteArea/gradSchemes/faGradScheme/faGradScheme.H

Merge request

* MR!611

=== 新しい並列プリコンディショナ ===
新しいプリコンディショナdistributedDILU, distributedDICは、DILU, DICプリコンディショナにRed-Black型の並列動作のバリエーションを追加したものである。これらの新しいプリコンディショナは、GAMGソルバーの最も粗いレベルを解くのに特に有用である：
<code>p
{
solver GAMG;
// Explicit specify solver for coarse-level correction to override
// preconditioner
coarsestLevelCorr
{
solver PCG;
preconditioner distributedDIC;
}
} </code>
コア数が非常に大きい場合、スケーリングのボトルネックは、最も粗いレベルの解における大域的な削減となる可能性があり、分散プリコンディショナーは、（追加のハロースワップを犠牲にして）掃引量と削減量を減らすことができる。4096コアの大規模な場合：

この性能上の利点は、タイミングに表れている：
{| class="wikitable"
!preconditioner
!Execution time
|-
|DIC
|8687s
|-
|distributedDIC
|6326s
|}
分散型プリコンディショナの使用は、一般に、計算が大域的なリダクションに束縛される場合にのみ意味を持つことに注意してください。非分散型と比較すると、ハロースイープを追加する代償として、CGスイープ回数（および削減回数）を減らすことができます。少ないコア数では、これは有益ではないかもしれない。CG掃引の回数がとにかく少ない場合、例えば相対公差で解く場合も同様です。

同じ戦略は、他の結合境界条件、例えばサイクリック、サイクリックAMIにも適用できる。前方ループでは、'owner'パッチに対する'neighbor'の効果が含まれ、後方ループではその逆の効果が含まれます。これはcoupledスイッチで切り替えます（デフォルトはon）：
<code>solver PCG;
preconditioner distributedDIC;
coupled false; // do not precondition across non-processor coupled</code>
cyclicAMIの場合、2つのサイドが異なるプロセッサー上に排他的に存在するか、まったく分散されていない必要があるという制限がある。

新しいプリコンディショナーは構築するのにかなりコストがかかるため、線形ソルバー内部にキャッシュされる。これは、GAMG内部の最も粗いレベルの補正ソルバーにのみ影響する。

Source code

* $FOAM_SRC/meshTools/matrices/lduMatrix/preconditioners/distributedDILUPreconditioner/distributedDILUPreconditioner.H
* $FOAM_SRC/meshTools/matrices/lduMatrix/preconditioners/distributedDILUPreconditioner/distributedDICPreconditioner.H

References

* Yousef Saad, Iterative Methods for Sparse Linear Systems (2nd edition)

Merge request

* MR!608

=== 新しいFPCG線形ソルバー ===
PCG線形ソルバーの新しいドロップイン代替であるFPCGは、1掃引あたりの削減回数を3回から2回に削減します。これにより、特にGAMG線形ソルバーで最も粗いレベルを解くときに、並列削減がボトルネックになる可能性のあるコア数が大きい場合に、並列スケーリングが改善されるはずです。
このソルバーは、リダクションの数と追加ストレージ/パイプライン量のトレードオフを提供します。これは、ハロースワップとリダクションをオーバーラップさせるPPCGソルバーと比較することができます（しかし、追加のストレージが必要です）。

FPCGは、1つの余分なプリコンディショニングステップを必要とするため、より複雑なプリコンディショナー（例えばGAMG）にとってはあまり有益でない可能性があることに注意されたい。

Attribution

* OpenCFD would like to acknowledge and thank Alon Zameret of Toga Networks for providing the code and elaborate discussions.

Source code

* $FOAM_SRC/matrices/lduMatrix/solvers/FPCG/FPCG.C

Merge request

* MR!601

=== テンソル反転の処理の改善 ===
テンソルの逆変換は、例えば最小二乗法計算に必要であり、テンソルの値が面内、例えば本質的に2Dである場合には特に厄介です。このような場合は、「安全な」逆変換アプローチによって処理されるようになり、擬似逆変換のようなコストのかかるオーバーヘッドなしにロバスト性が追加されます。この変更は、主にいくつかの有限面積スキームのロバスト性に影響します。

=== メッシュセル/ポイント計算の改善（高速化） ===
セルからポイント、またはポイントからセルへのアドレッシングの情報は、異なるアルゴリズムに必要とされる。このタイプのアドレッシングは計算するのに比較的コストがかかるので、可能な限りキャッシュされ、不足するアドレッシングを導き出すために再利用される。
これは通常1回限りのコストであるが、キャッシュされた値を無効にするようなトポロジーの変更を伴うメッシュでは、より大きな要因になる可能性がある。アドレッシングを再構築するための更新されたアプローチは、速度を1.4倍から2.4倍に向上させる。

Attribution

* OpenCFD would like to acknowledge and thank Toga Networks for providing the code and elaborate discussions.
* issue 2715
* MR!596

== ソルバーと物理モデル ==

=== 改良されたvanDriest LESデルタモデル ===
vanDriest LESデルタモデルでは、最も近い壁の特性（y*）が局所的な長さスケールを計算するために使用されます。以前のリリースでは、これらの壁のプロパティは、壁の距離（meshWave）を計算するために同じメカニズムを使用して輸送されていました。このリリースでは、アドレッシングは一度計算され、最も近い壁の情報を直接取得できるようにキャッシュされます。これにより、（余分なストレージを必要としますが）大きなメッシュで非常に大きなスピードアップが得られます。さらに、同じアドレッシングは、fvSchemesの新しいmeshWaveAddressing wallDistメソッドを使用して、壁の距離自体にも使用できます：
<code>wallDist
{
method meshWaveAddressing;

// Fetch the nearest wall normal
nRequired true;

// Optional entry delaying wall distance update to every n steps
// Default is 1 (update every step)
updateInterval 5;
} </code>
次の画像は、ExaFoamプロジェクトの一環として実証された、これらの改善による強力なスケーリング性能を示している：

Source code

* $FOAM_SRC/TurbulenceModels/turbulenceModels/LES/LESdeltas/vanDriestDelta

Resolved bugs

* !2648

=== 新しいラグランジュ粒子力クーロン ===
新しいクーロン有限体積オプション(fvOption)は、電場を評価するためのelectricPotential関数オブジェクトの本質的な基礎的な変更とともに、直径に基づいて粒子に作用する静電気力のモデルを提供します。カップリングは現在一方通行です。
最低限の使用例を以下に示す：
<code>subModels
{
solution
{
interpolationSchemes
{
<Ename> <interpolationScheme>; // Electric field name
}
}

particleForces
{
Coulomb
{
q <Function1<scalar>>; // Electric charge of particles
E <word>; // Electric field
}
}
}</code>
Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/ParticleForces/Coulomb

Merge request

* MR!602

=== 新しいfvOption：fanMomentumSource ===
新しいfanMomentumSource有限体積オプション（fvOption）は、流れに対するファンの作用を表現する運動量ソースを追加します。
まず、セルゾーンを囲む上流側の面を通過する流量が計算される。上流側の面は流れ方向と周囲の面ゾーンを用いて自動的に決定される。続いて、流量の関数としてのファン圧力曲線とファン（測定部）の厚さから圧力勾配を求める。

最小限の使用例は以下の通り：
<code>fan
{
// Mandatory entries
type fanMomentumSource;
fanCurve <Function1<scalar>>;
flowDir <vector>;
thickness <scalar>;
cellZone <word>;
faceZone <word>;

// Optional entries
gradient <scalar>;
rho <scalar>;
U <word>;

// Inherited entries
selectionMode <word>;
...
}</code>

Source code

* $FOAM_SRC/fvOptions/sources/derived/fanMomentumSource

Merge request

* MR!604

Attribution

* OpenCFD would like to acknowledge and thank Vuko Vukcevic of SimScale GmbH for providing the code and elaborate discussions.

=== 新しい fvOption: limitTurbulenceViscosity。 ===
新しいlimitTurbulenceViscosity有限体積オプション(fvOption)は、計算の安定性を高める乱流粘度nutを制限するメカニズムを提供します。
乱流粘性場は、層流粘性に係数を乗じた上限値を適用することで、指定された領域内で補正される：

最小限の使用例は以下の通り：
<code>limitTurbulenceViscosity1
{
// Mandatory entries
type limitTurbulenceViscosity;

// Optional entries
nut nut;
c 1e5;

// Inherited entries
...
}</code>
Source code

* $FOAM_SRC/fvOptions/corrections/limitTurbulenceViscosity

=== 改良された剛体運動拘束：軸 ===
軸拘束は、ボディが固定軸の周りにしか回転できないような方向制限を課します。これは、例えばバタフライバルブをモデル化するために、最小回転角度と最大回転角度を追加することで強化されました。
さらに、すべての剛体運動制約がランタイムで調整可能になった。

最小限の使用例は以下の通り：

<code>constraints
{
constrainRotation1
{
sixDoFRigidBodyMotionConstraint axis;
axis <vector>;

// Optional entries
maxClockwiseTheta <Function1<scalar>>;
maxCounterclockwiseTheta <Function1<scalar>>;
thetaUnits <word>;
referenceOrientation <tensor>;
}
}</code>
Source code

* $FOAM_SRC/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/constraints/axis

Merge request

* MR!613

== 境界条件 ==

==== 新しい境界条件：鏡面放射 ====
fvDOM放射モデルは、新しいspecularRadiation境界条件を使用して、軸対称および対称面セットアップに適用できるようになりました。
この境界条件の最小限の例を以下に示す：
<code>{
// Mandatory entries
type specularRadiation;

// Optional entries
interpolate <bool>;

// Inherited entries
patchType <word>;
...
} </code>
下図は、4つの異なる形状の内部無次元入射放射の観点から条件を検証したものである：

Source code

* $FOAM_SRC/thermophysicalModels/radiation/derivedFvPatchFields/specularRadiation

References

* Standard model:
** Kumar, P., & Eswaran, V. (2013). A methodology to solve 2D and axisymmetric radiative transfer problems using a general 3D solver. Journal of heat transfer, 135(12). DOI:10.1115/1.4024674

Merge request

* MR!610

Attribution

* OpenCFD would like to acknowledge and thank Hitachi Energy for sponsoring the development, and Bernardo Galletti and Marcelo Buffoni for elaborate discussions.

=== 新ユニフォーム混合コンディション ===
新しいuniformMixed境界条件は、既存のuniformFixedValue境界条件とuniformFixedGradient境界条件を補完するものです。
この条件は混合境界条件を定義するために使用され、値を定義するために関数を使用する。
<code>{
type uniformMixed;
uniformValue constant 0.2;
uniformGradient constant 0.2;
uniformValueFraction
{
type sine;
...
}
}</code>
しかし、境界条件は遅延定義を許可しているため、uniformValueまたはuniformGradientの一方だけを定義し、他のエントリーを暗黙的に定義することも可能である。

uniformMixedで使用される関数には式も含まれるため、この新しい境界条件は、将来非推奨となり削除される既存のexprMixed境界条件のより柔軟な形として使用することができる。

Source code

* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformMixed

Tutorial

* $FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/TJunctionAverage/0/U

=== 新しい有限領域境界条件 ===
有限面積計算でuniformFixedValue、uniformFixedGradient、uniformMixed境界条件が使用できるようになりました。
これらの境界条件はFinite Areaに関数と式のサポートを追加します。timeVaryingUniformFixedValue境界条件は非推奨となり、将来削除される予定です。

Source code

* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformFixedValue
* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformFixedGradient
* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformMixed

== 後処理 ==

=== ラグランジュ関数オブジェクトの改良 ===
ラグランジアン・クラウド・ファンクション・オブジェクトは複数のアップデートを受けた：

* patchPostProcessingとpatchParticleHistogramは、それぞれの機能をよりよく反映させるために、それぞれparticlePostProcessingとparticleHistogramという名前に変更されました；
* writeFileサポートが追加され、ファイル出力の制御が改善された。
* faceZoneのサポートが追加され、パーティクル収集のコントロールが向上しました。

最低限の使用例を以下に示す：

<code>ParticlePostProcessing1
{
// Mandatory entries
type particlePostProcessing;
maxStoredParcels <scalar>;

// Optional entries
fields (<wordRes>);

// Conditional entries

// Option-1
patches (<wordRes>);

// Option-2
faceZones (<wordRes>);

// Inherited entries
// writeFile entries
...
}

particleHistogram1
{
// Mandatory entries
type particleHistogram;
nBins <label>;
min <scalar>;
max <scalar>;
maxStoredParcels <scalar>;

// Conditional entries

// Option-1
patches (<wordRes>);

// Option-2
faceZones (<wordRes>);

// Inherited entries
// writeFile entries
...
}</code>
Source code

* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticleHistogram
* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticlePostProcessing

Merge request

* MR!595

=== 改良されたファンクション・オブジェクト：力とforceCoeffs ===
力とforceCoeffs関数オブジェクトは、実行時間を短縮するために最適化されました。
テストによると、以前は複数の力とforceCoeffs関数オブジェクトを使用すると、主に速度勾配の計算とさまざまな内部フィールドに対して実行される冗長な計算が原因で、総実行時間が2～10％の範囲でスローダウンしていた。

例えば、simpleCarチュートリアルのテストでは、速度勾配をキャッシュすることで補完した場合、力関数オブジェクトの実行時間が約3分の1に短縮されることが実証された。

Source code

* $FOAM_SRC/functionObjects/forces/forces
* $FOAM_SRC/functionObjects/forces/forceCoeffs

Merge request

* MR!598

== パラレル ==

=== parProfiling 関数オブジェクトの改良 ===
並列プロファイリング関数オブジェクト parProfiling の拡張により、プロファイリングを線形ソルバーに制限することができます。この関数オブジェクトは，controlDictで次のように指定します．
<code>functions
{
// Run parProfiling
profiling
{
libs (utilityFunctionObjects);
#includeEtc "caseDicts/profiling/parallel.cfg"
detail 2;
}
}</code>
これは、fvSolutionファイル内の新しいparProfilingラッパー・ソルバーの形をとります：
<code>solvers
{
p
{
solver parProfiling;
baseSolver PCG;
preconditioner DIC;
tolerance 1e-06;
relTol 0.05;
}
}</code>
上記の例では、PCG線形ソルバーに対してのみparProfiling関数オブジェクトを有効にしています。この拡張は、GAMGソルバー内の最も粗いレベルの線形ソルバーの効果を見るときに特に便利です。

典型的な出力だ：
<code>parProfiling:
reduce : avg = 72.7133s
min = 2.37s (processor 0)
max = 88.29s (processor 4)
all-all : avg = 14.9633s
min = 11.04s (processor 5)
max = 17.18s (processor 4)</code>
例えば、20台のプロセッサーを使ったキャビティ・リッド・ドライブ・チュートリアルのように、異なる線形ソルバーの効果を調べるには、両方を組み合わせることが非常に有効です：

PCG の parProfiling 出力：
<code>reduce : ..
..
counts 20(14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875)</code>
FPCG の parProfiling 出力：
<code>reduce : ..
..
counts 20(11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914)</code>
Source code

* $FOAM_SRC/functionObjects/utilities/parProfiling/parProfilingSolver.H

Tutorial

* $FOAM_TUTORIALS/IO/cavity_parProfiling

Merge request

* MR!603

=== スコッチ - マルチレベル分解をサポート ===
multiLevel分解法は、ノード内（より高速な通信を使用）よりもノード間カット（低速な通信を使用）の量を優先的に制限するために使用することができる。この機能は、重みのセットを指定することで、スコッチ（ptscotchではない）分解法にネイティブに存在するようになった：
<code>method scotch;
numberOfSubdomains 2048;
coeffs
{
// Divide into 64 nodes, each of 32 cores
domains (64 32);
// Inside a nodes the communication weight is 1% of that inbetween nodes
domainWeights (1 0.01);
}</code>
あるいは、そのレベルの重みを1として、第1レベルの分解を省略することもできる：
<code>method scotch;
numberOfSubdomains 2048;
coeffs
{
// Divide into 2048/32=64 nodes
domains (32);
// Inside a node the communication weight is 1% of that inbetween nodes
domainWeights (0.01);
} </code>
下の画像は、20x20の単純なメッシュを32分割したものである：

マルチレベル・メソッドと比較すると、次のようになる。

* multiLevelサブセットは、各第1レベルの分解を第2レベルに分解する。セル数が多くなると、これがボトルネックになる。
* multiLevelメソッドで時々起こるような、過剰な数のプロセッサ・パッチを作成することを避けることができる。

残念なことに、この機能は外部のptscotchライブラリには実装されていない。いったん利用できるようになれば、ptscotch分解メソッドに追加するのは簡単だ。

Source code

* $FOAM_SRC/parallel/decompose/scotchDecomp/scotchDecomp.C

Merge request

* MR!599

=== ノンブロッキング線形ソルバー ===
並列で実行する場合、線形ソルバーは、受信したデータを使用して境界条件（'インターフェース'）を更新する前に、すべての通信が終了するのを待ちます。このため、通信の1つが他の通信より遅い場合、ボトルネックになることがあります。例えば、接続が遅い、インターフェイスの面が多いなどです。
これを避けるために、インターフェイスのポーリングを有効にし、インターフェイスが「ready」になったときにインターフェイスの更新を実行するnPollProcInterfaces最適化スイッチが導入された。このスイッチは、一定の反復回数（その後にブロッキング待ちが続く）か、ポーリングのみの場合は「-1」（新機能）である：

etc/controlDictまたはローカルシステム/controlDictで、nPollProcInterfacesを-1に設定する：
<code>OptimisationSwitches
{
// Fixed or infinite (-1) number of polling iterations
nPollProcInterfaces -1;
}</code>
一般論として：

* 十分なローカルワークがある場合、つまりプロセッサインターフェースの解を追加する場合、通信とオーバーラップさせることに意味がある場合に使用する。GAMGの最も粗いレベルでは、これは当てはまらない。
* プロセッサ・インターフェースの最小サイズと最大サイズ、つまり面の数に大きな差がある場合に使用する。これは、幾何学的分解法などではあり得るが、スコッチなどの位相分解法では一般的ではない。

大きな欠点は、解の追加順序が非決定的になり、例えば、pitzDaily非圧縮チュートリアルを（悪い）ソルバーの組み合わせで実行すると、切り捨て誤差に影響することです：
<code>p
{
solver PCG;
preconditioner diagonal;

tolerance 1e-06;
relTol 0.1;
}</code>
は、100回の繰り返しで顕著な解の違いを生み出す：

* ポーリングなし:

<code>diagonalPCG: Solving for p, Initial residual = 0.012452, Final residual = 0.0012432, No Iterations 162</code>

* ポーリング:

<code>diagonalPCG: Solving for p, Initial residual = 0.012544, Final residual = 0.0012536, No Iterations 301</code>

=== マスターコースター凝集の改善 ===
多くのコアでGAMGを実行する場合、PCGなどの最も粗いレベルのソルバーがスケーリングのボトルネックになる可能性があります。これを回避する1つの方法は、粗いレベルの行列をより少ない、あるいは1つのプロセッサに集約することです。これは、プロセッサの行列を集めて、プロセッサ間の境界をすべて内部の面に置き換えた、単一の大きな行列を作成するものです。これにより、通信は回避されるが、この凝集行列を解くプロセッサの計算コストが増加する。例えば、元の凝集が10000個のプロセッサで1セルまでだった場合、凝集した行列は少なくとも10000個のセルを持つことになり、これを解くことがボトルネックになる可能性がある。
この開発では、masterCoarsestプロセッサーのアグロメレーションは、ローカルアグロメレーションを再スタートして、10000セルをより少ないセルに戻すことができる。この新しい動作はfvSolutionの新しいパラメータnCellsInMasterLevelによってトリガーされる。
<code>p
{
solver GAMG;
..
smoother GaussSeidel;

//- Local agglomeration parameters
nCellsInCoarsestLevel 1;

//- Processor-agglomeration parameters
processorAgglomerator masterCoarsest;
//- Optionally agglomerate after processor-agglomeration
nCellsInMasterLevel 1;
}</code>

==== 結果 ====
単純なテストケースとして、pitzDailyチュートリアルを15プロセッサで並列実行するように修正しました（分解方法としてscotchを使用）。masterCoarsestを使用し、凝集の再起動を行わない場合、最初の反復は次のようになります。

<code>DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0788583, No Iterations 6
DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0150588, No Iterations 6
..
DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0105486, No Iterations 6
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0759038, No Iterations 24</code>
nCellsInMasterLevel 1：

<code>DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0, No Iterations 1
DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 1.11661e-16, No Iterations 1
..
DICPCG: Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0, No Iterations 1
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0799836, No Iterations 24</code>
Source code

* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGProcAgglomerations/masterCoarsestGAMGProcAgglomeration/masterCoarsestGAMGProcAgglomeration.H

Merge request

* MR!600

=== 並列（MPI）処理の全般的な変更 ===
最近のexaFOAMの活動から得られた知見により、OpenFOAMのPstreamライブラリ（MPIインターフェース）の低レベルの改良と、コードベース全体の通信ボトルネックを低減するためのアルゴリズムとコードの変更が多数行われました。しかし、これらの変更のほとんどは、大規模シミュレーションにおいてのみ効果が現れます。アルゴリズムの変更の一部は*プレビュー*の変更とみなされるため、デフォルトでは有効ではなく、設定スイッチによって有効になります。
コード開発者向けに、MPIリクエストとコミュニケータの取り扱いが拡張され、独自の並列アルゴリズムを書く際に、より柔軟に対応できるようになりました。ノンブロッキングコンセンサス交換(NBX)を使ったサイズ交換の取り扱いが、全対全交換のドロップイン置き換えとして提供されます。

== ユーザビリティ ==

=== 新しい文書システム ===
以前の拡張コードガイドはDoxygenベースのシステムからnanocベースのシステム（Gitlab.comで使われているのと同じシステム）に移行され、コミュニティ貢献のために公開されました。新しいコンテンツはhttps://doc.openfoam.com：

* v2306: <nowiki>https://doc.openfoam.com/2306/</nowiki>
* v2212: <nowiki>https://doc.openfoam.com/2212/</nowiki> (old release)

このサイトは新しいルック＆フィールで、クイックスタート、多くの新しい境界条件、熱物理モデル、ノイズを含むツールなど、大幅なコンテンツ更新が行われた！

コンテンツはhttps://gitlab.com/openfoam/documentation。継続的に進化しており、さらなるアップデートが予定されている。

プルリクエストも喜んでお受けします！
=== 表現の変更 ===
式の評価関数にnormal()が追加されました。これはメッシュ面の単位法線を返すもので、face()/area()より少ない操作でよりロバストなものとなります。

OpenFOAM v2306リリースノート

2023-09-09T08:43:33Z

Mmer547: ページの作成:「OpenCFDは、OpenFOAM® v2306の2023年6月リリースを発表します。このリリースは、コードの多くの領域にわたってOpenFOAM-v2212の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。 OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。…」

EXUDYN

2023-08-19T07:57:16Z

Mmer547:

A flexible multibody dynamics systems simulation code with Python and C++<ref>https://github.com/jgerstmayr/EXUDYN</ref>

[https://github.com/jgerstmayr/EXUDYN EXUDYN(Github)]

PrePoMax

2023-07-29T07:20:46Z

Mmer547:

このページではオープンソース構造解析ソフト「PrePoMax」についてまとめていきます。

[https://prepomax.fs.um.si/ 公式サイト]

== インストール ==
公式のバイナリーはWindowsのみです。
公式サイトに行って「Downloads」を左クリックしてください。Zipファイルをダウンロードして解凍してください。新しくできるフォルダーは移動しても構いません。そのフォルダーの中にあるPrePoMax.exeというファイルを左ダブルクリックすると起動します。
PrePoMax.exeというファイルのショートカットをデスクトップに作ると便利だと思います。

== 公式動画チュートリアル(英語) ==
公式サイトの「Documentation」からも行けますが、ここにURLを記載します。
[https://www.youtube.com/@MatejBorovinsek Matej Borovinšek YouTube Cannnel]
[https://www.youtube.com/@feanalyst4302 FEAnalyst YouTube Channel]

== 応力解析 ==
[https://qiita.com/Jun_Tatsuno/items/f59d916b98e823341882 PrePoMaxを用いた部品を連結したAssyの応力解析]

[https://qiita.com/Sagittarius_Chiron/items/fd806361ceca4864bc79 PrePoMax使用法解説]

== 固有値解析 ==
[https://qiita.com/Jun_Tatsuno/items/f2bb87eaf3f594b52038 PrePoMaxを用いたモーダル解析]

== 日本語ドキュメント（有志） ==
[https://speakerdeck.com/juntatsuno/prepomax-v1-dot-1-1-maniyuaru PrePoMax v1.1.1 マニュアル]

== 関連書籍 ==
[https://www.amazon.co.jp/%E3%80%8CPrePoMax%E3%80%8D%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E5%AE%9F%E8%B7%B5%E6%A7%8B%E9%80%A0%E8%A7%A3%E6%9E%90-%E6%94%B9%E8%A8%82%E7%89%88-OBOOKS-%E6%9F%B4%E7%94%B0-%E8%89%AF%E4%B8%80/dp/4777522156/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=20HSEZ031ITSU&keywords=PrePoMax&qid=1680697869&s=books&sprefix=prepomax%2Cstripbooks%2C184&sr=1-1 <nowiki>「PrePoMax」ではじめる実践構造解析 [改訂版]</nowiki>]

OpenFOAM

2023-07-01T07:40:29Z

Mmer547: /* リリースノート */

このページではOpenFOAMについてまとめていきます。

== リリースノート ==

'''OpenCFD'''

[[OpenFOAM v2306リリースノート|OpenFOAM v2306 リリースノート]]

[[OpenFOAM v2212 リリースノート]]

[[OpenFOAM v2206 リリースノート]]

[[OpenFOAM v2112 リリースノート]]

[[OpenFOAM v2106 リリースノート]]

[https://www.notion.so/OF2012-3625e0d8029b40bda20fafe481dcbd95 OpenFOAM v2012 リリースノート]

[[OpenFOAM v2006 リリースノート]]

[[OpenFOAM v1912 リリースノート]]

[[OpenFOAM v1906 リリースノート]]

[[OpenFOAM v1812 リリースノート]]

[[OpenFOAM v1806 リリースノート]]

'''The OpenFOAM Foundation'''

[[OpenFOAM 9|OpenFOAM 9 リリースノート]]

[[OpenFOAM 8 リリースノート]]

[[OpenFOAM v7 リリースノート]]

[[OpenFOAM v6.0 リリースノート]]

[[OpenFOAM 4.0 リリースノート]]

[[OpenFOAM 3.0.0 リリースノート]]

[[OpenFOAM 2.4.0 リリースノート]]

==スターティングガイド==
[[OpenFOAMについて]]

[[OpenFOAMのインストール]]

[https://qiita.com/mmer547/items/e63d4cf76ea2fea659b2 チュートリアルケースの実行]

[https://qiita.com/mmer547/items/24b8491bf9776c3a27db OpenFOAMで入力できる項目の調べ方]

[https://qiita.com/mmer547/items/e4b13100e15508981a85 OpenFOAMの$FOAM変数]

==困った時は？==
[https://qiita.com/mmer547/items/7c7c257dcaf2efbc730b OpenFOAM Google Groupに投稿する際に抑えるポイント]

[https://qiita.com/mmer547/items/6b041536e2ac5dd17721 OpenFOAMで計算するネタがない時の探し方]

[[OpenFOAMのエラーメッセージの対応]]

==プリプロセス==

===形状作成===

[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%EF%BC%9A%E5%BD%A2%E7%8A%B6%E4%BD%9C%E6%88%90 形状作成ツールまとめ]

===メッシュ===
[https://scrapbox.io/opencae-kansai-memo/OpenFOAM%E3%81%AE%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A3%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 OpenFOAMのメッシャーについて]

[[メッシュ作成:blockMesh]]

[[メッシュ作成:snappyHexMesh]]

[[メッシュ作成:cfMesh]]

[https://qiita.com/mmer547/items/9fca38b8e8eadc869bb8 SalomeでOpenFOAMのメッシュを用意する方法]

===境界条件===
[[境界条件]]

==ソルバ==
[[simpleFoamについて]]

[[ExecutionTimeとClockTimeについて]]

[https://scrapbox.io/opencae-kansai-memo/SIMPLEC%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E8%A8%88%E7%AE%97%E5%AE%9F%E8%A1%8C%EF%BC%88OpenFOAM3.0.1%EF%BC%89 SIMPLECを使用した計算実行（OpenFOAM3.0.1）]

===並列計算の実行方法===

[[decomposeParDictの中身]]

===エラーメッセージ===
[[v1806のエラーメッセージ]]

==ポストプロセス==
[[ログファイルから残差ログを抽出]]

[https://qiita.com/mmer547/items/e463235ddb93f08db68a OpenFOAMのpostProcessについて]

==チュートリアルケース==
[[チュートリアルケース|チュートリアルケース一覧]]

==カスタマイズ==
[https://qiita.com/mmer547/items/2997bf8c71fe1e2423c9 OpenFOAM ソースコードの探し方]

==その他==
[https://scrapbox.io/opencae-kansai-memo/foam-extend_4.0%E3%82%92Bash_on_Ubuntu_on_Windows%E3%81%AB%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB foam-extend 4.0をBash on Ubuntu on Windowsにインストール]

[https://scrapbox.io/opencae-kansai-memo/ESI_Windows%E7%89%88OpenFOAM%E3%81%AE%E5%B0%8E%E5%85%A5 ESI Windows版OpenFOAMの導入]

[https://gitlab.com/OpenCAE/Supercomputer-OpenFOAM-Training/-/wikis/home スーパーコンピュータOpenFOAM講習会]

== 関連サービス ==
=== プリプロセス ===
[https://www.xsim.info/products/products.html XSim.Work]

== 関連書籍 ==

[https://www.amazon.co.jp/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEDEXCS-OpenFOAM%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E9%87%8E%E6%9D%91-%E6%82%A6%E6%B2%BB/dp/4621306138/ref=sr_1_5?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-5 オープンCAEのためのDEXCS for OpenFOAMハンドブック]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E7%AC%AC2%E7%89%88-%E4%B8%80%E8%88%AC%E7%A4%BE%E5%9B%A3%E6%B3%95%E4%BA%BA%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691025/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-1 OpenFOAMによる熱移動と流れの数値解析(第2版) ]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AE%E6%AD%A9%E3%81%8D%E6%96%B9-%E6%8A%80%E8%A1%93%E3%81%AE%E6%B3%89%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%EF%BC%88NextPublishing%EF%BC%89-%E5%B7%9D%E7%95%91-%E7%9C%9F%E4%B8%80/dp/4844379526/ref=sr_1_6?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-6　OpenFOAMの歩き方]

[https://www.amazon.co.jp/OpenFOAM%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%83%86%E3%83%A9%E3%83%90%E3%82%A4%E3%83%88/dp/4627691610/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-2 OpenFOAMライブラリリファレンス]

[https://www.amazon.co.jp/OpenFOAM%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-Tomislav-Mari%C2%B4c/dp/4627670915/ref=sr_1_3?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-3 OpenFOAMプログラミング]

[https://www.amazon.co.jp/OpenFOAM%E3%81%AB%E3%82%88%E3%82%8B%E7%86%B1%E7%A7%BB%E5%8B%95%E3%81%A8%E6%B5%81%E3%82%8C%E3%81%AE%E6%95%B0%E5%80%A4%E8%A7%A3%E6%9E%90-%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3CAE%E5%AD%A6%E4%BC%9A/dp/4627691017/ref=sr_1_4?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=OpenFOAM&qid=1622731659&s=books&sr=1-4 OpenFOAMによる熱移動と流れの数値解析]

OpenRadiossのインストール

2023-01-26T13:12:21Z

Mmer547:

WindowsでLinux版を使用する場合はWSL<ref>https://learn.microsoft.com/ja-jp/windows/wsl/install</ref>を使用する。
== バイナリ版のインストール[Linux、WSL] ==

Ubuntuでのみ確認済み。

Githubのページから～linux64.zipをダウンロードして、解凍する。

[https://github.com/OpenRadioss/OpenRadioss/releases OpenRadioss Github]

/optなどに解凍する。

== バイナリ版のインストール[Windows] ==

Githubのページから～Win64.zipをダウンロードして、任意の場所に解凍する。

[https://github.com/OpenRadioss/OpenRadioss/releases OpenRadioss Github]

並列計算を実行する場合は、Intel MPI Libraryをインストールする。

[https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html#mpi Intel MPI Library]

== ソースコードコンパイル ==

[https://github.com/OpenRadioss/OpenRadioss/blob/main/HOWTO.md How to Build OpenRadioss]

[https://getwelsim.medium.com/explore-openradioss-the-worlds-first-enterprise-grade-open-source-explicit-dynamics-solver-i-b4c7931a48ed Explore the enterprise-grade open-source solver OpenRadioss I : build in Linux]

==注記==