並列接触にスレーブ分割方式（CONTACT_OWNER）を追加

inagakirequested to merge
feature/contact-owner-slave-cleaned into master

Close #16 (closed) #104 (closed)

現在の並列接触は、マスター面を要素の所有ランクで分割し、スレーブ節点を複製する。 このためマスター面の隣接グラフがランクごとに分断され、find_surface_neighbor の探索が分割境界で行き止まりになる。

本MRは所有の向きを反転させた方式を追加する。スレーブ節点を所有するランクに、マスター面を丸ごと複製する。 1つのスレーブ節点に対するマスター面の隣接グラフが単一ランク内で閉じるため、スレーブがどこまですべっても探索が切れない。

  • パーティショナー（hecmw1/tools/partitioner/hecmw_partition.c）が、CONTACT_OWNER=SLAVE のとき スレーブ節点の所有ランクを起点にマスター要素を複製する
  • 所有方式は hecmw_flag_partcontact の bit 8 に詰めて分散メッシュに記録する。 MASTER を 0 に割り当てているので、既存の分散メッシュはそのまま従来動作として読める
  • fistr1 側（fistr1/src/lib/contact/fstr_contact_def.F90）は分散メッシュのフラグを読み、 マスター面を取るかどうかと、スレーブ節点を内部節点に限るかどうかを切り替える。制御ファイル側の指定は不要である

袖要素の剛性計算のスキップ

マスター面を複製すると関連する要素も袖要素として追加され、その結果として必要のない袖要素の剛性・応力更新処理が走り、無視できないコストが発生する。 そこで、内点を１つも含まない要素は剛性計算をスキップするようにした。応力更新については平滑化要素とシェル要素の1hop多く通信を必要とする要素が正しく計算できなくなるため、スキップはしていない。

これは設計判断で、hecMESHの構造体にpartitionerが情報をもたせるという実装もありえる。こちらは責務分解はややキレイだが、上記とくらべ実装量が格段に増える（そのわりに似たようなスキップをするだけなので恩恵がすくない）ため、今回は上記の実装とした。

効果

有限すべりのすべりモデル（マスター板 + スレーブブロック）での警告件数。

実行 従来（master 所有） 本MR（slave 所有）
逐次 0 0
MPI 2 6 0
MPI 4 12 0
MPI 8 22 0

接触状態の遷移が逐次実行と一致し、領域数に依存しなくなる。

計算時間（3717節点・2432要素、MPI 2、solve の3回最小値）。

条件 時間
従来（master 所有） 6.04 秒
slave 所有（剛性スキップなし） 9.25 秒
slave 所有（本MR） 6.45 秒

slave 所有方式は複製のぶん要素数が増える（このモデルで 1242 → 2432）。袖要素の剛性を省くことで、実質の計算対象が 1218 要素となり従来と同水準に戻る。

後方互換

  • CONTACT_OWNER を指定しない場合の動作は従来と完全に同一である。 未変更の master と、分散メッシュの sha256・ランク別 .res がバイト単位で一致することを MPI 4 / 8 で確認した
  • 既存の分散メッシュファイルは、所有方式のビットが 0（= MASTER）として読まれる
  • 袖要素の剛性スキップも解を変えない。袖要素が存在する条件（slave 所有、DEPTH = 2）でも、 スキップの前後でランク別 .res がバイト一致する

Merge request reports