Mmer547: /* Parallel */

2023-09-09T12:42:25Z

Parallel

← 古い版		2023年9月9日 (土) 21:42時点における版
696行目:		696行目:
	: $FOAM_SRC/functionObjects/field/surfaceDistance		: $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

			=== ファイル修正スキューを更新 ===
			複数のノードで並列ケースを実行する場合、プロセッサーのディレクトリは通常、NFSなどのネットワーク・ファイリング・システムを使用してアクセスされる。この場合、例えば辞書の変更を確認するために、自明でない待ち時間が発生する可能性があります。この目的のために、etc/controlDictに<syntaxhighlight lang="bash">
	fileModificationSkew 10;		fileModificationSkew 10;
			</syntaxhighlight>これは、辞書が変更されたとみなされるまでのファイル変更時間差の秒数である。2つ目の使用法は、#codeStream辞書エントリやコード化されたfunctionObjectなど、動的にコンパイルされたコードでの使用です。ここでは、dynamicCode/サブディクショナリ内の結果ライブラリが使用可能になるまでの待ち時間である。ただし、場合によってはファイルサーバーに大きな遅延が発生することがあるため、このfileModificationSkewは予想される最大値に設定する必要があります。

	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.		このリリースでは動作が変更され、以下のコントロールが追加されました。<syntaxhighlight lang="bash">

	~~In this release the behaviour has been changed in that there is an additional control~~

	maxFileModificationPolls 100;		maxFileModificationPolls 100;
			</syntaxhighlight>これは、fileModificationSkew 秒待ってからチェックする回数の最大値である。この動作により、fileModificationSkewをもっと低い値（最小1）に設定できるようになった。

	~~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).~~		上記の問題は、NFSでマウントされたディスクとマルチノードで実行する場合にのみ関係する。シングルノードの実行では、すべてのコアのファイルが一貫して表示されるため、マスターがコードのコンパイルを終了した場合、スレーブにも同じコードが表示されます。

	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.		例えば、異なるコアに異なるルートを使用する分散実行については、$FOAM_TUTORIALS/IO/fileHandlerチュートリアルを参照してください。ここでは、コードはすべてのコアでコンパイルされる必要があるので、同期の問題はありません。

	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.		=== ADIOS2ファンクションオブジェクトの更新 ===
			adiosWrite関数オブジェクトは、パラレルIO用のADIOS2ライブラリを使用するように書き換えられ、通常のOpenFOAMモジュールとして利用できるようになりました。

	~~=== 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...~~		HPC技術委員会の活動の一環として実施される予定である。

	~~More tests at scale are required and will be conducted as part of the activities of the HPC Technical Committee~~		== 携帯性 ==

	== ~~Portability~~ ==		==== 新しいバイナリファイルの互換性 ====
			OpenFOAM-v1912 は、OpenFOAM のコンパイルが混在するワークフローをサポートするために、異なる精度またはラベルサイズのバイナリ読み込みを処理するようになりました。

	~~==== 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:~~		* snappyHexMeshを使った倍精度メッシュ。
			* 空力用の単精度（メモリ帯域幅を削減するため）
	* ~~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,~~

			必要なサイズ情報がヘッダーに含まれていれば、バイナリ形式のOpenFOAMファイルでも可能です。例えば<syntaxhighlight lang="bash">
	FoamFile		FoamFile

	{		{

	version 2.0;		version 2.0;

	format binary;		format binary;

	arch "LSB;label=32;scalar=64";		arch "LSB;label=32;scalar=64";

	class vectorField;		class vectorField;

	object points;		object points;

	}		}
			</syntaxhighlight>OpenFOAM-v1612 以降で生成されたバイナリファイルには、すでにこの情報が含まれており、使用することができます。

	~~Binary files generated with OpenFOAM-v1612 and later will already contain this information and can be used.~~		64ビットのラベル幅を32ビットのラベル幅にするなど、データ範囲を狭める場合、範囲のオーバーフローは切り捨てられることに注意。

	~~Note that when narrowing the data range e.g. 64-bit label width to 32-bit label width, any range overflows will be truncated.~~

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

2023-09-09T12:39:59Z

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

差分を表示

OpenFOAM v1912 リリースノート - 版の履歴

Mmer547: /* Parallel */