Oakbridge-CX スーパーコンピュータシステム 利用負担金表（2022 年 4 月 1 日）
負担金額（税込）
区分
ディスク容量大学・公共機関等
企業

一般申込

申込 1 セット当り
100,000 円（8,640 トークン）

申込 1 セット当り
120,000 円（8,640 トークン）

ノード固定

申込 1 セット当り
150,000 円（8,640 トークン）

申込 1 セット当り
180,000 円（8,640 トークン）

一般申込（最小セット）8,400 円（720 トークン）

トークン量追加

8,400 円（720 トークン）

ディスク容量追加

備考

グループ 1 セット当り/work 4TB
利用者当り
/home 50GB

利用期間 12 か月の金額・ト
ークン量（利用期間は 1 ヶ月単位で設
定可）/work 4 TB
利用者当り
/home 50 GB

利用期間は当該年度末まで

10,000 円（720 トークン）
1TB 単位で申込可（/work のみ）

6,480 円／（1TB*年）※Oakbridge-CX においてもパーソナルコースとグループコースの区分を廃止し、これまでのパーソナルコースは一般申込に統合した。
※トークン消費係数は 1.00，ただしトークン消費係数 1.50 のノード群(優先利用向け)を全体の 15%程度設ける。
※1 ジョブで利用可能な最大ノード数は 256 ノード。
※括弧（）内は付与するトークン量。実行したジョブのノード時間積と消費係数に応じてトークンが消費される。
付与したトークンは，利用期間内に全量が使用できることを保証するものではない。
トークンは利用期間内に限り有効とし，利用終了後に残量がある場合でも繰越や利用負担金の返還は行わない。
トークンの他のシステムへの移行については，「トークン移行におけるトークン量の換算表」を参照。
※ノード固定の申し込みには審査を要する。
※/home のディスク容量は複数のグループに所属している場合でも利用者当り 50GB 固定。

トークン移行におけるトークン量の換算表
移行先
Oakbridge-CX
移行元
システム

Wisteria/BDEC-01
システム

Oakbridge-CX システム－

1.6

Wisteria/BDEC-01 システム

0.6－

移行先に追加されるトークン量＝移行トークン量×係数
注意事項（Wisteria/BDEC-01, Oakbridge-CX スーパーコンピュータシステム 共通）
・ 「大学・公共機関等」は大学，高等専門学校及び大学共同利用機関，文部科学省所管の独立行政法人，学術研究及び学術振興を目的とする国又は地方公共団体が所管する機関，並びに文部科学省科学研究費補助金の交付を受けて学術研究を行う者に適用する。
・ 「企業」の申し込みには，企業利用申込書添付書類の提出および審査を要する。
・ 利用期間は，利用開始月から終了月の末日またはサービス休止前までとする。利用期間内に計算機利用を中止した場合であっても利用負担金額の変更は行わない。年度の途中で利用開始または終了する場合の負担金額は月数別利用負担金表（Web ページ）を参照すること。
・ 前掲の利用負担金表は基本セットの内容であり，最小セットについては Web ページを参照すること。
・ 利用負担金は，原則として利用開始月に応じ，以下の月に一括して請求する。
- 利用開始月が 4 月から 9 月までは 12 月，10 月から 12 月までは 3 月，1 月から 3 月までは 3 月末。
- 前年度内に事前申込をした分については，利用開始月に関わらず，11 月の請求となる。
・ 利用負担金額が減額となる変更はできない。
・ ディスク量は，グループ全体の上限値である。

スーパーコンピューティングニュース- 1 -Vol. 24, No.3

2022

スーパーコンピュータシステム ジョブクラス制限値
Wisteria/BDEC-01 スーパーコンピュータシステム（Wisteria-O） ジョブクラス制限値（2021 年 5 月 14 日）
ノード数※２（最大コア数）

キュー名※１debug-o

1 ～

144

制限時間
（経過時間）(6,912)30 分

メモリー容量（ＧiＢ）※３

一般申込

公募制度
による申込

28

○

○

short-o
1 ～72(3,456)8 時間
28○○(regular-o)small-o
1 ～144(6,912)
48 時間
28
○
○
145 ～
(27,648)
medium-o
576
〃
〃
○
○
577 ～ 1,152(55,296)
large-o〃〃○○1,153 ～ 2,304(110,592)
x-large-o
24 時間
〃
○
○
priority-o
1 ～288(13,824)
48 時間
28
○
○
challenge-o
1 ～ 7,680(368,640)
24 時間
28
★
★
(interactive-o) ※４(48)
interactive-o_n1
1
30 分
28
○
○
2 ～
(576)
interactive-o_n12
12
10 分
〃
○
○
prepost
1
(56)
6 時間
340
○
○
prepost1_n1 ～1(56) 1～6 時間
340○○
prepost4_n1
prepost1_n4
1 ～4(224) 1～6 時間
340○○
prepost1_n8
1 ～8(448) 1～6 時間
340○○★ 審査による課題選定の上，月１回の一定期間のみ利用可能（原則として月末処理日前日の朝～翌日朝）※１ キューの指定(〝#PJM -L “rscgrp=キュー名” ″) は，regular-o，debug-o，short-o を小文字で指定する
regular-o キューはノード数の指定（〝#PJM -L “node=ノード数” ″）でノード数別のキューに投入される※２ トークンの消費係数は 1 ノード当り 1.00。ただし priority-o は優先利用ノード群のためトークン消費係数は 1.50
※３ １ノード当りの利用者が利用可能なメモリー容量※４ インタラクティブジョブの起動は次のとおり （トークン消費なし）
pjsub --interact –g グループ名 -L “rscgrp=interactive-o,node=ノード数”

Wisteria/BDEC-01 スーパーコンピュータシステム（Wisteria-A） ジョブクラス制限値（2021 年 5 月 14 日）
メモリー
公募制度
ノード数・GPU 数※２
制限時間
容量（ＧiＢ）
一般申込
キュー名※１
による申込（最大 GPU 数）（経過時間）※３

debug-a

GPU
専有申込

ノード固定

1 ノード

(8)

30 分

448

○

○

○

○

1 ～

2 ノード

(16)

2 時間

448

○

○

○

○

1 ～
3 ～
5 ～

2 ノード
4 ノード
8 ノード
1, 2, 4 GPU

(16)
(32)
(64)

48 時間
〃
24 時間
30 分

448
〃
〃
56

○
○
○
○

○
○
○
○

○
○
○
○

○
○
○
○

1, 2, 4 GPU

2 時間

○

○

○

○

1 GPU
2 GPU
4 GPU
1 ～ 39 ノード

48 時間
〃
24 時間
24 時間

56

56
〃
〃
448

○
○
○
★

○
○
○
★

○
○
○
★

○
○
○
★

(8) 任意 ※４
448
×
×
○
1 ノード
1 ノード
○
○
○
interactive-a ※５
10 分
56
(8)
○
○
○
share-interactive
〃
〃
1 GPU
★ 審査による課題選定の上，月１回の一定期間のみ利用可能（原則として月末処理日前日の朝～翌日朝）※１ キューの指定(〝#PJM -L “rscgrp=キュー名” ″) は，regular-a，debug-a，short-a を小文字で指定する
regular-a キューはノード数の指定（〝#PJM -L “node=ノード数” ″）でノード数別のキューに投入される※２ トークンの消費係数は 1GPU 当り 3.00
※３ １ノード当りの利用者が利用可能なメモリー容量※４ 申込ノード数の合計以内ならば，キュー名・制限時間（原則 48 時間以内）は相談の上，任意に設定可能※５ インタラクティブジョブの起動は次のとおり （トークン消費なし）
pjsub --interact –g グループ名 -L “rscgrp=interactive-a,node=ノード数”○

short-a(regular-a)
small-amedium-alarge-ashare-debug
share-short(share)share-1
share-2
share-4
challenge-a

(312)

任意

スーパーコンピューティングニュース

- 2 -

○
○

Vol. 24, No.3

2022

Oakbridge-CX スーパーコンピュータシステム ジョブクラス制限値（2019 年 7 月 1 日）
ノード数※２（最大コア数）

キュー名※１

制限時間（経過時間）

メモリー
容量
（ＧＢ）

30 分

168

一般
申込

ノード
固定

○

○

※３

debug

1 ～

16

(896)

short
1 ～
8
(448)
8 時間
168
○
○
(regular)
small
1 ～
16
(896)
48 時間
168
○
○
17 ～
64
medium(3584)
〃
〃
○
○
65 ～
128
large
(7168)
〃
〃
○
○
129 ～
256
x-large(14336)
24 時間〃○○
challenge
1 ～1368(76608)
24 時間
168
★
★
任意
申込数
任意 ※４
168
×
○
(interactive) ※５
1
interactive_n1
(56)
2 時間
168
○
○
interactive_n8
2 ～
8
(448)
10 分
〃
○
○
★ 審査による課題選定の上，月１回の一定期間のみ利用可能（原則として月末処理日前日の朝～翌日朝）※１ キューの指定(〝#PJM -L “rscgrp=キュー名” ″) は，regular，debug，short を小文字で指定する
regular キューはノード数の指定（〝#PJM -L “node=ノード数” ″）でノード数別のキューに投入される※２ トークンの消費係数は 1.00
※３ １ノード当りの利用者が利用可能なメモリー容量※４ 申込ノード数の合計以内ならば，キュー名・制限時間（原則 48 時間以内）は相談の上，任意に設定可能※５ インタラクティブジョブの起動は次のとおり （トークン消費なし）
pjsub --interact –g グループ名 -L “rscgrp=interactive,node=ノード数”

大規模共通ストレージシステム 利用負担金表
大規模共通ストレージシステム(第１世代、Ipomoea-01) 利用負担金表（2022 年 6 月 1 日）
区分負担金額（税込）【大学・公共機関等 7,200 円, 企業 8,640 円】（1TB の場合，年額）（ディスク容量ごとの負担金額は下表参照, 利用期間は 1 ヶ月単位で設定可）
利用者番号登録数
制限なし
並列ファイルシステム ディスク容量
1 TB[10 TB まで 1 TB 追加当たり]
10 TB[100 TB まで 1 TB 追加当たり]
100 TB[1,000 TB まで 1 TB 追加当たり]
1,000 TB
[以降 1 TB 追加当たり]

一般申込

大学・公共機関等
7,200 円/年
[4,200 円/年]
45,000 円/年[3,000 円/年]
315,000 円/年[2,400 円/年]
2,475,000 円/年[2,100 円/年]

企業
8,640 円/年
[5,040 円/年]
54,000 円/年[3,600 円/年]
378,000 円/年[2,880 円/年]
2,970,000 円/年[2,520 円/年]

※ 東京大学情報基盤センターのスーパーコンピュータシステムのいずれかに利用者番号（教育利用，講習会を除く）を有する場合，利用者ごとにディスク容量 5 TB を無償で付与し、グループごとに登録されているシステム（トークン移行先のシステムを除く）で付与されているディスク容量の 15%を無償で付与する。いずれも申込不要。
申込時点のディスク容量に応じて，1 TB 追加当たりの負担金額は下表参照（無償で付与されたディスク容量は「申込時点のディスク容量」に含まない）

ディスク容量追加

申込時点のディスク容量
1 TB 未満
1 TB 以上
10 TB 未満
10 TB 以上
100 TB 未満
100 TB 以上 1,000 TB 未満
1,000 TB 以上

大学・公共機関等
7,200 円/年
4,200 円/年
3,000 円/年
2,400 円/年
2,100 円/年

企業
8,640 円/年
5,040 円/年
3,600 円/年
2,880 円/年
2,520 円/年

※利用期間については利用開始月から当該年度のサービス終了月までとし，年度を超えないものとする。利用期間の指定がある場合は利用終了月までとする。
※ディスク容量は利用期間内に限り有効とし，利用終了後に残存しているデータは削除するものとする。
※ディスク容量追加の負担金額は追加単位額に追加する資源量および利用期間を乗じたものとする。
※ファイル，ディレクトリの総数制限についてはディスク容量に比例した値を別途定めるものとする。

スーパーコンピューティングニュース- 3 -Vol. 24, No.3

2022

センターから
サービス休止等のお知らせ
2022 年 5 月下旬からの計算機及びストレージシステムのサービス予定は以下のとおりです。
Wisteria/BDEC-01 スーパーコンピュータシステム○ Wisteria/BDEC-01 スーパーコンピュータシステム サービス休止のお知らせ
日 付

利用者サービスセンター内作業5 月 27 日（金）9:00 ～ 22:00 までサービス休止

月末処理

6 月 24 日 (金)9:00 ～ 22:00 までサービス休止

月末処理

7 月 29 日（金）9:00 ～ 22:00 までサービス休止

月末処理

・ Wisteria/BDEC-01 システムは，原則 24 時間サービスを行っています。
ただし，月末処理日 (原則として毎月最終金曜日) はサービスを停止します。

○ Wisteria/BDEC-01 スーパーコンピュータシステム 大規模 HPC チャレンジ のお知らせ（*）
大規模 HPC チャレンジ 実施期間
5 月 26 日 (木) 9:00 ～ 27 日 (金) 9:00 まで
6 月 23 日 (木) 9:00 ～ 24 日 (金) 9:00 まで
7 月 28 日 (木) 9:00 ～ 29 日 (金) 9:00 まで
・上記期間中，Wisteria/BDEC-01 の debug-o/a, short-o/a, regular-o/a, priority-o, interactive-o/a, prepost, share,share-debug, share-short, share-interactive, ノード固定及び講義用キューのサービスを休止します。
ログインノードは通常どおり利用できます。

Oakbridge-CX スーパーコンピュータシステム○ Oakbridge-CX スーパーコンピュータシステム サービス休止のお知らせ
日 付

利用者サービスセンター内作業5 月 25 日 (水)9:00 ～ 20:00 までサービス休止

月末処理

6 月 22 日 (水)9:00 ～ 20:00 までサービス休止

月末処理

7 月 27 日 (水)9:00 ～ 20:00 までサービス休止

月末処理

・ Oakbridge-CX システムは，原則 24 時間サービスを行っています。
ただし，月末処理日 (原則として毎月最終水曜日) はサービスを停止します。

○ Oakbridge-CX スーパーコンピュータシステム 大規模 HPC チャレンジ のお知らせ（*）
大規模 HPC チャレンジ 実施期間
5 月 24 日 (火) 9:00 ～ 25 日 (水) 9:00 まで
6 月 21 日 (火) 9:00 ～ 22 日 (水) 9:00 まで
7 月 26 日 (火) 9:00 ～ 27 日 (水) 9:00 まで
・上記期間中，Oakbridge-CX の debug, short, regular, interactive, prepost, ノード固定 及び 講義用キューのサービスを休止します。ログインノードは通常どおり利用できます。

スーパーコンピューティングニュース- 1 -Vol. 24, No.3

2022

大規模共通ストレージシステム（Ipomoea-01）○ 大規模共通ストレージシステム(第 1 世代) Ipomoea-01 サービス開始について
6 月 1 日（水）10:00 よりサービス運用を開始します。
詳細については，本誌別記事「大規模共通ストレージシステム(第１世代)運用に関するお知らせ」をご覧ください。

○ Ipomoea-01 サービス休止のお知らせ
日 付
6 月 24 日 (金)利用者サービスセンター内作業

9:00 ～ 20:00 までサービス休止

月末処理

・ Ipomoea-01 は，原則 24 時間サービスを行っています。
ただし，月末処理実施のためサービスを停止する場合もあります。
【注意事項】・ サービス休止等の計画は原稿作成時の予定です。やむを得ずサービスを変更したり，休止したりする場合がありますので，最新の情報
は login 時のメッセージ及びスーパーコンピューティング部門の Web ページの運用スケジュール (https://www.cc.utokyo.ac.jp/supercomputer/schedule.php) をご確認ください。
・ 平日の 9:00～17:00 以外，休日 (土・日・祝日等) は，システム障害等でサービスが停止した場合，運転を継続できない場合があります。その場合は，その時間をもってサービスを中止しますのでご了承ください。
* Wisteria/BDEC-01 及び Oakbridge-CX における大規模 HPC チャレンジについて、新型コロナウイルス感染症の状況次第で実施時間・実
施条件の変更や、中止となる可能性があります。詳細は Web ページ(https://www.cc.u-tokyo.ac.jp/guide/hpc/)をご覧ください。

スーパーコンピューティングニュース- 2 -Vol. 24, No.3

2022

システム変更等のお知らせ(2022.3.1 － 2022.4.30 変更)
1. ハードウェア
1.1 Wisteria/BDEC-01 スーパーコンピュータシステム… なし

1.2 Oakbridge-CX スーパーコンピュータシステム… なし

2. ソフトウェア
2.1 Red Hat Enterprise Linux 8 (Wisteria/BDEC-01)

Odyssey
LAMMPS

v29Sep2021(2022.3.31)

SingularityCEv3.9.5(2022.3.31)

Aquarius
CUDA Toolkit

v11.4.4(2022.3.31)

OpenMPI(CUDA-aware)v4.1.1(UCX v1.11.2)(2022.3.31)

NCCL

v2.9.6、v2.9.8、v2.9.9
v2.10.3、v2.11.4(2022.3.31)

cuDNN

v8.2.0、v8.2.1
v8.2.2、v8.2.4(2022.3.31)

gdrcopyv2.3(2022.3.31)

SingularityCEv3.9.5(2022.3.31)

Arm DDT/MAP

v21.1.3(2022.3.31)

oneAPI HPC Toolkit

v2022.1.2(2022.3.31)

NetCDF C++

v4.3.1(2022.4.22)

MessengerSingularityCEv3.9.5(2022.3.31)
インストールを実施しました。利用方法については、利用支援ポータルのお知らせ、または
ドキュメント閲覧より利用手引書をご覧ください。
2.2 Red Hat Enterprise Linux 7, CentOS 7 (Oakbridge-CX)
Arm DDT

21.1.3(2022.3.31)

oneAPI HPC Toolkit
v2022.1.2(2022.3.31)
インストールを実施しました。利用方法については、利用支援ポータルのお知らせ、または
ドキュメント閲覧より利用手引書をご覧ください。
3. その他
3.1

Oakforest-PACS サービス終了について

Oakforest-PACS スーパーコンピュータシステムは 2022 年 3 月末をもってすべてのサービスを終了致しました。
2021 年度の Oakforest-PACS の利用者様におきましては、2022 年 6 月に稼働開始する東京大学情スーパーコンピューティングニュース- 3 -Vol. 24, No.3

2022

報基盤センター「大規模共通ストレージシステム(Ipomoea-01)」へのファイル移行サービスについてのご案内を、最先端共同 HPC 基盤施設(JCAHPC) より別途メールで送らせていただいております。
(注) Ipomoea-01 への移行リクエスト受付は既に終了しております。
(注)「大規模共通ストレージシステム(Ipomoea-01)」へ移行リクエストを行なっていないディレクト
リのデータは移行されません。
(注) システム側では利用者データ等のバックアップは取得しておりません。サービス終了後にデータの回復等は対応いたしかねますので、ご了承ください。
(注) ファイル移行サービス希望者の方が大規模共通ストレージシステム(Ipomoea-01)に置かれたファイルを利用可能となるのは 2022 年 6 月以後の予定です。

スーパーコンピューティングニュース- 4 -Vol. 24, No.3

2022

大規模共通ストレージシステム(第 1 世代) 運用に関するお知らせ（更新）
スーパーコンピューティングチーム

東京大学情報基盤センター(以下「当センター」)におきまして、当センターで運用する各スーパーコンピュータシステムからアクセス可能なストレージシステム：大規模共通ストレージシステム(第１世代) (Ipomoea-01)を 2022 年 6 月からサービス運用いたします。ここでは、ご利用に際して必要な手続き及び負担金をお知らせいたします。なお、運用開始までに、予告なく運用仕様の変更を行う場合がありますので予めご了承ください。
1.

利用申込みについて
ご利用になるための利用申込み方法の詳細は当センター Web ページもご参照ください。Ipomoea-01 をご利用になる場合には、当センターのスーパーコンピュータシステム Oakbridge-CX、Wisteria/BDEC-01 をすでにご利用かどうかにより、
Ipomoea-01 の利用申込み手続きが必要なケースがあります。なお、Ipomoea-01 におけるディスク容量追加手続きは可能ですが、スーパーコンピュータシステムにユーザ ID を有するかに係わらず、容量追加のための手続きが別途必要になります。
1.1 2021 年度末に Oakforest-PACS にユーザ ID を有していなかった利用者、または、2021 年度末に Oakforest-PACS に
ユーザ ID を有していたが、Oakforest-PACS のファイル移行サービスを希望しなかった利用者


2022 年度 Oakbridge-CX、Wisteria/BDEC-01 にユーザ ID を有する場合
利用申し込み手続きは不要です。ご利用のユーザ ID で Ipomoea-01 を利用できます(教育利用、講習会を除く)。
 利用者ごとの領域に 5 TB の無償分のディスク容量を付与します。
 登録されているスーパーコンピュータシステムで付与されているグループのディスク容量の 15 ％を各プロ
ジェクトコードのグループごとの領域として無償で付与します。(トークン移行先のシステムを除く)
2022 年度 Oakbridge-CX、Wisteria/BDEC-01 にユーザ ID を持たない場合
利用申し込み手続きが必要です。無償分のディスク容量は設定されません。

1.2 2021 年度末に Oakforest-PACS にユーザ ID を有しており、ファイル移行サービスを希望した利用者


2022 年度 Oakbridge-CX、Wisteria/BDEC-01 にユーザ ID を有する場合
利用申し込み手続きは不要です。ご利用のユーザ ID で Ipomoea-01 を利用できます(教育利用、講習会を除く)。
 利用者ごとの領域に 5 TB の無償分のディスク容量を付与します。
 移行を希望したグループごとの領域に 5 TB の無償分のディスク容量を付与します。ただし、トークン移行
によりOakbridge-CX、Wisteria/BDEC-01のどちらかに同プロジェクトコードのグループが存在する場合は、
グループごとの領域への付与ディスク容量は、登録されているスーパーコンピュータシステムで付与されているグループのディスク容量の 15％ とします。
 登録されているスーパーコンピュータシステムで付与されているグループのディスク容量の 15 ％を各プロ
ジェクトコードのグループごとの領域として無償で付与します。(トークン移行先のシステムを除く)
2022 年度 Oakbridge-CX、Wisteria/BDEC-01 にユーザ ID を持たない場合
利用申し込み手続きは不要で、Oakforest-PACS のユーザ ID で 2022 年 11 月 30 日までは無償でご利用いただ
けます。2022 年 12 月 1 日以降も移行したファイルを利用するためには有償の利用申し込み手続きが必要です。
 利用者ごと、移行を希望したグループごとの領域に 5 TB の無償分のディスク容量を付与します。
 2022 年 11 月までに継続利用の申し込みがない場合、2022 年 12 月以降にファイルは削除されます。

スーパーコンピューティングニュース- 5 -Vol. 24, No.3

2022

2.

利用負担金について
Ipomoea-01 をご利用になる場合の利用負担金について、利用者様への運用を開始する 2022 年 6 月以降発生する予定です。

2.1 2021 年度末に Oakforest-PACS にユーザ ID を有していなかった利用者、または、2021 年度末に Oakforest-PACS に
ユーザ ID を有していたが、Oakforest-PACS のファイル移行サービスを希望しなかった利用者


2022 年度 Oakbridge-CX、Wisteria/BDEC-01 にユーザ ID を有する場合
無償分のディスク容量の範囲でご利用の場合、負担金は発生しません。別途 Ipomoea-01 でのディスク容量の追加手続きを行った場合に、追加分の利用負担金が発生します。
2022 年度 Oakbridge-CX、Wisteria/BDEC-01 にユーザ ID を持たない場合
利用申し込みディスク容量に対する負担金が発生します。

2.2 2021 年度末に Oakforest-PACS にユーザ ID を有しており、ファイル移行サービスを希望した利用者


2022 年度 Oakbridge-CX、Wisteria/BDEC-01 にユーザ ID を有する場合
利用者ごとの領域については、無償分のディスク容量の範囲でご利用の場合、負担金は発生しません。移行を希望したグループごとの領域については 2022 年 11 月まで負担金は発生しません。2022 年 12 月以降も移行を希望したグループごとの領域を利用するためには有償の利用申し込み手続きが必要です。別途 Ipomoea-01 でのディ
スク容量の追加手続きを行った場合に、追加分の利用負担金が発生します。
2022 年度 Oakbridge-CX、Wisteria/BDEC-01 にユーザ ID を持たない場合
2022 年 11 月まで負担金は発生しません。2022 年 12 月以降は利用申し込みディスク容量に対する負担金が発生します。

スーパーコンピューティングニュース- 6 -Vol. 24, No.3

2022

3.

運用開始後のサービスについて

3.1 ログインノードサービス
データ転送やそのためのツールを利用するための環境として、ログインノードを複数台用意する予定です。ログインノード
は、当センターでサービスを行っている他のスーパーコンピュータシステムと同様に、公開鍵認証方式による接続となります。
鍵登録の方法や、接続ホスト名などの詳細については、当センター Web ページや Ipomoea-01 利用支援ポータルにてお知ら
せいたします。
3.2 システムの利用イメージ
Ipomoea-01 のご利用イメージは、おおよそ図 2 の通りです (ただし、以下の図は、スーパーコンピューティングニュース
原稿作成時のものです。今後の検討状況によっては、変更する場合もあります)。

Wisteria/BDEC-01
ログインノード群
ログインノード

Ipomoea-01
ファイルアクセス

並列ファイルシステム(注) ログインノード群からのみアクセス可能

データ転送など
SSH 接続(鍵認証)

Oakbridge-CX ファイルアクセス
ログインノード群
ログインノード

データ転送など

Ipomoea-01
ログインノード群

ファイルアクセス

ログインノード

利⽤⽀援ポータル

SSH 接続
(鍵認証)

Web
ブラウザ

・SSH 公開鍵登録
・リソース確認など(注) Ipomoea-01 はストレージシステムのため、計算⽤のジョブを実⾏する環境はありません。

図２．システムのご利⽤イメージ
3.3 ファイルシステム
ファイルシステムは、システム構成図 (図 1、図 2、表 1) にある通り、並列ファイルシステムのみで構成されます。
並列ファイルシステムは DDN 社製の Lustre ベースの DDN EXAScaler で提供されます。主に以下の 2 つのディレクト
リにファイルを保存することができ、Ipomoea-01 のログインノード群からだけではなく、Oakbridge-CX、Wisteria/BDEC-01 のログインノード群からもファイルアクセス(ファイルの読み込み、書き込み)が可能なように設定する予定です。その他、詳細については当センター Web ページや Ipomoea-01 利用支援ポータルにてお知らせいたします。
/home/ユーザ名(ユーザ ID)：利用者ごとの領域/work/グループ名(プロジェクトコード)：グループごとの領域

4. その他
最新の情報は、当センター Web ページ (https://www.cc.u-tokyo.ac.jp) にて随時ご案内いたします。メールによる問い合わ
せについては、事前に Web ページで情報がないかご確認の上、受付窓口 uketsuke@cc.u-tokyo.ac.jp までお願いいたします。

スーパーコンピューティングニュース- 7 -Vol. 24, No.3

2022

2022 ᖺᗘᮾி኱Ꮫ᝟ሗᇶ┙ࢭࣥࢱ࣮ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢸ࢕ࣥࢢ㒊㛛ㅮ⩦఍ᐇ ᪋ணᐃࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢸ࢕ࣥࢢࢳ࣮࣒
ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢸ࢕ࣥࢢࢳ࣮࣒࡛ࡣࠊ඲ᅜࡢࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ฼⏝⪅ࠊ࠾ࡼࡧ฼⏝ࢆ᳨ウࡋ࡚࠸ࡿ᪂つ࣮ࣘࢨ㸦௻ᴗࡢᢏ⾡⪅࣭◊✲⪅ࢆྵࡴ㸧ࢆᑐ㇟࡜ࡋࡓࠊࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢆ⏝࠸ࡓᐇ⩦௜ࡁࡢ୪ิࣉࣟࢢ࣑ࣛࣥࢢㅮ
⩦఍㸦࠾ヨࡋ࢔࢝࢘ࣥࢺ௜ࡁㅮ⩦఍㸧ࢆᐃᮇⓗ࡟ᐇ᪋ࡋ࡚࠸ࡲࡍࠋ
ᮏㅮ⩦఍ࡣࠊᙜࢭࣥࢱ࣮ࡀ㐠⏝ࡍࡿ Oakbridge-CX, Wisteria/BDEC-01 ࡟࡚ᐇ᪋ࡉࢀࡿணᐃ࡛ࡍࠋ
୪ิฎ⌮࡟㛵ࡍࡿᇶ♏▱㆑ࢆᚲせ࡜ࡋ࡞࠸ึ⣭⦅࡟ጞࡲࡾࠊᩘ್ィ⟬ࡢᛂ⏝ࣞ࣋ࣝࡢ୪ิ໬ࡲ࡛ࠊཷㅮ⪅ࡢ⩦ᚓࣞ࣋ࣝ࡟ᛂࡌࡓㅮ⩦఍࡟ཧຍࡀྍ⬟࡛ࡍࠋ୪ิ໬࡟ࡣ MPI (Message Passing Interface)ࠊOpenMP ࡲࡓࡣ OpenACC ࡀ⏝࠸ࡽࢀࡲࡍࡢ࡛ࠊࡇࢀࡽࢆ⏝࠸ࡓ୪ิ໬᪉ἲࡢ⩦ᚓࡀ࡛ࡁࡲࡍࠋ
ㅮ⩦఍ࡣ↓ᩱ࡛ࡍࠋ࡞࠾ࠊ1 ࣨ᭶㛫฼⏝࡛ࡁࡿࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ㸦ㅮ⩦఍࡛฼⏝ࡍࡿࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ㸧ࡢ࢔࢝࢘ࣥࢺࡀ㓄ᕸࡉࢀࡲࡍࠋㅮ⩦఍ᮇ㛫࡟ຍ࠼࡚ㅮ⩦఍⤊஢ᚋࡶࠊㅮ⩦ෆᐜ࡟㛵ࡍࡿ₇⩦࡟㓄ᕸ࢔࢝࢘ࣥࢺࡀ฼⏝࡛ࡁࡲࡍࠋ2022 ᖺᗘࡢㅮ⩦఍㛤ദணᐃࢆ௨ୗ࡟ᥖ㍕ࡋࡲࡍࠋࡩࡿࡗ࡚ࡈཧຍࡢࡈ᳨ウࢆ࠾㢪࠸ࡋࡲࡍࠋ࡞࠾ᮏࢫࢣࢪ࣮ࣗࣝࡣணᐃ࡛࠶ࡾࠊ᪥⛬࠾ࡼࡧෆᐜࡢኚ᭦ࡀ⏕ࡌࡿࡇ࡜ࡀ࠶ࡾࡲࡍࡢ࡛ணࡵࡈ஢ᢎࡃࡔࡉ࠸ࠋㅮ⩦᪥᫬࠾ࡼࡧෆᐜࡢヲ⣽㸦㐣ཤࡢㅮ⩦఍ࡢ PDF ㈨ᩱ࡞࡝㸧ࡣࠊ௨ୗࡢ HP ࢆࡈぴ☜ㄆࡃࡔࡉ࠸ࠋ
  https://www.cc.u-tokyo.ac.jp/events/lecture/‫ڦ‬2022 ᖺᗘࡢ࠾ヨࡋ࢔࢝࢘ࣥࢺ௜ࡁㅮ⩦఍㛤ദ࠙ணᐃࠚ
ྡ⛠ཬࡧᐇ᪋ᮇ㛫᪥᫬㸦ணᐃ㸧
࣭6 ᭶ 6 ᪥

Wisteria ᐇ㊶

MPI ᇶ♏

スーパーコンピューティングニュース

࣭9 ᭶㡭
࣭2 ᭶㡭
࣭4 ᭶ 26 ᪥
࣭10 ᭶㡭

ഛ⪃ᮏᖺᗘࡼࡾ㐠⏝ࢆ㛤ጞࡍࡿ
Wisteria/BDEC-01 ࢆ฼⏝ணᐃ

MPI ࡟ࡼࡿ୪ิࣉࣟࢢ࣑ࣛࣥࢢࡢ
ᇶ♏࡟㛵ࡍࡿㅮ⩦ࠊᐇ⩦ࠋ
Wisteria/BDEC-01 ࢆ฼⏝ணᐃ- 8 -Vol. 24, No.3

2022ࡼࡾࣁ࢖ࣞ࣋ࣝ࡞ MPI ࡟ࡼࡿ୪ิ
MPI ୖ⣭⦅ࣉࣟࢢ࣑ࣛࣥࢢ࡟㛵ࡍࡿㅮ⩦ࠊᐇ⩦

࣭10 ᭶㡭

Wisteria/BDEC-01 ࢆ฼⏝ணᐃࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ࡬ࡢࣟࢢ࢖
ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗ

࣭4 ᭶ 22 ᪥ࣥ᪉ἲࡸࣉࣟࢢ࣒ࣛࡢᐇ⾜᪉ἲ࡞

ࢱ㉸ධ㛛

࣭9 ᭶㡭

࡝౑࠸᪉ࢆᏛࡪOakbridge-CX ࢆ฼⏝

OpenFOAM࣭5 ᭶ 31 ᪥
࣭9 ᭶ 27 ᪥
࣭1 ᭶ 17 ᪥ᩘ್ィ⟬ࣛ࢖ࣈࣛࣜ฼⏝࡟ࡼࡿ⛉Ꮫᢏ⾡ィ⟬ࡢຠ⋡໬࡟㛵ࡍࡿㅮ⩦ࠊᐇ⩦
Wisteria/BDEC-01 ࢆ฼⏝ணᐃ⛉Ꮫᢏ⾡ィ⟬ࡢຠ⋡໬ධ㛛

࣭10 ᭶㡭

GPU ࣉࣟࢢ࣑ࣛࣥࢢධ㛛

࣭5 ᭶ 18 ᪥
࣭10 ᭶㡭

GPU ࣑ࢽ࢟ࣕࣥࣉ㹼
HPC ⦅㹼

࣮࢜ࣉࣥࢯ࣮ࢫࡢ CFD ࢶ࣮ࣝ࢟ࢵ
ࢺ࡛࠶ࡿ OpenFOAM ࢆ⏝࠸ࡓㅮ⩦ࠊᐇ⩦
Wisteria/BDEC-01 ࢆ฼⏝ணᐃ

࣭7 ᭶ 12 ᪥~19 ᪥

GPU ࣉࣟࢢ࣑ࣛࣥࢢ࡟㛵ࡍࡿㅮ⩦ࠊᐇ⩦
Wisteria/BDEC-01 ࢆ฼⏝ணᐃཧຍ⪅ࡀࢥ࣮ࢻࢆᣢࡕ㎸ࡳࠊGPU
࡟ヲࡋ࠸࣓ࣥࢱ࣮ࡢຓゝࢆཷࡅ࡞
ࡀࡽࠊGPU ฼⏝ࡢຠ⋡໬ࢆ┠ᣦࡍࠋ
Wisteria/BDEC-01 ࢆ฼⏝ணᐃཧຍ⪅ࡀࢥ࣮ࢻࢆᣢࡕ㎸ࡳࠊࢹ࢕GPU ࣑ࢽ࢟ࣕࣥࣉ㹼ࢹ࢕࣮ࣉ࣮ࣛࢽࣥࢢ
⦅㹼

スーパーコンピューティングニュース࣭7 ᭶ 12 ᪥
~19 ᪥

- 9 -

࣮ࣉ࣮ࣛࢽࣥࢢ࡟ヲࡋ࠸࣓ࣥࢱ࣮
ࡢຓゝࢆཷࡅ࡞ࡀࡽࠊࢥ࣮ࢻࡢຠ
⋡໬ࢆ┠ᣦࡍࠋ
Wisteria/BDEC-01 ࢆ฼⏝ணᐃ

Vol. 24, No.3

2022࣐ࣝࢳ GPU ࣉࣟࢢ࣑ࣛࣥࢢ࡟㛵ࡍ
OpenACC ࡜ MPI ࡟ࡼࡿ࣐ࣝࢳ GPU ࣉࣟࢢ࣑ࣛࣥࢢධ㛛࣭11 ᭶㡭

ࡿㅮ⩦ࠊᐇ⩦
Wisteria/BDEC-01 ࢆ฼⏝ணᐃᣦ♧⾜ࢆグ㍕ࡍࡿࡇ࡜࡛ᡭ㍍࡟୪
OpenMP ࡟ࡼࡿ࣐ࣝ
ࢳࢥ࢔࣭࣓ࢽ࢕ࢥ࢔
୪ิࣉࣟࢢ࣑ࣛࣥࢢ
ධ㛛୪ิ᭷㝈せ⣲ἲ࡛Ꮫࡪ୪ิࣉࣟࢢ࣑ࣛࣥࢢᚭᗏධ㛛

࣭5 ᭶ 23 ᪥
࣭9 ᭶ 6 ᪥
࣭12 ᭶ 6 ᪥

࣭4 ᭶ 14 ᪥
࣭11 ᭶ 1 ᪥ิ໬ࡍࡿ OpenMP ࢆ⏝࠸ࡓࠕ᭷㝈య✚ἲ࠿ࡽᑟ࠿ࢀࡿ␯⾜ิࢆᑐ㇟࡜ࡋࡓ ICCG ἲࠖࢆ㢟ᮦ࡟ࡋࡓㅮ
⩦ࠊ₇⩦
Wisteria/BDEC-01 ࢆ฼⏝ணᐃ᭷㝈せ⣲ἲ࡟ࡼࡿ୍ḟඖ࣭୕ḟඖ⇕ఏᑟゎᯒࣉࣟࢢ࣒ࣛࢆ㸪MPI ࢆ౑⏝ࡋ࡚୪ิ໬ࡍࡿࡓࡵࡢᡭ㡰࡟ࡘ࠸࡚ゎㄝ㸪ᐇ⩦
Wisteria/BDEC-01 ࢆ฼⏝ணᐃ
Wisteria/BDEC-01 Aquarius ࡛

MATLAB ࡢᐇ⾜᪉ἲ

WaitIO ࡢ฼⏝᪉ἲ

࣭4 ᭶ 27 ᪥

࣭9 ᭶㡭

MATLAB ࢆᐇ⾜ࡍࡿ୍㐃ࡢ᧯సࢆ₇⩦ᙧᘧ࡛ᐇ⩦ࡋࡲࡍࠋ

Wisteria/BDEC-01 ࡢ Aquarius ࣀ࣮ࢻ⩌࡜ Odyssey ࣀ࣮ࢻ⩌ࢆ༠ㄪ฼⏝ࡍࡿࡓࡵࡢࢯࣇࢺ࢙࢘࢔࡛࠶ࡿ
WaitIO ࡟ࡘ࠸࡚Ꮫࡧࡲࡍࠋ

௨ୖ

スーパーコンピューティングニュース- 10 -

Vol. 24, No.3

2022५‫ش‬ঃ‫ش‬॥থআগ‫ॱش‬३५ॸ঒َপૠெ HPC ॳকঞথ४ُୖ਻൳ૐभउੴैच
 Wisteria/BDEC-01‫ؚ‬Oakbridge-CX ५‫ش‬ঃ‫ش‬॥থআগ‫ॱش‬३५ॸ঒दम‫ؚ‬َপૠெ HPC ॳকঞথ४ُ॑ৰ઱खथःऽ
घ‫؛‬َপૠெ HPC ॳকঞথ४ُम‫ؚ‬५‫ش‬ঃ‫ش‬॥থআগ‫ॱش‬३५ॸ঒ऋुणਈপૠெभঀ‫ॻش‬ਯ॑‫ؚ‬ਈপ 24 ৎ৑‫؞‬1 ଢ଼஢ॢঝ‫ش‬উदੑ઴ৱ౺भ௧થਹ৷ऋदऌॊਁ൳஑উট४ख़ॡॺदघ‫఼؛‬උ૖੯ಉपणःथम‫ؚ‬ਰৣ॑ओ༮ऎटऔः‫؛‬຦஘ऊैभୖ਻ૢ൳॑उୄठखथउॉऽघ‫؛‬‫ پ‬ৗ஑॥টॼक़ॖঝ५૎ഉඪभ૾யઃਸ਼दৰ઱ৎ৑ृৰ઱૖੯भ૗ಌ‫ؚ‬রૃभ૭ચਙुँॉऽघ‫؛‬

1. ઀୹ৱ౺  ਰৣभ५‫ش‬ঃ‫ش‬॥থআগ‫ॱش‬३५ॸ঒भঀ‫॑ॻش‬ਈপ 24 ৎ৑௧થਹ৷घॊऒधऋदऌऽघ‫؛‬yWisteria/BDEC-01 ५‫ش‬ঃ‫ش‬॥থআগ‫ॱش‬३५ॸ঒भ३঑গঞ‫ش‬३ঙথঀ‫ॻش‬ණ‫ق‬Odyssey‫ك‬6,144 ঀ‫ॻش‬‫ق‬294,912 ॥॔‫ك‬‫৾؞ॱشॹؚ‬ಆঀ‫ॻش‬ණ‫ق‬Aquarius‫ك‬36 ঀ‫قॻش‬GPU 288 ੦‫ك‬yOakbridge-CX ५‫ش‬ঃ‫ش‬॥থআগ‫ॱش‬३५ॸ঒भੑ઴ঀ‫ ॻش‬1,280 ঀ‫قॻش‬৔ SSD ࿌ൗ 112 ঀ‫كॻش‬

2. ਹ৷੧৔
y1 নাप 1 ৚‫ؚ‬ਉಋधखथাଜ૪৶৐঩भ 9:00‫ع‬โ 9:00 ऽदभਈপ 24 ৎ৑‫୹઀ؚ‬ৱ౺॑௧થਹ৷घॊऒधऋ
૭ચदघ‫؛‬‫ق‬পૠெ HPC ॳকঞথ४भਊ঩प‫ॳؚ‬কঞথ४৷भਝ৒प૗ಌःञखऽघ‫؛‬ऒभ૗ಌम 1 ৎ৑ங২भ੿঵ৎ৑ऋৄ
੢ऽोॊञी‫ؚ‬পૠெ HPC ॳকঞথ४भओਹ৷ৎ৑म 10 ৎႃ৫઩‫ؚ‬โ঩ 9 ৎીവधऩॉऽघ‫؛‬‫ك‬yୖ਻मਁ൳਑धख‫ؚ‬ਠঘ‫ش‬२‫ش‬प଒৒चङ‫ઁؚ‬ऎୖ਻॑൳ૐखऽघ‫଻؛‬য‫఺ؚ‬लॢঝ‫ش‬উपेॊૢ൳ऋ૭ચदघ
ऋ‫ؚ‬૚াप 1 ॢঝ‫ش‬উभ఼৷‫॑ك*ق‬ਉಋधखऽघ‫؛‬yম਑২पेॉ੭ैोञਛટपणःथमਁ৫खथຘऌऽघ‫؛‬ਛટਁ৫पमূ਎প৾ੲਾ੦ೕ७থॱ‫ش‬भ५‫ش‬ঃ‫ش‬॥থআগ‫ॱش‬३५ॸ঒॑ਹ৷ख‫ؚ‬َপૠெ HPC ॳকঞথ४ُ਑২पेढथৰ઱खञ຺॑৥੶खथःञटऌऽघ‫؛‬ऽञ‫ؚ‬َ५‫ش‬ঃ‫ش‬॥থআগ‫ॸش‬ॕথॢॽগ‫ش‬५ُृઁਾ๟ಉषभਛટਾઔ੶হभ෋ൿऩन॑ষढथःञटऌऽघ‫؛‬y७থॱ‫ش‬भ਌ಈ‫ુؚ‬ಈघॊ७঑ॼ‫ؚش‬ড‫ش‬ॡ३ঙॵউಉदओ৅਀ःञटऎৃ়ऋँॉऽघ‫؛‬yਹ৷મসम૮મदघ‫؛‬
* Wisteria/BDEC-01 पउःथम૚া Odyssey द 1 ੯‫ؚ‬Aquarius द 1 ੯‫ؚ‬ਈপ 2 ੯ऽदਭো૭ચ‫ؚ‬ञटख 1 ॢঝ‫ش‬উद Odyssey‫ؚ‬Aquarius ૏্ਹ৷घॊऒधु૭ચ

3. ৰ઱঩ங
2022 ফ২भ০৏भَপૠெ HPC ॳকঞথ४ُৰ઱঩ஙम਀ 1‫ع‬2 भधउॉदघ‫؛‬ͤ ৗ஑॥টॼक़ॖঝ५૎ഉඪभ૾யઃਸ਼द‫ؚ‬ৰ઱ৎ৑ृৰ઱૖੯भ૗ಌ‫ؚ‬রૃधऩॊ૭ચਙुँॉऽघ‫؛‬

ਸ਼
2
৚
ਸ਼
3
৚

਀ 1. 2022 ফ২ Wisteria/BDEC-01 পૠெ HPC ॳকঞথ४ৰ઱঩ங
ৰ઱঩ৎ
൳ૐഁજ
ଟਪ
2022 ফ 8 া 18 ঩(਽) 10:00 ‫ ع‬19 ঩(স) 9:00
2022 ফ
2022 ফ 9 া 15 ঩(਽) 10:00 ‫ ع‬16 ঩(স) 9:00
6 া 27 ঩ (া)
7 া঱ഽ2022 ফ 10 া 27 ঩(਽) 10:00 ‫ ع‬28 ঩(স) 9:00
17:00ْഁજٓ
2022 ফ 11 া 24 ঩(਽) 10:00 ‫ ع‬25 ঩(স) 9:00
2022 ফ 12 া 22 ঩(਽) 10:00 ‫ ع‬23 ঩(স) 9:00
2022 ফ
2023 ফ 1 া 26 ঩(਽) 10:00 ‫ ع‬27 ঩(স) 9:00
10 া 31 ঩ (া)
11 া঱ഽ
2023 ফ 2 া 21 ঩(ౌ) 10:00 ‫ ع‬22 ঩(਷) 9:00
17:00ْഁજٓ
2023 ফ 3 া 30 ঩(਽) 10:00 ‫ ع‬31 ঩(স) 9:00

スーパーコンピューティングニュース- 11 -

఼උৢੴ

7 ারഽ

11 ারഽ

Vol. 24, No.3

2022

ਸ਼
2
৚
ਸ਼
3
৚
y
y
y

਀ 2. 2022 ফ২ Oakbridge-CX পૠெ HPC ॳকঞথ४ৰ઱঩ங
ৰ઱঩ৎ
൳ૐഁજ
ଟਪ
2022 ফ 8 া 25 ঩(਽) 10:00 ‫ ع‬26 ঩(স) 9:00
2022 ফ
2022 ফ 9 া 21 ঩(਷) 10:00 ‫ ع‬22 ঩(਽) 9:00
6 া 27 ঩ (া)
7 া঱ഽ2022 ফ 10 া 25 ঩(ౌ) 10:00 ‫ ع‬26 ঩(਷) 9:00
17:00ْഁજٓ
2022 ফ 11 া 21 ঩(া) 10:00 ‫ ع‬22 ঩(ౌ) 9:00
2022 ফ 12 া 20 ঩(ౌ) 10:00 ‫ ع‬21 ঩(਷) 9:00
2022 ফ
2023 ফ 1 া 24 ঩(ౌ) 10:00 ‫ ع‬25 ঩(਷) 9:00
10 া 31 ঩ (া)
11 া঱ഽ
2023 ফ 2 া 16 ঩(਽) 10:00 ‫ ع‬17 ঩(স) 9:00
17:00ْഁજٓ
2023 ফ 3 া 30 ঩(਽) 10:00 ‫ ع‬31 ঩(স) 9:00

఼උৢੴ

7 ারഽ

11 ারഽ

ওথॸॼথ५ಉभ੃়पेॉ൳ૐ५ॣ४গ‫ش‬ঝऋ૗ಌधऩॊऒधऋँॉऽघ‫؛‬ਈৗੲਾम Web Page1॑ओ༮ऎटऔः‫؛‬
ফളਯ৚॑ணख੢िऒधु૭ચदघऋ‫ؚ‬ண੢૾யपेॉओൌ஦प๣इऩःৃ়ुँॉऽघभदँैऊगीओവ
അऎटऔः‫؛‬ऽञ‫ؚ‬঳৚भணख੢ादਹ৷૭ચऩभम঳৚भादघ‫؛‬਀पൕൗऔोथःॊਰਗभ঩ஙदु൳ૐ॑ষअऒधऋँॉऽघ‫؛‬ਈৗੲਾम Web Page1 ॑ओ༮ऎटऔः‫؛‬

4. ଢ଼஢ৌ଴ َপૠெ

HPC ॳকঞথ४ُदम‫୹઀ؚ‬घॊਈপঀ‫॑ॻش‬ઞ৷घॊপૠெੑ઴॑ৰ઱घॊଢ଼஢प଒৒खऽघ‫؛‬ண੢঻఺लଢ଼஢ॢঝ‫ش‬উभওথং‫ش‬म‫ؚ‬ব৔ਗभధഔੑ઴ਃ॑ਹ৷खञপૠெੑ઴भৰౚऋँॊऒध॑৐઀धख‫ؚ‬ਰৣभ
ेअऩَHigh-Performance Computingُपঢ়৴खञ்ઁःী৙भଢ଼஢॑ৌ଴धखथःऽघ‫؛‬yyyyপૠெ३঑গঞ‫ش‬३ঙথপૠெॹ‫ॱش‬૪৶পૠெঋথॳঐ‫ش‬ॡ‫ؚ‬౰઴‫ৢ؞‬ਦ३५ॸ঒ਙચ௬੼
जभ౎‫ؚ‬পૠெੑ઴पঢ়બघॊ९ইॺक़ख़॔ৰষ

5. ਹ৷ৱત ਹ৷ৱતम‫ؚ‬ண੢છ॑੦प‫ূؚ‬਎প৾ੲਾ੦ೕ७থॱ‫ش‬५‫ش‬ঃ‫ش‬॥থআগ‫ॸش‬ॕথॢଢ଼஢৖୅भઇ૙৩‫఺ؚ‬ल‫ؚ‬ਗ৖੻৩पेॉଡਛऔोॊଟਪ੻৩ভपउःथଟਪऔोऽघ‫؛‬ਠঘ‫ش‬२‫ش‬दँॊ૑ਏमँॉऽच॒‫؛‬ ૢ൳ୖ਻म‫ؚ‬ଟਪ੻৩ভपेॉ఼උୖ਻॑৭અख‫ؚ‬दऌॊटऐசृऊपਁ਀॑ষअ੒৒दघ‫؛‬ ऩउ‫ؚ‬ண੢঻मَব৔भপ৾‫ુਁؚ‬ਃঢ়पਚരघॊଢ଼஢঻‫఺ؚ‬लড়৑੫঵पਚരघॊ঻ُधखऽघ‫؛‬ऽञ‫ؚ‬ଢ଼஢ॢঝ‫ش‬উभওথং‫ྼش‬मண੢঻ऋ੫঵भ্भৃ়म‫ؚ‬ਰৣभછథभःङोऊ॑઀লखथःञटऎ૑ਏऋँॉऽघ‫؛‬yyyَુ৊ଢ଼஢ీ৺છभ୼खُ
‫ق‬ண੢঻भਚരਃঢ়धુ৊ଢ଼஢ీ৺॑੥॒दःॊଢ଼஢ੌ௶पਚരघॊ঻‫ك‬َిજप૰୚॑ষअऒध॑੶खञ࿐৺છ఺लட଀ీ৺છभ୼खُ
‫ق‬ண੢঻भਚരਃঢ়धட଀ీ৺॑੥॒दःॊ੫঵भజ঵৩‫ك‬َਹ৷ૠ৒पँॊਹ৷৯৓॑Ꮝஹघॊऒध॑੶खञ࿐৺છُ
‫ق‬ড়৑੫঵पਚരखथःॊ঻‫ك‬1َপૠெ HPC ॳকঞথ४ُ

https://www.cc.u-tokyo.ac.jp/guide/hpc/

スーパーコンピューティングニュース- 12 -

Vol. 24, No.32022

6. ఼උ੦૆‫ؚ‬ଟਪ্১ ૢ൳ୖ਻म‫ؚ‬ਰৣभ੦૆पेॉ‫ؚ‬ূ਎প৾ੲਾ੦ೕ७থॱ‫ش‬५‫ش‬ঃ‫ش‬॥থআগ‫ॸش‬ॕথॢଢ଼஢৖୅भઇ૙৩‫ؚ‬఺ल‫ؚ‬ਗ৖੻৩ेॉଡਛऔोॊଟਪ੻৩ভपेॉ఼උୖ਻॑৭અख‫ؚ‬दऌॊटऐசृऊपਁ਀॑ষअ੒৒दघ‫؛‬  ਌ऩ఼උ੦૆
A)

ੑ઴‫؞‬੥ટभถ಍॑૛ધಉुஅीथਁ਀दऌॊऒध‫؛‬B)ੑ઴੥ટऋఐ৾৓पથ৷‫ँؚ‬ॊःम঺ভ৓ऩॖথঃॡॺऋँॊधઅइैोॊऒध‫؛‬C)઀୹घॊਈপঀ‫ॻش‬ਯभਹ৷॑৯ఏधखथःॊऒध‫؛‬D)ੑ઺पৰਠਙऋँॉ‫ؚ‬ಢ਋৑द஍ટ॑ંघऒधऋ૭ચदँॊऒध‫ق‬঳৚भઞ৷ৎ৑मਈপ 23 ৎ৑दघ‫؛ك‬E)ম३५ॸ঒भઈ৷‫ؚ‬ঘ‫ش‬२‫ش‬पधढथથ৷ऩੲਾ॑઀୹घॊऒध‫؛‬ͤ ඨ৯ A) ‫ ع‬D)म‫ؚ‬૑೼धऩॉऽघ‫؛‬ඨ৯ E)म૑೼दमँॉऽच॒ऋ‫ؚ‬ண੢છपჾਊघॊ੶஽ऋँॊৃ়‫ؚ‬ਸਡ௬੼औोॊৃ়ऋँॉऽघ‫؛‬

7. ਹ৷ண੢ ൳ૐਏඨ‫ؚ‬५‫ش‬ঃ‫ش‬॥থআগ‫شॱش‬३५ॸ঒ਹ৷ૠஙಉ॑ेऎउഭाभ঱‫ؚ‬ਹ৷ண੢છप૑ਏহඨ॑ओ੶োऎटऔ
ः‫؛‬ओ੶োຘःञਹ৷ண੢છमਰৣभ઀ল੔ऽद‫ؚ‬ਗ਼৕ও‫ش‬ঝप๣હखथउଛॉऎटऔः‫؛‬ண੢છథप૑ਏऩඨ৯मਰৣभৢॉदघ‫؛‬
1. ண੢ফা঩
2. ਹ৷ൌ஦ৎ਋
3. ண੢঻ੲਾ‫੽ق‬੡‫ؚ‬ਚര‫ؚ‬૙੡‫ؚ‬৴൪੔કਚ‫ؚ‬E-mail‫ؚ‬ਗ਼ਵ‫ك‬
4. ଢ଼஢ୖ਻੡‫ق‬ਮધ‫ؚ‬ஶધ‫ك‬‫ؚ‬໪ਏ
5. ଢ଼஢ୖ਻भ৔ઍ‫ؚ‬৯ఏ
6. ண੢঻‫ؚ‬ଢ଼஢ॢঝ‫ش‬উওথং‫ش‬भਊჾী৙पउऐॊଢ଼஢঵ౚभअठ‫ؚ‬পૠெੑ઴ਃਹ৷भৰౚधखथ৻਀৓ऩ
૛ધ 1 ౣभશླྀॉ
7. উটॢছ঒ੲਾ‫ؚ‬ਹ৷५ॣ४গ‫ش‬ঝಉ
8. ਏ஦হඨ‫੶્ؚ‬হඨ
9. ଢ଼஢ॢঝ‫ش‬উওথং‫ش‬भੲਾ

8. ਖः়ॎच੔ ਹ৷ண੢ಉओਂ৥ऩਡम‫ؚ‬ਗ਼৕ও‫ش‬ঝदउਖः়ॎचऎटऔः‫؛‬‫ق‬ਗ਼ਵदभउਖः়ॎचमओ೫ൟऎटऔः‫؛‬ऩउ‫ؚ‬ถ಍मম७থॱ‫ش‬Web Page1 दुओ੧৔खथउॉऽघभद‫ؚ‬ँॎचथओ༮ऎटऔः‫ك‬‫؛‬  ْ ண੢છ઀ল੔ ٓ
E-Mail ‫ ؟‬koubo@cc.u-tokyo.ac.jpূ਎প৾ ੲਾ३५ॸ঒৖ ੲਾਅറୖ ଢ଼஢੍ରॳ‫ش‬঒  ْ ਖः়ॎच੔ ٓ
E-Mail ‫؟‬uketsuke@cc.u-tokyo.ac.jpূ਎প৾ ੲਾ३५ॸ঒৖ ੲਾਅറୖ ଢ଼஢੍ରॳ‫ش‬঒

スーパーコンピューティングニュース- 13 -

Vol. 24, No.3

2022

スーパーコンピュータシステム「大規模 HPC チャレンジ」採択課題のお知らせ
1. はじめに Wisteria/BDEC-01、Oakbridge-CX では「大規模 HPC チャレンジ」を実施しています。
「大規模 HPC チャレンジ」は、スーパーコンピュータシステムがもつ最大規模のノード数を、最大 24 時間・1 研究グループで計算資源の専有利用ができる公募型プロジェクトです1。
 課題審査委員会による厳正な審査の結果、以下の課題を採択しましたのでお知らせいたします。

2. 採択課題
システム：Oakbridge-CX
 募集期間：2022 年度 第 1 回募集 2022 年 2 月 2 日～2 月 28 日
 1 件の応募があり、以下の課題を採択しました。
 採択課題一覧
課題名

前処理付き並列反復法における通信と計算のオーバーラップ

代表者名（所属） 中島 研吾（東京大学情報基盤センター）
クリロフ部分空間法による前処理付き反復法は広範な科学技術アプリケーションに使用されている。超並列環境下では，内積おける集団通信，行列ベクトル積等における一対一通信によるオーバヘッドが顕著となる。提案者は，特に一対一通信に着目し，三次元静的弾性問題（構造力学）を有限要素法で解く場合に得られる対称正定な大規模疎行列を共役勾配法（CG 法）で解く場合について，通信と計算をオーバーラ
ップさせ，更に OpenMP の動的スケジューリング機能により，通信オーバーヘッドを削減する手法に関する研究を実施してきた。本研究課題では，ICCG 法等データ依存性を有する処理において，通信と計算を効果的にオーバーラップさせるための手法を提案し，Oakbridge-CX 1,024 ノードを使用して効果を検証する。本研究課題で使用する GeoFEM/ICCG は，構造力学における三次元静的弾性問題を対象とした，有限要素法に基づくプログラムであり，導出された連立一次方程式を前処理付き反復法（ICCG 法）によって解く。

1「大規模 HPC チャレンジ」

https://www.cc.u-tokyo.ac.jp/guide/hpc/

スーパーコンピューティングニュース- 14 -

Vol. 24, No.3

2022

2022 年度 前期
東京大学情報基盤センター「若手・女性利用者推薦」採択課題
スーパーコンピューティングチーム
東京大学情報基盤センター（以下、センター）では、若手研究者（2022 年 4 月 1 日時点において 40 歳以下、学生を含む）及び女性研究者（年齢は問わない）による、スーパーコンピュータ、
データプラットフォームなどの大型計算資源を使用した研究を対象とした公募型プロジェクトを実施しています。センターの教員による審査の上、年間で数十件の優れた研究提案課題を採択する予定です。採択された課題では申請した計算資源を無料で使用することができます。
本制度では、前期と後期に一年または半年単位（後期は半年のみ）で実施する一名で行う研究課題を募集します。
採 択 さ れ た 課 題 の う ち 、特 に 優 れ た 課 題 で「 学 際 大 規 模 情 報 基 盤 共 同 利 用・共 同 研 究 拠 点（JHPCN）」の萌芽型共同研究課題の条件を満たすものについては、本センターより同拠点萌芽型共同研究課題として推薦する予定です。同拠点共同研究課題審査委員会で審査の上、JHPCNの萌芽型共同研究課題としても採択された場合、毎年 7 月に開催される JHPCN のシンポジウムにて発表の機会が与えられる場合があります。本制度に採択された課題は終了後、得られた成果をもとに、「学際大規模情報基盤共同利用・共同研究拠点（JHPCN）」の公募型共同研究（一
般課題、国際課題、企業課題）等へと進展することが大いに期待されます。
このたび、以下の基準による厳正な審査のうえ、2022 年度前期は 12 件の課題を採択いたしま
した。

•

本制度が提供する計算機システムを利用することで、学術的にインパクトがある成果を創出できると期待される提案を積極的に採択します。

• スーパーコンピュータの利用環境の改善に寄与すると期待されるソフトウェア開発に関する提案を歓迎します。

• 現状の環境にとどまらず、将来の先端的なスーパーコンピュータ環境を目指した提案は特に歓迎します。

• 特に、mdx については、理工系・人文系にまたがる多様なデータの収集・整備、研究コ
ミュニティにおけるデータの共有やプラットフォームの整備、そして機械学習等の先端的なデータサイエンス手法を用いたデータ解析など、多様なデータ科学・データ利活用
研究を歓迎します。

本制度の詳細は、以下の HP をご覧ください。

https://www.cc.u-tokyo.ac.jp/guide/young/

スーパーコンピューティングニュース- 15 -

Vol. 24, No.3

2022

■ 2022 年度 前期 採択課題
課題名

濡れた粉体の変形・流動特性の理解

代表者名（所属）吉井 究（大阪大学 基礎工学研究科）

利用システム名

Oakbridge-CX

実施期間

一年

粉や砂のような巨視的なサイズの粒子の集合体である粉体は、粒子の密度が閾値より高いと、剛性を有し固体的に振る舞う一方、その閾値より低い場合は剛性を示さず流体的に振る舞う。この力学的特性の変化はジャミング転移と呼ばれ、近年盛んに研究されている。特に、粒子間に接触による反発相互作用だけが働く乾いた粉体系の転移点近傍の振る舞いについては、多くのことが明らかになっている。ところが、現実の粉体は濡れを伴う場合が多く、そのような系で乾いた粉体の挙動がそのまま観測されるかは不明である。実際、粉体は少量の水を加えるだけで、応力ひずみ曲線などのレオロジー特性が大きく変化することが知られている。これは粒子間に入り込んだ液体が表面張力によって架橋を形成し、実行的な引力相互作用を与えることに起因する。しかし、従来の濡れた粉体の研究では、個別の視点に立脚した研究は行われているが、理論的な理解や濡れの影響を系統的に調べた研究はほとんど無く、十分な理解に至っていない。そこで本研究
では、濡れた粉体系の大変形や流動状態に着目し、離散要素法を用いたシミュレーションを行い、乾いた粉体系との違いを明らかにする。

課題名

t6A 修飾を含むリボソーム翻訳開始複合体における開始コドン認識動態の
分子動力学計算による解析

代表者名（所属）亀田 健（立命館大学 生命科学部）

利用システム名

mdx

実施期間

一年

申請者は、真核生物のリボソーム翻訳開始複合体における、翻訳開始コドン認識をとりまく分子動態の解明を行っている。これまでに、適切な翻訳開始コドン以外のミスマッチコドンや、修飾
コドンなどを対象としてきた。本課題では、それらのミスマッチコドンや修飾コドンの翻訳開始を制御すると考えられている、アンチコドンの隣に位置する塩基に t6A 修飾が入った tRNA を含む、リボソーム翻訳開始複合体の動態に着目する。t6A は生体内での存在と疾患との関連可能性は調べられているものの、リボソーム内での動態や相互作用を含む、翻訳開始制御機構への具体的な作用メカニズムは不明である。本研究課題で行う分子動力学計算を用いた研究により、その作用メカニズムを考察するとともに、医薬研究の基盤技術へと発展させていくことを目指す。

スーパーコンピューティングニュース- 16 -

Vol. 24, No.3

2022

課題名

擬スペクトル MHD コードで狙う磁気回転乱流における慣性領域の解像

代表者名（所属）

川面 洋平（東北大学 学際科学フロンティア研究所）

利用システム名

Oakbridge-CX, Wisteria/BDEC-01 Odyssey

実施期間

一年

ブラックホールは降着円盤と呼ばれるプラズマの乱流に取り囲まれている。この乱流は磁気回転不安定性 (MRI) によって駆動されている。MRI 乱流の直接数値シミュレーションは膨大な数が行われてきたが数値解像度が不十分であり、乱流の特性を捉えるに至っていない。そこで本研究では、我々が新しく開発した擬スペクトル法コードを用いて降着乱流の特性に迫る。このコードはこれまで用いられてきたコードに比べ、飛躍的に MRI 乱流の解像度を上げることができる。
本課題では具体的に、これまで解像することができていなかった慣性領域に迫る。慣性領域の情報を得ることができれば、Event Horizon Telescope によるブラックホールシャドー観測の物理的解釈に必要となる理論モデルを高精度化することに繋がる。

課題名

着陸探査プローブのクラッシャブル材とレゴリスの衝突・干渉作用に関する数値解析

代表者名（所属）

徳永 賢太郎（東京大学 工学系研究科）

利用システム名

Wisteria/BDEC-01 Odyssey

実施期間

一年

近年重力天体への着陸探査において、着陸時に必要な逆噴射装置やパラシュートといった減速装置を用いる代わりに、発泡金属やプラスチック発泡体といった、クラッシャブルなポーラス材料
を着陸機構の一部に使用し着陸時のエネルギーを吸収する技術が着目されている。天体の微小重力や真空環境を地上で完全に模擬できないことも踏まえ、ミッションに用いる着陸機構の最適設計のためには、数値解析モデルを構築し各種パラメータが着陸機構に与える影響を評価する必要がある。本課題は、圧縮変形しながらエネルギーを吸収するポーラス材料とレゴリス（粒状体）との衝突・干渉による相互作用を DEM（Discrete Element Method）により数値モデル化し、ポーラス材料の各種パラメータが着陸メカニズムに与える影響を調査するものである。

スーパーコンピューティングニュース- 17 -

Vol. 24, No.3

2022

課題名

磁気ノズルスラスタにおける中性粒子流れとエネルギー輸送の数値解析

代表者名（所属）

江本 一磨（横浜国立大学 理工学府）

利用システム名

Oakbridge-CX, Wisteria/BDEC-01 Odyssey

実施期間

一年

宇宙機の主推進として利用されることが期待される磁気ノズルスラスタを研究対象とし、particle-

in cell / Monte Carlo collisions / direct simulation Monte Carlo (PIC-MCC-DSMC) コード
を用いて、スラスタ内部の中性粒子流れとエネルギー輸送を明らかにすることを目的とする。

PIC-MCC-DSMC コードは Boltzmann 方程式で構成されるプラズマと中性粒子を確率的に解く手法であり、磁気ノズルスラスタなどの低温プラズマの解析を行う上で強力な手法として知られている。PIC-MCC-DSMC コードを用いることで磁気ノズルスラスタ内部のプラズマ・中性粒
子流れを再現し、実験では測定することが困難な中性粒子とエネルギーの輸送現象を解明することが期待される。また、中性粒子とエネルギーの損失過程を理解することで、磁気ノズルスラス
タの性能向上を目指す上で必要な指針を得ることができる。

課題名

次世代銀河分光観測に向けたフィールドレベル解析の確立

代表者名（所属）

大里 健（京都大学 基礎物理学研究所）

利用システム名

Wisteria/BDEC-01 Aquarius

実施期間

一年

宇宙物理学における根源的な問題であるダークマター・ダークエネルギーの正体、そして加速膨張の物理的な機構を探るため、大規模な銀河分光観測計画が予定されている。これらの計画では、銀河の三次元位置を測定し背景にある物質分布を描き出すことが主たる観測目的である。従来の解析では、観測された銀河分布から、その情報を要約する統計量を用いてダークマターの存在量に代表される宇宙論パラメータを推定する。しかしながら、統計量は銀河分布の持つ情報の一部しか取り入れられず、統計量で表現できない高次の情報は失われてしまう。そこで、本研究では観測された銀河分布の場が持つ情報の全てを考慮するフィールドレベル解析に着目し、高速で実用的な統計解析基盤を構築する。近年開発された物質密度場の重力進化理論モデル GridSPT を基礎に GPU による高速化を実装することで、ダークマター・ダークエネルギーのモデル決定に最大限迫ることを目標とする。

スーパーコンピューティングニュース- 18 -

Vol. 24, No.3

2022

課題名

階層性が内在するガラスのエネルギー地形における低周波数振動の緩和予言能の起源

代表者名（所属）白石薫平（東京大学 大学院総合文化研究科）

利用システム名

Oakbridge-CX

実施期間

一年

液体を急冷すると生じるガラスは、複雑なエネルギー地形を持つ。構成粒子がダイマーという「形」を持った粒子のとき、過冷却液体は alpha 緩和と Johari-Goldstein beta 緩和という 2 種類の緩和過程を持つ。この緩和過程の分離は、エネルギー地形からはベイスンとメタベイスンという階層構造の現れとして解釈できる。ベイスンにおける低周波数振動は結晶とは異なる性質を示
し、振動粒子は熱緩和の発生位置と相関する。ダイマー系での階層的エネルギー地形という理解を踏まえると、緩和と振動の相関は非自明であり、その起源も明らかではない。本研究では、ダイマー系の大規模分子動力学シミュレーションにより、振動状態の特徴付けと緩和予言能の起源の解明を行う。レプリカ交換法を用いて広範な温度領域の平衡液体配置を生成し、振動特性の温度依存性を調べる。そして、各ベイスンにおけるモード・モード相関という新規な量を導入し、緩和予言能を生み出すエネルギー地形的な起源を明らかにする。

課題名

Constructing deep learning models of biological ﬁtness landscapes fromsequencing data

代表者名（所属）

Adam Beattie（東京大学 理学系研究科）

利用システム名

Wisteria/BDEC-01 Aquarius

実施期間

一年

Deep learning has made breakthroughs in biology but requires substantial training data.
With a novel high throughput system, over 10ˆ12 peptides can be screened for activity withpost translational modiﬁcation enzymes. We will use the sequencing data output to train
substrate ﬁtness landscape models. We will test our method on a biosynthetic enzyme, thenbuild a general platform for modelling ﬁtness landscapes for the study of uncharacterised
enzymes and the design of selective therapeutics.

スーパーコンピューティングニュース- 19 -

Vol. 24, No.3

2022

課題名

波形インバージョンによる南大西洋下のマントル最下部領域の地震波異方性構造推定

代表者名（所属）

大鶴 啓介（東京大学 理学系研究科）

利用システム名

Oakbridge-CX

実施期間

一年

地球マントルの最下部数百 km の領域は核-マントル境界（CMB）直上の熱境界層をなしており、外核による加熱を受けて上昇流を発生させることでマントル対流を駆動している。これまでに行われた地震波による構造推定からは、アフリカ下と太平洋下の 2 箇所に巨大な S 波低速度域（LLSVP）が存在することが知られており、これが高温の上昇流に対応するとされている。しかし、最下部マントルでの物質の詳しい流動様式が解明されていないためにこの LLSVP の成因や性質についてもよくわかっていない。そこで本課題では、地震波形に含まれる情報を余すことなく活用することで詳細な構造推定を可能にする波形インバージョン手法と、スペクトル要素法により理論波形を計算するソフトを使用して、アフリカ LLSVP の西側境界域にあたる南大西洋下のマントル最下部の地震波異方性構造を推定する。そしてその結果から、マントル最下部での物質の流動に関する制約を得ることを目指す。

課題名

地震波形インバージョンによるマントル最下部の S・P 波速度構造同時推定̶地球深部の熱・化学進化の理解に向けて̶

代表者名（所属）佐藤 嶺（東京大学 理学系研究科）

利用システム名

Oakbridge-CX

実施期間

一年

地球の核-マントル境界 (CMB) は、固体岩石のマントルと液体鉄合金の外核が接する地球内部の最も主要な熱・化学組成境界であるため、CMB 直上数 100km(D″領域) は地球の熱・化学進化の理解に重要な領域である。D″領域では地温勾配とマントル組成のソリダスが近いために部分溶融に伴う化学分化を起こすマグマが定常的に発生する可能性が高く、また典型的な沈み込み領域下においては海洋プレートの沈み込みに伴う化学組成不均質が形成されると考えられている。
従って観測情報から化学組成異常のサイズと度合いを制約することが重要である。しかし、地震波速度不均質を温度・化学組成効果に定量的に分離するには S・P 波速度構造を同程度の解像度で同時に推定する必要があったが、データセットの質や種類が異なる等課題があった。また正確な理論地震波形の計算も必要であるが、短周期までの計算は計算資源の問題から困難であった。
本申請研究では地震波形に含まれる情報を余すことなく活用できる波形インバージョン手法と、スペクトル要素法による理論地震波形計算ソフトウェア SPECFEM3D GLOBE を用いて D″
領域の S・P 波速度構造を同時推定する。

スーパーコンピューティングニュース- 20 -

Vol. 24, No.3

2022

課題名

臨界レイノルズ数付近における矩形ダクト乱流中の二次流れと熱的制御

代表者名（所属）関本 敦（岡山大学 学術研究院）

利用システム名

Wisteria/BDEC-01 Odyssey

実施期間

一年

矩形ダクトなどの角を有する乱流中は、角へと向かう主流に垂直方向の平均二次流れが生じる。
この二次流れによって、主流の平均的な分布だけでなく乱流熱伝達率に影響を及ぼすことが知られている。 臨界レイノルズ数付近では、乱流渦と管路幅が同程度のスケールになるため、乱流渦の出現位置が側壁によって拘束される。さらに、壁面加熱して、浮力効果を加えることで、乱流渦の挙動をある程度コントロールできると考えられる。 本研究では、矩形ダクト乱流の直接数値
シミュレーションを行い、浮力効果が乱流効果と同程度となるような浮力パラメターにおいて、二次流れの安定化効果や乱流パフへの影響を調べ、壁面加熱による乱流制御の新たな指針へとつ
なげる。

課題名

Inversion modeling of aquifer deformation for permeability estimation
using Automatic Diﬀerential and adjoint methods

代表者名（所属）

張 毅（地球環境産業技術研究機構）

利用システム名

Oakbridge-CX, Wisteria/BDEC-01 Aquarius

実施期間

一年

Recently, distributed ﬁber-optic strain sensing tool has been successfully deployed for theacquisition of aquifer strain along the optical ﬁber-installed well. To estimate aquifer permeability using the strain array data, inversely solving the coupled ﬂuid ﬂow and mechanical(poroelastic) equations is required. In this study, we aim to develop an Automatic Diﬀerential(AD) and adjoint state combination method to accelerate the Jacobian matrix calculationand the inverse modeling以上

スーパーコンピューティングニュース- 21 -

Vol. 24, No.3

2022

スーパーコンピューティングニュース- 22 -

Vol. 24, No.3

2022

7%

3%

⣙൨෇

୺࣓࣮ࣔࣜࢧ࢖ࢬィࢹ࢕ࢫࢡᐜ㔞

ᖺᗘ
ᖺ㛫೉ᩱ

1(&/;5]
7)/2367%35,0(5*<&;035,0(5*<&;
0 3)/2367%⣙൨෇

3%

7%

3)/236

1(&6;$XURUD768%$6$
3)/2367%35,0(5*<&;
035,0(5*<&;
0 3)/2367%

3)/236

ᮾ໭኱Ꮫ

໭ᾏ㐨኱Ꮫ

⥲⌮ㄽ₇⟬ᛶ⬟㸦⌮ㄽ₇⟬ᛶ⬟㸪࣓࣮ࣔࣜࢧ࢖ࢬ㸧୰ኸฎ⌮⿦⨨

኱Ꮫྡ⣙൨෇

3%

7L%

3)/236)8-,768:LVWHULD%'(&$TXDULXV:LVWHULD$3)/2367L%)8-,768:LVWHULD%'(&2G\VVH\:LVWHULD2
3)/2367L%)8-,768
2DNEULGJH&;3)/2367L%ᮾி኱Ꮫ⣙൨෇

3%

7L%

3)/236+3(
3UR/LDQW'/7)/2367L%+3(
6XSHUGRPH)OH[7)/2367L%)8-,768&;03)/2367L%)8-,768);
3)/2367L%ྡྂᒇ኱Ꮫ䠓኱Ꮫ䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍ẚ㍑⾲

⣙൨෇

3%7%

3)/236&UD\&6;7)/2367%㸧

&UD\&6;7
3)/2367%&5$<;&3)/2367%ி㒔኱Ꮫ⣙൨෇

3%

7%

3)/236

1(&
648,'
㸦7)/2367%㸧

1(&
2&723867)/2367%኱㜰኱Ꮫ⣙൨෇

3%

7%3)/236,72኱ᐜ㔞ࣇࣟࣥࢺ࢚ࣥࢻ
7)/2367%,72
ᇶᮏࣇࣟࣥࢺ࢚ࣥࢻ
3)/2367%,72
ࢧࣈࢩࢫࢸ࣒%3)/2367%,72ࢧࣈࢩࢫࢸ࣒$3)/2367%஑ᕞ኱Ꮫ㻞㻜㻞㻞ᖺ㻠᭶⌧ᅾスーパーコンピューティングニュース- 23 -

Vol. 24, No.3

2022

ฟຊ

ഛ⪃

ࢡࣛ࢘ࢻࢩࢫࢸ࣒

᭶㢠෇
ᖺ㢠෇
᭶㢠෇
ᖺ㢠෇
᭶㢠෇
ᖺ㢠෇
᭶㢠෇
ᖺ㢠෇

᭶㢠෇
ᖺ㢠෇
᭶㢠෇
ᖺ㢠෇ ᇶᮏࢧ࣮ࣅࢫ࡟ಀࡿ⤒㈝ࡢ㈇ᢸ࡟࠾࠸࡚㸪Ꮫ⏕ࡢ㐺⏝࡜࡞ࡿࡶࡢࡣᏛᰯᩍ⫱ἲ࡟࠾ࡅࡿࠕᏛ⏕ࠖ࡜ࡋ㸪ࠕᏛ⏕ドࠖ෗ࡋࡢᥦฟࢆ
ࡶࡗ࡚㐺⏝࡜ࡍࡿࠋࡑࡢ௚ࡢ㐺⏝࡟ࡘ࠸࡚ࡣ㸪ࢭࣥࢱ࣮㛗ࡀ≉࡟ㄆࡵࡓࡶࡢ࡜ࡍࡿࠋ ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࡢඹ⏝ࣀ࣮ࢻ฼⏝࡟࠾࠸࡚㸪₇⟬᫬㛫ࡢ⟬ฟ᪉ἲࡣ฼⏝ࣀ࣮ࢻᩘ࡟⤒㐣᫬㛫㸦⛊㸧ࢆ஌ࡌ࡚ィ⟬ࡍࡿࡶࡢ࡜
ࡍࡿࠋࢡࣛ࢘ࢻࢧ࣮ࣅࢫ
㸯㸧ࢡࣛ࢘ࢻࢫࢺ࣮ࣞࢪ

᭶㢠෇
ᖺ㢠෇
ࢡࣛ࢘ࢻࢫࢺ࣮ࣞࢪ฼⏝࡟࠾࠸࡚㸯㹒㹀࡟ࡘࡁ
᭶㢠ࠉ෇
㸦࠸ࡎࢀࡶᖺᗘෆ฼⏝࡟㝈ࡿ㸧ᖺ㢠ࠉ෇
኱ุ࣮࢝ࣛࣉࣜࣥࢱ฼⏝࡟࠾࠸࡚
ᬑ㏻⣬㸯ᯛ࡟ࡘࡁ
ࠉ෇
ගἑ⣬㸯ᯛ࡟ࡘࡁ
ࠉ෇
ࢡࣟࢫ㸯ᯛ࡟ࡘࡁ
ࠉ෇ ୍⯡฼⏝ࢥ࣮ࢫ࡟࠾࠸࡚฼⏝࡛ࡁࡿ኱ᆺィ⟬ᶵࢩࢫࢸ࣒ࡣ㸪ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ㸪࢔ࣉࣜࢣ࣮ࢩࣙࣥࢧ࣮ࣂ㸪ࢫࣃࢥࣥࢫࢺ࣮ࣞ
ࢪ㸪ࢡࣛ࢘ࢻࢧ࣮ࣂ㸦௬᝿ࢧ࣮ࣂ㸪≀⌮ࢧ࣮ࣂ㸪㹅㹎㹓ࢧ࣮ࣂཬࡧ⛣⾜⏝ࢧ࣮ࣂ㸧㸪ࢡࣛ࢘ࢻࢫࢺ࣮ࣞࢪཬࡧ኱ุࣉࣜࣥࢱ࡜ࡍ
ࡿࠋ ᇶᮏࢧ࣮ࣅࢫ࡟࠾࠸࡚ࡣ㸪௨ୗࡢࢧ࣮ࣅࢫࢆ฼⏝ࡍࡿࡇ࡜ࡀ࡛ࡁࡿࠋ
ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢧ࣮ࣅࢫ
㸯㸧ヨ⏝࣭ࢹࣂࢵࢢ⏝ࡢඹ⏝ࣀ࣮ࢻࡢ฼⏝㸰㸧࢔ࣉࣜࢣ࣮ࢩࣙࣥࢧ࣮ࣂࡢ฼⏝㸱㸧KRPH㡿ᇦ㸦ࢫࣃࢥࣥࢫࢺ࣮ࣞࢪ㸧㹑ࢧ࣮ࣂ㸪㹋ࢧ࣮ࣂ㸪㹊ࢧ࣮ࣂ㏣ຍࢫࢺ࣮ࣞࢪ㸯㹒㹀࡟ࡘࡁ㹊ࢧ࣮ࣂ㸯ྎ࡟ࡘࡁ㹋ࢧ࣮ࣂ㸯ྎ࡟ࡘࡁ㹑ࢧ࣮ࣂ㸯ྎ࡟ࡘࡁ⛣⾜⏝ࢧ࣮ࣂ฼⏝࡟࠾࠸࡚࣍ࢫࢸ࢕ࣥࢢࢧ࣮ࣂ

㸲ᣐⅬ㸯༢఩࡟ࡘࡁ

࢖ࣥࢱ࣮ࢡࣛ࢘ࢻࣃࢵࢣ࣮ࢪ฼⏝࡟࠾࠸࡚㸱ᣐⅬ㸯༢఩࡟ࡘࡁ

㏣ຍࢫࢺ࣮ࣞࢪ㸯㹒㹀࡟ࡘࡁ㹅㹎㹓ࢧ࣮ࣂ㸯ྎ࡟ࡘࡁ᭶㢠෇
ᖺ㢠෇
᭶㢠෇
ᖺ㢠෇
᭶㢠෇
ᖺ㢠෇
᭶㢠෇
ᖺ㢠෇

ᖺ㢠෇
ᖺ㢠෇

㸦࠸ࡎࢀࡶᖺᗘෆ฼⏝࡟㝈ࡿ㸧ࢡࣛ࢘ࢻࢧ࣮ࣂ฼⏝࡟࠾࠸࡚௬᝿ࢧ࣮ࣂ㸯༢఩࡟ࡘࡁ
㸦ࡓࡔࡋ㸪᭱ᑠ㸰༢఩࡜ࡍࡿ㸧≀⌮ࢧ࣮ࣂ㸯ྎ࡟ࡘࡁᖺ㢠෇

ᖺ㢠෇

ᖺ㢠෇
ᖺ㢠෇
ᖺ㢠෇
ᖺ㢠෇

᪋⾜㸦㐠⏝㸧
ᖺ᭶᪥ͤ ᮏࢥ࣮ࢫࡢ௚㸪Ẹ㛫௻ᴗ➼฼⏝ࢥ࣮ࢫࡀ࠶ࡿࠋ

 ࢖ࣥࢱ࣮ࢡࣛ࢘ࢻࣃࢵࢣ࣮ࢪ࡟࠾ࡅࡿ≀⌮ࢧ࣮ࣂ࡜ᣐⅬ࡟ࡘ࠸࡚ࡣ௨ୗࡢ࡜࠾ࡾ࡛࠶ࡿࠋ
㸯㸧㸱ᣐⅬ㸸໭ᾏ㐨኱Ꮫ㸪ᮾி኱Ꮫ㸪኱㜰኱Ꮫ࡟࠾࠸࡚ྛ㸯ࢧ࣮ࣂ㸰㸧㸲ᣐⅬ㸸໭ᾏ㐨኱Ꮫ㸪ᮾி኱Ꮫ㸪኱㜰኱Ꮫ㸪஑ᕞ኱Ꮫ࡟࠾࠸࡚ྛ㸯ࢧ࣮ࣂ ࢖ࣥࢱ࣮ࢡࣛ࢘ࢻࣃࢵࢣ࣮ࢪ࡟ࡘ࠸࡚ࡣ㸪୍⯡㈈ᅋἲே㧗ᗘ᝟ሗ⛉Ꮫᢏ⾡◊✲ᶵᵓ 5,67 ࡀබເࡍࡿ+3&,ࢩࢫࢸ࣒ඹ⏝ィ⟬㈨※ࡢ฼⏝◊✲ㄢ㢟ཬࡧᏛᰯᩍ⫱ἲ᪋⾜つ๎࡟ᇶ࡙ࡁㄆᐃࡉࢀࡓᏛ㝿኱つᶍ᝟ሗᇶ┙ඹྠ฼⏝࣭ඹྠ◊✲ᣐⅬ -+3&1 ࡀබເࡍࡿඹྠ◊✲ㄢ㢟ࡢ᥇ᢥ⪅࡟㝈ࡗ࡚฼⏝ࡍࡿࡶࡢ࡜ࡍࡿࠋࡓࡔࡋ㸪ࢭࣥࢱ࣮㛗ࡀ㐺ᙜ࡜ㄆࡵࡓ࡜ࡁࡣ㸪᥇ᢥ⪅௨እࡶࡑࡢ฼⏝ࢆጉࡆ࡞࠸㝈ᗘ࡟࠾࠸࡚฼⏝ࡍࡿࡇ࡜ࡀ࡛ࡁࡿࠋ ⛣⾜⏝ࢧ࣮ࣂ࡟࠾ࡅࡿࢧ࣮ࣂᵓᡂࡣ௨ୗࡢ࡜࠾ࡾ࡛࠶ࡿࠋ
㸯㸧࣍ࢫࢸ࢕ࣥࢢࢧ࣮ࣂ㸯ྎ࠶ࡓࡾࠉࠉࢥ࢔ᩘ㸯㸦㹆㸿ᶵ⬟㸧㸪࣓ࣔࣜ㸱㹅㹀㸪ࢫࢺ࣮ࣞࢪ㸯㸮㸮㹅㹀㸰㸧㹑ࢧ࣮ࣂ㸯ྎ࠶ࡓࡾࠉࠉࢥ࢔ᩘ㸯㸪࣓ࣔࣜ㸱㹅㹀㸪ࢫࢺ࣮ࣞࢪ㸯㸮㸮㹅㹀㸱㸧㹋ࢧ࣮ࣂ㸯ྎ࠶ࡓࡾࠉࠉࢥ࢔ᩘ㸲㸪࣓ࣔࣜ㸯㸰㹅㹀㸪ࢫࢺ࣮ࣞࢪ㸯㸮㸮㹅㹀㸲㸧㹊ࢧ࣮ࣂ㸯ྎ࠶ࡓࡾࠉࠉࢥ࢔ᩘ㸯㸮㸪࣓ࣔࣜ㸱㸮㹅㹀㸪ࢫࢺ࣮ࣞࢪ㸯㸮㸮㹅㹀ᖺ㢠෇
ᖺ㢠෇
ᖺ㢠෇
ᖺ㢠෇ ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩࢫࢸ࣒ࡢ௜ຍࢧ࣮ࣅࢫ㸦༨᭷ࣀ࣮ࢻ➼㸧ࡣ㸪◊✲ࢢ࣮ࣝࣉ࡛ࡢඹྠ฼⏝ࡀ࡛ࡁࡿࡶࡢ࡜ࡍࡿࠋ◊✲ࢢ࣮ࣝࣉࡢᵓᡂ࣓ࣥࣂ࣮ࡣ㸪኱ᆺィ⟬ᶵࢩࢫࢸ࣒ࡢ฼⏝⪅ࡢ୰࠿ࡽ㸪௜ຍࢧ࣮ࣅࢫࡢ⏦ㄳ⪅ࡀᣦᐃࡍࡿࠋ ࢡࣛ࢘ࢻࢧ࣮ࣂ࡟࠾ࡅࡿࢧ࣮ࣂᵓᡂࡣ௨ୗࡢ࡜࠾ࡾ࡛࠶ࡿࠋ
㸯㸧௬᝿ࢧ࣮ࣂ㸯༢఩࠶ࡓࡾ
ࠉࠉࢥ࢔ᩘ㸯㸪࣓ࣔࣜ㸴㹅㹀㸪ࢫࢺ࣮ࣞࢪ㸳㸮㹅㹀㸰㸧≀⌮ࢧ࣮ࣂ㸯ྎ࠶ࡓࡾࠉࠉࢥ࢔ᩘ㸲㸮㸪࣓ࣔࣜ㸰㸳㸴㹅㹀㸪ࢫࢺ࣮ࣞࢪ㸰㹒㹀㸱㸧㹅㹎㹓ࢧ࣮ࣂྎ࠶ࡓࡾ
ࠉࠉࢥ࢔ᩘ㸲㸮㸪࣓ࣔࣜ㸰㸳㸴㹅㹀㸪ࢫࢺ࣮ࣞࢪ㸰㹒㹀㸪㹅㹎㹓㸰ᇶ㸦7HVOD9㸧ᖺ㢠෇

໭ᾏ㐨኱Ꮫࡘ࡙ࡁ ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࡢ༨᭷ࣀ࣮ࢻ฼⏝ࡣ㸪⏦ㄳᚋࡢᢎㄆ᪥࠿ࡽᖺᗘᮎࡲ࡛ࡢ฼⏝࡜ࡍࡿࠋࡲࡓ㸪ᢎㄆ᪥࡟ᛂࡌ࡚ḟࡢ࡜࠾ࡾࡢ฼⏝㈇ᢸ㔠࡜ࡍࡿࠋ
㸯㸧㸵᭶㹼㸷᭶ࡢሙྜ㸪฼⏝㈇ᢸ㔠㢠ࡢ㸵㸳㸣࡜ࡍࡿࠋ㸰㸧㸯㸮᭶㹼㸯㸰᭶ࡢሙྜ㸪฼⏝㈇ᢸ㔠㢠ࡢ㸳㸮㸣࡜ࡍࡿࠋ㸱㸧⩣ᖺ㸯᭶㹼㸱᭶ࡢሙྜ㸪฼⏝㈇ᢸ㔠㢠ࡢ㸰㸳㸣࡜ࡍࡿࠋᖺ㢠෇

ᖺ᭶⌧ᅾ㸵኱Ꮫࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ฼⏝㈇ᢸ㔠⾲㸯㸦໭ᾏ㐨኱Ꮫ㸧ࢫࣃࢥࣥࢫࢺ࣮ࣞࢪ
KRPH㡿ᇦ㸯㹒㹀࡟ࡘࡁ
ZRUN㡿ᇦ㸱㹒㹀࡟ࡘࡁ໭ᾏ㐨኱Ꮫ༨᭷ࣀ࣮ࢻ㸦₇⟬࠾ࡼࡧࢫࣃࢥࣥࢫࢺ࣮ࣞࢪ㸧ࢧࣈࢩࢫࢸ࣒㸿㸯ࣀ࣮ࢻ㸦㸱㹒㹀ࡢZRUN㡿ᇦࢆྵࡴ㸧࡟ࡘࡁࢧࣈࢩࢫࢸ࣒㹀㸯ࣀ࣮ࢻ㸦㸱㹒㹀ࡢZRUN㡿ᇦࢆྵࡴ㸧࡟ࡘࡁࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ
୰ኸฎ⌮⿦⨨
35,0(5*<&;035,0(5*<&;0 7%35,0(5*<&;035,0(5*<&;0 7%࣓࣮ࣔࣜࢧ࢖ࢬ
࢖ࣥࢱ࣮ࢡࣛ࢘ࢻ
35,0(5*<&;&;0㸦*%㸧
35,0(5*<&;&;0㸦*%㸧
35,0(5*<0㸦*%㸧኱ᆺィ⟬ᶵࢩࢫࢸ࣒฼⏝⏦ㄳ᫬ࡢ฼⏝⪅Ⓩ㘓࡟࠾࠸࡚ᇶᮏࢧ࣮ࣅࢫ
㸯௳࡟ࡘࡁࡓࡔࡋࠊᏛ⏕࡟࠾࠸࡚㸯௳࡟ࡘࡁ௜ ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗ ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ฼⏝࡟ࡼࡿࣂࢵࢳฎ⌮࡟࠾࠸࡚ຍ ࢱࢩࢫࢸ࣒
ࢧඹ⏝ࣀ࣮ࢻ㸦₇⟬㸧勖ࢧࣈࢩࢫࢸ࣒㸿ࣅ$ࢥ࣮ࢫ㸸₇⟬᫬㛫⛊ࡲ࡛ࢫ$ࢥ࣮ࢫ㸸₇⟬᫬㛫⛊ࡲ࡛$ࢥ࣮ࢫ㸸₇⟬᫬㛫⛊ࡲ࡛$ࢥ࣮ࢫ㸸₇⟬᫬㛫⛊ࡲ࡛ࢧࣈࢩࢫࢸ࣒㹀%ࢥ࣮ࢫ㸸₇⟬᫬㛫⛊ࡲ࡛%ࢥ࣮ࢫ㸸₇⟬᫬㛫⛊ࡲ࡛%ࢥ࣮ࢫ㸸₇⟬᫬㛫⛊ࡲ࡛%ࢥ࣮ࢫ㸸₇⟬᫬㛫⛊ࡲ࡛኱Ꮫྡスーパーコンピューティングニュース- 24 -

Vol. 24, No.3

2022

ฟຊ㈇ᢸ⤒㈝

ࣇ࢓࢖ࣝ
㈇ᢸ⤒㈝

୪ิ
ࢥࣥࣆ࣮ࣗࢱ

ࢡࣟࢫᯛ࡟ࡘࡁ

ࣇ࢓࢖ࣝ
㈇ᢸ⤒㈝
ࢡࣟࢫᯛ࡟ࡘࡁ

༨᭷฼⏝ࣀ࣮ࢻᩘࠉ฼⏝ᮇ㛫ࣨ᭶࡟ࡘࡁ
ඹ᭷
7%ࡲ࡛↓ᩱࠊ㏣ຍᐜ㔞7%࡟ࡘࡁᖺ㢠༨᭷
7%ࡲ࡛↓ᩱࠊ㏣ຍᐜ㔞7%࡟ࡘࡁᖺ㢠኱ุࣉࣜࣥࢱ࣮࢝ࣛࣉࣜࣥࢺࠉࣇ࢛ࢺගἑ⏝⣬ᯛ࡟ࡘࡁ

₇
⟬
㈇
ᢸ
⤒
㈝

᪋⾜㸦㐠⏝㸧
ᖺ᭶᪥ഛ⪃ฟຊ㈇ᢸ⤒㈝

ࣇ࢓࢖ࣝ
㈇ᢸ⤒㈝

୪ิ
ࢥࣥࣆ࣮ࣗࢱ

ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ

ㄢ㔠ᑐ㇟᫬㛫㸻㸦฼⏝9(ᩘ¹ࢆษୖࡆࡓᩘ㸧⤒㐣᫬㛫 ⛊ㄢ㔠ᑐ㇟᫬㛫᫬㛫࡟ࡘࡁ෇෇

෇

↓ᩱ

෇
෇
෇
෇
෇



෇
෇
෇
෇
ࢡࣟࢫᯛ࡟ࡘࡁ
෇
㸯ࠉ㈇ᢸ㢠ࡀ↓ᩱ࡜࡞ࡿࡢࡣᑓ⏝ࡢ࣮࡛࢟ࣗᐇ⾜ࡉࢀࡓࡶࡢ࡜ࡋࠊไ㝈᫬㛫ࢆ㉸࠼ࡓሙྜࡣᙉไ⤊஢ࡍࡿࠋ㸰ࠉ₇⟬㈇ᢸ⤒㈝ࡢㄢ㔠ᑐ㇟᫬㛫࡟ࡘ࠸࡚ࡣ༙ᮇẖ ᭶࠿ࡽ᭶ཬࡧ᭶࠿ࡽ᭶ ࡟ྜィࡋࠊ᫬㛫ᮍ‶ࢆษୖࡆ࡚
ࠉࠉ㈇ᢸ㔠ࢆㄳồࡍࡿࠋ㸱ࠉ₇⟬㈇ᢸ⤒㈝࡟ࡘ࠸࡚ᐃ㢠ไࢆ㑅ᢥࡋࡓሙྜࡣࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱཬࡧ୪ิࢥࣥࣆ࣮ࣗࢱࢆㄢ㔠ᑐ㇟᫬㛫ࡢࠉࠉ⠊ᅖෆ࡛ඹ⏝࡛ࡁࡿࠋ㸲ࠉ༨᭷฼⏝ᮇ㛫ࡣᖺᗘࢆ㉸࠼࡞࠸ࡶࡢ࡜ࡋࠊᮇ㛫୰࡟㞀ᐖࠊ࣓ࣥࢸࢼࣥࢫసᴗࡀⓎ⏕ࡋࡓሙྜ࡟࠾࠸࡚ࡶࠊཎ๎
ࠉࠉ฼⏝ᮇ㛫ࡢᘏ㛗ࡣࡋ࡞࠸ࠋ
㸳ࠉࣇ࢓࢖ࣝ㈇ᢸ⤒㈝࡟ࡘ࠸࡚ࡣ⏦ㄳ᪥࠿ࡽᙜヱᖺᗘᮎࡲ࡛ࡢᩱ㔠࡜ࡍࡿࠋ㐠⏝ᮇ㛫ࡀᖺ࡟‶ࡓ࡞࠸ሙྜࡣࠊ᭶๭
ࠉࠉࡾࢆࡶࡗ࡚ィ⟬ࡋࡓ㢠࡜ࡍࡿࠋඹ᭷㈇ᢸ㢠୓෇࡟ࡘࡁㄢ㔠ᑐ㇟᫬㛫᫬㛫ศ౑⏝ྍ⬟ᐃ㢠༨᭷฼⏝9(ᩘࠉ฼⏝ᮇ㛫ࣨ᭶࡟ࡘࡁ
ඹ᭷ㄢ㔠ᑐ㇟᫬㛫㸻฼⏝ࣀ࣮ࢻᩘ⤒㐣᫬㛫 ⛊ᚑ㔞ㄢ㔠ᑐ㇟᫬㛫᫬㛫࡟ࡘࡁඹ᭷㈇ᢸ㢠୓෇࡟ࡘࡁㄢ㔠ᑐ㇟᫬㛫᫬㛫ศ౑⏝ྍ⬟ᐃ㢠༨᭷฼⏝ࣀ࣮ࢻᩘࠉ฼⏝ᮇ㛫ࣨ᭶࡟ࡘࡁ
ඹ᭷
7%ࡲ࡛↓ᩱࠊ㏣ຍᐜ㔞7%࡟ࡘࡁᖺ㢠༨᭷
7%ࡲ࡛↓ᩱࠊ㏣ຍᐜ㔞7%࡟ࡘࡁᖺ㢠኱ุࣉࣜࣥࢱ࣮࢝ࣛࣉࣜࣥࢺࠉࣇ࢛ࢺගἑ⏝⣬ᯛ࡟ࡘࡁඹ᭷ᚑ㔞࠙Ẹ㛫ᶵ㛵฼⏝ࠉ ᡂᯝ㠀බ㛤ᆺ ࠚඹ᭷฼⏝9(ᩘ ᐇ⾜ᩘࠊᐇ⾜᫬㛫ࡢไ㝈᭷↓ᩱฟຊ㈇ᢸ⤒㈝෇෇

෇↓ᩱ෇
෇
෇
෇෇

෇෇

෇ඹ᭷㈇ᢸ㢠୓෇࡟ࡘࡁㄢ㔠ᑐ㇟᫬㛫᫬㛫ศ౑⏝ྍ⬟ᐃ㢠༨᭷฼⏝9(ᩘࠉ฼⏝ᮇ㛫ࣨ᭶࡟ࡘࡁ
ඹ᭷ㄢ㔠ᑐ㇟᫬㛫㸻฼⏝ࣀ࣮ࢻᩘ⤒㐣᫬㛫 ⛊ᚑ㔞ㄢ㔠ᑐ㇟᫬㛫᫬㛫࡟ࡘࡁඹ᭷㈇ᢸ㢠୓෇࡟ࡘࡁㄢ㔠ᑐ㇟᫬㛫᫬㛫ศ౑⏝ྍ⬟ᐃ㢠༨᭷฼⏝ࣀ࣮ࢻᩘࠉ฼⏝ᮇ㛫ࣨ᭶࡟ࡘࡁ
ඹ᭷
7%ࡲ࡛↓ᩱࠊ㏣ຍᐜ㔞7%࡟ࡘࡁᖺ㢠༨᭷
7%ࡲ࡛↓ᩱࠊ㏣ຍᐜ㔞7%࡟ࡘࡁᖺ㢠኱ุࣉࣜࣥࢱ࣮࢝ࣛࣉࣜࣥࢺࠉࣇ࢛ࢺගἑ⏝⣬ᯛ࡟ࡘࡁ↓ᩱ฼⏝9(ᩘ ᐇ⾜ᩘࠊᐇ⾜᫬㛫ࡢไ㝈᭷ㄢ㔠ᑐ㇟᫬㛫㸻㸦฼⏝9(ᩘ¹ࢆษୖࡆࡓᩘ㸧⤒㐣᫬㛫 ⛊ㄢ㔠ᑐ㇟᫬㛫᫬㛫࡟ࡘࡁᖺ᭶⌧ᅾ᪋⾜㸦㐠⏝㸧ᖺ᭶᪥ഛ⪃䝕䜱䝇䜽㏣ຍ

䝖䞊䜽䞁㏣ຍ

୍⯡⏦㎸䠄᭱ᑠ䝉䝑䝖䠅

䝜䞊䝗ᅛᐃ

୍⯡⏦㎸
䠄ᇶᮏ䝉䝑䝖䠅

䝁䞊䝇୰ኸฎ⌮⿦⨨
㻔䝯䝰䝸䞊䝃䜲䝈㻕

኱Ꮫྡ

ᮾி኱Ꮫ

㻝㻜㻘㻜㻜㻜㻌෇䠄㻣㻞㻜㻌㻌䝖䞊䜽䞁䠅䝕䜱䝇䜽ᐜ㔞

㻛㼣㼛㼞㼗㻌㻠㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮⏦㎸㻝䝉䝑䝖ᙜ䜚㻛㼣㼛㼞㼗㻌㻠㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮ഛ⪃ᖺ᭶⌧ᅾ௻ᴗ⏦㎸㻝䝉䝑䝖
௜୚䝖䞊䜽䞁㻝㻞䛛᭶㻟㻜㻘㻜㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌㻌䝖䞊䜽䞁䠅䈜㻌᭱኱㻝㻌䝉䝑䝖䈜㻌᭱኱㻌㻝㻞㻌䛛᭶ศ

䝕䜱䝇䜽㔞

䝕䜱䝇䜽㔞

⏦㎸㻝䝉䝑䝖ᙜ䜚㻛㼣㼛㼞㼗㻌㻠㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮௻ᴗ㻛㼣㼛㼞㼗㻌㻠㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮⏦㎸㻝䝉䝑䝖
௜୚䝖䞊䜽䞁㻝㻞䛛᭶㻞㻣㻘㻜㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌㻌䝖䞊䜽䞁䠅䈜㻌᭱኱㻌㻠㻌䝉䝑䝖䈜㻌᭱኱㻌㻝㻞㻌䛛᭶ศ䚸㻌㻌㻌㻟䛛᭶ศ䛿↓ൾ

ᇶᮏ㈇ᢸ㔠኱Ꮫ䞉බඹᶵ㛵➼䈜㻌㻻㼍㼗㼎㼞㼕㼐㼓㼑㻙㻯㼄㻌䛻୍ᗘ䜒䜰䜹䜴䞁䝖Ⓩ㘓
䚷䚷䛥䜜䛶䛔䛺䛔ሙྜ䛾䜏⏦㎸ྍ⬟

↓ൾ

ᇶᮏ㈇ᢸ㔠
኱Ꮫ䞉බඹᶵ㛵➼

ഛ⪃฼⏝ᮇ㛫䛿ᙜヱᖺᗘᮎ䜎䛷᭱኱䝜䞊䝗ᩘ㻌㻞㻡㻢㻌䝜䞊䝗ഛ⪃฼⏝ᮇ㛫䛿฼⏝㛤ጞ᪥䛛䜙㻝䛛᭶ᚋ䜎䛷
᭱኱䝜䞊䝗ᩘ㻌㻤㻌䝜䞊䝗䈜㻌䝖䞊䜽䞁ᾘ㈝ಀᩘ䛿㻌㻝㻚㻜㻜䠈䛯䛰䛧䝖䞊䜽䞁ᾘ㈝ಀᩘ㻌㻝㻚㻡㻜㻌䛾䝜䞊䝗⩌㻔ඃඛ฼⏝ྥ䛡㻕䜢඲య䛾㻝㻡㻑⛬ᗘタ䛡䜛

㏻ᖖ฼⏝䠄䝖䝷䜲䜰䝹䠅㻛௻ᴗ฼⏝䠄䝖䝷䜲䜰䝹䠅䛚ヨ䛧䝇䝟䝁䞁฼⏝䠄↓ᩱయ㦂䠅䞉 㻻㼍㼗㼎㼞㼕㼐㼓㼑㻙㻯㼄㻌䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䝅䝇䝔䝮䛷䛿䚸䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䜢↓ൾ䠈䜎䛯䛿㏻ᖖ฼⏝䛻ẚ䜉䛶Ᏻ౯䛺฼⏝㈇ᢸ㔠䛷䠈୍ᐃᮇ㛫ヨ⏝䛷䛝䜛ไᗘ䜢ᐇ᪋䛧䛶䛔䜛䚹㈇ᢸ㔠➼䛿௨ୗ䜢ཧ↷䚹 ィ⟬㈨※ࢆண⣙ࡍࡿ⏦㎸࡟࠾࠸࡚ࡣ㸪ண⣙ࡋࡓᮇ㛫࠾ࡼࡧࣀ࣮ࢻᩘ࡟┦ᙜࡍࡿࢪࣙࣈᐇ⾜ࢆ⾜ࡗࡓࡶࡢ࡜ࡳ࡞ࡋ࡚㸪ࢺ࣮ࢡ
ࣥࢆᾘ㈝ࡍࡿࡶࡢ࡜ࡍࡿ ࢺ࣮ࢡࣥࡣ฼⏝ᮇ㛫ෆ࡟㝈ࡾ᭷ຠ࡜ࡋ㸪฼⏝⤊஢ᚋ࡟ࢺ࣮ࢡࣥࡢṧ㔞ࡀ࠶ࡿሙྜ࡛ࡶᘬ⥅ࡂ࠾ࡼࡧ฼⏝㈇ᢸ㔠ࡢ㏉㑏ࡣ⾜ࢃ࡞࠸ ௜୚ࡋࡓࢺ࣮ࢡࣥࡣ㸪฼⏝ᮇ㛫ෆ࡟඲㔞ࡀ౑⏝࡛ࡁࡿࡇ࡜ࢆಖドࡍࡿࡶࡢ࡛ࡣ࡞࠸ ࢺ࣮ࢡࣥࡢ୍㒊ࢆ௚ࡢࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩࢫࢸ࣒࡬⛣⾜ࡍࡿࡇ࡜ࡀ࡛ࡁࡿࠋ⛣⾜ඖ࡜⛣⾜ඛ࡛ࡢࢺ࣮ࢡࣥ㔞ࡢᑐᛂ࡟ࡘ
࠸࡚ࡣู⾲㸳࡟ᐃࡵࡿ ࣀ࣮ࢻᅛᐃࡣᑂᰝ࡟ࡼࡗ࡚ㄆࡵࡽࢀࡓ฼⏝ᮇ㛫࠾ࡼࡧࣀ࣮ࢻᩘ࡟࡚༨᭷฼⏝࡛ࡁࡿࡶࡢ࡜ࡍࡿࠋణࡋ㸪ࢺ࣮ࢡࣥṧ㔞ࡀ↓ࡃ࡞ࡗࡓ᫬Ⅼ࡛༨᭷ࡣゎ㝖ࡉࢀࡿ ࣀ࣮ࢻᅛᐃࡢ⏦㎸࡟ᥦ౪ࡍࡿࣜࢯ࣮ࢫࡣ㸪⏦㎸≧ἣࡸࢩࢫࢸ࣒ࡢ✌ാ≧ἣ࡟ࡼࡾኚ᭦ࡍࡿሙྜࡀ࠶ࡿࠋኚ᭦࡜࡞ࡗࡓሙྜࡢ㈇ᢸ㔠㢠ࡢ㐺⏝࡟ࡘ࠸࡚ࡣ⏦ࡋྜࢃࡏ࡟ࡼࡿࡶࡢ࡜ࡍࡿ
 ㏣ຍ࢜ࣉࢩࣙࣥࡣ฼⏝ᮇ㛫ෆ࡟㝈ࡾ᭷ຠ࡜ࡍࡿ
 ㏣ຍ࢜ࣉࢩࣙࣥࡢ㈇ᢸ㔠㢠ࡣ㏣ຍ༢఩㢠࡟㏣ຍࡍࡿ㈨※㔞࠾ࡼࡧ฼⏝ᮇ㛫ࢆ஌ࡌࡓࡶࡢ࡜ࡍࡿ
 ⏦㎸඲యࡢࢺ࣮ࢡࣥ㔞ࡀᥦ౪ྍ⬟࡞ࢺ࣮ࢡࣥ㔞ࡢಸࢆ㉸࠼࡞࠸ሙྜ࡟㝈ࡾཷࡅ௜ࡅࡿࡶࡢ࡜ࡍࡿࠋణࡋ㸪௻ᴗ㸪ⱝᡭ࣭ዪᛶ㸪኱つᶍ+3&ࢳࣕࣞࣥࢪ➼ࡢබເไᗘ࡟ࡼࡿ฼⏝㸪ㅮ⩏࣭ㅮ⩦఍➼ࡢᩍ⫱฼⏝࠾ࡼࡧࢺࣛ࢖࢔࣮ࣝࣘࢫ➼ࡢ⏦㎸࡟࠾࠸࡚ࡣ
ࡇࡢ㝈ࡾ࡛࡞࠸ ࠕ኱Ꮫ࣭බඹᶵ㛵➼ࠖࡣ➨᮲➨ྕ㸪➨ྕ㸪➨ྕ㸪➨ྕ㸪➨ྕ࠾ࡼࡧ➨ྕ࡟ヱᙜࡍࡿ⪅࡟㐺⏝ࡍࡿ ࠕ௻ᴗࠖࡣ➨᮲➨ྕ࡟ヱᙜࡍࡿ⪅࡟㐺⏝ࡍࡿ ฼⏝ᮇ㛫࡟ࡘ࠸࡚ࡣ฼⏝㛤ጞ᭶࠿ࡽᙜヱᖺᗘࡢࢧ࣮ࣅࢫ⤊஢᭶ࡲ࡛࡜ࡋ㸪ᖺᗘࢆ㉸࠼࡞࠸ࡶࡢ࡜ࡍࡿࠋ฼⏝ᮇ㛫ࡢᣦᐃࡀ࠶
ࡿሙྜࡣ฼⏝⤊஢᭶ࡲ࡛࡜ࡍࡿ ࢺ࣮ࢡࣥࡣࢪࣙࣈᐇ⾜ࡈ࡜࡟ࣀ࣮ࢻ᫬㛫✚㸦⤒㐣᫬㛫ࣀ࣮ࢻᩘ㸧࡟ࢺ࣮ࢡࣥᾘ㈝ಀᩘࢆ஌ࡌࡓ್ࢆᾘ㈝ࡍࡿࡶࡢ࡜ࡋ㸪ࢺ࣮ࢡࣥṧ㔞ࡀ↓ࡃ࡞ࡗࡓሙྜ࡟ࡣ㸪ࢪࣙࣈᐇ⾜ࡣᢚṆࡉࢀࡿࠋణࡋ㸪ィ⟬ࣜࢯ࣮ࢫࡢ≧ἣ࡟ࡼࡗ࡚㠀ඃඛࢪࣙࣈࡢᐇ⾜ࢆチྍࡍࡿࡶࡢ࡜ࡍࡿ

㻝㻌㼀㻮༢఩䛷⏦㎸ྍ䠄㻛㼣㼛㼞㼗䛾䜏䠅฼⏝ᮇ㛫䛿ᙜヱᖺᗘᮎ䜎䛷฼⏝ᮇ㛫㻝㻞䛛᭶䛾㔠㢠䞉䝖䞊䜽䞁㔞䠄฼⏝ᮇ㛫䛿㻝䞄᭶༢఩䛷タᐃྍ䠅䈜 䝖䞊䜽䞁ᾘ㈝ಀᩘ䛿㻌㻝㻚㻜㻜䠈䛯䛰䛧䝖䞊䜽䞁ᾘ㈝ಀᩘ㻌㻝㻚㻡㻜㻌䛾䝜䞊䝗⩌㻔ඃඛ฼⏝ྥ䛡㻕䜢඲య䛾㻝㻡㻑⛬ᗘタ䛡䜛䈜 㻝䝆䝵䝤䛷฼⏝ྍ⬟䛺᭱኱䝜䞊䝗ᩘ䛿㻞㻡㻢㻌䝜䞊䝗㻢㻘㻠㻤㻜෇䠋䠄㻝㻌㼀㻮㻌㻖㻌㻝㻞䛛᭶䠅㻤㻘㻠㻜㻜㻌෇䠄㻣㻞㻜㻌㻌䝖䞊䜽䞁䠅㻤㻘㻠㻜㻜㻌෇䠄㻣㻞㻜㻌㻌䝖䞊䜽䞁䠅㈇ᢸ㔠㢠䠄⛯㎸䠅኱Ꮫ䞉බඹᶵ㛵➼௻ᴗ⏦㎸㻝䝉䝑䝖ᙜ䜚⏦㎸㻝䝉䝑䝖ᙜ䜚㻝㻞㻜㻘㻜㻜㻜㻌෇㻝㻜㻜㻘㻜㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌㻌䝖䞊䜽䞁䠅䠄㻤㻘㻢㻠㻜㻌㻌䝖䞊䜽䞁䠅⏦㎸㻝䝉䝑䝖ᙜ䜚⏦㎸㻝䝉䝑䝖ᙜ䜚㻝㻤㻜㻘㻜㻜㻜㻌෇㻝㻡㻜㻘㻜㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌㻌䝖䞊䜽䞁䠅䠄㻤㻘㻢㻠㻜㻌㻌䝖䞊䜽䞁䠅㻻㼍㼗㼎㼞㼕㼐㼓㼑㻙㻯㼄㻌䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䝅䝇䝔䝮㻲㼁㻶㻵㼀㻿㼁㻌㻼㻾㻵㻹㻱㻾㻳㼅㻌㻯㼄㻠㻜㻜㻌㻹㻝㻛㻯㼄㻞㻡㻡㻜㻌㻹㻡㻛㻯㼄㻞㻡㻢㻜㻌㻹㻡㻔㻝㻥㻞㻌㻳㼕㻮㻛䝜䞊䝗㽢㻝㻘㻟㻢㻤㻧㻌㻻㼍㼗㼎㼞㼕㼐㼓㼑㻙㻯㼄㻕㻲㼁㻶㻵㼀㻿㼁㻌㻼㻾㻵㻹㻱㻴㻼㻯㻌㻲㼄㻝㻜㻜㻜㻌㻔㻟㻞㻳㼕㻮㻛䝜䞊䝗㻌㽢㻌㻣㻘㻢㻤㻜㻧㻌㼃㼕㼟㼠㼑㼞㼕㼍㻛㻮㻰㻱㻯㻙㻜㻝㻌㻻㼐㼥㼟㼟㼑㼥㻕㻲㼁㻶㻵㼀㻿㼁㻌㻼㻾㻵㻹㻱㻾㻳㼅㻌㻳㼄㻞㻡㻣㻜㻌㻹㻢㻌㻔㻔㻡㻝㻞㻳㼕㻮㻗㻳㻼㼁㻠㻜㻳㼕㻮㽢㻤㻕㻛䝜䞊䝗㻌㽢㻌㻠㻡㻌㻧㻌㼃㼕㼟㼠㼑㼞㼕㼍㻛㻮㻰㻱㻯㻙㻜㻝㻌㻭㼝㼡㼍㼞㼕㼡㼟㻕㸵኱Ꮫࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ฼⏝㈇ᢸ㔠⾲㸰㸦ᮾ໭኱Ꮫ࣭ᮾி኱Ꮫ㸧

ඹ᭷
ᚑ㔞

ᮾ໭኱Ꮫ

ඹ᭷
↓ᩱ

1(&ࠉ6;$XURUD768%$6$ 7%1(&/;5] 7%࠙Ẹ㛫ᶵ㛵฼⏝ࠉ ᡂᯝබ㛤ᆺ ࠚඹ᭷฼⏝9(ᩘ ᐇ⾜ᩘࠊᐇ⾜᫬㛫ࡢไ㝈᭷↓ᩱㄢ㔠ᑐ㇟᫬㛫㸻ඹ᭷㸦฼⏝9(ᩘ¹ࢆษୖࡆࡓᩘ㸧⤒㐣᫬㛫 ⛊
ࢫ࣮ࣃ࣮
ᚑ㔞
₇
ㄢ㔠ᑐ㇟᫬㛫᫬㛫࡟ࡘࡁࢥࣥࣆ࣮ࣗࢱ⟬ඹ᭷㈇ᢸ㢠୓෇࡟ࡘࡁㄢ㔠ᑐ㇟᫬㛫᫬㛫ศ౑⏝ྍ⬟
㈇
ᐃ㢠
ᢸ
༨᭷
฼⏝9(ᩘࠉ฼⏝ᮇ㛫ࣨ᭶࡟ࡘࡁ
⤒ඹ᭷ㄢ㔠ᑐ㇟᫬㛫㸻฼⏝ࣀ࣮ࢻᩘ⤒㐣᫬㛫 ⛊㈝ᚑ㔞ㄢ㔠ᑐ㇟᫬㛫᫬㛫࡟ࡘࡁ୪ิඹ᭷ࢥࣥࣆ࣮ࣗࢱ㈇ᢸ㢠୓෇࡟ࡘࡁㄢ㔠ᑐ㇟᫬㛫᫬㛫ศ౑⏝ྍ⬟
ᐃ㢠

₇
⟬
㈇
ᢸ
⤒
㈝

ࢫ࣮ࣃ࣮
ࢥࣥࣆ࣮ࣗࢱ

࠙኱Ꮫ࣭Ꮫ⾡฼⏝ࠚ୰ኸฎ⌮⿦⨨
࣓࣮ࣔࣜࢧ࢖ࢬ

኱Ꮫྡスーパーコンピューティングニュース- 25 -

Vol. 24, No.3

2022䝕䜱䝇䜽ᐜ㔞

⏦㎸㻝㻳㻼㼁䝉䝑䝖ᙜ䜚㻟㻞㻠㻘㻜㻜㻜㻌෇䠄㻞㻡㻘㻥㻞㻜㻌㻌䝖䞊䜽䞁䠅⏦㎸㻝㻳㻼㼁䝉䝑䝖ᙜ䜚㻞㻣㻜㻘㻜㻜㻜㻌෇䠄㻞㻡㻘㻥㻞㻜㻌㻌䝖䞊䜽䞁䠅㻞㻘㻝㻢㻜㻘㻜㻜㻜㻌෇䠄㻞㻜㻣㻘㻟㻢㻜㻌䝖䞊䜽䞁䠅㻡㻘㻜㻜㻜㻌෇䠄㻣㻞㻜㻌䝖䞊䜽䞁䠅㻡㻘㻜㻜㻜㻌෇䠄㻣㻞㻜㻌䝖䞊䜽䞁䠅㻳㻼㼁ᑓ᭷⏦㎸䠄බເไᗘ䛾⏦㎸ྍ䠅㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭䝜䞊䝗ᅛᐃ䠄බເไᗘ䛾⏦㎸ྍ䠅㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭୍⯡⏦㎸䠄᭱ᑠ䝉䝑䝖䠅
㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻛㻭䝖䞊䜽䞁㏣ຍ

᪋⾜䠄㐠⏝䠅ᖺ᭶᪥ഛ⪃䝕䜱䝇䜽㏣ຍ

⏦㎸㻝㻳㻼㼁䝉䝑䝖ᙜ䜚㻛㼣㼛㼞㼗㻌㻢㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮⏦㎸㻝䝉䝑䝖ᙜ䜚㻞㻝㻢㻘㻜㻜㻜㻌෇䠄㻞㻡㻘㻥㻞㻜㻌䝖䞊䜽䞁䠅⏦㎸㻝䝉䝑䝖ᙜ䜚㻝㻤㻜㻘㻜㻜㻜㻌෇䠄㻞㻡㻘㻥㻞㻜㻌䝖䞊䜽䞁䠅බເไᗘ䛻䜘䜛⏦㎸㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭ഛ⪃㻝㻌㼀㻮༢఩䛷⏦㎸ྍ䠄㻛㼣㼛㼞㼗䛾䜏䠅฼⏝ᮇ㛫䛿ᙜヱᖺᗘᮎ䜎䛷฼⏝ᮇ㛫㻝㻞䛛᭶䛾㔠㢠䞉䝖䞊䜽䞁㔞䠄฼⏝ᮇ㛫䛿㻝䞄᭶༢఩䛷タᐃྍ䠅㻝䝉䝑䝖䛾䜏⏦㎸ྍ฼⏝ᮇ㛫㻝㻞䛛᭶䛾㔠㢠䞉䝖䞊䜽䞁㔞䠄฼⏝ᮇ㛫䛿㻝䞄᭶༢఩䛷タᐃྍ䠅㻝㻘㻌㻞㻘㻌㻠㻳㻼㼁䛾䜏⏦㎸ྍ㻘
⏦㎸༢఩䛿ୗ⾲ཧ↷฼⏝ᮇ㛫㻝㻞䛛᭶䛾㔠㢠䞉䝖䞊䜽䞁㔞䠄฼⏝ᮇ㛫䛿㻝䞄᭶༢఩䛷タᐃྍ䠅⏦㎸㻝䝉䝑䝖
௜୚䝖䞊䜽䞁㻝㻞䛛᭶㻝㻤㻘㻜㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌㻌䝖䞊䜽䞁䠅䈜㻌᭱኱㻝㻌䝉䝑䝖䈜㻌᭱኱㻌㻝㻞㻌䛛᭶ศ

䝕䜱䝇䜽㔞

䝕䜱䝇䜽㔞

⏦㎸㻝䝉䝑䝖ᙜ䜚㻛㼣㼛㼞㼗㻌㻞㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮௻ᴗ㻛㼣㼛㼞㼗㻌㻞㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮⏦㎸㻝䝉䝑䝖
௜୚䝖䞊䜽䞁㻝㻞䛛᭶㻝㻢㻘㻞㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌㻌䝖䞊䜽䞁䠅䈜㻌᭱኱㻌㻠㻌䝉䝑䝖䈜㻌᭱኱㻌㻝㻞㻌䛛᭶ศ䚸㻌㻌㻌㻟䛛᭶ศ䛿↓ൾ

ᇶᮏ㈇ᢸ㔠኱Ꮫ䞉බඹᶵ㛵➼䈜㻌㼃㼕㼟㼠㼑㼞㼕㼍㻛㻮㻰㻱㻯㻙㻜㻝㻌䛻୍ᗘ䜒䜰䜹䜴䞁䝖㻌㻌㻌㻌Ⓩ㘓䛥䜜䛶䛔䛺䛔ሙྜ䛾䜏⏦㎸ྍ⬟௻ᴗ㻞㻜㻞㻞㻚㻠㻚㻝

ഛ⪃฼⏝ᮇ㛫䛿ᙜヱᖺᗘᮎ䜎䛷᭱኱䝜䞊䝗ᩘ㻛㻳㻼㼁ᩘ㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻦㻌㻞㻘㻟㻜㻠㻌䝜䞊䝗㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭㻦㻌㻢㻠㻌㻳㻼㼁ഛ⪃฼⏝ᮇ㛫䛿฼⏝㛤ጞ᪥䛛䜙㻝䛛᭶ᚋ䜎䛷
᭱኱䝜䞊䝗ᩘ㻛㻳㻼㼁ᩘ㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻦㻌㻝㻞㻌䝜䞊䝗㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭㻦㻌㻠㻌㻳㻼㼁䈜㻌㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻌䛾䝖䞊䜽䞁ᾘ㈝ಀᩘ䛿㻌㻝㻚㻜㻜㻌㻔㻝㻌䝜䞊䝗ᙜ䜚㻕㻌䠈㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭㻌䛾䝖䞊䜽䞁ᾘ㈝ಀᩘ䛿㻌㻟㻚㻜㻜㻌㻔㻝㻌㻳㻼㼁ᙜ䜚㻕㻌㻌㻌㻌㻌㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻌䛻䛿䝖䞊䜽䞁ᾘ㈝ಀᩘ㻌㻝㻚㻡㻜㻌䛾䝜䞊䝗⩌㻔ඃඛ฼⏝ྥ䛡㻕䜢඲య䛾㻝㻡㻌㻑⛬ᗘタ䛡䜛䈜㻌௻ᴗ฼⏝䠄䝖䝷䜲䜰䝹䠅䛿䝜䞊䝗⩌䠄㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻䠈㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭䠅䛤䛸䛾⏦㎸㏻ᖖ฼⏝䠄䝖䝷䜲䜰䝹䠅㻛௻ᴗ฼⏝䠄䝖䝷䜲䜰䝹䠅䛚ヨ䛧䝇䝟䝁䞁฼⏝䠄↓ᩱయ㦂䠅

↓ൾ

ᇶᮏ㈇ᢸ㔠኱Ꮫ䞉බඹᶵ㛵➼䞉 㼃㼕㼟㼠㼑㼞㼕㼍㻛㻮㻰㻱㻯㻙㻜㻝㻌䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䝅䝇䝔䝮䛷䛿䚸䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䜢↓ൾ䠈䜎䛯䛿㏻ᖖ฼⏝䛻ẚ䜉䛶Ᏻ౯䛺฼⏝㈇ᢸ㔠䛷䠈୍ᐃᮇ㛫ヨ⏝䛷䛝䜛ไᗘ䜢ᐇ᪋䛧䛶䛔䜛䚹㈇ᢸ㔠➼䛿௨ୗ䜢ཧ↷䚹 ࠕ኱Ꮫ࣭බඹᶵ㛵➼ࠖࡣ➨᮲➨ྕ㸪➨ྕ㸪➨ྕ㸪➨ྕ㸪➨ྕ࠾ࡼࡧ➨ྕ࡟ヱᙜࡍࡿ⪅࡟㐺⏝ࡍࡿ ࠕ௻ᴗࠖࡣ➨᮲➨ྕ࡟ヱᙜࡍࡿ⪅࡟㐺⏝ࡍࡿ ฼⏝ᮇ㛫࡟ࡘ࠸࡚ࡣ฼⏝㛤ጞ᭶࠿ࡽᙜヱᖺᗘࡢࢧ࣮ࣅࢫ⤊஢᭶ࡲ࡛࡜ࡋ㸪ᖺᗘࢆ㉸࠼࡞࠸ࡶࡢ࡜ࡍࡿࠋ฼⏝ᮇ㛫ࡢᣦᐃࡀ࠶
ࡿሙྜࡣ฼⏝⤊஢᭶ࡲ࡛࡜ࡍࡿ
 2G\VVH\ࢆ౑⏝ࡋࡓሙྜ㸪ࢺ࣮ࢡࣥࡣࢪࣙࣈᐇ⾜ࡈ࡜࡟ࣀ࣮ࢻ᫬㛫✚㸦⤒㐣᫬㛫ࣀ࣮ࢻᩘ㸧࡟ࢺ࣮ࢡࣥᾘ㈝ಀᩘࢆ஌ࡌࡓ್
ࢆᾘ㈝ࡍࡿ
 $TXDULXVࢆ౑⏝ࡋࡓሙྜ㸪ࢺ࣮ࢡࣥࡣࢪࣙࣈᐇ⾜ࡈ࡜࡟*38᫬㛫✚㸦⤒㐣᫬㛫*38ᩘ㸧࡟ࢺ࣮ࢡࣥᾘ㈝ಀᩘࢆ஌ࡌࡓ್ࢆᾘ㈝ࡍࡿ
 ࢺ࣮ࢡࣥࡢṧ㔞ࡀ↓ࡃ࡞ࡗࡓሙྜ࡟ࡣ㸪ࢪࣙࣈᐇ⾜ࡣᢚṆࡉࢀࡿࠋణࡋ㸪ィ⟬ࣜࢯ࣮ࢫࡢ≧ἣ࡟ࡼࡗ࡚㠀ඃඛࢪࣙࣈࡢᐇ⾜ࢆチྍࡍࡿࡶࡢ࡜ࡍࡿ ィ⟬㈨※ࢆண⣙ࡍࡿ⏦㎸࡟࠾࠸࡚ࡣ㸪ண⣙ࡋࡓᮇ㛫࠾ࡼࡧࣀ࣮ࢻᩘ࡟┦ᙜࡍࡿࢪࣙࣈᐇ⾜ࢆ⾜ࡗࡓࡶࡢ࡜ࡳ࡞ࡋ࡚㸪ࢺ࣮ࢡ
ࣥࢆᾘ㈝ࡍࡿࡶࡢ࡜ࡍࡿ ࢺ࣮ࢡࣥࡣ฼⏝ᮇ㛫ෆ࡟㝈ࡾ᭷ຠ࡜ࡋ㸪฼⏝⤊஢ᚋ࡟ࢺ࣮ࢡࣥࡢṧ㔞ࡀ࠶ࡿሙྜ࡛ࡶᘬ⥅ࡂ࠾ࡼࡧ฼⏝㈇ᢸ㔠ࡢ㏉㑏ࡣ⾜ࢃ࡞࠸ ௜୚ࡋࡓࢺ࣮ࢡࣥࡣ㸪฼⏝ᮇ㛫ෆ࡟඲㔞ࡀ౑⏝࡛ࡁࡿࡇ࡜ࢆಖドࡍࡿࡶࡢ࡛ࡣ࡞࠸ ࢺ࣮ࢡࣥࡢ୍㒊ࢆ௚ࡢࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩࢫࢸ࣒࡬⛣⾜ࡍࡿࡇ࡜ࡀ࡛ࡁࡿࠋ⛣⾜ඖ࡜⛣⾜ඛ࡛ࡢࢺ࣮ࢡࣥ㔞ࡢᑐᛂ࡟ࡘ
࠸࡚ࡣู⾲㸳࡟ᐃࡵࡿ ࣀ࣮ࢻᅛᐃࡣᑂᰝ࡟ࡼࡗ࡚ㄆࡵࡽࢀࡓ฼⏝ᮇ㛫࠾ࡼࡧࣀ࣮ࢻᩘ࡟࡚༨᭷฼⏝࡛ࡁࡿࡶࡢ࡜ࡍࡿࠋణࡋ㸪ࢺ࣮ࢡࣥṧ㔞ࡀ↓ࡃ࡞ࡗࡓ᫬Ⅼ࡛༨᭷ࡣゎ㝖ࡉࢀࡿ ࣀ࣮ࢻᅛᐃࡢ⏦㎸࡟ᥦ౪ࡍࡿࣜࢯ࣮ࢫࡣ㸪⏦㎸≧ἣࡸࢩࢫࢸ࣒ࡢ✌ാ≧ἣ࡟ࡼࡾኚ᭦ࡍࡿሙྜࡀ࠶ࡿࠋኚ᭦࡜࡞ࡗࡓሙྜࡢ㈇ᢸ㔠㢠ࡢ㐺⏝࡟ࡘ࠸࡚ࡣ⏦ࡋྜࢃࡏ࡟ࡼࡿࡶࡢ࡜ࡍࡿ
 ㏣ຍ࢜ࣉࢩࣙࣥࡣ฼⏝ᮇ㛫ෆ࡟㝈ࡾ᭷ຠ࡜ࡍࡿ
 ㏣ຍ࢜ࣉࢩࣙࣥࡢ㈇ᢸ㔠㢠ࡣ㏣ຍ༢఩㢠࡟㏣ຍࡍࡿ㈨※㔞࠾ࡼࡧ฼⏝ᮇ㛫ࢆ஌ࡌࡓࡶࡢ࡜ࡍࡿ
 ⏦㎸඲యࡢࢺ࣮ࢡࣥ㔞ࡀᥦ౪ྍ⬟࡞ࢺ࣮ࢡࣥ㔞ࡢಸࢆ㉸࠼࡞࠸ሙྜ࡟㝈ࡾཷࡅ௜ࡅࡿࡶࡢ࡜ࡍࡿࠋణࡋ㸪௻ᴗ㸪ⱝᡭ࣭ዪᛶ㸪኱つᶍ+3&ࢳࣕࣞࣥࢪ➼ࡢබເไᗘ࡟ࡼࡿ฼⏝㸪ㅮ⩏࣭ㅮ⩦఍➼ࡢᩍ⫱฼⏝࠾ࡼࡧࢺࣛ࢖࢔࣮ࣝࣘࢫ➼ࡢ⏦㎸࡟࠾࠸࡚ࡣ
ࡇࡢ㝈ࡾ࡛࡞࠸䈜 㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻌䛾䝖䞊䜽䞁ᾘ㈝ಀᩘ䛿㻌㻝㻚㻜㻜㻌㻔㻝㻌䝜䞊䝗ᙜ䜚㻕㻌䠈㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭㻌䛾䝖䞊䜽䞁ᾘ㈝ಀᩘ䛿㻌㻟㻚㻜㻜㻌㻔㻝㻌㻳㻼㼁ᙜ䜚㻕㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻌䛻䛿䝖䞊䜽䞁ᾘ㈝ಀᩘ㻌㻝㻚㻡㻜㻌䛾䝜䞊䝗⩌㻔ඃඛ฼⏝ྥ䛡㻕䜢඲య䛾㻝㻡㻌㻑⛬ᗘタ䛡䜛䈜 㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻌䛾㻝䝆䝵䝤䛷฼⏝ྍ⬟䛺᭱኱䝜䞊䝗ᩘ䛿㻞㻘㻟㻜㻠㻌䝜䞊䝗㼃㼕㼟㼠㼑㼞㼕㼍㻙㻭㻌䛾㻝䝆䝵䝤䛷฼⏝ྍ⬟䛺᭱኱㻳㻼㼁ᩘ䛿㻢㻠㻌㻳㻼㼁䈜 㻳㻼㼁ᑓ᭷⏦㎸䛾⏦㎸༢఩
㻳㻼㼁
䝖䞊䜽䞁㔞
኱Ꮫ䞉බඹᶵ㛵➼௻ᴗ㻝㻌㻌㻞㻡㻘㻥㻞㻜
㻌㻌㻌㻞㻣㻜㻘㻜㻜㻜㻌෇㻌㻌㻌㻟㻞㻠㻘㻜㻜㻜㻌෇㻞㻌㻌㻡㻝㻘㻤㻠㻜
㻌㻌㻌㻡㻠㻜㻘㻜㻜㻜㻌෇㻌㻌㻌㻢㻠㻤㻘㻜㻜㻜㻌෇㻠㻝㻜㻟㻘㻢㻤㻜
㻝㻘㻜㻤㻜㻘㻜㻜㻜㻌෇㻝㻘㻞㻥㻢㻘㻜㻜㻜㻌෇㻢㻘㻠㻤㻜㻌෇䠋䠄㻝㻌㼀㻮㻌㻖㻌㻝㻞䛛᭶䠅㻢㻘㻜㻜㻜㻌෇䠄㻣㻞㻜㻌䝖䞊䜽䞁䠅㻛㼣㼛㼞㼗㻌㻠㻤㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮㻛㼣㼛㼞㼗㻌㻞㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮⏦㎸㻝䝉䝑䝖ᙜ䜚㻛㼣㼛㼞㼗㻌㻢㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮බເไᗘ䛻䜘䜛⏦㎸㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻞㻘㻝㻢㻜㻘㻜㻜㻜㻌෇䠄㻞㻜㻣㻘㻟㻢㻜㻌䝖䞊䜽䞁䠅⏦㎸㻝䝉䝑䝖ᙜ䜚㻛㼣㼛㼞㼗㻌㻞㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮⏦㎸㻝䝉䝑䝖ᙜ䜚㻣㻞㻘㻜㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌䝖䞊䜽䞁䠅⏦㎸㻝䝉䝑䝖ᙜ䜚㻛㼣㼛㼞㼗㻌㻞㻌㼀㻮฼⏝⪅ᙜ䜚㻛㼔㼛㼙㼑㻌㻡㻜㻌㻳㻮⏦㎸㻝䝉䝑䝖ᙜ䜚㻢㻜㻘㻜㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌䝖䞊䜽䞁䠅௻ᴗ⏦㎸㻝䝉䝑䝖ᙜ䜚㻢㻜㻘㻜㻜㻜㻌෇䠄㻤㻘㻢㻠㻜㻌䝖䞊䜽䞁䠅䝁䞊䝇ࠉᮾி኱Ꮫࡘ࡙ࡁ

ᡂᯝ㠀බ㛤ᆺẸ㛫฼⏝㈇ᢸ㔠

Ẹ㛫
฼⏝㈇ᢸ㔠

ࣜࢸࣛࢩ࣮
฼⏝㈇ᢸ㔠

ࢢ࣮ࣝࣉ
฼⏝㈇ᢸ㔠

ഛ⪃

㏣ຍ㈇ᢸ㔠

ᇶᮏ㈇ᢸ㔠

㈇ᢸ㔠ࡢ༊ศ

୰ኸฎ⌮⿦⨨
࣓࣮ࣔࣜࢧ࢖ࢬ

኱Ꮫྡ

ྡྂᒇ኱Ꮫ

ᖺ᭶⌧ᅾ

㏣ຍ㈇ᢸ㔠㢠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘ ࣜࢸࣛࢩ࣮⏝࡜ࡣ㸪ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢆ฼⏝ࡋࡓ◊✲ࢆ┠ⓗ࡜ࡋࡓᐇ⩦ࢆ⾜࠺ࡶࡢࢆ࠸࠺ࠋ ᇶᮏ㈇ᢸ㔠㸦෇㸧ࢆ㈇ᢸࡍࡿࡇ࡜࡟ࡼࡾ㸪ู⾲ࡢ₇⟬㈇ᢸ࣏࢖ࣥࢺཬࡧࣇ࢓࢖ࣝ౑⏝㈇ᢸ࣏࢖ࣥࢺࡢྜィࢆ෇ᙜࡓ
ࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺ࡟㐩ࡍࡿࡲ࡛㸪฼⏝ࢆྍ⬟࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏࢖ࣥࢺࡢ᭷ຠᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ ᇶᮏ㈇ᢸ㔠ࢆ㈇ᢸࡋ㸪࠿ࡘ㸪㏣ຍ㈇ᢸ㔠෇ࢆ㈇ᢸࡍࡿ࡜ࡁࡣ㸪㏣ຍ㈇ᢸ㔠࡟ࡘ࠸࡚฼⏝ࡋࡓ⤒㈝ࢆ෇ᙜࡓࡾ࣏࢖ࣥ
ࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺ࡟㐩ࡍࡿࡲ࡛฼⏝࡛ࡁࡿࡶࡢ࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏࢖ࣥࢺࡢ᭷ຠᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ
 ฼⏝Ⓩ㘓࡟࠾࠸࡚௳ᮍ‶࡜࡞ࡿ฼⏝Ⓩ㘓௳ᩘ࡟ࡘ࠸࡚ࡣ㸪ᙜヱⓏ㘓௳ᩘࢆ௳࡟ษࡾୖࡆࡿࡶࡢ࡜ࡍࡿࠋ
ᇶᮏ㈇ᢸ㔠㸸฼⏝Ⓩ㘓௳࡟ࡘࡁᖺ㢠෇
ࠉࡇࡢሙྜ࡟࠾࠸࡚㸪ᇶᮏ㈇ᢸ㔠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍ
ࡿࠋ
㏣ຍ㈇ᢸ㔠㸸⤒㈝ࡢぢ㎸ࡳ➼࡟ᇶ࡙ࡃ௵ពࡢ㔠㢠㸦෇༢఩㸧ࠉࡇࡢሙྜ࡟࠾࠸࡚㸪㏣ຍ㈇ᢸ㔠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍࡿࠋ Ẹ㛫฼⏝࡜ࡣ㸪฼⏝つ⛬➨㸱᮲➨㸯㡯➨㸵ྕࡢつᐃ࡟ᇶ࡙ࡁࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢆ฼⏝ࡋ㸪ࡑࡢᡂᯝࢆබ⾲ࡍࡿሙྜࡢࡇ ᇶᮏ㈇ᢸ㔠㸦෇㸧ࢆ㈇ᢸࡍࡿࡇ࡜࡟ࡼࡾ㸪ู⾲㸰ࡢ₇⟬㈇ᢸ࣏࢖ࣥࢺཬࡧࣇ࢓࢖ࣝ౑⏝㈇ᢸ࣏࢖ࣥࢺࡢྜィࡀ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺ࡟㐩ࡍࡿࡲ࡛㸪฼⏝ࢆྍ⬟࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏
࢖ࣥࢺࡢ᭷ຠᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ ᇶᮏ㈇ᢸ㔠ࢆ㈇ᢸࡋ㸪࠿ࡘ㸪㏣ຍ㈇ᢸ㔠෇ࢆ㈇ᢸࡍࡿ࡜ࡁࡣ㸪㏣ຍ㈇ᢸ㔠࡟ࡘ࠸࡚฼⏝ࡋࡓ⤒㈝ࢆ෇ᙜࡓࡾ
࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺ࡟㐩ࡍࡿࡲ࡛฼⏝࡛ࡁࡿࡶࡢ࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏࢖ࣥࢺࡢ᭷ຠ
ᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ
 ฼⏝Ⓩ㘓࡟࠾࠸࡚௳ᮍ‶࡜࡞ࡿ฼⏝Ⓩ㘓௳ᩘ࡟ࡘ࠸࡚ࡣ㸪ᙜヱⓏ㘓௳ᩘࢆ௳࡟ษࡾୖࡆࡿࡶࡢ࡜ࡍࡿࠋ
ᇶᮏ㈇ᢸ㔠㸸฼⏝Ⓩ㘓௳࡟ࡘࡁᖺ㢠෇
ࡇࡢሙྜ࡟࠾࠸࡚㸪ᇶᮏ㈇ᢸ㔠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍࡿࠋࠉ
㏣ຍ㈇ᢸ㔠㸸⤒㈝ࡢぢ㎸ࡳ➼࡟ᇶ࡙ࡃ௵ពࡢ㔠㢠㸦෇༢఩㸧ࠉࡇࡢሙྜ࡟࠾࠸࡚㸪㏣ຍ㈇ᢸ㔠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍࡿࠋ ᡂᯝ㠀බ㛤ᆺẸ㛫฼⏝࡜ࡣ㸪฼⏝つ⛬➨㸱᮲➨㸯㡯➨㸵ྕࡢつᐃ࡟ᇶ࡙ࡁࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢆ฼⏝ࡋ㸪ࡑࡢᡂᯝࢆ㠀බ㛤࡜ࡍࡿሙྜࡢࡇ࡜ࢆ࠸࠺ࠋ ᇶᮏ㈇ᢸ㔠㸦෇㸧ࢆ㈇ᢸࡍࡿࡇ࡜࡟ࡼࡾ㸪ู⾲㸰ࡢ₇⟬㈇ᢸ࣏࢖ࣥࢺཬࡧࣇ࢓࢖ࣝ౑⏝㈇ᢸ࣏࢖ࣥࢺࡢྜィࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺ࡟㐩ࡍࡿࡲ࡛㸪฼⏝ࢆྍ⬟࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏
࢖ࣥࢺࡢ᭷ຠᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ ᇶᮏ㈇ᢸ㔠ࢆ㈇ᢸࡋ㸪࠿ࡘ㸪㏣ຍ㈇ᢸ㔠෇ࢆ㈇ᢸࡍࡿ࡜ࡁࡣ㸪㏣ຍ㈇ᢸ㔠࡟ࡘ࠸࡚฼⏝ࡋࡓ⤒㈝ࢆ෇ᙜࡓࡾ
࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺ࡟㐩ࡍࡿࡲ࡛฼⏝࡛ࡁࡿࡶࡢ࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏࢖ࣥࢺࡢ᭷ຠ
ᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ
 ฼⏝Ⓩ㘓࡟࠾࠸࡚௳ᮍ‶࡜࡞ࡿ฼⏝Ⓩ㘓௳ᩘ࡟ࡘ࠸࡚ࡣ㸪ᙜヱⓏ㘓௳ᩘࢆ௳࡟ษࡾୖࡆࡿࡶࡢ࡜ࡍࡿࠋ

㏣ຍ㈇ᢸ㔠㸸⤒㈝ࡢぢ㎸ࡳ➼࡟ᇶ࡙ࡃ௵ពࡢ㔠㢠㸦෇༢఩㸧ࠉࠉ ࡇࡢሙྜ࡟࠾࠸࡚㸪㏣ຍ㈇ᢸ㔠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍࡿࠋ

ᇶᮏ㈇ᢸ㔠㸸฼⏝Ⓩ㘓௳࡟ࡘࡁࠊ୍ࡢᖺᗘ࡟࠾ࡅࡿ⟠᭶ࡢ㔠㢠෇ࠉ ࡇࡢሙྜ࡟࠾࠸࡚㸪ᇶᮏ㈇ᢸ㔠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍࡿࠋ ࢢ࣮ࣝࣉ฼⏝㈇ᢸ㔠ࡢ⏦㎸ࡳࡣ㸪◊✲ࢢ࣮ࣝࣉ༢఩࡛⾜࠺ࡶࡢ࡜ࡍࡿࠋ ᇶᮏ㈇ᢸ㔠㸦෇㸧ࢆ㈇ᢸࡍࡿࡇ࡜࡟ࡼࡾ㸪ู⾲ࡢ₇⟬㈇ᢸ࣏࢖ࣥࢺཬࡧࣇ࢓࢖ࣝ౑⏝㈇ᢸ࣏࢖ࣥࢺࡢྜィࡀ㸪෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺ࡟㐩ࡍࡿࡲ࡛㸪฼⏝ࢆྍ⬟࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏࢖ࣥࢺࡢ᭷
ຠᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ
 ㏣ຍ㈇ᢸ㔠ࢆ㈇ᢸࡍࡿ࡜ࡁࡣ㸪୍ཱྀ෇௨ୖ࡜ࡋ㸪฼⏝ྍ⬟࣏࢖ࣥࢺ࡬ࡢ᥮⟬ࡣ㸪ู⾲ࡢ㏣ຍ㈇ᢸ㔠つ⛬࡟‽ࡎࡿࡇ࡜࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏࢖ࣥࢺࡢ᭷ຠᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ
 ฼⏝Ⓩ㘓࡟࠾࠸࡚௳ᮍ‶࡜࡞ࡿ฼⏝Ⓩ㘓௳ᩘ࡟ࡘ࠸࡚ࡣ㸪ᙜヱⓏ㘓௳ᩘࢆ௳࡟ษࡾୖࡆࡿࡶࡢ࡜ࡍࡿࠋ

㏣ຍ㈇ᢸ㔠㸸⤒㈝ࡢぢ㎸➼࡟ᇶ࡙ࡃ௵ពࡢ㔠㢠㸦୍ཱྀ෇௨ୖ㸧ࡇࡢሙྜ࡟࠾࠸࡚㸪฼⏝ྍ⬟࣏࢖ࣥࢺ࡬ࡢ᥮⟬ࡣ㸪ู⾲ࡢ㏣ຍ㈇ᢸ㔠つ⛬࡟‽ࡎࡿࡇ࡜࡜ࡍࡿࠋ
ࠉ

ᇶᮏ㈇ᢸ㔠㸸฼⏝Ⓩ㘓௳࡟ࡘࡁᖺ㢠෇
ࡇࡢሙྜ࡟࠾࠸࡚㸪ᇶᮏ㈇ᢸ㔠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍࡿࠋ
ࠉ෇௨ୖ

㏣ຍ฼⏝ྍ⬟࣏࢖ࣥࢺᩘ
㏣ຍ㈇ᢸ㔠㢠ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘ

෇ᮍ‶ᅇࡢ㏣ຍ㈇ᢸ㔠ࡢධ㔠㢠⤒㈝ࡢぢ㎸➼࡟ᇶ࡙ࡃ௵ពࡢ㔠㢠㸦෇༢఩㸧ࡇࡢሙྜ࡟࠾࠸࡚㸪㏣ຍ㈇ᢸ㔠ࡀ෇ᮍ‶ࡢሙྜࡣ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟㸪෇௨ୖࡢሙྜࡣ෇ᙜࡓࡾ࣏
࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍࡿࠋ ᇶᮏ㈇ᢸ㔠ࢆ㈇ᢸࡍࡿࡇ࡜࡟ࡼࡾ㸪₇⟬㈇ᢸ࣏࢖ࣥࢺཬࡧࣇ࢓࢖ࣝ౑⏝㈇ᢸ࣏࢖ࣥࢺࡢྜィࡀ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺ࡟㐩ࡍࡿࡲ࡛㸪฼⏝ࢆྍ⬟࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏࢖ࣥࢺࡢ᭷ຠᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀ
ᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ ᇶᮏ㈇ᢸ㔠ࢆ㈇ᢸࡋ㸪࠿ࡘ㸪ᅇᙜࡓࡾḟ⾲ࡢᕥḍ࡟ᥖࡆࡿ㏣ຍ㈇ᢸ㔠ࢆ㈇ᢸࡍࡿ࡜ࡁࡣ㸪㏣ຍ㈇ᢸ㔠࡟ࡘ࠸࡚฼⏝ࡋࡓ⤒㈝ࡀࡑࢀࡒࢀྑḍ࡟ᥖࡆࡿ᥮⟬᪉ἲ࡟ᇶ࡙ࡃ㏣ຍ฼⏝ྍ⬟࣏࢖ࣥࢺᩘ࡟㐩ࡍࡿࡲ࡛฼⏝࡛ࡁࡿࡶࡢ࡜ࡍࡿࠋࡓࡔࡋ㸪ྲྀᚓࡋࡓ࣏࢖ࣥࢺࡢ᭷ຠᮇ㝈ࡣ㸪ᙜヱ࣏࢖ࣥࢺࢆྲྀᚓࡋࡓᖺᗘෆ࡟㝈ࡿࡶࡢ࡜ࡍࡿࠋ

)8-,768ࠉ7\SH,ࢧࣈࢩࢫࢸ࣒ࠉ); *L%
ࠉࠉࠉࠉ7\SH,,ࢧࣈࢩࢫࢸ࣒&;0 *L%
+3(7\SH,,,ࢧࣈࢩࢫࢸ࣒+3(6XSHUGRPH)OH[ 7L%
ࢡࣛ࢘ࢻࢩࢫࢸ࣒+3(3UR/LDQW'/ *L%฼⏝㈇ᢸ㔠㢠
฼⏝Ⓩ㘓㸯௳࡟ࡘࡁᖺ㢠෇
ࡇࡢሙྜ࡟࠾࠸࡚㸪ᇶᮏ㈇ᢸ㔠㢠෇ࢆ෇ᙜࡓࡾ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓ࣏࢖ࣥࢺᩘࢆྲྀᚓࡍࡿࡶࡢ࡜ࡍࡿࠋ

㸵኱Ꮫࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ฼⏝㈇ᢸ㔠⾲㸱㸦ᮾி኱Ꮫ࣭ྡྂᒇ኱Ꮫ㸧୍⯡⏦㎸䠄ᇶᮏ䝉䝑䝖䠅
㼃㼕㼟㼠㼑㼞㼕㼍㻙㻻㻛㻭㈇ᢸ㔠㢠䠄⛯㎸䠅኱Ꮫ䞉බඹᶵ㛵➼㼃㼕㼟㼠㼑㼞㼕㼍㻛㻮㻰㻱㻯㻙㻜㻝䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䝅䝇䝔䝮スーパーコンピューティングニュース- 26 -

Vol. 24, No.3

2022

఍ヰᆺฎ⌮

ࣂࢵࢳฎ⌮

᪋⾜㸦㐠⏝㸧
ᖺ᭶᪥ഛ⪃ࣇ࢓࢖ࣝ౑⏝㈇ᢸ
࣏࢖ࣥࢺ

࣏₇
࢖⟬
ࣥ㈇
ࢺᢸ

࣏࢖ࣥࢺࡢ༊ศ

ࢥ࣮ࣝࢻࢫࢺ࣮ࣞࢪ฼⏝㈇ᢸ㔠ࣀ࣮ࢻ‽༨᭷฼⏝㈇ᢸ㔠ࣇ࢓࢖ࣝࡢ౑⏝ᐜ㔞ࡀ7%௨ୗࡢሙྜᚩ཰ࡋ࡞࠸ࠋ
ࣇ࢓࢖ࣝࡢ౑⏝㔞ࡀ7%ࢆ㉸࠼ࡓሙྜ㉸࠼ࡓ㒊ศ࡟ࡘ࠸࡚㸯*%࡟ࡘࡁ㸯᪥ᙜࡓࡾ࣏࢖ࣥࢺ

 ྛ༊ศࡢ฼⏝㈇ᢸࢆ࣏࢖ࣥࢺ࡟᥮⟬ࡋࡓሙྜ࡟࣏࢖ࣥࢺᮍ‶ࡢ➃ᩘࡀ⏕ࡌࡿ࡜ࡁࡣ㸪ࡇࢀࢆษࡾୖࡆࡿࠋ

 7\SH,,,ࢧࣈࢩࢫࢸ࣒ࡢ఍ヰᆺฎ⌮࡟࠾ࡅࡿ₇⟬㈇ᢸ࣏࢖ࣥࢺࡣ㸪㸯᪥༢఩࡛㸪࠿ࡘ㸪ࢩࢫࢸ࣒ࡈ࡜࡟Ⓩ㘓␒ྕ࡟ࡼࡾ౑⏝ࡋ
ࡓ&38ࢥ࢔ࡢ₇⟬᫬㛫ࢆ㞟ィࡋ㸪⟬ᐃࡍࡿࠋ ࣍ࢵࢺࢫࢺ࣮ࣞࢪࡢࣇ࢓࢖ࣝ౑⏝㈇ᢸ࣏࢖ࣥࢺࡣ㸪᪥༢఩࡛㸪࠿ࡘ㸪Ⓩ㘓␒ྕࡈ࡜࡟౑⏝㔞ࢆ㞟ィࡋ㸪⟬ᐃࡍࡿࠋ ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࡢࣂࢵࢳฎ⌮࡟࠾ࡅࡿ₇⟬㈇ᢸ࣏࢖ࣥࢺࡣ㸪ᙜヱࢪࣙࣈࡢ⤒㐣᫬㛫ཬࡧ౑⏝ࣀ࣮ࢻᩘ㸦ࣀ࣮ࢻඹ᭷ࢆ
ྵࡴࠋ㸧*38ᩘ㸪&38ࢯࢣࢵࢺᩘཪࡣ&38ࢥ࢔ᩘ࡟ࡼࡾ⟬ᐃࡍࡿࠋ࣍ࢵࢺࢫࢺ࣮ࣞࢪ㸸

7\SH,,,ࢧࣈࢩࢫࢸ࣒㸸&38ࢥ࢔ࡢ₇⟬᫬㛫㸯⛊࡟ࡘࡁ࣏࢖ࣥࢺ

ഛ⪃

ࢫ
勖
ࣃ
勖
ࢥ
ࣥ
ࣆ
勑
勖
ࢱ
ࢩ
ࢫ
ࢸ
࣒

༊ศ

෇ᖺ

ᇶᮏᇶᮏࣃ࣮ࢯࢼࣝ ࢱ࢖ࣉ%ࢱ࢖ࣉ&෇ᖺ

ᥦ౪ࢧ࣮ࣅࢫ
ࢩࢫࢸ࣒㈨※

⤒㐣᫬㛫
㸦᫬㛫㸧




ؐ


















ؐ

ؐ

ؐ

ؐ

ࢫࢺ࣮ࣞࢪ ↓ᩱ฼⏝⪅7%ᩘᖺ᭶⌧ᅾ᭱኱ࣀ࣮ࢻ┦ᙜ%ඹ᭷ࢥ࢔ࠊ*%࣓ࣔࣜ 㸧᭱኱ࣀ࣮ࢻ┦ᙜ$ඹ᭷ࢥ࢔ࠊ*%࣓ࣔࣜ 㸧᭱኱ࣀ࣮ࢻ┦ᙜ
%
ඹ᭷


ࢥ࢔ࠊ*%࣓ࣔࣜ 㸧᭱኱ࣀ࣮ࢻ┦ᙜ&ඹ᭷ࢥ࢔ࠊ*%࣓ࣔࣜ 㸧ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ඃඛࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ 

$ ‽ඃඛ
ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ༨᭷ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ඃඛࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ 

% ‽ඃඛ
ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ༨᭷ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ඃඛࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ &ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ‽ඃඛࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ $༨᭷ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ 
%
༨᭷

ؐ
ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ &༨᭷ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ 

%
ؐ
ؐ
ࣀ࣮ࢻ ࢥ࢔ࠊ*%࣓ࣔࣜ ࢫࢺ࣮ࣞࢪᐜ㔞7%ࡢ㏣ຍ࡟ࡘࡁྍど໬ࢯࣇࢺ $96(19,,'/ ࠾ࡼࡧࣉ࣏ࣜࢫࢺ࢙࢘࢔ࡢࣛ࢖ࢭࣥࢫ࡟ࡘࡁ

ࢩࢫࢸ࣒ ࣂࢵࢳ

ி㒔኱Ꮫ

฼⏝㈇ᢸ㢠
෇᭶
෇᭶

&

%

$

ࢩࢫࢸ࣒
ࣀ࣮ࢻ
ࣀ࣮ࢻ
ࣀ࣮ࢻ
ࣀ࣮ࢻ
ࣀ࣮ࢻ
ࣀ࣮ࢻ
ࣀ࣮ࢻ
ࣀ࣮ࢻ
ࣀ࣮ࢻ

ࢩࢫࢸ࣒㈨※
ࢥ࢔ࠊ*%࣓ࣔࣜ ࢥ࢔ࠊ*%࣓ࣔࣜ ࢥ࢔ࠊ*%࣓ࣔࣜ ࢥ࢔ࠊ*%࣓ࣔࣜ ࢥ࢔ࠊ*%࣓ࣔࣜ ࢥ࢔ࠊ*%࣓ࣔࣜ ࢥ࢔ࠊ*%࣓ࣔࣜ ࢥ࢔ࠊ*%࣓ࣔࣜ ࢥ࢔ࠊ*%࣓ࣔࣜ ㉸㐣᫬㛫 ࢫࢺ࣮ࣞࢪ ↓ᩱ฼⏝
7%
㸦᫬㛫㸧
⪅ᩘ




























෇ᖺ
෇ᖺ
෇ᖺ
෇ᖺ
෇ᖺ
෇ᖺ
෇ᖺ
෇ᖺ
෇ᖺ฼⏝㈇ᢸ㢠฼⏝㈇ᢸ㢠⟬ᐃ༢఩Ỉ෭෭༷᪉ᘧࡢィ⟬ࢧ࣮ࣂ➼ࡢᐃ᱁㟁ຊN:࡟ࡘࡁ
✵෭෭༷᪉ᘧࡢィ⟬ࢧ࣮ࣂ➼ࡢᐃ᱁㟁ຊN:࡟ࡘࡁ
ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩࢫࢸ࣒㸦Ẹ㛫ᶵ㛵฼⏝㸧

෭༷᪉ᘧ
Ỉ෭
✵෭

 ฼⏝㈇ᢸ㢠ࡣࠊᖺᗘ༢఩࡛⟬ᐃࡋ࡚࠸ࡿࠋࡲࡓࠊ⥲㢠⾲♧࡛࠶ࡿࠋࣃ࣮ࢯࢼࣝࢥ࣮ࢫࠊࢢ࣮ࣝࣉࢥ࣮ࢫཪࡣᑓ⏝ࢡࣛࢫࢱࢥ࣮ࢫࢆࠊ
ᖺᗘ㏵୰࠿ࡽ฼⏝ࢆ㛤ጞࡍࡿሙྜཬࡧᖺᗘ㏵୰࡛฼⏝ࢆ⤊஢ࡍࡿሙྜࡢ฼⏝㈇ᢸ㢠ࡣࠊୖグ⾲୰ࡢ฼⏝㈇ᢸ㢠ࢆ࡛㝖ࡋࡓᚋࠊ฼⏝᭶ᩘࢆ஌ࡌ࡚⟬ฟࡍࡿࡶࡢ࡜ࡋࠊ෇ᮍ‶࡟➃ᩘࡀฟࡓሙྜࡣࠊ෇༢఩ࢆᅄᤞ஬ධࡍࡿࡶࡢ࡜ࡍࡿࠋ
࡞࠾ࠊ᭶㏵୰࠿ࡽ฼⏝ࢆ㛤ጞࡍࡿሙྜཬࡧ᭶㏵୰࡛฼⏝ࢆ⤊஢ࡍࡿሙྜࡣࠊࡑࢀࡒࢀ᭶ࡢ฼⏝࡜ࡍࡿࠋ ኱ᆺィ⟬ᶵࢩࢫࢸ࣒ࡢ඲࡚ࡢ฼⏝⪅ࡣࠊୖグ⾲ࡢࢧ࣮ࣅࢫࡢ௚ࠊḟࡢࢧ࣮ࣅࢫࢆཷࡅࡿࡇ࡜ࡀ࡛ࡁࡿࠋ
ࠉ㸧኱ุࣉࣜࣥࢱࢧ࣮ࣅࢫ
ࠉ㸧ࡑࡢ௚ࠊ኱ᆺィ⟬ᶵࢩࢫࢸ࣒ࡀᥦ౪ࡍࡿࢧ࣮ࣅࢫࠊᶵჾࡢ฼⏝ ୖグ⾲ࡢ኱つᶍࢪࣙࣈࢥ࣮ࢫࠊࢫࢺ࣮ࣞࢪᐜ㔞㏣ຍࠊࣛ࢖ࢭࣥࢫࢧ࣮ࣅࢫࡢ⏦ㄳ࡟ࡣࠊࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩࢫࢸ࣒ࡢ฼⏝⪅࡛࠶ࡿࡇ࡜ࡀᚲせ࡛࠶ࡿࠋ 㺀ඹ᭷ࠖࠉ㸸ᙜヱ࢝ࢸࢦࣜࡢ࣮ࣘࢨ㛫୍࡛ᐃࡢィ⟬㈨※ࢆඹ᭷ࡍࡿ࣋ࢫࢺ࢚ࣇ࢛࣮ࢺࡢࢫࢣࢪ࣮ࣗࣜࣥࢢࢆ⾜࠺ࠋ㺀‽ඃඛࠖ㸸ᐃᖖ✌ാ≧ἣ࡟࠾࠸࡚グ㍕್㸦௨ୖ㸧ࡢィ⟬㈨※ࡀ☜ಖࡉࢀࡿࡼ࠺࡟ඃඛࢫࢣࢪ࣮ࣗࣜࣥࢢࢆ⾜࠺ࠋࠉࠉࠉࠉࠉࠉࡲࡓ✌ാ≧ἣ࡟ࡼࡽࡎグ㍕್ࡢࡢィ⟬㈨※ࡀ☜ಖࡉࢀࡿࡇ࡜ࢆಖドࡍࡿࠋ㺀ඃඛࠖࠉ㸸ᐃᖖ✌ാ≧ἣ࡟࠾࠸࡚グ㍕್㸦௨ୖ㸧ࡢィ⟬㈨※ࡀ☜ಖࡉࢀࡿࡼ࠺࡟ඃඛࢫࢣࢪ࣮ࣗࣜࣥࢢࢆ⾜࠺ࠋࠉࠉࠉࠉࠉࠉࡲࡓ✌ാ≧ἣ࡟ࡼࡽࡎグ㍕್ࡢࡢィ⟬㈨※ࡀ☜ಖࡉࢀࡿࡇ࡜ࢆಖドࡍࡿࠋ㺀༨᭷ࠖࠉ㸸✌ാ≧ἣ࡟ࡼࡽࡎグ㍕್ࡢィ⟬㈨※ࡀ☜ಖࡉࢀࡿࡇ࡜ࢆಖドࡍࡿࠋ ࢫࢺ࣮ࣞࢪᐜ㔞ࡣࣂࢵࢡ࢔ࢵࣉ㡿ᇦ㸦᭱኱࡛⥲ᐜ㔞ࡢ㸧ࢆྵࡴࠋ ࢢ࣮ࣝࣉࢥ࣮ࢫཬࡧᑓ⏝ࢡࣛࢫࢱࢥ࣮ࢫࡢ฼⏝⪅␒ྕࡣ฼⏝⪅࠶ࡓࡾᖺ㢠෇ࢆ㈇ᢸࡍࡿࡇ࡜࡛㏣ຍ࡛ࡁࡿࠋ ᶵ㛵࣭㒊ᒁᐃ㢠ไᗘ௚ᶵ㛵ཪࡣᏛෆ࡟࠾ࡅࡿ㒊ᒁ㸦ࠗᅜ❧኱Ꮫἲேி㒔኱Ꮫࡢ⤌⧊࡟㛵ࡍࡿつ⛬࠘➨❶➨⠇࠿ࡽ➨⠇࡛ᐃࡵࡿ⤌⧊ࢆ࠸࠺ࠋ㸧ࡢ⤌⧊ࡀࠊࡑࡢ⤌⧊༢఩࡛ࢢ࣮ࣝࣉࢥ࣮ࢫࢧ࣮ࣅࢫࢆ฼⏝⏦ㄳࡍࡿሙྜࡢ฼⏝㈇ᢸ㢠ࡣࠊู⾲㸯࡟つᐃࡍࡿ㢠ࡢಸࡢ㢠࡜ࡍࡿࠋ࡞࠾ࠊ฼⏝㈇ᢸ㢠ࡀᖺ㢠୓෇ᮍ‶ࡢሙྜࡣேࠊᖺ㢠୓෇ࢆ㉸࠼ࡿሙྜࡣࠊ୓෇ẖ࡟ேࡲ࡛ࡢ฼⏝⪅ࢆㄆࡵࡿࠋ
ࢫࢺ࣮ࣞࢪࡣࠊಸࡢᐜ㔞࡜ࡍࡿࠋ ࢫࣃࢥࣥ㐃ᦠࢧ࣮ࣅࢫ
Ꮫ⾡᝟ሗ࣓ࢹ࢕࢔ࢭࣥࢱ࣮ࡢࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩࢫࢸ࣒࡜ᐦ࡞㐃ᦠ࡟ࡼࡾࠊᏛෆ࡟࠾ࡅࡿ㒊ᒁࡢ⤌⧊ࡀィ⟬ࢧ࣮ࣂ➼ࢆタ⨨ࡍࡿሙྜࠊ
ୗグࡢ㈇ᢸ㢠ࢆᨭᡶ࠺ࡶࡢ࡜ࡍࡿࠋ᭱ᑠ ෇ᖺ
㏣ຍ༢఩ ෇ᖺ᭱ᑠ ෇ᖺ
ࢱ࢖ࣉ$
㏣ຍ༢఩ ෇ᖺ᭱ᑠ ෇ᖺ
ࢱ࢖ࣉ$
㏣ຍ༢఩ ෇ᖺ᭱ᑠ ෇ᖺ
ࢱ࢖ࣉ%
㏣ຍ༢఩ ෇ᖺ
ࢢ࣮ࣝࣉ᭱ᑠ ෇ᖺ
ࢱ࢖ࣉ%
㏣ຍ༢఩ ෇ᖺ᭱ᑠ ෇ᖺ
ࢱ࢖ࣉ%
㏣ຍ༢఩ ෇ᖺ᭱ᑠ ෇ᖺ
ࢱ࢖ࣉ&㏣ຍ༢఩ ෇ᖺ᭱ᑠ ෇ᖺ
ࢱ࢖ࣉ&㏣ຍ༢఩ ෇ᖺ᭱ᑠ ෇㐌 ᪥ࢱ࢖ࣉ$㏣ຍ༢఩ ෇㐌 ᪥᭱ᑠ ෇㐌 ᪥
኱つᶍ
ࢱ࢖ࣉ%
ࢪࣙࣈ
㏣ຍ༢఩ ෇㐌 ᪥᭱ᑠ ෇㐌 ᪥ࢱ࢖ࣉ&㏣ຍ༢఩ ෇㐌 ᪥᭱ᑠ ෇ᖺ
ᑓ⏝
ؐ
ࢡࣛࢫࢱ
㏣ຍ༢఩ ෇ᖺ
ࢫࢺ࣮ࣞࢪᐜ㔞㏣ຍ
෇ᖺ
ࣛ࢖ࢭࣥࢫࢧ࣮ࣅࢫ
෇ᖺ
ࢱ࢖ࣉ$෇ᖺ

ᇶᮏ

ࢱ࢖ࣉ$

෇ᖺ

ᇶᮏ

ؐ

฼⏝㈇ᢸ㢠

࢚ࣥࢺࣜ

ࢭࢵࢺ

ࢱ࢖ࣉ

ࢥ࣮ࢫ

༊ศ

୰ኸฎ⌮
&5$<;& *%*%
⿦⨨&5$<&6;7 *%㸧࣓࣮ࣔࣜ
ࢧ࢖ࢬ &5$<&6; 7%

኱Ꮫྡ㸵኱Ꮫࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ฼⏝㈇ᢸ㔠⾲㸲㸦ྡྂᒇ኱Ꮫ࣭ி㒔኱Ꮫ㸧ྡྂᒇ኱Ꮫࡘ࡙ࡁ
7\SH,,ࢧࣈࢩࢫࢸ࣒㸸㸯ࣀ࣮ࢻ࡟ࡘࡁ୍ࣨ᭶ᙜࡓࡾ෇
ࢡࣛ࢘ࢻࢩࢫࢸ࣒㸸㸯ࣀ࣮ࢻ࡟ࡘࡁ୍ࣨ᭶ᙜࡓࡾ෇ ࣀ࣮ࢻ༨᭷฼⏝࡜ࡣ㸪7\SH,,ࢧࣈࢩࢫࢸ࣒࠾ࡼࡧࢡࣛ࢘ࢻࢩࢫࢸ࣒࡟࠾ࡅࡿ୍㒊ࡢࣀ࣮ࢻࢆඃඛⓗ࡟༨᭷ࡋ࡚฼⏝ࡍࡿሙྜࡢࡇ࡜ࢆ࠸࠺ࠋ ࡢሙྜ࡟࠾ࡅࡿࣇ࢓࢖ࣝ౑⏝㈇ᢸ࣏࢖ࣥࢺࡣ㸪ู⾲࡛ᐃࡵࡿᇶᮏ㈇ᢸ㔠ཬࡧ㏣ຍ㈇ᢸ㔠ࡢྜィ㢠࡜ࡋ㸪⟬ᐃ᪉ἲࡣ㸪ู⾲࡟‽ࡎࡿࠋ ‽༨᭷࡛ࡁࡿࣀ࣮ࢻᩘࡣ㸪ࣀ࣮ࢻ༢఩࡜ࡋ㸪ᮇ㛫ࡣ୍ࣨ᭶༢఩࡜ࡍࡿࠋ ࣀ࣮ࢻ‽༨᭷฼⏝ࡣ㸪Ⓩ㘓᫬ࡢ฼⏝ᮇ㛫ཬࡧᖺᗘࢆ㉺࠼࡚࡛ࡁ࡞࠸ࠋ ࣀ࣮ࢻ‽༨᭷ࡣ㸪Ꮫ⾡◊✲ࡢ฼⏝ࡢࡳ฼⏝ྍ࡜ࡍࡿࠋ
ࣇ࢓࢖ࣝ㈇ᢸ㔠㸸࣮࢝ࢺࣜࢵࢪࢆ㸯ཱྀ㸦7%㸧࡜ࡋ࡚ึᖺᗘ෇࡜ࡋ㸪ḟᖺᗘ௨㝆⥅⥆ࡍࡿሙྜࡣ㸪ࣇ࢓࢖ࣝ㈇ᢸ
㔠ࡣᚩ཰ࡋ࡞࠸ࠋ
ࣇ࢓࢖ࣝ⟶⌮㔠㸸ࢫࣟࢵࢺ㸯ཱྀ㸦7%㸧࡜ࡋࣇ࢓࢖ࣝ⟶⌮㔠ࢆึᖺᗘࡣ෇㸪ḟᖺᗘ௨㝆⥅⥆ࡉࢀࡓሙྜᖺ㛫෇ࢆᚩ཰ࡍࡿࠋ ࣇ࢓࢖ࣝ㈇ᢸ㔠࡜ࡣ㸪ᮏࢭࣥࢱ࣮ࡢࢥ࣮ࣝࢻࢫࢺ࣮ࣞࢪࢩࢫࢸ࣒ࢆ฼⏝ࡍࡿ᫬㸪ࢭࣥࢱ࣮タ⨨ࡢගࢹ࢕ࢫࢡࢆ౑⏝ࡍࡿሙྜ
࡟Ⓨ⏕ࡍࡿ㈇ᢸ㔠࡛࠶ࡿࠋ ࣇ࢓࢖ࣝ⟶⌮㔠࡜ࡣ㸪ᮏࢭࣥࢱ࣮࡟タ⨨ࡉࢀ࡚࠸ࡿࢥ࣮ࣝࢻࢫࢺ࣮ࣞࢪࢩࢫࢸ࣒ࢆ฼⏝ࡋࡓ᫬㸪⟶⌮㐠⏝⤒㈝࡜ࡋ࡚ᚩ཰ࡍ
ࡿࡶࡢ࡛࠶ࡿࠋ
࣏࢖ࣥࢺࡢ⟬ᐃᇶ♏㢠
7\SH,ࢧࣈࢩࢫࢸ࣒㸸⤒㐣᫬㛫㸯⛊࡟ࡘࡁ࣏࢖ࣥࢺ࡟౑⏝ࣀ࣮ࢻᩘࢆ஌ࡌ࡚ᚓࡓ࣏࢖ࣥࢺᩘࠋ
7\SH,,ࢧࣈࢩࢫࢸ࣒㸸⤒㐣᫬㛫㸯⛊࡟ࡘࡁ࣏࢖ࣥࢺ࡟౑⏝*38ᩘࢆ஌ࡌ࡚ᚓࡓ࣏࢖ࣥࢺᩘࠋ
7\SH,,,ࢧࣈࢩࢫࢸ࣒࠾ࡼࡧࢡࣛ࢘ࢻࢩࢫࢸ࣒㸸⤒㐣᫬㛫㸯⛊࡟ࡘࡁ࣏࢖ࣥࢺ࡟౑⏝&38ࢯࢣࢵࢺᩘࢆ஌ࡌ࡚ᚓࡓ࣏࢖ࣥ
ࢺᩘࠋࠉࡓࡔࡋ㸪ࢡࣛ࢘ࢻࢩࢫࢸ࣒ࡢண⣙ࢩࢫࢸ࣒࡛ࡢ฼⏝ࡢሙྜࡣ㸪⤒㐣᫬㛫⛊࡟ࡘࡁ࣏࢖ࣥࢺ࡟౑⏝&38ࢥ࢔ᩘࢆࡑࢀࡒ
ࢀࡢࢧࣈࢩࢫࢸ࣒࡛㸪ඃඛࢪࣙࣈࢡࣛࢫࢆ౑⏝ࡋࡓሙྜࡣ㸪ᚓࡓ㈇ᢸ࣏࢖ࣥࢺ࡟ࢆ஌ࡌ࡚ᚓࡓ࣏࢖ࣥࢺ࡜ࡍࡿࠋ஌ࡌ࡚ᚓࡓ࣏
࢖ࣥࢺᩘࠋスーパーコンピューティングニュース- 27 -

Vol. 24, No.3

2022

᪋⾜㸦㐠⏝㸧
ᖺ᭶᪥

ഛ⪃

኱Ꮫྡ

ி㒔኱Ꮫࡘ࡙ࡁ

㻞 ࢫࢺ࣮ࣞࢪᐜ㔞ࡣࣂࢵࢡ࢔ࢵࣉ㡿ᇦ㸦᭱኱࡛⥲ᐜ㔞ࡢ㸧ࢆྵࡴ

ᇶᮏ㈇ᢸ㢠෇㸭ᖺ෇㸭ᖺ෇㸭ᖺ༨᭷ࣀ࣮ࢻᩘ
ỗ⏝&38ࣀ࣮ࢻ⩌ࣀ࣮ࢻ
*38ࣀ࣮ࢻ⩌ࣀ࣮ࢻ
;HRQ3KLࣀ࣮ࢻ⩌ࣀ࣮ࢻ

1(&2&72386㸦7)/2367%㸧1(&648,'㸦7)/2367%㸧

኱㜰኱Ꮫᖺ᭶⌧ᅾ

ᾘ㈝ಀᩘ





 㸦&㸧ࡣᖺᗘࡢ㏵୰ࡣ㏣ຍ⏦ㄳࡢࡳཷࡅ௜ࡅࡿࠋ
 㸦&㸧ࡣ㸯ࡘࡢ⏦ㄳࢢ࣮ࣝࣉ࡟ࡘࡁࠊ7%ࡢ㏣ຍࢆୖ㝈࡜ࡍࡿࠋࣀ࣮ࢻ⩌ỗ⏝&38ࣀ࣮ࢻ⩌*38ࣀ࣮ࢻ⩌;HRQ3KLࣀ࣮ࢻ⩌኱ᐜ㔞୺グ᠈ᦚ㍕ࣀ࣮ࢻ⩌Ꮨ⠇ಀᩘ኱つᶍィ⟬ᶵࢩࢫࢸ࣒
:(%࣮࣌ࢪ࡟グ㍕

ᾘ㈝ಀᩘ
㧗ඃඛᗘ
㏻ᖖඃඛᗘ






Ꮨ⠇ಀᩘࢩ࢙࢔኱つᶍィ⟬ᶵࢩࢫࢸ࣒

:(%࣮࣌ࢪ࡟グ㍕


㸦㸧21,21 ࢜ࣈࢪ࢙ࢡࢺࢫࢺ࣮ࣞࢪ ࡢ㈇ᢸ㢠
ᇶᮏ㈇ᢸ㢠
ᥦ౪༢఩
෇㸭ᖺഛ⪃
ᖺᗘࡢ㏵୰ࡣ㏣ຍ⏦ㄳࡢࡳཷࡅ௜ࡅࡿࠋ
᪋⾜㸦㐠⏝㸧
ᖺ᭶᪥

7%

 㸦&㸧ࡣᖺᗘࡢ㏵୰ࡣ㏣ຍ⏦ㄳࡢࡳཷࡅ௜ࡅࡿࠋ
 㸦&㸧ࡣ㸯ࡘࡢ⏦ㄳࢢ࣮ࣝࣉ࡟ࡘࡁࠊ+''7%ࠊ66'7%ࡢ㏣ຍࢆୖ㝈࡜ࡍࡿࠋỗ⏝&38ࣀ࣮ࢻ⩌*38ࣀ࣮ࢻ⩌࣋ࢡࢺࣝࣀ࣮ࢻ⩌ࣀ࣮ࢻ⩌㸦㸧648,'ࡢ㈇ᢸ㢠
㸦$㸧༨᭷
ᇶᮏ㈇ᢸ㢠
༨᭷ࣀ࣮ࢻᩘ
෇㸭ᖺỗ⏝&38ࣀ࣮ࢻ⩌ࣀ࣮ࢻ
෇㸭ᖺ*38ࣀ࣮ࢻ⩌ࣀ࣮ࢻ
෇㸭ᖺ࣋ࢡࢺࣝࣀ࣮ࢻ⩌ࣀ࣮ࢻ
㸦%㸧ඹ᭷
ᇶᮏ㈇ᢸ㢠
2&72386࣏࢖ࣥࢺ୓෇࣏࢖ࣥࢺ
୓෇࣏࢖ࣥࢺ
ࢥ࣮ࢫ
୓෇
࣏࢖ࣥࢺ
୓෇࣏࢖ࣥࢺ
୓෇࣏࢖ࣥࢺ
㸦&㸧ࢫࢺ࣮ࣞࢪᐜ㔞㏣ຍ
ᇶᮏ㈇ᢸ㢠
ᥦ౪༢఩
෇㸭ᖺ
+''7%෇㸭ᖺ
66'7% ㈇ᢸ㢠ࡣୖグ㈇ᢸ㢠࡛⟬ฟࡋࡓྜィ㢠࡟ࠊᾘ㈝⛯㸦㸧ࢆຍ࠼࡚ᚓࡓ㢠࡜ࡍࡿࠋഛ⪃ࡓࡔࡋࠊ⏘ᴗ฼⏝ᡂᯝ㠀බ㛤ᆺࡢ㈇ᢸ㢠ࡣࠊୖグ㈇ᢸ㢠࡛⟬ฟࡋࡓྜィ㢠࡟ࢆ஌ࡌࠊ
ᾘ㈝⛯㸦㸧ࢆຍ࠼࡚ᚓࡓ㢠࡜ࡍࡿࠋ Ⓩ㘓᫬ࡢ฼⏝ᮇ㝈ࡲࡓࡣᖺᗘࢆ㉺࠼࡚฼⏝ࡣ࡛ࡁ࡞࠸ࠋ ࢫࢺ࣮ࣞࢪᐜ㔞ࡣ⏦ㄳ༢఩࡛+''7%ࢆ๭ࡾᙜ࡚ࡿࠋࡓࡔࡋࠊ௚ࡢࢫࢺ࣮ࣞࢪᐜ㔞࡜ྜ⟬࡛ࡁ࡞࠸ࠋ
 㸦$㸧ࡣ༨᭷ࣀ࣮ࢻᩘࢆ㏣ຍࡍࡿሙྜࡢࡳኚ᭦⏦ㄳࢆཷࡅ௜ࡅࡿࠋ
 㸦$㸧ࡢࣀ࣮ࢻ௨ୖࡢᇶᮏ㈇ᢸ㢠ࡣࠊࣀ࣮ࢻࢆᇶ‽࡟ẚ౛ࡍࡿࡶࡢ࡜ࡍࡿࠋ
 㸦$㸧ࡣ㈨※ᥦ౪≧ἣ࡟ࡼࡾ࠿᭶༢఩ࡢ⏦ㄳࢆཷࡅ௜ࡅࡿሙྜࡀ࠶ࡿࠋ
ࡑࡢሙྜࡢ᭶㢠ࡢ㈇ᢸ㢠ࡣࠊࣀ࣮ࢻᖺࡢᇶᮏ㈇ᢸ㢠ࡢ࡜ࡍࡿࠋ
 㸦%㸧ࡣᖺᗘࡢ㏵୰࡛ࢥ࣮ࢫࡢኚ᭦ࡣ࡛ࡁ࡞࠸ࠋ᪂ࡓ࡟ࢥ࣮ࢫࢆ㏣ຍࡍࡿሙྜࡣ⏦ㄳࢆཷࡅ௜ࡅࡿࠋ ィ⟬ࣀ࣮ࢻࡢ฼⏝࡟౑⏝ࡍࡿ648,'࣏࢖ࣥࢺࡣࠊ౑⏝ࡋࡓࣀ࣮ࢻ᫬㛫࡟ᑐࡋ࡚௨ୗࡢᾘ㈝ಀᩘ࠾ࡼࡧᏘ⠇ಀᩘࢆ஌ࡌࡓࡶࡢ࡜ࡍࡿࠋᏘ⠇ಀᩘࡣ๓ᖺࡢ฼⏝≧ἣ➼ࢆ㚷ࡳࠊࢆ㉸࠼ࡿ௨ୗࡢ್ࢆタᐃࡍࡿࠋ

ࢥ࣮ࢫ

ᇶᮏ㈇ᢸ㢠
2&72386࣏࢖ࣥࢺ୓෇࣏࢖ࣥࢺ
୓෇࣏࢖ࣥࢺ
୓෇࣏࢖ࣥࢺ
୓෇࣏࢖ࣥࢺ
୓෇࣏࢖ࣥࢺ
㸦&㸧ࢹ࢕ࢫࢡᐜ㔞㏣ຍ
ᇶᮏ㈇ᢸ㢠
ᥦ౪༢఩
෇㸭ᖺ7%㈇ᢸ㢠ୖグ㈇ᢸ㢠࡛⟬ฟࡋࡓྜィ㢠࡟ᾘ㈝⛯㸦㸧ࢆຍ࠼࡚ᚓࡓ㢠 ㈇ᢸ㢠ࡣୖグ㈇ᢸ㢠࡛⟬ฟࡋࡓྜィ㢠࡟ࠊᾘ㈝⛯㸦㸧ࢆຍ࠼࡚ᚓࡓ㢠࡜ࡍࡿࠋഛ⪃ࡓࡔࡋࠊ⏘ᴗ฼⏝ᡂᯝ㠀බ㛤ᆺࡢ㈇ᢸ㢠ࡣࠊୖグ㈇ᢸ㢠࡛⟬ฟࡋࡓྜィ㢠࡟ࢆ஌ࡌࠊ
ᾘ㈝⛯㸦㸧ࢆຍ࠼࡚ᚓࡓ㢠࡜ࡍࡿࠋ Ⓩ㘓᫬ࡢ฼⏝ᮇ㝈ࡲࡓࡣᖺᗘࢆ㉺࠼࡚฼⏝ࡣ࡛ࡁ࡞࠸ࠋ ࢹ࢕ࢫࢡᐜ㔞ࡣ⏦ㄳ༢఩࡛7%ࢆ๭ࡾᙜ࡚ࡿࠋࡓࡔࡋࠊ௚ࡢࢹ࢕ࢫࢡᐜ㔞࡜ྜ⟬࡛ࡁ࡞࠸ࠋ
 㸦$㸧ࡣ༨᭷ࣀ࣮ࢻᩘࢆ㏣ຍࡍࡿሙྜࡢࡳኚ᭦⏦ㄳࢆཷࡅ௜ࡅࡿࠋ
 㸦$㸧ࡢࣀ࣮ࢻ௨ୖࡢᇶᮏ㈇ᢸ㢠ࡣࠊࣀ࣮ࢻࢆᇶ‽࡟ẚ౛ࡍࡿࡶࡢ࡜ࡍࡿࠋ
 㸦$㸧ࡣ㈨※ᥦ౪≧ἣ࡟ࡼࡾࣀ࣮ࢻ௨ୖ࠿᭶༢఩ࡢ⏦ㄳࢆཷࡅ௜ࡅࡿሙྜࡀ࠶ࡿࠋ
ࡑࡢሙྜࡢ᭶㢠ࡢ㈇ᢸ㢠ࡣࠊࣀ࣮ࢻᖺࡢᇶᮏ㈇ᢸ㢠ࡢ࡜ࡍࡿࠋ
 㸦%㸧ࡣᖺᗘࡢ㏵୰࡛ࢥ࣮ࢫࡢኚ᭦ࡣ࡛ࡁ࡞࠸ࠋ᪂ࡓ࡟ࢥ࣮ࢫࢆ㏣ຍࡍࡿሙྜࡣ⏦ㄳࢆཷࡅ௜ࡅࡿࠋ ィ⟬ࣀ࣮ࢻࡢ฼⏝࡟౑⏝ࡍࡿ2&72386࣏࢖ࣥࢺࡣࠊ౑⏝ࡋࡓࣀ࣮ࢻ᫬㛫࡟ᑐࡋ࡚௨ୗࡢᾘ㈝ಀᩘ࠾ࡼࡧᏘ⠇ಀᩘࢆ஌ࡌࡓࡶࡢ࡜ࡍࡿࠋᏘ⠇ಀᩘࡣ๓ᖺࡢ฼⏝≧ἣ➼ࢆ㚷ࡳࠊࢆ㉸࠼ࡿ௨ୗࡢ್ࢆタᐃࡍࡿࠋ

㸦%㸧ඹ᭷

㸦$㸧༨᭷

㸦㸧2&72386ࡢ㈇ᢸ㢠୰ኸฎ⌮⿦⨨
࣓࣮ࣔࣜࢧ࢖ࢬ

኱Ꮫྡ㸵኱Ꮫࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ฼⏝㈇ᢸ㔠⾲㸳㸦ி㒔኱Ꮫ࣭኱㜰኱Ꮫ㸧䚷ഛ⪃㻝 ฼⏝㈇ᢸ㢠ࡣࠊᖺᗘ༢఩࡛⟬ᐃࡋ࡚࠸ࡿࠋࡲࡓࠊ⥲㢠⾲♧࡛࠶ࡿࠋࣃ࣮ࢯࢼࣝࢥ࣮ࢫࠊࢢ࣮ࣝࣉࢥ࣮ࢫཪࡣᑓ
⏝ࢡࣛࢫࢱࢥ࣮ࢫࢆࠊᖺᗘ㏵୰࠿ࡽ฼⏝ࢆ㛤ጞࡍࡿሙྜཬࡧᖺᗘ㏵୰࡛฼⏝ࢆ⤊஢ࡍࡿሙྜࡢ฼⏝㈇ᢸ㢠ࡣࠊୖグ⾲୰ࡢ฼⏝㈇ᢸ㢠ࢆ࡛㝖ࡋࡓᚋࠊ฼⏝᭶ᩘࢆ஌ࡌ࡚⟬ฟࡍࡿࡶࡢ࡜ࡋࠊ෇ᮍ‶࡟➃ᩘࡀฟࡓሙྜࡣࠊ
෇༢఩ࢆᅄᤞ஬ධࡍࡿࡶࡢ࡜ࡍࡿࠋ࡞࠾ࠊ᭶㏵୰࠿ࡽ฼⏝ࢆ㛤ጞࡍࡿሙྜཬࡧ᭶㏵୰࡛฼⏝ࢆ⤊஢ࡍࡿሙྜ
ࡣࠊࡑࢀࡒࢀ᭶ࡢ฼⏝࡜ࡍࡿࠋி㒔኱Ꮫスーパーコンピューティングニュース- 28 -

Vol. 24, No.3

2022

Ẹ
ࠉ
㛫
ࠉ
฼
ࠉ
⏝

᪋⾜㸦㐠⏝㸧
ᖺ᭶᪥

ഛ⪃

ࢫࢺ࣮ࣞࢪ

ඹ᭷ࢱ࢖ࣉ

༊ศ

ഛ⪃

ࢫࢺ࣮ࣞࢪ

බເᆺ
ࣉࣟࢪ࢙ࢡࢺ୍ ࣀ࣮ࢻᅛᐃࢱ࢖ࣉ
ࠉ
⯡
ࠉ
฼
ࠉ
⏝

ඹ᭷ࢱ࢖ࣉ

༊ศ

୰ኸฎ⌮⿦⨨
࣓࣮ࣔࣜࢧ࢖ࢬ

኱Ꮫྡ↓ᩱ

0ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇
/ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

6ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉ7%᭶㢠㸸෇ࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉ7%᭶㢠㸸෇
࣭ୖグࡢ㔠㢠ࡣᾘ㈝⛯ࢆྵࡴࠋ࣭㸯ࣨ᭶ᮍ‶ࡢ฼⏝ᮇ㛫࡟ࡘ࠸࡚ࡣࠊᙜヱ฼⏝ᮇ㛫ࢆ㸯ࣨ᭶࡜ࡳ࡞ࡍࠋ

ࣀ࣮ࢻ
᭶㢠㸸෇

ࣀ࣮ࢻ
᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇↓ᩱࣀ࣮ࢻ᭶㢠㸸෇

/ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

0ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇↓ᩱ

/ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

/ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

0ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

0ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

,72኱ᐜ㔞ࣇࣟࣥࢺ࢚ࣥࢻ
7%

ᖺ᭶⌧ᅾ㸵኱Ꮫࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱ฼⏝㈇ᢸ㔠⾲㸴㸦஑ᕞ኱Ꮫ㸧

6ࣉࣛࣥ>ࢥ࢔᫬㛫✚@᭶㢠㸸෇

,72ᇶᮏࣇࣟࣥࢺ࢚ࣥࢻ
*%

஑ᕞ኱Ꮫࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉ7%᭶㢠㸸෇ࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉࠉ7%᭶㢠㸸෇
࣭ୖグࡢ㔠㢠ࡣᾘ㈝⛯ࢆྵࡴࠋ࣭㸯ࣨ᭶ᮍ‶ࡢ฼⏝ᮇ㛫࡟ࡘ࠸࡚ࡣࠊᙜヱ฼⏝ᮇ㛫ࢆ㸯ࣨ᭶࡜ࡳ࡞ࡍࠋ

↓ᩱ

ࣀ࣮ࢻ
᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࣀ࣮ࢻ
᭶㢠㸸෇

ࣀ࣮ࢻ
᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

ࣀ࣮ࢻ᭶㢠㸸෇

,72ࢧࣈࢩࢫࢸ࣒%*%

ࣀ࣮ࢻ᭶㢠㸸෇

,72ࢧࣈࢩࢫࢸ࣒$*%

スーパーコンピュータ利用による成果報告（2021 年）
利用者の皆様には、スーパーコンピュータシステムを利用して得られた研究成果（論文、口頭発表、著書、受賞情報）の登録にご協力いただき、誠にありがとうございます。今回はその中の 2021 年分（2021
年 1 月～2021 年 12 月）を掲載いたします。
研究成果の登録は、Web ページ (https://www.cc.u-tokyo.ac.jp/achievements/) にある「研究成果登録」から行うことができます。何卒ご協力のほどよろしくお願い申し上げます。

－Wisteria/BDEC-01－● 口頭・ポスター発表【材料工学】
1. [Odyssey] 大野直子、河村創憲: ODS 鋼に形成される複合酸化物の照射安定性 〜第一原理計算による酸化物の照射耐性評価〜: 材料照射研究会「原子力イノベーションを見据えた材料研究」, 材料照射研究会 予稿集, O-22.

－Oakbridge-CX－● 論文【応用物理学】
2. Mizuki Tani, Tomohito Otobe, Yasushi Shinohara, and Kenichi L. Ishikawa: Semiclassical description ofelectron dynamics in extended systems under intense laser fields: Physical Review B, The American PhysicalSociety, 104, 7.
【物理学】
3. 越智正之: 第一原理計算を用いた物質設計：その電子状態の次元性に注目して: 生産と技術, 生
産技術振興協会, 73, 1.
4. Hiroshi Takatsu, Masayuki Ochi, Morito Namba, Haobo Li, Aurelien Daniel, Takahito Terashima, Kazuhiko
Kuroki, and Hiroshi Kageyama: Strain-Assisted Topochemical Synthesis of La-Doped SrVO2H Films:
Crystal Growth & Design, American Chemical Society, 21, 7.
5. Y. Yamashita, G. Lim, T. Maruyama, A. Chikamatsu, T. Hasegawa, H. Ogino, T. Ozawa, M. Wilde, K.
Fukutani, T. Terashima, M. Ochi, K. Kuroki, H. Kitagawa, and M. Maesato: Heavy carrier doping byhydrogen in the spin-orbit coupled Mott insulator Sr2IrO4: Physical Review B, American Physical Society,
104, 4.
6. R. Mizuno, M. Ochi, and K. Kuroki: Development of an efficient impurity solver in dynamical mean field
theory for multiband systems: Iterative perturbation theory combined with parquet equations: Physical Review
B, American Physical Society, 104, 3.
7. K. Higashi, M. Ochi, Y. Nambu, T. Yamamoto, T. Murakami, N. Yamashina, C. Tassel, Y. Matsumoto, H.
Takatsu, C. M. Brown, and H. Kageyama: Enhanced Magnetic Interaction by Face-Shared Hydride Anions in
6H-BaCrO2H: Inorganic Chemistry, ACS Publications, 60, 16.
8. K. Miyazaki, M. Ochi, T. Nishikubo, J. Suzuki, T. Saito, T. Kamiyama, K. Kuroki, T. Yamamoto, and M.
Azuma: High-Pressure and High-Temperature Synthesis of Anion-Disordered Vanadium Perovskite
Oxyhydrides: Inorganic Chemistry, American Chemical Society, 60, 20.
【地球惑星科学】
9. Nishizawa, S., T. Yamaura, and Y. Kajikawa: Influence of sub-mesoscale topography on daytime precipitation
associated with thermally driven local circulations over a mountainous region: Journal of Atmospheric
Science, American Meteorological Society, 78, 8.
【総合工学】
10. Sugaya, K., and Imamura, T.: Unsteady turbulent flow simulations on moving Cartesian grids using immersedboundary method and high-order scheme: Computers and Fluids, Elsevier, Vol. 231.
11. 張毅: Toward Retrieving Distributed Aquifer Hydraulic Parameters From Distributed Strain Sensing: Journalof Geophysical Research: Solid Earth, American Geophysical Union, 126.

スーパーコンピューティングニュース- 29 -

Vol. 24, No.3

2022

● 口頭・ポスター発表【物理学】
12. 越智正之: 複合アニオン化合物の物質機能の第一原理的研究: 日本物理学会第 76 回年次大会（2021年）.
13. 越智正之: 複合アニオン化合物における理論物質設計の試み: 第 12 回複合アニオン ウェブセミナー.
【総合工学】
14. Keisuke Sugaya and Taro Imamura: Unsteady Flow Simulation using Immersed Boundary Method on
Cartesian Grid with Moving Grid Technique: AIAA Scitech 2021 Forum.
15. 菅谷圭祐，原惇，今村太郎: 階層型直交格子と再帰的なフィッティングを用いた低速・高迎角条件における NASA-CRM 巡航形態の空力予測: 第 53 回流体力学講演会／第 39 回航空宇宙数値シミュレーショ
ン技術シンポジウム, 1A17.
16. 菅谷圭祐，今村太郎: 埋め込み境界法と移動格子による Caradonna-Tung 回転翼の非定常乱流解析:
第 53 回流体力学講演会／第 39 回航空宇宙数値シミュレーション技術シンポジウム, 2E07.

－Oakforest-PACS－● 論文【計算基盤】
17. Hiroshi Murakami: Single-Precision Calculation of Iterative Refinement of Eigenpairs of a Real SymmetricDefinite Generalized Eigenproblem by Using a Filter Composed of a Single Resolvent: ICPS Proceedings of
HPC Asia 2021 Companion "ISBN 978-1-4503-8303-5", ACM.
【物理学】
18. Noritaka Shimizu, Yusuke Tsunoda, Yutaka Utsuno, and Takaharu Otsuka: Variational approach with thesuperposition of the symmetry-restored quasiparticle vacua for nuclear shell-model calculations: PhysicalReview C, American Physical Society, 103.
【地球惑星科学】
19. Takeshi Nishimura, Kentaro Emoto, Hisashi Nakahara, Satoshi Miura, Mare Yamamoto, Shunsuke Sugimura,
Ayumu Ishikawa and Tsunehisa Kimura: Source location of volcanic earthquakes and subsurface
characterization using fiber-optic cable and distributed acoustic sensing system: Scientific Reports, Nature
Research, 11.
20. Yohei Onuki, Sylvain Joubaud, Thierry Dauxois: Simulating turbulent mixing caused by local instability ofinternal gravity waves: Journal of Fluid Mechanics, Cambridge University Press, 915.
【土木工学】
21. Masahide Otsubo, Reiko Kuwano, Catherine O''Sullivan, Thomas Shire: Using geophysical data to quantify
stress transmission in gap-graded granular materials: Géotechnique, Thomas Telford Ltd. .
22. Yang Li, Masahide Otsubo, Reiko Kuwano: DEM analysis on the stress wave response of spherical particle
assemblies under triaxial compression: Computers and Geotechnics, Elsevier, Vol.133, 104043.

－Reedbush－● 論文【生物科学】
23. [Reedbush-H] Yushiro Endo, Tomohiro Koga, Hiroki Otaki, Kaori Furukawa, Atsushi Kawakami: Systemic
lupus erythematosus overlapping dermatomyositis owing to a heterozygous TREX1 Asp130Asn missense
mutation: Clinical Immunology, Elsevier, 227.
【内科系臨床医学】
24. [Reedbush-L] 弘瀬拓矢、土岐富士緒、西村栄美、難波大輔、古徳純一: Label-free quality control andidentification of human keratinocyte stem cells by deep learning-based automated cell tracking: Stem Cells.

スーパーコンピューティングニュース- 30 -

Vol. 24, No.3

2022



研究成果の登録のお願い
情報戦略課研究支援チーム
情報基盤センタースーパーコンピューティング部門

研究成果の登録は、本センターのスーパーコンピューターシステムを利用して得られた研究成果のうち、論文、口頭発表、著書、受賞情報についてご報告いただくものです。研究成果の登録は、本センタースーパーコンピューティング部門の :HE サイト（KWWSVZZZFFXWRN\
RDFMS）から「研究成果登録」に進んでください。なお、ご報告いただいた内容は、研究
成果データベースへの登録、本センター発行の広報誌及び :HE ページに掲載させていただきま
すので、ご了解ください。
研究成果は、東京大学におけるスーパーコンピューターシステムの整備・拡充につながるものとなりますので、利用者の皆様には何卒ご協力くださいますようお願い申し上げます。


① 「研究成果」をクリック㻌

② 研究成果ページの「研究成果登録」をクリック㻌

③アカウント名（利用者番号）㻌
及びメールアドレスを入力し、㻌登録したい業績を選択㻌

④「ログイン」をクリックし、成果登録ページで㻌
研究成果の登録をお願いいたします㻌
スーパーコンピューティングニュース- 31 -

Vol. 24, No.3

2022

㻥㻣㻠

㻝㻘㻝㻜㻟

㻥㻟㻥

㻝㻘㻜㻡㻤

㻝㻘㻝㻥㻟

㻝㻘㻞㻣㻥

㻝㻘㻞㻤㻢

㻝㻘㻟㻞㻟

㻝㻘㻞㻥㻟

㻝㻘㻞㻞㻝

㻢᭶

㻣᭶

㻤᭶

㻥᭶

㻝㻜᭶

㻝㻝᭶

㻝㻞᭶

㻞㻜㻞㻞ᖺ㻝᭶

㻞᭶

㻟᭶
㻞㻘㻞㻜㻝

㻝㻤㻣

㻞㻣㻡

㻞㻞㻜

㻟㻢㻢

㻟㻝㻝

㻞㻞㻢

㻝㻡㻜

㻞㻤

㻢㻠

㻝㻤㻢

㻝㻤㻤

㻝㻤㻡㻘㻠㻣㻜

㻢㻜㻘㻞㻢㻡

㻝㻟㻘㻠㻠㻥

㻞㻣㻘㻝㻜㻤

㻥㻘㻣㻡㻞

㻣㻘㻟㻠㻜

㻝㻞㻘㻣㻡㻥

㻞㻜㻘㻠㻟㻝

㻠㻘㻡㻡㻝㻝㻜㻘㻣㻟㻜

㻝㻞㻘㻟㻢㻣

㻢㻘㻣㻝㻤㻞㻣㻝㻘㻥㻥㻡

㻟㻝㻘㻞㻜㻟

㻞㻥㻘㻡㻡㻟

㻟㻟㻘㻡㻡㻜

㻟㻝㻘㻥㻡㻞

㻞㻢㻘㻢㻣㻢

㻞㻣㻘㻡㻤㻥

㻝㻥㻘㻣㻢㻥

㻥㻘㻤㻢㻢㻞㻠㻘㻣㻞㻟

㻞㻟㻘㻠㻥㻝

㻝㻟㻘㻢㻞㻟

㻝㻘㻝㻟㻝

㻝㻘㻝㻜㻡

㻥㻢㻝

㻤㻟㻣

㻣㻣㻠

㻡㻤㻜

㻠㻟㻠

㻟㻤㻟

㻠㻟㻤

㻟㻢㻝

㻝㻠㻤

㻛㼔㼛㼙㼑

㻝㻘㻜㻜㻣㻘㻟㻞㻣㻝㻘㻜㻞㻝㻘㻥㻞㻥㻥㻣㻥㻘㻤㻜㻢

㻤㻟㻟㻘㻣㻟㻞

㻡㻝㻡㻘㻢㻟㻝

㻟㻥㻢㻘㻞㻠㻜

㻞㻠㻢㻘㻜㻢㻟

㻝㻞㻤㻘㻟㻟㻣

㻞㻝㻝㻘㻢㻥㻢

㻝㻤㻥㻘㻜㻝㻤

㻢㻢㻘㻝㻞㻝

㻛㼘㼡㼟㼠㼞㼑

䝣䜯䜲䝹౑⏝㔞㻌㼇㻳㼕㻮㼉㻞㻣㻘㻥㻤㻟

㻥㻘㻢㻠㻞㻚㻡㻞

㻞㻘㻢㻣㻡㻚㻡㻝

㻝㻘㻥㻞㻢㻚㻠㻣

㻝㻘㻤㻣㻥㻚㻤㻟

㻟㻘㻜㻥㻞㻚㻥㻝

㻤㻟㻢㻚㻡㻝

㻝㻘㻥㻠㻠㻚㻣㻥

㻞㻘㻞㻝㻤㻚㻠㻤

㻝㻘㻢㻣㻜㻚㻝㻜

㻝㻘㻟㻥㻤㻚㻢㻜

㻢㻥㻣㻚㻟㻞

䝻䜾䜲䞁䠄ᐇ㻯㻼㼁䠅

㻞㻘㻟㻟㻥

㻟㻞㻞

㻠㻥㻢

㻞㻡㻢

㻝㻞㻟

㻤㻢

㻞㻤㻠

㻞㻤㻝

㻞㻡㻡

㻣㻠

㻝㻞㻞

㻠㻜

䝥䝸䝫䝇䝖

㻡㻥㻟

㻠㻞

㻝㻞㻠

㻢㻜

㻢㻠

㻥㻝

㻤㻡

㻠㻜

㻢

㻝㻜

㻟㻢

㻟㻡

䜲䞁䝍䝷䜽䝔䜱䝤
䝆䝵䝤㻡㻘㻣㻥㻝㻘㻝㻢㻞㻝㻘㻞㻞㻞㻘㻞㻡㻠㻤㻝㻟㻘㻥㻢㻤

㻤㻜㻝㻘㻝㻥㻤

㻢㻣㻞㻘㻡㻥㻝

㻝㻠㻣㻘㻡㻠㻥

㻟㻡㻝㻘㻠㻟㻡

㻞㻜㻠㻘㻞㻣㻥

㻝㻞㻟㻘㻟㻞㻞

㻢㻥㻤㻘㻠㻜㻡

㻠㻣㻟㻘㻠㻠㻢

㻞㻤㻞㻘㻣㻝㻡

䝞䝑䝏䝆䝵䝤

₇⟬᫬㛫㻌㼇䝜䞊䝗᫬㛫㼉㻌䠄⤒㐣᫬㛫䠅

㻠㻜
㻟㻜
㻝㻜
㻜

㻢㻜㻜㻘㻜㻜㻜
㻠㻜㻜㻘㻜㻜㻜
㻞㻜㻜㻘㻜㻜㻜
㻜㻟㻜㻘㻜㻜㻜

㻞㻜㻘㻜㻜㻜

㻝㻜㻘㻜㻜㻜

䝻䜾䜲䞁௳ᩘ
䜲䞁䝍䝷䜽䝔䜱䝤௳ᩘ䝞䝑䝏䝆䝵䝤௳ᩘ₇⟬᫬㛫㻔䝞䝑䝏⤒㐣㻕㻢㻜㻤㻜㻜㻘㻜㻜㻜

㻠㻜㻘㻜㻜㻜

㻜

㻣㻜

㻞㻜

㻡㻜

㻤㻜

㻥㻜

㻝㻘㻜㻜㻜㻘㻜㻜㻜㻝㻜㻜฼⏝⋡㻔䠂㻕

㻞㻜㻞㻝ᖺ㻠᭶₇⟬᫬㛫㻔䝜䞊䝗᫬㛫㻕㻡㻜㻘㻜㻜㻜

㻤᭶㻝㻘㻞㻜㻜㻘㻜㻜㻜㻝㻞᭶㻢㻜㻘㻜㻜㻜

㻞㻜㻞㻞ᖺ㻝᭶㻝㻘㻠㻜㻜㻘㻜㻜㻜㻞᭶㻣㻜㻘㻜㻜㻜

᭶ู฼⏝≧ἣ

䝜䞊䝗฼⏝⋡

㻝㻝᭶
㻣᭶

㻢᭶

㻡᭶

䞉䝜䞊䝗฼⏝⋡䠖䚷䝃䞊䝡䝇䝜䞊䝗䛻ᑐ䛩䜛฼⏝ẚ⋡䚹䚷ィ⟬ᘧ䠙䝜䞊䝗฼⏝ᩘ㾂䝃䞊䝡䝇䝜䞊䝗ᩘ㽢㻝㻜㻜

㻝㻞᭶

㻝㻜᭶
㻥᭶

㻤᭶

䞉䝻䜾䜲䞁䠄ᐇ㻯㻼㼁䠅䠖䚷䝁䜰᫬㛫༢఩㻞㻜㻞㻞ᖺ㻝᭶

㻝㻝᭶

㻝㻜᭶

㻥᭶

㻣᭶

㻢᭶

㻡᭶

㻞㻜㻞㻝ᖺ㻠᭶- 32 -

㻞᭶㻝㻘㻣㻝㻡㻚㻣

㻝㻘㻞㻟㻡㻚㻟

㻝㻘㻜㻥㻢㻚㻜

㻥㻞㻜㻚㻝

㻞㻜㻤㻚㻤

㻠㻤㻜㻚㻥

㻞㻤㻥㻚㻜

㻞㻝㻥㻚㻠

㻝㻘㻠㻥㻞㻚㻞

㻤㻠㻞㻚㻡

㻞㻞㻚㻟

㻝㻢㻚㻝

㻝㻠㻚㻟

㻝㻞㻚㻜

㻞㻚㻣

㻢㻚㻟

㻟㻚㻤

㻞㻚㻥

㻝㻥㻚㻠

㻝㻝㻚㻜

㻝㻜㻚㻣

㻔㻑㻕

㻤㻞㻞㻚㻜

㻔䝜䞊䝗㻕

䢅䡬䢀䢚
฼⏝⋡

฼⏝ᩘ

ᖹᆒ䢅䡬䢀䢚

䞉䝜䞊䝗฼⏝ᩘ䠖䚷䜲䞁䝍䝷䜽䝔䜱䝤䛚䜘䜃䝞䝑䝏䝆䝵䝤䛾⤒㐣᫬㛫䜢㻝䝜䞊䝗䛜㻝㻜㻜㻑ືస䛧䛯䛸௬ᐃ䛧䛯ሙྜ䛾฼⏝䝜䞊䝗ᩘ䚹

㻝㻘㻝㻣㻤

㻝㻟㻡

㻝㻢㻤

㻥㻞

㻣㻢

㻣㻢

㻞㻡㻢

㻣㻢

㻤㻞

㻢㻢

㻥㻣

㻡㻠

䝥䝸䝫䝇䝖

᥋⥆᫬㛫
㼇᫬㛫㼉

㻌㻌ィ⟬ᘧ䠙㻝䞄᭶䛾䜲䞁䝍䝷䜽䝔䜱䝤䛚䜘䜃䝞䝑䝏䝆䝵䝤⤒㐣᫬㛫ྜィ㾂㻝䞄᭶䛾✌ື᫬㛫㻡㻢㻘㻤㻢㻡

㻢㻘㻤㻥㻢

㻢㻘㻜㻝㻡

㻣㻘㻟㻞㻥

㻢㻘㻝㻤㻥

㻡㻘㻟㻟㻣

㻡㻘㻞㻞㻝

㻟㻘㻤㻟㻡

㻞㻘㻞㻝㻞

㻠㻘㻢㻟㻤

㻡㻘㻤㻠㻡

㻟㻘㻟㻠㻤

䝻䜾䜲䞁

䜲䞁䝍䝷䜽䝔䜱䝤
䝞䝑䝏䝆䝵䝤䝆䝵䝤ฎ⌮௳ᩘ䞉᥋⥆᫬㛫䠖䚷䝻䜾䜲䞁᫬㛫䛾⣼ィ

㻞㻢㻡

㻞㻢㻥

㻞㻥㻠

㻞㻥㻤

㻞㻡㻢

㻟㻝㻝

㻝㻥㻢

㻝㻠㻣

㻞㻞㻥

㻞㻣㻜

㻞㻜㻢

ᐇ฼⏝⪅ᩘ

䞉ヨ㐠㌿䛿䚸㻞㻜㻞㻝ᖺ㻡᭶㻝㻠᪥䜘䜚㛤ጞ䚹ṇᘧ䝃䞊䝡䝇䛿䚸㻞㻜㻞㻝ᖺ㻤᭶㻞᪥䜘䜚㛤ጞ

ྜィ

㻤㻢㻜

㻞㻜㻞㻝ᖺ㻡᭶

Ⓩ㘓⪅ᩘ

㻟᭶

ᖺ᭶

㻝䠊㼃㼕㼟㼠㼑㼞㼕㼍㻛㻮㻰㻱㻯㻙㻜㻝䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䝅䝇䝔䝮䠄㻻㼐㼥㼟㼟㼑㼥䠅㻌䝆䝵䝤ฎ⌮≧ἣ䚷䠄㻾㼑㼐㻴㼍㼠㻌㻱㼚㼠㼑㼞㼜㼞㼕㼟㼑㻌㻸㼕㼚㼡㼤㻌㻤䠅㻞䞉㻟᭶䛾䝆䝵䝤⤫ィ㻟᭶

スーパーコンピューティングニュースVol. 24, No.3

2022

㻠㻣㻥

㻟᭶

㻝㻡㻜㻚㻝

㻝㻠㻣㻚㻜

㻝㻟㻣㻚㻣

㻝㻠㻤㻚㻡

㻥㻝㻚㻥

㻤㻣㻚㻡

㻢㻡㻚㻝

㻢㻣㻚㻥

㻝㻤㻜㻚㻥

㻝㻠㻟㻚㻟

᭶ู฼⏝≧ἣ

㻥㻜㻝㻤㻜㻘㻜㻜㻜

Vol. 24, No.3

₇⟬᫬㛫㻔䝞䝑䝏⤒㐣㻕䝞䝑䝏䝆䝵䝤௳ᩘ䜲䞁䝍䝷䜽䝔䜱䝤௳ᩘ㻜㻝㻜㻞㻜㻘㻜㻜㻜
㻜㻞㻜㻠㻜㻘㻜㻜㻜

㻡㻘㻜㻜㻜

㻜

㻟㻜

㻢㻜㻘㻜㻜㻜

㻝㻜㻘㻜㻜㻜

㻝㻡㻘㻜㻜㻜

㻠㻜㻝㻜㻜㻞㻜㻜㻘㻜㻜㻜

฼⏝⋡㻔䠂㻕

㻞㻜㻞㻝ᖺ㻠᭶₇⟬᫬㛫㻔㻳㻼㼁᫬㛫㻕㻡㻜㻞㻜㻞㻝ᖺ㻠᭶㻤㻜㻘㻜㻜㻜㻡᭶㻢㻜㻢᭶㻝㻜㻜㻘㻜㻜㻜

㻣᭶

㻣㻜

㻥᭶

㻝㻞㻜㻘㻜㻜㻜

㻝㻜᭶㻞㻜㻘㻜㻜㻜

㻝㻝᭶

㻤㻜

㻝㻞᭶

㻝㻠㻜㻘㻜㻜㻜

㻞㻜㻞㻞ᖺ㻝᭶㻝㻢㻜㻘㻜㻜㻜

㻞᭶㻞㻡㻘㻜㻜㻜

㻟㻜㻘㻜㻜㻜

㻤᭶㻳㻼㼁฼⏝⋡

䞉㻳㻼㼁฼⏝⋡䠖䚷䝃䞊䝡䝇㻳㻼㼁䛻ᑐ䛩䜛฼⏝ẚ⋡䚹䚷ィ⟬ᘧ䠙㻳㻼㼁฼⏝ᩘ㾂䝃䞊䝡䝇㻳㻼㼁ᩘ㽢㻝㻜㻜㻡᭶㻌㻌ィ⟬ᘧ䠙㻝䞄᭶䛾䜲䞁䝍䝷䜽䝔䜱䝤䛚䜘䜃䝞䝑䝏䝆䝵䝤⤒㐣᫬㛫ྜィ㾂㻝䞄᭶䛾✌ື᫬㛫

㻠㻝㻚㻣

㻠㻜㻚㻤

㻟㻤㻚㻞

㻠㻝㻚㻞

㻞㻡㻚㻡

㻞㻠㻚㻟

㻝㻤㻚㻝

㻝㻤㻚㻥

㻡㻜㻚㻟

㻟㻥㻚㻤

㻞㻠㻚㻟

㻔㻑㻕

㻤㻣㻚㻡

㻔㻳㻼㼁㻕

㻢᭶

㻌㻌䝻䜾䜲䞁䠄ᐇ㻯㻼㼁䠅䛿㼃㼕㼟㼠㼑㼕㼞㼍㻛㻮㻰㻱㻯㻙㻜㻝㻔㻻㼐㼥㼟㼟㼑㼥㻕㻌䛸ඹ㏻䚹

㻣㻜㻝㻘㻜㻤㻤

㻤㻡㻘㻢㻡㻜

㻣㻠㻘㻥㻤㻞

㻣㻢㻘㻢㻟㻜

㻤㻠㻘㻝㻤㻣

㻠㻢㻘㻤㻥㻡

㻠㻢㻘㻟㻞㻣

㻞㻤㻘㻣㻜㻞

㻞㻠㻘㻝㻤㻤

㻝㻜㻡㻘㻞㻟㻥

㻥㻞㻘㻢㻠㻟

㻟㻡㻘㻢㻠㻡

㻣᭶䞉㻳㻼㼁฼⏝ᩘ䠖䚷䜲䞁䝍䝷䜽䝔䜱䝤䛚䜘䜃䝞䝑䝏䝆䝵䝤䛾⤒㐣᫬㛫䜢㻝㻳㻼㼁䛜㻝㻜㻜㻑ືస䛧䛯䛸௬ᐃ䛧䛯ሙྜ䛾฼⏝㻳㻼㼁ᩘ䚹

㻣㻘㻣㻡㻤

㻠㻝㻣

㻤㻜㻝

㻢㻞㻟

㻥㻡㻣

㻝㻘㻝㻜㻣

㻥㻝

㻟㻡㻤

㻠㻣㻜

㻝㻘㻡㻟㻝

㻝㻘㻞㻠㻡

㻝㻡㻤

㻳㻼㼁
฼⏝⋡

฼⏝ᩘ

ᖹᆒ㻳㻼㼁

㻤᭶

䞉ヨ㐠㌿䛿䚸㻞㻜㻞㻝ᖺ㻡᭶㻝㻠᪥䜘䜚㛤ጞ䚹ṇᘧ䝃䞊䝡䝇䛿䚸㻞㻜㻞㻝ᖺ㻤᭶㻞᪥䜘䜚㛤ጞ㻤㻢㻘㻡㻤㻡

㻣㻘㻞㻜㻠

㻢㻘㻝㻝㻢

㻤㻘㻤㻠㻢

㻣㻘㻞㻜㻥

㻡㻘㻤㻞㻠

㻟㻘㻝㻟㻥

㻟㻘㻡㻥㻥

㻟㻘㻜㻜㻠

㻝㻡㻘㻝㻡㻡

㻞㻝㻘㻟㻥㻠

㻡㻘㻜㻥㻡䝞䝑䝏䝆䝵䝤

₇⟬᫬㛫㻌㼇㻳㻼㼁᫬㛫㼉㻔⤒㐣᫬㛫㻕䜲䞁䝍䝷䜽䝔䜱䝤
䝆䝵䝤

㻝㻝᭶

㻝㻜᭶
㻥᭶

- 33 -

㻝㻞᭶

䞉Ⓩ㘓⪅ᩘ䚸ᐇ฼⏝⪅ᩘ䚸䝻䜾䜲䞁௳ᩘ䚸᥋⥆᫬㛫䚸䝣䜯䜲䝹౑⏝㔞䚸

㻤㻘㻝㻝㻥

㻤㻢㻟

㻞᭶

ྜィ

㻢㻝㻡

㻞㻣㻞

㻝㻜᭶

㻞㻜㻞㻞ᖺ㻝᭶

㻠㻤㻜

㻥᭶

㻝㻘㻝㻞㻞

㻠㻢㻢

㻤᭶

㻝㻘㻜㻣㻣

㻝㻘㻡㻠㻜

㻣᭶

㻝㻝᭶

㻥㻡㻟

㻢᭶

㻝㻞᭶

㻞㻡㻞

㻞㻜㻞㻝ᖺ㻡᭶䝞䝑䝏䝆䝵䝤

ฎ⌮௳ᩘ䜲䞁䝍䝷䜽䝔䜱䝤
䝆䝵䝤

㻟᭶

ᖺ᭶

㻞䠊㼃㼕㼟㼠㼑㼞㼕㼍㻛㻮㻰㻱㻯㻙㻜㻝䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䝅䝇䝔䝮䠄㻭㼝㼡㼍㼞㼕㼡㼟䠅㻌䝆䝵䝤ฎ⌮≧ἣ䚷䠄㻾㼑㼐㻴㼍㼠㻌㻱㼚㼠㼑㼞㼜㼞㼕㼟㼑㻌㻸㼕㼚㼡㼤㻌㻤䠅㻞᭶㻞㻜㻞㻞ᖺ㻝᭶

スーパーコンピューティングニュース

2022

㻟᭶

㻞㻥㻥

㻟㻡㻤

㻟㻢㻢

㻞㻣㻤

㻞㻤㻠

㻟㻜㻡

㻝㻘㻝㻥㻢

㻝㻘㻜㻤㻣

㻝㻘㻝㻟㻞

㻝㻘㻝㻠㻝

㻝㻘㻜㻢㻣

㻝㻘㻝㻞㻜

㻝㻘㻝㻣㻥

㻝㻘㻝㻤㻣

㻝㻘㻞㻜㻜

㻝㻘㻞㻞㻥

㻝㻘㻞㻠㻡

㻡᭶

㻢᭶

㻣᭶

㻤᭶

㻥᭶

㻝㻜᭶

㻝㻝᭶

㻝㻞᭶

㻞㻜㻞㻞ᖺ㻝᭶㻞᭶㻟᭶᭶ู฼⏝≧ἣ

㻝㻥㻠

㻜

㻜

㻜

㻞

㻜

㻞㻥

㻝㻣

㻡㻥

㻠㻞

㻠㻟

㻜

㻞

㻞㻝㻘㻥㻣㻢

㻠㻜㻟

㻡㻞㻝

㻠㻥㻣

㻣㻢㻟

㻣㻘㻟㻣㻜

㻟㻘㻤㻥㻤

㻝㻘㻡㻤㻡

㻝㻘㻤㻝㻠

㻝㻘㻤㻢㻜

㻝㻘㻟㻡㻢

㻥㻤㻞

㻥㻞㻣

㻠㻥㻣㻘㻟㻞㻥

㻟㻥㻘㻢㻥㻟

㻟㻤㻘㻡㻣㻞

㻡㻜㻘㻢㻡㻞

㻠㻟㻘㻡㻠㻠

㻠㻥㻘㻞㻤㻥

㻠㻤㻘㻡㻢㻡

㻟㻞㻘㻜㻢㻤

㻞㻞㻘㻞㻥㻥

㻡㻣㻘㻤㻡㻣

㻠㻤㻘㻣㻠㻜

㻟㻤㻘㻢㻥㻥

㻞㻣㻘㻟㻡㻝

᥋⥆᫬㛫
㼇᫬㛫㼉

㻝㻘㻡㻣㻥

㻝㻘㻡㻜㻣

㻝㻘㻡㻞㻞

㻝㻘㻟㻣㻣

㻝㻘㻞㻞㻣

㻝㻘㻝㻤㻟

㻝㻘㻜㻥㻡

㻝㻘㻜㻢㻜

㻝㻘㻜㻝㻣

㻥㻥㻟

㻤㻣㻠

㻥㻝㻟

㻛㼔㼛㼙㼑

㻝㻘㻢㻣㻠㻘㻤㻞㻢㻝㻘㻤㻠㻞㻘㻡㻥㻤㻝㻘㻥㻠㻝㻘㻠㻤㻟㻝㻘㻤㻤㻟㻘㻞㻣㻥㻝㻘㻤㻢㻜㻘㻟㻤㻢㻝㻘㻢㻥㻣㻘㻣㻥㻤㻝㻘㻡㻥㻞㻘㻤㻥㻠㻝㻘㻠㻥㻥㻘㻟㻡㻡㻝㻘㻠㻟㻜㻘㻝㻢㻥㻝㻘㻟㻡㻣㻘㻠㻤㻜㻝㻘㻞㻥㻞㻘㻤㻡㻟㻝㻘㻟㻟㻥㻘㻠㻤㻞㻛㼣㼛㼞㼗䝣䜯䜲䝹౑⏝㔞㻌㼇㻳㼕㻮㼉㻡㻤㻘㻣㻠㻟

㻟㻘㻜㻜㻢㻚㻤㻟

㻞㻘㻝㻞㻢㻚㻥㻢

㻣㻘㻤㻥㻥㻚㻥㻟

㻞㻘㻞㻥㻡㻚㻡㻢

㻟㻘㻠㻠㻢㻚㻡㻡

㻟㻘㻢㻝㻢㻚㻢㻜

㻞㻘㻟㻝㻠㻚㻠㻣

㻠㻘㻝㻟㻢㻚㻣㻟

㻝㻢㻘㻤㻜㻣㻚㻞㻜㻞㻘㻤㻡㻟㻚㻡㻝

㻤㻘㻥㻥㻢㻚㻜㻜

㻝㻘㻞㻠㻞㻚㻠㻞

䝻䜾䜲䞁䠄ᐇ㻯㻼㼁䠅

㻝㻝

㻜

㻜

㻜

㻜

㻜

㻟

㻜

㻡

㻞

㻝

㻜

㻜

㻣㻘㻠㻜㻞

㻞㻞㻤

㻝㻥㻞

㻞㻢㻞

㻞㻡㻤

㻤㻤㻝

㻝㻘㻞㻡㻟

㻡㻥㻞

㻡㻥㻞

㻢㻣㻠

㻝㻘㻜㻥㻟

㻥㻥㻞

㻟㻤㻡

䜲䞁䝍䝷䜽䝔䜱䝤
䝆䝵䝤㻣㻘㻜㻜㻝㻘㻟㻜㻠㻡㻟㻠㻘㻣㻡㻞

㻡㻡㻥㻘㻝㻢㻞

㻢㻣㻜㻘㻞㻢㻟

㻢㻤㻢㻘㻤㻞㻤

㻢㻤㻢㻘㻞㻟㻝

㻣㻝㻡㻘㻡㻣㻜

㻡㻤㻢㻘㻜㻣㻟

㻠㻠㻢㻘㻝㻡㻟

㻢㻞㻞㻘㻞㻜㻞

㻡㻠㻣㻘㻠㻞㻠

㻠㻣㻞㻘㻡㻡㻤

㻠㻣㻠㻘㻜㻤㻤

䝞䝑䝏䝆䝵䝤

₇⟬᫬㛫㻌㼇䝜䞊䝗᫬㛫㼉㻌䠄⤒㐣᫬㛫䠅
䝥䝸䝫䝇䝖

㻜

㻜
䝻䜾䜲䞁௳ᩘ
䜲䞁䝍䝷䜽䝔䜱䝤௳ᩘ䝞䝑䝏䝆䝵䝤௳ᩘ₇⟬᫬㛫㻔䝞䝑䝏⤒㐣㻕

㻜

㻝㻜

㻞㻜

㻞㻜㻜㻘㻜㻜㻜
㻝㻜㻜㻘㻜㻜㻜

㻟㻜㻞㻜㻘㻜㻜㻜

㻠㻜㻟㻜㻜㻘㻜㻜㻜

㻠㻜㻘㻜㻜㻜

㻡㻜㻠㻜㻜㻘㻜㻜㻜

㻢㻜㻘㻜㻜㻜

㻢㻜㻤㻜㻤㻜㻜㻘㻜㻜㻜

㻡㻜㻜㻘㻜㻜㻜

㻥㻜㻥㻜㻜㻘㻜㻜㻜

㻢㻜㻜㻘㻜㻜㻜

㻝㻜㻜㻝㻘㻜㻜㻜㻘㻜㻜㻜฼⏝⋡㻔䠂㻕

㻣᭶㻢᭶㻡᭶䝜䞊䝗฼⏝⋡

䞉ୗ⥺㒊ศ䛾್䛻ㄗ䜚䛜䛤䛦䛔䜎䛧䛯䚹䛚ル䜃䛧䛶ゞṇ䛔䛯䛧䜎䛩䚹㻞᭶㻞㻜㻞㻞ᖺ㻝᭶
㻝㻞᭶

㻝㻝᭶

㻤㻟㻜㻚㻥

㻥㻞㻡㻚㻝

㻥㻥㻠㻚㻝

㻝㻘㻜㻝㻢㻚㻤

㻝㻘㻜㻠㻣㻚㻤

㻝㻘㻜㻡㻣㻚㻣

㻝㻘㻜㻝㻝㻚㻥

㻥㻠㻡㻚㻜

㻥㻜㻥㻚㻡

㻤㻟㻞㻚㻤

㻣㻜㻠㻚㻝

㻢㻜㻚㻣

㻢㻣㻚㻢

㻣㻞㻚㻣

㻣㻠㻚㻟

㻣㻢㻚㻢

㻣㻣㻚㻟

㻣㻠㻚㻞

㻢㻥㻚㻝

㻢㻢㻚㻡

㻢㻜㻚㻥

㻡㻝㻚㻡

㻡㻢㻚㻞

㻔㻑㻕

㻣㻢㻥㻚㻝

㻔䝜䞊䝗㻕

䢅䡬䢀䢚
฼⏝⋡

฼⏝ᩘ

ᖹᆒ䢅䡬䢀䢚

䞉䝜䞊䝗฼⏝⋡䠖䚷䝃䞊䝡䝇䝜䞊䝗䛻ᑐ䛩䜛฼⏝ẚ⋡䚹䚷ィ⟬ᘧ䠙䝜䞊䝗฼⏝ᩘ㾂䝃䞊䝡䝇䝜䞊䝗ᩘ㽢㻝㻜㻜㻞㻜㻞㻝ᖺ㻠᭶₇⟬᫬㛫㻔䝜䞊䝗᫬㛫㻕㻣㻜㻞㻘㻥㻠㻟

㻠㻤㻘㻝㻥㻡

㻣㻜㻘㻞㻞㻝

㻤㻠㻘㻣㻞㻝

㻣㻟㻘㻡㻜㻜

㻢㻟㻘㻣㻤㻤

㻣㻞㻘㻞㻢㻤

㻟㻝㻘㻤㻡㻝

㻟㻝㻘㻡㻡㻥

㻢㻞㻘㻣㻟㻟

㻣㻥㻘㻟㻣㻢

㻢㻜㻘㻞㻟㻟

㻞㻠㻘㻠㻥㻤

䝞䝑䝏䝆䝵䝤

㻤㻜㻘㻜㻜㻜

㻞㻜㻞㻝ᖺ㻠᭶㻣㻜㻡᭶㻣㻜㻜㻘㻜㻜㻜

㻢᭶㻝㻜㻜㻘㻜㻜㻜

㻝㻞㻜㻘㻜㻜㻜

㻝㻠㻜㻘㻜㻜㻜

㻣᭶㻌㻌ィ⟬ᘧ䠙㻝䞄᭶䛾䜲䞁䝍䝷䜽䝔䜱䝤䛚䜘䜃䝞䝑䝏䝆䝵䝤⤒㐣᫬㛫ྜィ㾂㻝䞄᭶䛾✌ື᫬㛫㻥᭶䞉䝜䞊䝗฼⏝ᩘ䠖䚷䜲䞁䝍䝷䜽䝔䜱䝤䛚䜘䜃䝞䝑䝏䝆䝵䝤䛾⤒㐣᫬㛫䜢㻝䝜䞊䝗䛜㻝㻜㻜㻑ືస䛧䛯䛸௬ᐃ䛧䛯ሙྜ䛾฼⏝䝜䞊䝗ᩘ䚹㻝㻜᭶䞉᥋⥆᫬㛫䠖䚷䝻䜾䜲䞁᫬㛫䛾⣼ィ㻥㻟㻘㻥㻣㻤

㻢㻘㻣㻢㻣

㻣㻘㻠㻜㻠

㻝㻜㻘㻥㻝㻡

㻥㻘㻜㻡㻞

㻤㻘㻢㻤㻟

㻤㻘㻥㻢㻥

㻢㻘㻣㻜㻜

㻡㻘㻠㻥㻠

㻤㻘㻡㻠㻡

㻤㻘㻢㻠㻥

㻢㻘㻟㻥㻡

㻢㻘㻠㻜㻡

䜲䞁䝍䝷䜽䝔䜱䝤
䝆䝵䝤

ฎ⌮௳ᩘ

㻝㻜᭶
㻥᭶

㻤᭶

- 34 㻝㻝᭶䞉䝻䜾䜲䞁䠄ᐇ㻯㻼㼁䠅䠖䚷䝁䜰᫬㛫༢఩

ྜィ

㻟㻝㻣

㻟㻞㻤

㻟㻣㻡

㻟㻢㻞

㻟㻠㻤

㻟㻞㻟

㻝㻘㻜㻣㻜

㻞㻜㻞㻝ᖺ㻠᭶㻤᭶䝥䝸䝫䝇䝖㻞㻜㻞㻞ᖺ㻝᭶

䝻䜾䜲䞁

㻝㻞᭶

ᐇ฼⏝⪅ᩘ

㻟᭶

ᖺ᭶

㻞᭶

Ⓩ㘓⪅ᩘ

㻟䠊㻻㼍㼗㼎㼞㼕㼐㼓㼑㻙㻯㼄㻌䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䝅䝇䝔䝮䝆䝵䝤ฎ⌮≧ἣ㻌䠄㻾㼑㼐㻌㻴㼍㼠㻌㻱㼚㼠㼑㼞㼜㼞㼕㼟㼑㻌㻸㼕㼚㼡㼤㻌㻣䚸㻯㼑㼚㼠㻻㻿㻌㻣䠅㻌㻟᭶

スーパーコンピューティングニュースVol. 24, No.3

2022

㻟㻝㻥

㻝㻘㻟㻞㻥

㻝㻘㻟㻟㻢

㻝㻘㻟㻣㻟

㻝㻘㻠㻝㻠

㻝㻘㻠㻞㻥

㻝㻘㻠㻞㻥

㻝㻘㻠㻟㻟

㻝㻘㻠㻟㻟

㻝㻘㻠㻟㻜

㻣᭶

㻤᭶

㻥᭶

㻝㻜᭶

㻝㻝᭶

㻝㻞᭶

㻞㻜㻞㻞ᖺ㻝᭶㻞᭶㻟᭶᭶ู฼⏝≧ἣ

㻞㻘㻞㻠㻢

㻝㻜㻟

㻝㻡㻝

㻞㻜㻢

㻞㻜㻣

㻞㻠㻥

㻝㻣㻜

㻝㻤㻠

㻝㻤㻥

㻝㻥㻟

㻞㻣㻠

㻝㻥㻞

㻝㻞㻤

㻞㻘㻟㻢㻟

㻠㻝

㻝㻣㻟

㻝㻞㻟

㻟㻣

㻣㻟

㻝㻝㻟

㻝㻣㻝

㻞㻟㻣

㻠㻝㻡

㻡㻝㻝

㻞㻤㻤

㻝㻤㻝

䜲䞁䝍䝷䜽䝔䜱䝤䝆䝵䝤ฎ⌮௳ᩘ㻢㻞㻥㻘㻜㻣㻢

㻢㻟㻘㻡㻢㻠

㻢㻞㻘㻜㻥㻡

㻞㻤㻘㻠㻤㻤

㻠㻝㻘㻥㻢㻠

㻣㻥㻘㻢㻣㻞

㻞㻤㻘㻞㻞㻢

㻟㻝㻘㻝㻝㻞

㻟㻟㻘㻠㻝㻢

㻢㻥㻘㻞㻠㻜

㻡㻥㻘㻜㻥㻣

㻢㻟㻘㻤㻞㻥

㻢㻤㻘㻟㻣㻟

䝞䝑䝏䝆䝵䝤

㻢㻝㻣㻘㻡㻣㻟

㻡㻝㻘㻜㻟㻜

㻠㻠㻘㻝㻥㻣

㻡㻡㻘㻥㻜㻢

㻠㻜㻘㻣㻟㻝

㻠㻢㻘㻡㻞㻞

㻡㻥㻘㻟㻢㻞

㻟㻤㻘㻢㻣㻝

㻞㻤㻘㻥㻜㻡

㻣㻠㻘㻜㻤㻣

㻢㻢㻘㻞㻝㻡

㻢㻟㻘㻥㻥㻣

㻠㻣㻘㻥㻡㻜

᥋⥆᫬㛫
㼇᫬㛫㼉

㻞㻘㻟㻟㻢

㻞㻘㻟㻢㻠

㻞㻘㻞㻢㻢

㻞㻘㻞㻢㻡

㻞㻘㻞㻞㻢

㻞㻘㻞㻝㻞

㻞㻘㻞㻠㻢

㻞㻘㻝㻣㻣

㻞㻘㻝㻥㻥

㻞㻘㻞㻟㻢

㻞㻘㻞㻝㻢

㻞㻘㻢㻝㻤

㻛㼔㼛㼙㼑

㻡㻘㻠㻤㻢㻘㻟㻠㻟㻡㻘㻞㻟㻤㻘㻟㻜㻝㻡㻘㻜㻟㻠㻘㻣㻞㻠㻡㻘㻝㻝㻟㻘㻢㻜㻣㻡㻘㻞㻡㻠㻘㻝㻠㻥㻡㻘㻝㻟㻣㻘㻣㻟㻟㻡㻘㻜㻥㻟㻘㻜㻣㻞㻡㻘㻜㻠㻥㻘㻝㻢㻞㻠㻘㻥㻠㻣㻘㻞㻞㻝㻠㻘㻤㻟㻜㻘㻞㻡㻥㻠㻘㻣㻞㻥㻘㻣㻤㻞㻢㻘㻞㻟㻟㻘㻤㻞㻟㻛㼣㼛㼞㼗䝣䜯䜲䝹౑⏝㔞㻌㼇㻳㼕㻮㼉㻥㻜㻘㻟㻥㻥

㻤㻘㻟㻢㻤㻚㻜㻟

㻝㻝㻘㻝㻣㻠㻚㻡㻤㻝㻡㻘㻥㻠㻤㻚㻝㻟㻞㻢㻘㻥㻜㻝㻚㻞㻝㻥㻘㻢㻠㻤㻚㻟㻞

㻝㻘㻝㻠㻤㻚㻝㻞

㻝㻘㻥㻠㻜㻚㻝㻝

㻡㻘㻡㻢㻡㻚㻣㻤

㻞㻘㻜㻡㻜㻚㻥㻣

㻞㻘㻜㻤㻤㻚㻟㻜

㻞㻘㻜㻟㻢㻚㻞㻠

㻟㻘㻡㻞㻤㻚㻥㻤

䝻䜾䜲䞁䠄ᐇ㻯㻼㼁䠅

㻠㻘㻟㻢㻠

㻞㻠㻢

㻞㻢㻤

㻞㻜㻢

㻟㻠㻡

㻟㻣㻞

㻟㻢㻟

㻠㻟㻜

㻡㻞㻟

㻠㻞㻜

㻠㻣㻜

㻠㻝㻝

㻟㻝㻜

㻝㻘㻜㻝㻡

㻝㻣

㻢㻣

㻝㻞㻜

㻝㻣

㻠㻟

㻠㻡

㻝㻜㻤

㻝㻢㻜

㻞㻜㻟

㻥㻞

㻣㻤

㻢㻡

䜲䞁䝍䝷䜽䝔䜱䝤
䝆䝵䝤㻟㻢㻘㻥㻝㻡㻘㻥㻟㻢㻠㻘㻣㻣㻣㻘㻞㻤㻝㻟㻘㻢㻝㻞㻘㻟㻢㻝㻞㻘㻣㻤㻢㻘㻥㻠㻣㻟㻘㻜㻣㻝㻘㻥㻥㻡㻞㻘㻡㻜㻥㻘㻥㻢㻥㻞㻘㻝㻢㻡㻘㻣㻤㻡㻞㻘㻡㻠㻣㻘㻞㻢㻜㻞㻘㻥㻤㻝㻘㻠㻥㻠㻟㻘㻡㻣㻠㻘㻤㻢㻞㻟㻘㻝㻣㻥㻘㻢㻜㻡㻞㻘㻥㻣㻣㻘㻞㻠㻤㻞㻘㻣㻟㻝㻘㻝㻞㻥䝞䝑䝏䝆䝵䝤

₇⟬᫬㛫㻌㼇䝜䞊䝗᫬㛫㼉㻌䠄⤒㐣᫬㛫䠅䝥䝸䝫䝇䝖㻠㻘㻜㻜㻜㻘㻜㻜㻜㻡㻘㻜㻜㻜㻘㻜㻜㻜㻢㻘㻜㻜㻜㻘㻜㻜㻜㻜㻡㻜㻘㻜㻜㻜
㻜䝻䜾䜲䞁௳ᩘ
䜲䞁䝍䝷䜽䝔䜱䝤௳ᩘ䝞䝑䝏䝆䝵䝤௳ᩘ₇⟬᫬㛫㻔䝞䝑䝏⤒㐣㻕㻝㻘㻜㻜㻜㻘㻜㻜㻜

㻜

㻝㻜

㻞㻜

㻟㻜

㻠㻜

㻡㻜

㻢㻜

㻣㻜

㻤㻜

㻥㻜

㻝㻜㻜

䝜䞊䝗฼⏝⋡㻥᭶㻤᭶㻞㻜㻞㻝ᖺ㻠᭶฼⏝⋡㻔䠂㻕

㻞㻜㻞㻞ᖺ㻝᭶
㻝㻞᭶

㻝㻝᭶
㻣᭶

㻢᭶

㻡᭶

㻠㻥㻚㻤

㻢㻘㻡㻡㻟㻚㻞

㻡㻘㻠㻥㻜㻚㻡

㻟㻘㻤㻞㻟㻚㻟

㻣㻥㻚㻤

㻢㻢㻚㻥

㻠㻢㻚㻢

㻡㻝㻚㻟

㻠㻟㻚㻡
㻠㻘㻞㻜㻣㻚㻥

㻟㻢㻚㻟㻟㻘㻡㻣㻝㻚㻥

㻠㻤㻚㻥

㻢㻡㻚㻠

㻡㻥㻚㻢

㻡㻡㻚㻡

㻞㻘㻥㻣㻤㻚㻞

㻠㻘㻜㻝㻝㻚㻥

㻡㻘㻟㻢㻢㻚㻠

㻠㻘㻤㻥㻡㻚㻤

㻠㻘㻡㻡㻣㻚㻜

㻠㻘㻜㻤㻥㻚㻤

㻡㻜㻚㻞㻔㻑㻕㻠㻘㻝㻝㻢㻚㻤

㻔䝜䞊䝗㻕

䢅䡬䢀䢚
฼⏝⋡

฼⏝ᩘ

ᖹᆒ䢅䡬䢀䢚

䞉䝜䞊䝗฼⏝⋡䠖䚷䝃䞊䝡䝇䝜䞊䝗䛻ᑐ䛩䜛฼⏝ẚ⋡䚹䚷ィ⟬ᘧ䠙฼⏝䝜䞊䝗᫬㛫㾂䝃䞊䝡䝇䝜䞊䝗᫬㛫㽢㻝㻜㻜㻝㻜᭶₇⟬᫬㛫㻔䝜䞊䝗᫬㛫㻕㻞㻘㻜㻜㻜㻘㻜㻜㻜㻞㻜㻞㻝ᖺ㻠᭶㻝㻜㻜㻘㻜㻜㻜

㻡᭶㻟㻘㻜㻜㻜㻘㻜㻜㻜㻢᭶㻝㻡㻜㻘㻜㻜㻜

㻞㻜㻜㻘㻜㻜㻜

㻞㻡㻜㻘㻜㻜㻜

㻣᭶㻌㻌ィ⟬ᘧ䠙䝜䞊䝗฼⏝⋡㽢⥲䝜䞊䝗ᩘ㻔㻤㻞㻜㻤㻕㻥᭶䞉䝻䜾䜲䞁䠄ᐇ㻯㻼㼁䠅䠖䚷䝁䜰᫬㛫༢఩㻤㻣㻘㻢㻞㻡

㻢㻘㻥㻢㻣

㻢㻘㻝㻝㻝

㻢㻘㻥㻞㻢

㻣㻘㻡㻜㻞

㻢㻘㻥㻞㻤

㻢㻘㻥㻡㻢

㻡㻘㻤㻥㻝

㻡㻘㻥㻥㻠

㻤㻘㻠㻞㻤

㻥㻘㻟㻠㻤

㻝㻜᭶

䞉䝜䞊䝗฼⏝ᩘ䠖䚷䜲䞁䝍䝷䜽䝔䜱䝤䛚䜘䜃䝞䝑䝏䝆䝵䝤䛾⤒㐣᫬㛫䜢㻝䝜䞊䝗䛜㻝㻜㻜㻑ືస䛧䛯䛸௬ᐃ䛧䛯ሙྜ䛾฼⏝䝜䞊䝗ᩘ䚹

㻟㻠㻤

㻟㻝㻤

㻟㻝㻠

㻟㻡㻥

㻟㻞㻤

㻟㻞㻥

㻟㻤㻜

㻟㻣㻤

㻤㻘㻞㻡㻞

㻤㻘㻟㻞㻞

㻝㻝᭶

䞉᥋⥆᫬㛫䠖䚷䝻䜾䜲䞁᫬㛫䛾⣼ィ

ྜィ

㻟㻜㻤

㻝㻘㻟㻥㻣

㻢᭶

㻟㻠㻣

㻝㻘㻣㻟㻞

㻡᭶

㻠㻡㻜

㻝㻘㻢㻥㻜

㻞㻜㻞㻝ᖺ㻠᭶

㻤᭶

䝥䝸䝫䝇䝖

㻝㻞᭶

䝻䜾䜲䞁

㻞㻜㻞㻞ᖺ㻝᭶

ᐇ฼⏝⪅ᩘ

㻞᭶

Ⓩ㘓⪅ᩘ

㻟᭶

ᖺ᭶

㻠䠊㻻㼍㼗㼒㼛㼞㼑㼟㼠㻙㻼㻭㻯㻿䝇䞊䝟䞊䝁䞁䝢䝳䞊䝍䝅䝇䝔䝮䝆䝵䝤ฎ⌮≧ἣ䚷䠄㻾㼑㼐㻴㼍㼠㻌㻱㼚㼠㼑㼞㼜㼞㼕㼟㼑㻌㻸㼕㼚㼡㼤㻌㻣䚸㻯㼑㼚㼠㻻㻿㻌㻣䠅㻞᭶

- 35 -

㻟᭶

スーパーコンピューティングニュースVol. 24, No.3

2022

Wisteria/BDEC-01 ฼⏝஦౛㸦4㸧ࢹ࣮ࢱཷࡅΏࡋࣛ࢖ࣈࣛࣜ h3-Open-SYS/WaitIO (2/2)ఫඖ┿ྖ㸦ᮾி኱Ꮫ᝟ሗᇶ┙ࢭࣥࢱ࣮㸧ᆏཱྀྜྷ⏕㸦ᐩኈ㏻ᰴᘧ఍♫㸧
ᯇⴥᾈஓ* (᪥❧〇సᡤ)*2021 ᖺᗘᐈဨᩍᤵ᫬ࡢᡂᯝ

୰ᓥ◊࿃㸦ᮾி኱Ꮫ᝟ሗᇶ┙ࢭࣥࢱ࣮㸧
1. ࡣࡌࡵ࡟ ௒ᅇࡣࠊ
๓ᅇ㸦2022 ᖺ 3 ᭶ྕ㸧࡜ḟᅇ
㸦2022 ᖺ 7 ᭶ྕ㸧࡜ࡢ 3 ᅇ࠿ࡽ࡞ࡿ 2 ᅇ┠࡛㸪Wisteria/BDEC01㹙1,2,3㹛ࡢࡼ࠺࡞࣊ࢸࣟࢪࢽ࢔ࢫ࡞⎔ቃ࡛ࠕィ⟬࣭ࢹ࣮ࢱ࣭Ꮫ⩦ࠖ⼥ྜࢆᐇ⌧ࡍࡿࡓࡵࡢࢶ࣮
࡛ࣝ࠶ h3-Open-SYS/WaitIO㹙4㹛࡟ࡘ࠸࡚ࠊ≉࡟ Wisteria/BDEC-01 ࢩࢫࢸ࣒࡛ࡢᐇᶵ฼⏝ࢆ᝿ᐃࡋࡓ฼⏝஦౛࡟ࡘ࠸࡚⤂௓ࡍࡿࠋ

2. WaitIO Hostname Server๓ᅇࡢᐇ⾜࡛ࡣ WaitIO ࡢࣉࣟࢢ࣒ࣛࢆࣂࢵࢳᐇ⾜ࡍࡿ࡟ࡣ PBID ࡀ 0 ࡢ࣍ࢫࢺྡ࡜࣏࣮ࢺ␒
ྕࢆࣂࢵࢳᐇ⾜㛤ጞᚋ࡟ࣟࢢࣇ࢓࢖ࣝ࠿ࡽ⋓ᚓࡋ࡚ PBID 1 ௨㝆ࡢࣂࢵࢳࢪࣙࣈࢫࢡࣜࣉࢺࢆኚ
᭦ࡋࡓୖ࡛ᐇ⾜ࡍࡿᚲせࡀ࠶ࡗࡓࠋࣂࢵࢳฎ⌮ࡣᐇ⾜᫬࡟࣍ࢫࢺࡀỴࡲࡿ࠿ࡽ࡛࠶ࡿࠋࡇࡢ≧ἣࢆᨵၿࡍࡿࡓࡵࠊᐇ⾜᫬࡟Ỵࡲࡿ࣍ࢫࢺྡࢆᐇ⾜᫬࡟୰⥅ࡍࡿ WaitIO Hostname Server ࢆ㛤Ⓨࡋ࡚࠸ࡿࠋ⌧ᅾࠊࢩࢫࢸ࣒㐃ᦠ࡟ྥࡅ࡚ࡢᨵၿ⥅⥆୰ࡢࡓࡵࠊ௒ᚋ௙ᵝ࡞࡝ࡀኚ᭦ࡉࢀࡿྍ⬟ᛶࡀ࠶ࡿࡢ࡛ὀពࡉࢀࡓ࠸ࠋ௒ᅇࡣ⌧≧ࡢືస௙ᵝ࡟ࡘ࠸࡚ㄝ᫂ࡍࡿࠋ
WaitIO Hostname Server ࡣィ⟬ࣀ࣮ࢻ࠿ࡽ┤᥋ࢿࢵࢺ࣮࣡ࢡ㏻ಙࡀྍ⬟࡞࣍ࢫࢺ࡛ᐇ⾜ྍ⬟࡞ࢧ࣮ࣂ࡛࠶ࢀࡤᐇ⾜ྍ⬟࡛࠶ࡿࠋWisteria/BDEC-01 ࢩࢫࢸ࣒࡛ࡣࣟࢢ࢖ࣥࣀ࣮ࢻ࡛ᐇ⾜ྍ⬟࡛࠶ࡿࠋᐇ⾜ࣂ࢖ࢼࣜ࡜ࡋ࡚ࡣࠊintel CPU(waitio-serv, waitio-serv-intel : ࣟࢢ࢖ࣥࣀ࣮ࢻ࡜ Aquarius)⏝
࡜ Arm CPU(waitio-serv-a64fx : Odyssey)⏝ࡀ࠶ࡾᐇ⾜ࡍࡿࣀ࣮ࢻ࡛౑࠸ศࡅࡿᚲせࡀ࠶ࡿࠋᅗ 1. WaitIO Hostname Server ࡢ⎔ቃタᐃ౛

ᅗ 1 ࡟ WaitIO Hostname Server ࡢ ⎔ ቃ タ ᐃ ౛ ࢆ ♧ ࡍ ࠋ ๓ ᅇ ࡟ ♧ ࡋ ࡓ ᐇ ⾜ ౛ ࡟
WAITIO_SERVER_HOST ࡜ WAITIO_SERVEWR_PORT ࡢ⎔ቃኚᩘࢆタᐃࡋ࡚ ࣟࢢ࢖ࣥࣀ࣮ࢻ࡞

スーパーコンピューティングニュース- 36 -

Vol. 24, No.32022

࡝࡛ waitio_serv ࢥ࣐ࣥࢻࢆࢧ࣮ࣂ࣮ࣔࢻ࡛㉳ື㸦-s ࢜ࣉࢩࣙࣥࠊᅗ 1ࠊ1)㸧ࡋࠊྛࣂࢵࢳࢫࢡࣜ
ࣉࢺ࡛ᐇ⾜㸦ᅗ 1ࠊ3㸧, 4)㸧ࡍࡿࡇ࡜࡛ࣂࢵࢳࢪࣙࣈᐇ⾜᫬࡟ waitio_serv ࢧ࣮ࣂࢆ௓ࡋ࡚࣐ࢫࢱ
࣮࣍ࢫࢺ᝟ሗࡢ୰⥅ࡀྍ⬟࡛࠶ࡿࠋ࡞࠾ࠊwaitio-serv ࢥ࣐ࣥࢻࢆࢧ࣮ࣂ࣮ࣔࢻ࡛❧ࡕୖࡆࡿ᫬ࠊ
᪤࡟࣏࣮ࢺ␒ྕࡀ౑ࢃࢀ࡚࠸ࡿ࡜ Socket ࡢྲྀᚓ࡟ኻᩋࡍࡿࡇ࡜ࡀ࠶ࡿࠋ
㸦ᅗ㸯ࠊ2㸧
㸧ࡇࡢࡼ࠺࡞
ሙྜࡣ㔜」ࡋࡓ␒ྕ࡜␗࡞ࡿ࣏࣮ࢺ␒ྕࢆ෌タᐃࡋ࡚ᐇ⾜ࡍࡿࠋ

3. WaitIO-Socket ࡢ࢔ࣉࣜࢣ࣮ࢩࣙࣥ㐺⏝஦౛
WaitIO-Socket ࡢ฼⏝஦౛࡜ࡋ࡚ࡣࠊh3-Open-UTIL/MP㹙5㹛࡜ほ ࢹ࣮ࢱྠ໬࡟ࡼࡿ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண 㹙11㹛࡛ά⏝ࡀ㐍ࢇ࡛࠸ࡿࠋ
h3-Open-UTIL/MP ࡣ WaitIO-Socket ࡜ྛ PB ࡛ᐇ⾜ࡉࢀࡿ MPI ࣛ࢖ࣈࣛࣜࢆ⏝࠸࡚ Hybrid ࡞
MPI ᐇ⾜⎔ቃࢆᐇ⌧ࡋࠊ」ᩘࡢ MPI ࢔ࣉࣜࢣ࣮ࢩࣙࣥࢆ⼥ྜࡍࡿ࢝ࢵࣉ࣮ࣛ࡜ࡋ࡚࢔ࣉࣜࢣ࣮
ࢩࣙࣥ㛫ࡢࢹ࣮ࢱࢥࣥࣂ࣮ࢪࣙࣥࢆྵࡴᐇ⾜⎔ቃࢆᥦ౪ࡋ࡚࠸ࡿࠋࢩ࣑࣮ࣗࣞࢩࣙࣥ࡜ࢹ࣮ࢱྠ
໬࡟ࡼࡿᏛ⩦ࡢ⼥ྜࢆᐇ⌧ࡍࡿࠋヲࡋࡃࡣḟᅇ㸦2022 ᖺ 7 ᭶ྕ㸧ࡢグ஦ࢆཧ↷ࡉࢀࡓ࠸ࠋ
ほࢹ࣮ࢱྠ໬࡟ࡼࡿ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண

㹙11㹛࡟࠾࠸࡚ WaitIO ࡣ᪥ᮏྛᡤ࡟タ⨨ࡉࢀ࡚࠸ࡿᆅ㟈ほ Ⅼ࠿ࡽࡢࢹ࣮ࢱࢆࣜ࢔ࣝࢱ࢖࣒࡛㌿㏦ࡋ Wisteria/BDEC-01 ࢩࢫࢸ࣒࡛ࡢண
࡟ά⏝ࡍࡿࡓࡵ࡟㛤Ⓨࢆ㐍ࡵ࡚࠸ࡿࠋ

ᅗ 2. ほࢹ࣮ࢱྠ໬࡟ࡼࡿ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண

࡟࠾ࡅࡿ WaitIO ά⏝౛ᅗ 2 ࡟ほ ࢹ࣮ࢱྠ໬࡟ࡼࡿ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண ࡟࠾ࡅࡿ WaitIO ά⏝౛ࢆ♧ࡍࠋほ῭ࡳࢹ࣮ࢱࢆ⏝࠸࡚ᆅ㟈ືࢆゎᯒࡍࡿሙྜࠊ㏻ᖖ⵳✚ࡉࢀࡓࢹ࣮ࢱࢆࣇ࢓࢖ࣝ࡟᱁⣡ࡋ࡚ࡇࡢࣇ࢓࢖ࣝࢆ࢔ࣉࣜࢣ࣮ࢩࣙࣥ࡟ㄞࡳ㎸ࡲࡏ࡚ゎᯒฎ⌮ࢆᐇ⾜ࡍࡿࠋࡋ࠿ࡋࠊ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண ࡟࠾࠸࡚ࡣ㏲୍グ㘓ࡉࢀࡿᆅ㟈ࢹ࣮ࢱࢆࣜ࢔ࣝࢱ࢖
࣒࡟ゎᯒࡍࡿᚲせࡀ࠶ࡿࠋWaitIO-Socket ࡣࡇࡢࣇ࢓࢖ࣝㄞࡳฟࡋࢆ㏻ಙ࡟⨨ࡁ᥮࠼ࡿࠋ

スーパーコンピューティングニュース- 37 -

Vol. 24, No.3

2022

ᅗ 3. ほࢹ࣮ࢱྠ໬࡟ࡼࡿ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண

࡟࠾ࡅࡿ WaitIO ά⏝౛㸸ࢹ࣮ࢱ౪⤥ഃᅗ 3, ᅗ 4 ࡟ WaitIO-Socket ࢆ⏝࠸ࡓ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண ࡛⏝࠸ࡿࢹ࣮ࢱ㌿㏦⏝ࡢࣉࣟࢢ࣒ࣛࢆ♧ࡍࠋ㏻ᖖࠊࢩࢫࢸ࣒㛫ࡢ㏻ಙࡣ TCP/IP ࣉࣟࢺࢥࣝୖࡢ Socket ࢆ౑࠺ࡇ࡜࡟࡞ࡿ
ࡀࠊSocket ࡢసᡂࠊ┦ᡭࢧ࣮ࣂ࡜ࡢ㏻ಙ☜❧࡞࡝ Socket ㏻ಙ⮬యࡢࣉࣟࢢ࣒ࣛ▱㆑ࡀᚲせ࡛࠶
ࡿࡀࠊWaitIO-Socket ࢆ⏝࠸ࡿࡇ࡜࡛ Socket ࡢ▱㆑ࡀ࡞ࡃ࡚ࡶ MPI ࣉࣟࢢ࣒ࣛࢆ᭩ࡃࡇ࡜ࡀ࡛ࡁ
ࢀࡤࠊࢧ࣮ࣂ㛫ࡢ㏻ಙࣉࣟࢢ࣒ࣛࢆ⡆᫆࡟᭩ࡃࡇ࡜ࡀ࡛ࡁࡿࠋ
ᅗ 3 ࡣᆅ㟈ࢹ࣮ࢱࢆ᱁⣡ࡍࡿࢧ࣮ࣂ࡟࠾ࡅࡿࣉࣟࢢ࣒࡛ࣛࢧ࣮ࣂୖࡢࣇ࢓࢖ࣝࢆㄞࢇ࡛
WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜࢆ⏝࠸࡚ࣜ࢔ࣝࢱ࢖࣒ண ࢆᐇ⾜ࡍࡿࢩࢫࢸ࣒࡟㌿㏦ࡍࡿࠋ

ᅗ 4. ほࢹ࣮ࢱྠ໬࡟ࡼࡿ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண

࡟࠾ࡅࡿ WaitIO ά⏝౛㸸ࢹ࣮ࢱά⏝ഃ

ᅗ 4 ࡣඖࠎࣇ࢓࢖ࣝ࠿ࡽᆅ㟈ࢹ࣮ࢱࢆㄞࢇ࡛ฎ⌮ࡍࡿࣉࣟࢢ࣒࡛ࣛ࠶ࡗࡓࡶࡢࢆ WaitIO MPIConversion ࣛ࢖ࣈࣛࣜࢆ⏝࠸ู࡚ࡢࢧ࣮ࣂ࠿ࡽࢿࢵࢺ࣮࣡ࢡࢆ⤒⏤ࡋ࡚ࢹ࣮ࢱࢆ⋓ᚓࡋ࡚࠸ࡿࠋ

スーパーコンピューティングニュース- 38 -

Vol. 24, No.3

2022ࡇࡢࡼ࠺࡟ Socket ㏻ಙࡢࣉࣟࢢ࣒ࣛᢏ⾡ࡀ࡞ࡃ࡚ࡶ WaitIO Socket ࢆ⏝࠸࡚ᡭ㍍࡟ࢿࢵࢺ࣮࣡
ࢡࢆ௓ࡋ࡚ࢹ࣮ࢱࢆ㌿㏦࡛ࡁࡿࡇ࡜ࡀࢃ࠿ࡿࠋ

4. Toy ࣉࣟࢢ࣒ࣛ࡟ࡼࡿᐇ࢔ࣉࣜࢣ࣮ࢩࣙࣥࢥ࣮ࢻᐇ⾜ᮏ❶࡛ࡣᐇ㝿ࡢ࢔ࣉࣜࢣ࣮ࢩࣙࣥࣉࣟࢢ࣒ࣛࢆ⡆␎໬ࡋࡓ Toy ࣉࣟࢢ࣒ࣛ࡟ࡼࡾᐇ㝿ࡢ
WaitIO-Socket ࡟ࡼࡿ࢔ࣉࣜࢣ࣮ࢩࣙࣥᐇ⾜ࢆヨࡋ࡚ࡳࡿࠋ࢔ࣉࣜࢣ࣮ࢩࣙࣥᐇ⾜࡟ࡘ࠸࡚ࡣࠊ6᭶ࡼࡾ㛤ጞணᐃࡢ Wisteria/BDEC-01 ࢩࢫࢸ࣒࡛ࡢ WaitIO ヨ⾜ࢧ࣮ࣅࢫ⎔ቃୗ࡛ࡢᐇ⾜ᡭ㡰ࢆㄝ᫂ࡍࡿࠋ ࡇࡇ࡛ࡣࠊⅬ※࡟ࡼࡿⓎ⇕㔞ィ⟬⤖ᯝࢆฟຊࡍࡿࣉࣟࢢ࣒ࣛ(Code-1)ࡢࣇ࢓࢖ࣝฟຊࢆࠊ᭷㝈せ⣲ἲ࡟ࡼࡿ୕ḟඖ㠀ᐃᖖ⇕ఏᑟゎᯒࡍࡿࣉࣟࢢ࣒ࣛ(Code-2)ࠊ୪ࡧ࡟ Code-2 ࡜ Code-1 ࠿ࡽࡢࣇ࢓࢖ࣝฟຊࢆඖ࡟᭷㝈せ⣲ἲ࡟ࡼࡿ୕ḟඖ㠀ᐃᖖ⇕ఏᑟゎᯒࢆ⾜࠸ Z=Zmax 㠃ࡢቃ⏺᮲௳࡬ᒎ㛤ࡍࡿࣉࣟࢢ࣒ࣛ(Code-3)ࡢ 3 ࡘࡢࣉࣟࢢ࣒ࣛࢆ WaitIO-Socket ࢆ⏝࠸࡚᭩ࡁ᥮࠼࡚ࡳࡿࠋࢯ
࣮ࢫࢥ࣮ࢻ୍ᘧࡣ Wisteria/BDEC-01 ࢩࢫࢸ࣒ୖࡢ /work/share/waitio/src/examples/SYStest-waitiosocket.tgz ࡟⨨࠿ࢀ࡚࠸ࡿࡢ࡛ࡑࢀࡒࢀࡢ࢔࢝࢘ࣥࢺࡢ work ࢹ࢕ࣞࢡࢺࣜ࡟ᒎ㛤ࡋ࡚ཧ↷ࡉࢀࡓ࠸ࠋ

ᅗ 4. ᭷㝈せ⣲ἲ࡟ࡼࡿ୕ḟඖ㠀ᐃᖖ⇕ఏᑟゎᯒ Toy ࣉࣟࢢ࣒ࣛࡢᵓᡂ

ᅗ 4 ࡟ᮏ Toy ࣉࣟࢢ࣒ࣛࡢ඲యീࢆࠊ⾲ 1 ࡟ྛࣉࣟࢢ࣒ࣛࡢᴫせ࡜ධฟຊࣇ࢓࢖ࣝ࡟ࡘ࠸࡚♧ࡍࠋCode-1 ࡢฟຊࡍࡿࣇ࢓࢖ࣝ s1.out ࡣ Code-2 ࡜ Code-3 ࠿ࡽㄞࡳ㎸ࡲࢀࡿࠋࡲࡓࠊCode-2 ࡢฟຊࡍࡿ s2.out ࡣ Code-3 ࠿ࡽㄞࡳ㎸ࡲࢀࡿࠋࡇࢀࡽࡢࣇ࢓࢖ࣝ࡟ࡼࡿධฟຊࢆ WaitIO-Socket ࡢࢹ࣮ࢱ㌿㏦࡟᭩ࡁ᥮࠼ࡿࠋ

スーパーコンピューティングニュース- 39 -

Vol. 24, No.3

2022

⾲ 1. ᭷㝈せ⣲ἲ࡟ࡼࡿ୕ḟඖ㠀ᐃᖖ⇕ఏᑟゎᯒ Toy ࣉࣟࢢ࣒ࣛࡢᴫせ4.1 ࢯ࣮ࢫࢥ࣮ࢻࡢಟṇࣇ࢓࢖ࣝฟຊ࠿ࡽ WaitIO ࡛ࡢࢹ࣮ࢱ㐃ᦠ࡬ࡢኚ᭦ࡣࠊࢹ࣮ࢱඹ᭷ࡋ࡚࠸ࡿࣇ࢓࢖ࣝ࡬ࡢධฟຊ
㒊ศࡢࢯ࣮ࢫࢥ࣮ࢻࢆ WaitIO ࡟ࡼࡿ㏦ཷಙࡢࢥ࣮ࢻ࡟ࡼࡿ㏦ཷಙࡢࢯ࣮ࢫࢥ࣮ࢻ࡟ኚ᭦ࡍࡿࡇ
࡜࡛ᐇ⌧ྍ⬟࡛࠶ࡿࠋ
WaitIO ࡟࠾ࡅࡿࢯ࣮ࢫࢥ࣮ࢻࡢಟṇᡭ㡰ࢆ௨ୗ࡟♧ࡍࠋ
1.

ྛ࢔ࣉࣜࢣ࣮ࢩࣙࣥࣉࣟࢭࢫ㛫ࡢ᥋⥆᪉ᘧ࡜฼⏝ API ࡢỴᐃ
WaitIO MPI Conversion ࣛ࢖ࣈ࡛ࣛࣜࡣ 2 ✀㢮ࡢ⡆᫆ึᮇ໬㛵ᩘࢆ‽ഛࡋ࡚࠸ࡲࡍࠋ
1) ྛ࢔ࣉࣜࢣ࣮ࢩࣙࣥࡢ MPI ࣉࣟࢭࢫࡢࡍ࡭࡚ࢆ⏝࠸ࡿ waitio_create_universe()㛵ᩘ2) ྛ࢔ࣉࣜࢣ࣮ࢩࣙࣥࡢ MPI ࣉࣟࢭࢫࡢඛ㢌ࣉࣟࢭࢫ(MPI ࣛࣥࢡ␒ྕ 0)ࡔࡅࢆ౑࠺
waitio_create_universe_pbhead()㛵ᩘ1), 2)௨እࡢሙྜࡣ waitio_create_group()㛵ᩘࢆ⏝࠸࡚ಶู࡟సᡂࡍࡿࡇ࡜ࡀྍ⬟࡛ࡍࠋࡲ ࡓ ࠊ ᐇ 㝿 ࡢ ㏻ ಙ ࡢ ࢹ ࣮ ࢱ ᙧ ᘧ ࡸ ㏻ ಙ ࣃ ࢱ ࣮ ࣥ ࡟ ᛂ ࡌ ࡚ WaitIO 㛵 ᩘ (waitio_isend,
waitio_irecv)ࠊࡶࡋࡃࡣ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜ(waitio_mpi_xxx()㛵ᩘ)ࢆ㑅ᢥྍ⬟࡛ࡍࠋࡇࡇ࡛ࡣࠊ࢔ࣉࣜࢣ࣮ࢩࣙࣥ㛫ࡢ᥋⥆᪉ᘧ࡜ࡋ࡚ࠊྛ࢔ࣉࣜࢣ࣮ࢩࣙࣥࡢඛ㢌ࣉࣟࢭࢫࡢࡳࢆ㑅ᢥࡍࡿ waitio_create_universe_pbhead()㛵ᩘࢆ㑅ᢥࡋࠊ฼⏝㛵ᩘ࡜ࡋ࡚⾲グἲࡀ
MPI ࡜㢮ఝࡋ࡚࠸ࡿ WaitIO MPI Conversion ࣛ࢖ࣈ࡛ࣛࣜグ㏙ࡍࡿࡇ࡜࡟ࡋࡲࡍࠋ
2.

ྛ࢔ࣉࣜࢣ࣮ࢩࣙࣥࡢ PBID ࡬ࡢ࣐ࢵࣆࣥࢢ

1 ࡛㏙࡭ࡓ᥋⥆᪉ᘧ࡜ PBID ࡟ࡼࡾࠊWaitIO ࡛⏝࠸ࡿࣉࣟࢭࢫࣛࣥࢡ␒ྕࡀ␗࡞ࡿࡓࡵࠊ࢔
ࣉࣜࢣ࣮ࢩࣙࣥࡢ⤖ྜ㡰ᗎࢆỴࡵࡿࡓࡵ࡟ྛ࢔ࣉࣜࢣ࣮ࢩࣙࣥࡢ PBID ࢆỴᐃࡋࡲࡍࠋࡇࡇ
࡛ࡣࠊCode-1 ࢆ PBID=0, Code-2 ࢆ PBID=1, Code-3 ࢆ PBID=2 ࡜ᐃ⩏ࡋࡲࡍࠋ
3.

࢔ࣉࣜࢣ࣮ࢩࣙࣥ㛫ࡢࢹ࣮ࢱ㐃ᦠࢥ࣮ࢻࡢࣉࣟࢢ࣑ࣛࣥࢢ

ࡉ࡚ࠊᐇ㝿ࡢࢹ࣮ࢱ㐃ᦠࢥ࣮ࢻࡢࣉࣟࢢ࣑ࣛࣥࢢ࡛࠶ࡿࡀࠊ௒ᅇࡣࠊࣇ࢓࢖ࣝධฟຊ࡟ࡼࡿ
ࢹ࣮ࢱ஺᥮ࢆ WaitIO ࡛᭩ࡁ᥮࠼ࡿࡇ࡜࡟࡞ࡿࡓࡵࠊᐇ㝿ࡢࣇ࢓࢖ࣝධฟຊࡀ࡝ࡢࡼ࠺࡟⾜ࢃࢀ࡚࠸ࡿࡢ࠿ࢆᩚ⌮ࡍࡿᚲせࡀ࠶ࡿࠋ௨ୗࡢ⠇࡛ࡣᐇ㝿ࡢࢥ࣮ࢻಟṇࢆඖ࡟ヲࡋࡃ㏙࡭ࡿࠋ
4.2 ࢔ࣉࣜࢣ࣮ࢩࣙࣥ㛫ࡢࢹ࣮ࢱ㐃ᦠࢥ࣮ࢻࡢࣉࣟࢢ࣑ࣛࣥࢢࡢᐇ㝿ᮏ⠇࡛ࡣ Toy ࣉࣟࢢ࣒ࣛࡢࢹ࣮ࢱ㐃ᦠࢥ࣮ࢻࢆ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜࡢ㛵ᩘࢆ⏝࠸

スーパーコンピューティングニュース- 40 -

Vol. 24, No.3

2022࡚᭩ࡁ᥮࠼ࡿࠋToy ࣉࣟࢢ࣒࡛ࣛ࠶ࡿ SYStest-waitio-socket ࢹ࢕ࣞࢡࢺࣜୗ࡟ࡣྛࣉࣟࢢ࣒ࣛࢆ
᱁⣡ࡍࡿ src1(Code-1), src2(Code-2), src3(Code-3)ࡢྛࢹ࢕ࣞࢡࢺࣜ࡜ᐇ⾜ࢆ⾜࠺ run ࢹ࢕ࣞࢡࢺ
ࣜ࠿ࡽᵓᡂࡉࢀࡿࠋ

ᅗ 5. Toy ࣉࣟࢢ࣒ࣛࡢ Original ࣉࣟࢢ࣒ࣛ㸸Code-1 ඲యࢯ࣮ࢫࢥ࣮ࢻ(FORTRAN)
File:SYStest-waitio-socket/src1/test1.fᅗ 5 ࡟ࠊToy ࣉࣟࢢ࣒ࣛࡢෆ Code-1(FORTRAN)ࡢ Original ࡢ඲యࢯ࣮ࢫࢥ࣮ࢻࢆ♧ࡍࠋᅗ 5 ୰ࠊ
001-016 ⾜┠ࡲ࡛ࡣึᮇ໬ࢥ࣮ࢻ࡛࠶ࡾࠊ004 ⾜࡛ MPI ࡢึᮇ໬ᚋࠊ005 ⾜࡛ࣃ࣓࣮ࣛࢱࣇ࢓࢖
ࣝࢆ Open ࡋࠊ006 ⾜࡛ࣃ࣓࣮ࣛࢱࢆㄞࡳ㎸ࢇ࡛࠸ࡿࠋࡑࡋ࡚ࠊ012 ⾜࡛ฟຊ⏝ࡢࣇ࢓࢖ࣝ s1.out
ࢆ Open ࡋࡓᚋࠊ017 ⾜࠿ࡽࡢ࣮ࣝࣉᮏయࡢࡓࡵࡢኚᩘึᮇ໬ࢆ⾜ࡗ࡚࠸ࡿࠋ
 017-030 ⾜ࡀ Code-1 ࡢᮏయ࣮ࣝࣉ࡛࠶ࡿࠋ017-030 ⾜ࡢ࣮ࣝࣉᮏయ࡛ࡣィ⟬⤖ᯝࢆ 029 ⾜ࡢ
write ᩥ࡛ኚᩘ ttt ࡜ Source ࢆ࣮ࣝࣉẖ࡟᭩ࡁฟࡋ࡚࠸ࡿࠋ
௒ᅇࠊᅗ 5 ࡢ Code-1 ࢥ࣮ࢻࢆ WaitIO ᑐᛂࡢࢥ࣮ࢻ࡟ࡍࡿࡓࡵ࡟ࠊࡲࡎࠊ᭱ึ࡟ྛࣇ࢓࢖ࣝࡢ
ࣉࣟࢢ࣒ࣛ㛫ࡢ౫Ꮡ㛵ಀࢆᢕᥱࡍࡿᚲせࡀ࠶ࡿࠋᅗ 4ࠊ⾲ 1 ࡼࡾࠊCode-1 ࡟࡚ฟຊࡉࢀࡿ s1.out
ࡣࠊCode-2, Code-3 ࡛ㄞࡳࡔࡉࢀ࡚࠸ࡿࠋࡇࡢࡓࡵࠊCode-1 ࡢ s1.out ฟຊࡣ Code-2, Code-3 ࡟㏦
ಙࡍࡿᚲせࡀ࠶ࡿࠋ⾲ 1 ࡼࡾࠊCode-2 ࡟࠾࠸࡚ࡣ Code-1 ࠿ࡽࡢࢹ࣮ࢱࢆㄞࡳ㎸ࡳࠊCode-2 ࡬㏦
ಙࠊCode-3 ࡟࠾࠸࡚ࡣࠊCode-1 ࡜ Code-2 ࠿ࡽࡢࢹ࣮ࢱࢆㄞࡳ㎸ࡴᚲせࡀ࠶ࡿࠋ

スーパーコンピューティングニュース- 41 -

Vol. 24, No.3

2022

ᅗ 6. Toy ࣉࣟࢢ࣒ࣛࡢ WaitIO ࣉࣟࢢ࣒ࣛ㸸Code-1 ಟṇ㒊
File:SYStest-waitio-socket/src1/test1_waitio.fᅗ 6 ࡟ࠊToy ࣉࣟࢢ࣒ࣛࡢ WaitIO ࣉࣟࢢ࣒ࣛ Code-1 ࡢಟṇ῭ࡳ FORTRAN ࢥ࣮ࢻࢆ♧ࡍࠋᅗ 6୰ࠊ㟷Ꮠࡢࣛ࢖ࣥࡀ㏣ຍࡋࡓࢥ࣮ࢻ࡛࠶ࡿࠋᅗ 6 ࡟࡚ 038-048 ⾜ࡢ࣮ࣝࣉ࡛ࣇ࢓࢖ࣝฟຊࡉࢀࡿ
ኚᩘ ttt ࡜ Source ࢆ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜࢆ⏝࠸࡚ Code-2(WatiIO ࣛࣥࢡ␒ྕ=㸯)࡜
Code-3(WatiIO ࣛ ࣥ ࢡ ␒ ྕ =2) ࡟ ㏦ ಙ ࡋ ࡚ ࠸ ࡿ ࠋ ࡇ ࡢ 2 ࡘ ࡢ ኚ ᩘ ࡢ ㏦ ಙ ࡟ ࡣ 2 ࡘ ࡢ
WAITIO_MPI_Isend()㛵ᩘࢆ⏝࠸ࠊ2 ࠿ᡤ࡟㏦ಙࡍࡿࡓࡵ࡟ WaitIO ࣛࣥࢡ␒ྕ 1,2 ࡟࣮ࣝࣉࢆ⏝࠸࡚࠸ࡿࠋࡑࢀࡒࢀࡢ WAITIO_MPI_Isend()㛵ᩘ࡟ᚲせ࡞ Request ᵓ㐀యࡣ 005,017 ⾜࡛ 2 ḟඖ㓄ิ࡜ࡋ࡚๭ࡾᙜ࡚࡚࠸ࡿࠋ038-048 ⾜ࡢ࣮ࣝࣉ࡛ࡑࢀࡒࢀࡢ WaitIO ࣛࣥࢡ␒ྕ 1,2 ࡟ᑐࡋ࡚WAITIO_MPI_Isend()㛵ᩘࢆ 2 ᅇⓎ⾜ࡋࡓᚋࠊ048 ⾜ࡢ WATIO_MPI_Waitall()㛵ᩘ࡛┦ᡭࡀཷಙࡋ
ࡓࡇ࡜ࢆᚅࡕྜࢃࡏࡿࠋ࡞ ࠾ ࠊ 018 ⾜ ࡢ

WAITIO_CREATE_UNIVERSE_PBHEAD() 㛵 ᩘ ࡢ ᘬ ᩘ ࡛ ࠶ ࡿ

WAITIO_SOLVER_COMM ኚᩘࡣ 8 ࣂ࢖ࢺࡢ࣏࢖ࣥࢱ࣮ࡀ᱁⣡ࡉࢀࡿࡓࡵ 8 ࣂ࢖ࢺࡢኚᩘᐃ⩏ࡀᚲせ࡛࠶ࡿࠋᮏࢥ࣮ࢻ࡛ࡣ implicit ᐃ⩏࡟ࡼࡾ 8 ࣂ࢖ࢺࡢ REAL ኚᩘ࡜ࡋ࡚ᐃ⩏ࡉࢀ࡚࠸ࡿࠋ

ᅗ 7. Toy ࣉࣟࢢ࣒ࣛࡢ WaitIO ࣉࣟࢢ࣒ࣛ㸸Code-2 ಟṇ㒊
File:SYStest-waitio-socket/src2/test1_waitio.f

スーパーコンピューティングニュース- 42 -

Vol. 24, No.3

2022

ᅗ 7 ࡟ࠊToy ࣉࣟࢢ࣒ࣛࡢ WaitIO ࣉࣟࢢ࣒ࣛࡢෆ Code-2 ࡢಟṇ῭ࡳ FORTRAN ࢥ࣮ࢻࢆ♧ࡍࠋࡇࡢಟṇࡢ௚ึᮇ໬ࢥ࣮ࢻࡶ Code-1 ࡜ྠᵝ࡟㏣ຍࡉࢀ࡚࠸ࡿࠋCode-1 ࡜ྠᵝ WaitIO MPIConversion ࣛ࢖ࣈࣛࣜ࡟⨨ࡁ᥮࠼࡚࠸ࡿࠋ
ᅗ 7 ୰ࠊ054-061 ⾜ࡣ Code-1(WatiIO ࣛࣥࢡ␒ྕ=0)࠿ࡽࡢࢹ࣮ࢱཷಙ࡛࠶ࡿࠋࢥ࣓ࣥࢺ࢔࢘ࢺ
ࡉࢀࡓ 053 ⾜ࢆ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜ࡟᭩ࡁ᥮࠼ࡓࡶࡢ࡛࠶ࡿࠋࡲࡓࠊ102-121 ⾜ࡣྠࡌࡃ 100 ⾜ࡢࣇ࢓࢖ࣝฟຊࢆ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜ࡟᭩ࡁ᥮࠼ࠊCode-3(WatiIO ࣛ
ࣥࢡ␒ྕ=2)࡬ࡢ㏻ಙ࡟ኚ᥮ࡋࡓࡶࡢ࡛࠶ࡿࠋ

ᅗ 8. Toy ࣉࣟࢢ࣒ࣛࡢ WaitIO ࣉࣟࢢ࣒ࣛ㸸Code-3 ಟṇ㒊
File:SYStest-waitio-socket/src3/test1_waitio.fᅗ 8 ࡟ࠊToy ࣉࣟࢢ࣒ࣛࡢ WaitIO ࣉࣟࢢ࣒ࣛࡢෆ Code-3 ࡢಟṇ῭ࡳ FORTRAN ࢥ࣮ࢻࢆ♧ࡍࠋࡇࡢಟṇࡢ௚ึᮇ໬ࢥ࣮ࢻࡶ Code-1, Code-2 ࡜ྠᵝ࡟㏣ຍࡉࢀ࡚࠸ࡿࠋCode-1, Code-2 ࡜ྠᵝ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜ࡟⨨ࡁ᥮࠼࡚࠸ࡿࠋ
ᅗ 8 ୰ࠊCode-2 ࡜ྠᵝ࡟ 055-062 ⾜ࡣ Code-1(WatiIO ࣛࣥࢡ␒ྕ=0)࠿ࡽࡢࢹ࣮ࢱཷಙ࡛࠶ࡿࠋ
ࢥ࣓ࣥࢺ࢔࢘ࢺࡉࢀࡓ 054 ⾜ࢆ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜ࡟᭩ࡁ᥮࠼ࡓࡶࡢ࡛࠶ࡿࠋࡲ
ࡓࠊ072-091 ⾜ࡣ 071 ⾜ࡢࣇ࢓࢖ࣝධຊࢆ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜ࡟᭩ࡁ᥮࠼ࠊCode2(WatiIO ࣛࣥࢡ␒ྕ=2)࠿ࡽࡢࢹ࣮ࢱཷಙ࡟ኚ᥮ࡋࡓࡶࡢ࡛࠶ࡿࠋ ௨ୖࡢࡼ࠺࡟ࠊࣇ࢓࢖ࣝධฟຊࢆ WaitIO MPI Conversion ࣛ࢖ࣈࣛࣜ࡟⨨ࡁ᥮࠼ࡿࡢࡣᶵᲔⓗ࡟⾜࠺ࡇ࡜ࡀྍ⬟࡛࠶ࡿࠋ
4.3 Wisteria/BDEC-01 ࡟࠾ࡅࡿ WaitIO ᐇ⾜⎔ቃࡢᴫせ ᮏ⠇࡛ࡣ 6 ᭶ࡼࡾࢧ࣮ࣅࢫ㛤ጞࢆணᐃࡋ࡚࠸ࡿ WaitIO ࡢヨ⾜⎔ቃ࡟ࡘ࠸࡚ㄝ᫂ࡍࡿࠋ
z

WaitIO 㛵㐃ࡢࣇ࢓࢖ࣝࡣ Wistria/BDEC-01 ࡢ/work/share/waitio ୗ࡟㓄⨨ࡉࢀࡿࠋToy ࣉࣟࢢ࣒ࣛ➼ࠊᐇ⾜⏝ࡢࢸࢫࢺࢧࣥࣉࣝࡣ௨ୗ࡟㓄⨨ࡉࢀࡿ /work/share/waitio/src/examples/z

module ᐇ⾜⎔ቃ࡜ࡋ࡚ waitio ࡀᥦ౪ࡉࢀ PATHࠊLD_LIBRARY_PATH ➼ࡢᐇ⾜࡟ᚲせ࡞タᐃࡀᥦ౪ࡉࢀࡿࠋ౛࠼ࡤࣂࢵࢳࢫࢡࣜࣉࢺෆ࡛ module load waitio ࡜ࡍࡿ࡜ࢪࣙࣈᐇ⾜࡟ᚲせ࡞⎔ቃタᐃࡀᐇ⾜ࡉࢀࡿࠋ

スーパーコンピューティングニュース- 43 -

Vol. 24, No.3

2022

z

ࡇࡢ௚ࠊWisteria/BDEC-01 ࡢ Odyssey ࡜ Aquarius 㛫࡛ࡢࣂࢵࢳฎ⌮༠ㄪᐇ⾜ࡢࡓࡵࡢ௙⤌ࡳࡶ‽ഛ୰࡛࠶ࡿࠋ

ࡇࢀ௨㝆ࡢ Toy ࣉࣟࢢ࣒ࣛࡢࢥࣥࣃ࢖ࣝ࡜ᐇ⾜ࡢㄝ࡛᫂ࡣ௨ୖࡢ⎔ቃୗ࡟࠾ࡅࡿヨ⾜࡟ࡘ࠸࡚ㄝ᫂ࡍࡿࠋ
4.4 Toy ࣉࣟࢢ࣒ࣛࡢࢥࣥࣃ࢖ࣝ࡜ᐇ⾜ ᮏ⠇࡛ࡣ 6 ᭶࡟ Wistria/BDEC-01 ࡛ࡢ WaitIO ࢧ࣮ࣅࢫ㛤ጞ᫬ࡢ⎔ቃࢆ᝿ᐃࡋࡓࣉࣟࢢ࣒ࣛࡢ
ࢥࣥࣃ࢖ࣝ࡜ᐇ⾜ࡢᴫせࢆㄝ᫂ࡍࡿࠋ๓⠇࡛᭩࠸ࡓ㏻ࡾ WaitIO ࡟㛵㐃ࡍࡿࣇ࢓࢖ࣝ⩌ࡣ
Wistria/BDEC-01 ࡢ/work/share/waitio ࢹ࢕ࣞࢡࢺࣜ࡟⨨࠿ࢀ࡚࠸ࡿࠋToy ࣉࣟࢢ࣒ࣛࡢࢯ࣮ࢫ୪ࡧ
࡟ᐇ⾜⎔ቃࡣ/work/share/waitio/src/examples/SYStest-waitio-socket.tgz ࡟୍ᘧ࢔࣮࢝࢖ࣈࡉࢀ࡚࠸
ࡿࡢ࡛ྛ࣮ࣘࢨࡢ/work ୗࡢࢹ࢕ࣞࢡࢺࣜ࡟ᒎ㛤ࡋ࡚฼⏝ࡍࡿࠋᅗ 9 ࡟୍㐃ࡢฎ⌮ࢆ♧ࡍࠋ
Toy ࣉࣟࢢ࣒ࣛࡢ࢔࣮࢝࢖ࣈࢆྛ࣮ࣘࢨࡢ work ࢹ࢕ࣞࢡࢺࣜ࡟ᒎ㛤ࡍࡿ࡜ࢥ࣮ࢻ୍ᘧࡣ
SYStest-waitio-socket ࢹ࢕ࣞࢡࢺࣜୗ࡟ᒎ㛤ࡉࢀࡿࡢ࡛ࠊࡇࡢࢹ࢕ࣞࢡࢺࣜୗ࡛ make ࢥ࣐ࣥࢻࢆ
ᐇ⾜ࡍࡿ࡜ SYStest-waitio-socket 㓄ୗࡢ run ࢹ࢕ࣞࢡࢺࣜ࡟ Odyssey ⏝ࣂ࢖ࢼࣜ(-a64fx)࡜ Aquarius⏝ࣂ࢖ࢼࣜ(-intel)ࡢ 3 ✀㢮㹶2 CPU ࢱ࢖ࣉ㸻ィ 6 ✀ࡢ WaitIO ⏝ࡢᐇ⾜ࣂ࢖ࢼࣜ࡜࢜ࣜࢪࢼࣝࡢ
ᐇ⾜ࣂ࢖ࢼࣜ 3 ✀ࡀ⏕ᡂࡉࢀࡿࠋ(ᅗ 9)ᅗ 9. WaitIO ∧ Toy ࣉࣟࢢ࣒ࣛࡢࣇ࢓࢖ࣝᒎ㛤࡜ࢥࣥࣃ࢖ࣝ

ᅗ 10. 11. ࡟ Wisteria/BDEC-01 ࢩࢫࢸ࣒(Odyssey+Aquarius)࡛ᐇ⾜ྍ⬟࡞ࣂࢵࢳࢫࢡࣜࣉࢺࢆ♧ࡍࠋࡇࢀࡽࡢࣂࢵࢳࢫࢡࣜࣉࢺࡣ wisteria01 ࣀ࣮ࢻୖ࡛ 2 ❶ㄝ᫂ࡢ waitio-serv ࢥ࣐ࣥࢻ࡟ࡼࡿࢧ
࣮ࣂࡢ฼⏝ࡀ๓ᥦ࡛࠶ࡿࠋࡇࢀ࡟ࡼࡾࠊࢪࣙࣈᐇ⾜᫬ࡢࣂࢵࢳࢫࢡࣜࣉࢺࡢಟṇࡣ୙せ࡛࠶ࡿࠋࡲࡓࠊwaitio module ࡢ฼⏝࡟ࡼࡾ⎔ቃኚᩘ PATH ࡜ LD_LIBRARY_PATH ࡢタᐃࡀ୙せ࡟࡞ࡗ࡚࠸ࡿࠋスーパーコンピューティングニュース- 44 -

Vol. 24, No.3

2022

ᅗ 10. Toy ࣉࣟࢢ࣒ࣛࡢ WaitIO ࣂࢵࢳᐇ⾜⏝ࢫࢡࣜࣉࢺ: a64fx

ᅗ 11. Toy ࣉࣟࢢ࣒ࣛࡢ WaitIO ࣂࢵࢳᐇ⾜⏝ࢫࢡࣜࣉࢺ: intel

ᅗ 10ࠊᅗ 11 ࡢࣂࢵࢳࢫࢡࣜࣉࢺࡣ Code-1+Code-2+Code-3 ࡢ⤌ࡳྜࢃࡏ࡛࠶ࢀࡤ a64fx ⏝ࠊintel ⏝࡝ࡢ⤌ࡳྜࢃࡏ࡛ࡶືసྍ⬟࡛࠶ࡿࠋᐇ⾜᫬࡟ὀពࡍࡿࡇ࡜ࡣ Code-1, Code-2 ࡢࢪࣙࣈࢆ
Submit ࡋࡓᚋࠊCode-2 ࡀᐇ⾜㛤ጞࡋࡓᚋ࡟ Code-3 ࢆ Submit ࡍࡿࡇ࡜࡛࠶ࡿࠋࡇࢀࡣࠊCode-3
ࡢࢪࣙࣈࢫࢡࣜࣉࢺࡢ mpiexec ⾜ࡢ๓࡟ᐇ⾜ࡉࢀࡿ waitio-serv –r ࢥ࣐ࣥࢻࡀⓏ㘓ࡉࢀࡓࢧ࣮ࣂタᐃࢆࣜࢭࢵࢺࡍࡿࡓࡵ࡛࠶ࡿࠋࡇࡢࡓࡵࠊࣜࢭࢵࢺᚋ࡟ Code-2 ࡢࢪࣙࣈࡀᐇ⾜㛤ጞࡉࢀ࡚ࡶ
ࢧ࣮ࣂྡࢆ⋓ᚓ࡛ࡁࡎᐇ⾜ᚅࡕ࡟࡞ࡿࠋ
 ᅗ 12, ᅗ 13 ࡟ᐇ㝿ࡢ WaitIO ∧ Toy ࣉࣟࢢ࣒ࣛࡢᐇ⾜౛ࢆ♧ࡍࠋᅗ 12 ࡀᐇ㝿ࡢࢪࣙࣈᐇ⾜ࡢᵝᏊࢆ♧ࡋ࡚࠾ࡾࠊᅗ 13 ࡀ୍㐃ࡢࢪࣙࣈᐇ⾜࡟ᚲせ࡞ waitio-serv ࣉࣟࢢ࣒ࣛࡢᐇ⾜ฟຊ࡛࠶ࡿࠋ
ᅗ 12 ࡛ࡣࠊCode-1(Intel)+Code-2(a64fx)+Code-3(a64fx)ࡢ⤌ࡳྜࢃࡏ࡛ࡢᐇ⾜⤖ᯝ࡛࠶ࡿࡀࠊ
Code-1, Code-2, Code-3 ࡢࡑࢀࡒࢀ௵ពࡢ a64fx ୪ࡧ࡟ intel ⏝ࡢࢫࢡࣜࣉࢺࢆ㑅ᢥྍ⬟࡛࠶ࡿࠋ ᅗ 13 ࡢ waitio-serv ࣉࣟࢢ࣒ࣛࡢฟຊ࡛࠶ࡿࡀࠊCode-1 ࡟ࡼࡿ Master Host ࡢⓏ㘓࡟ጞࡲࡾࠊ
Code-3 ࡟ࡼࡿ Master Host Ⓩ㘓ࡢࣜࢭࢵࢺ୍࡛㐃ࡢࢪࣙࣈᐇ⾜ࡀ⤊஢ࡍࡿࠋ

スーパーコンピューティングニュース- 45 -

Vol. 24, No.3

2022

ᅗ 12. WaitIO ∧ Toy ࣉࣟࢢ࣒ࣛࡢᐇ⾜౛: Code-1(Intel)+Code-2(a64fx)+Code-3(a64fx)

ᅗ 13. WaitIO ∧ Toy ࣉࣟࢢ࣒ࣛࡢᐇ⾜౛ waitio-serv ฟຊ: Code-1(Intel)+Code-2(a64fx)+Code-3(a64fx)

ᅗ 14. WaitIO ∧ Toy ࣉࣟࢢ࣒ࣛࡢᐇ⾜౛: s3.out ࣇ࢓࢖ࣝฟຊ: Code-1(Intel)+Code-2(a64fx)+Code-3(a64fx)

スーパーコンピューティングニュース- 46 -

Vol. 24, No.3

2022

ᅗ 14 ࡟᭱⤊ฟຊ࡛࠶ࡿ s3.out ࣇ࢓࢖ࣝࡢฟຊ⤖ᯝࡢᢤ⢋ࢆ♧ࡍࠋᮏࣉࣟࢢ࣒࡛ࣛࡣ᭱ᚋࡢ 2 ࡘࡢ⤖ᯝࡀ୍⮴ࡍࡿࡇ࡜࡛ィ⟬ࡀṇࡋࡃᐇ⾜ࡉࢀ࡚࠸ࡿ࠿ࢆ☜ㄆࡍࡿࡇ࡜ࡀ࡛ࡁࡿࠋ

5.

ࡲ࡜ࡵ࡜௒ᚋࡢணᐃ

ᮏ✏࡛ࡣ Wisteria/BDEC-01 ฼⏝஦౛࡜ࡋ࡚ h3-Open-BDEC ࡜ h3-Open-BDEC ࡢ୍ࡘࡢࣔࢪ࣮ࣗ
ࣝࡢ୍ࡘ࡛࠶ࡿ h3-Open-SYS/WaitIO ࡢᴫせ࡟ࡘ࠸࡚ࠊ㐺⏝஦౛ࢆྵࡵࡓࣉࣟࢢ࣑ࣛࣥࢢ࡜ᐇ⾜౛ࢆ஺࠼࡚⤂௓ࡋࡓࠋᮏྕࡢูグ஦࡛ࡣ h3-Open-UTIL/MP ࡢᴫせࠊḟྕ࡛ࡣ h3-Open-UTIL/MPࢆά⏝ࡋࡓ GP-GPU 㐃ᦠࢆྵࡵࡓከᶵ⬟࢝ࢵࣉ࣮ࣛ࡜ࡋ࡚ࠕィ⟬࣭ࢹ࣮ࢱ࣭Ꮫ⩦ࠖ⼥ྜࡢ஦౛ࡶ
⤂௓ࡍࡿࡢ࡛ྜࢃࡏ࡚ཧ⪃࡟ࡉࢀࡓ࠸ࠋ
WaitIO-Socket ࡣ 6 ᭶ࡼࡾ Wisteria ࡛ࡢࢧ࣮ࣅࢫࢆ㛤ጞࡍࡿணᐃ࡛ࠊᚎࠎ࡟࢔ࣉࣜࢣ࣮ࢩࣙࣥ
࣮ࣘࢨ࡬ࡢ㐺⏝஦౛ࢆቑࡸࡋ࡚࠸ࡃ࡭ࡃ࣮ࣘࢨࢆເ㞟୰࡛࠶ࡿࠋᗈࡃ࣮ࣘࢨ࡟౑ࡗ࡚࠸ࡓࡔࡃࡓ
ࡵࠊ௒ᖺᗘࢳ࣮ࣗࢺࣜ࢔࣭ࣝㅮ⩦఍ࡢ㛤ദࢆィ⏬ࡋ࡚࠸ࡿࠋࡈ⯆࿡ࡢ࠶ࡿ᪉ࡣཧຍ࠸ࡓࡔࡅࢀࡤ
ᖾ࠸࡛࠶ࡿࠋ
௒ᚋࡣᐇ㐠⏝࡟⪏࠼ࡿ࡭ࡃṇᖖ⣔ࡢฎ⌮࡟ຍ࠼␗ᖖ⣔ࡢฎ⌮ࢆᣑ඘ࡍࡿ࡜ඹ࡟ࢭࣥࢱ࣮ෆࡔ
ࡅ࡛࡞ࡃࢭࣥࢱ࣮㛫࡛ࡢࢹ࣮ࢱ㏻ಙ࡟ࡶά⏝ྍ⬟࡞ࣛ࢖ࣈࣛࣜࢆᣑᙇࡋ࡚࠸ࡃணᐃ࡛࠶ࡿࠋ

ཧ⪃ᩥ⊩[1] Wisteria/BDEC-01㸦ࠕィ⟬࣭ࢹ࣮ࢱ࣭Ꮫ⩦ࠖ⼥ྜࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩࢫࢸ
࣒㸧:https://www.cc.utokyo.ac.jp/supercomputer/wisteria[2] ୰ᓥ◊࿃, ሮᩄ༤, ୗᕝ㎶㝯ྐ, ఀ⏣᫂ᘯ, Ⱚ㞙ே, ୕ᮌὒᖹ, ᫍ㔝ဴஓ, ᭷㛫 ⱥᚿ, Ἑྜ┤⪽, ᆏᮏ㱟୍, ᒾୗṊྐ, ඵ௦ᑦ, 㛗ᑿ኱㐨, ᯇⴥᾈஓ, Ⲷ⏣Ṋྐ, ∦᱒Ꮥὒ㸪ྂᮧᏕᚿ, 㭯ᒸᘯ, ᕷᮧᙉ, ⸨⏣⯟ᖹ㸪㏆⸨ṇ❶㸪ࠕィ⟬࣭ࢹ࣮ࢱ࣭Ꮫ⩦ࠖ⼥ྜࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩ
ࢫࢸ࣒ࠕWisteria/BDEC- 01ࠖࡢᴫせ㸪᝟ሗฎ⌮Ꮫ఍◊✲ሗ࿌㸦2020-HPC-179-01㸧㸪2021[3] ሮ ᩄ༤㸪୰ᓥ ◊࿃㸪ୗᕝ㎶㝯ྐ, Ⱚ㞙ே, ୕ᮌὒᖹ, ᫍ㔝ဴஓ, Ἑྜ┤⪽㸪ఝ㫽ၨ࿃, ௒ᮧಇᖾ㸪ᕤ⸨࿘ᖹ㸪୰ᑿ ᫀᗈ㸪ࠕィ⟬࣭ࢹ࣮ࢱ࣭Ꮫ⩦ࠖ⼥ྜࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢱࢩࢫࢸ
࣒ࠕWisteria/BDEC- 01ࠖࡢᛶ⬟ホ౯㸪᝟ሗฎ⌮Ꮫ఍◊✲ሗ࿌㸦2021-HPC-180-22㸧㸪2021[4] ఫඖ┿ྖ㸪Ⲩᕝ㝯㸪ᆏཱྀྜྷ⏕㸪ᯇⴥᾈஓ㸪ඵ௦ᑦ㸪ሮᩄ༤㸪୰ᓥ◊࿃㸪WaitIO-Socket㸸␗✀ࢩࢫࢸ࣒ୖࡢ」ᩘ MPI ࣉࣟࢢ࣒ࣛࢆ⤖ྜࡍࡿ㏻ಙࣛ࢖ࣈࣛࣜࡢヨస㸪᝟ሗฎ⌮Ꮫ఍◊✲ሗ࿌㸦2021-HPC-181-07㸧㸪2021[5] Arakawa, T., Yashiro, H., Nakajima, K., Development of a coupler h3-Open-UTIL/MP, ACM
Proceedings of the International Conference on High Performance Computing in Asia-Pacific Region(HPC Asia 2022), 2022
[6] ppOpen-HPC: https://github.com/Post-Peta-Crest/ppOpenHPC[7] h3-Open-BDEC㸸https://h3-open-bdec.cc.u-tokyo.ac.jp/[8] Iwashita, T, Nakajima, K., Shimokawabe, T., Nagao, H., Ogita, T., Katagiri, T., Yashiro, H., Matsuba,
H., h3-Open-BDEC: Innovative Software Platform for Scientific Computing in the Exascale Era byIntegrations of (Simulation + Data + Learning), Project Poster, ISC-HPC 2020
[9] Nakajima, K., Matsuba, K., Hanawa, T., Furumura, T., Tsuruoka, H., Nagao, H., Integration of 3D

スーパーコンピューティングニュース- 47 -

Vol. 24, No.3

2022

Earthquake Simulation & Real-Time Data Assimilation on h3-Open-BDEC, MS290: Progress &Challenges in Extreme Scale Computing & Data SIAM Conference on Computational Science &Engineering (CSE21) (Online, March 4, 2021)[10] SIAM News (March 10, 2021), Supercomputer Simulations of Earthquakes in Real Time (by Jillian
Kunze), https://sinews.siam.org/Details-Page/supercomputer-simulations-of-earthquakes-in-real-time[11] ୰ᓥ◊࿃㸪ྂᮧᏕᚿ㸪㭯ᒸᘯ㸪ᆏཱྀྜྷ⏕㸪ᯇⴥᾈஓ㸪ఫඖ┿ྖ㸪ඵ௦ᑦ㸪Ⲩᕝ㝯㸪ሮᩄ༤㸪ほ ࢹ࣮ࢱྠ໬࡟ࡼࡿ㛗࿘ᮇᆅ㟈ືࣜ࢔ࣝࢱ࢖࣒ண ࡬ྥࡅࡓヨࡳ㸪᝟ሗฎ⌮Ꮫ఍◊✲ሗ࿌㸦2021-HPC-182-08㸧㸪2021[12] Nakajima, K., Parallel Iterative Solvers of GeoFEM with Selective Blocking Preconditioning for
Nonlinear Contact Problems on the Earth Simulator. ACM/IEEE Proceedings of SC’03,
https://doi.org/10.1145/1048935.1050164, 2003

スーパーコンピューティングニュース- 48 -

Vol. 24, No.3

2022

Wisteria/BDEC-01 利用事例（5）マルチプログラム連成ライブラリ h3-Open-UTIL/MP (1/2)
荒川隆（CliMTech）
八代尚（国立環境研究所）
中島研吾（東京大学情報基盤センター）
1

はじめに
今回と次回（2022 年 7 月号）の 2 回に分けて複数のシミュレーションプログラムを連成実行

し「計算・データ・学習」融合を推進するためのライブラリ h3-Open-UTIL/MP について紹介する。今回は一般的な単一アーキテクチャ環境で複数プログラムを連成するケースについて説明し，
次回では h3-Open-UTIL/MP の特徴的な機能であるアンサンブル連成，Python APP 連成，異機種間連成機能などについて紹介する。なお対象読者としては MPI を用いた並列計算には一通り習熟しているが連成計算については未経験のレベルを想定し，今号では煩瑣をいとわず連成計算の基礎的な概念や実行方法も含めて解説してゆく。なお，このような計算方法は「連成解析」「連成計算」「結合計算」など複数の用語が用いられるが本稿では基本的に「連成計算」の語を用い，
一部はコミュニティの慣習に従って結合（例：大気海洋結合）を用いることとする。

2

連成計算の基本概念
本節では連成計算の基本的な概念について解説し，次節で MPI 環境における連成計算の実行方法を説明する。既に MPI を用いた連成計算の経験がある読者は本節および次節は飛ばしても差し支えない。
連成計算の基本概念を説明する前に，ひとつの逸話を紹介したい。司馬遼太郎の「街道をゆく」の一篇[1]に，ある僧侶が鈴木大拙の著作「華厳の研究」の翻訳（原著は英語）を読み華厳経の難解な仏教用語である「相即相入」が平易な言葉として表現されていることで経典の内容が腑に落ちる，という経験をしたことが語られている。この際，鈴木大拙が用いた語がinterpenetration で，辞書的には相互浸透あるいは相互貫入と説明されている。すなわち世界のすべては相互に影響し合い，何一つとして独立して存在するものはないという意である。これをシミュレーションに置き換えると，単一の事象を再現するだけでは不完全であり関連する様々な事象との相互作用も含めて考える必要がある，という事になろう。連成計算とはまさにこの世界の構造（の極めて不完全なごく一部）を計算機内で実現するための計算手法である。
改めて述べると，連成計算とは複数のシミュレーションプログラムを複合させ相互作用を伴いながら計算してゆく手法である。計算手法として複数の場をひとつの支配方程式で解く強連成と支配方程式を個別に解いて時間ステップ毎に解を交換しながら計算を進める弱連成に大別される。本稿で述べる h3-Open-UTIL/MP は不特定のシミュレーションモデルを対象として弱連成計算を容易に実現するためのソフトウェアである。このようなソフトウェアを一般にカプラと呼ぶ。現代では連成計算は構造や流体，熱解析など様々な分野で実現されており専用の解析ソフトウェアも多くリリースされているが，ここでは連成計算の先駆的な事例のひとつである
気象・気候シミュレーションを事例として連成計算の基本概念について解説する。2021 年ノー- 1 スーパーコンピューティングニュース- 49 -

Vol. 24, No.3

2022

ベル物理学賞受賞者に眞鍋淑郎博士が選ばれたことは，本稿の読者にとっても既知のことであろう。真鍋の代表的な業績が大気海洋結合モデルの開発およびそれを用いた気候変動予測シミュレーションである[2,3]。この計算では大気モデルと海洋モデルが相互に海水面温度や風速などの情報（データ）を交換しながら時間積分を進めるようになっている。現代の最先端の気
象・気候シミュレーションモデルでも真鍋が開発した基本的なフレームは変わっておらず，例
えば日本の代表的なモデルのひとつである MIROC(Model for Interdisciplinary Research on Climate)
は大気モデルと海洋モデルの２つのモデルコンポーネントを中心にしてシステムが構成されている[4]。大気モデルと海洋モデルは異なるバイナリとしてコンパイル・リンクされ，MPI 環境
下で同時に実行される（具体的な実行方法については後述）。大きなモデルコンポーネントは
大気と海洋の２つであるが他にも陸面や河川などの過程がコンポーネント化されており，これらは大気モデルの一サブルーチンとして大気モデルのプログラムに組み込まれている。実際の計算ではこれらの要素モデルが相互に必要な情報を交換しながら時間積分を進めてゆくことになる。この際，個々のモデルコンポーネントはそれが表現している現象に応じた時空間構造を持つため，情報の交換に際しては構造の差違を吸収するための適切な変換を行う必要がある。
MIROC の大気海洋モデルを例にすると，大気モデルは緯度経度に沿った規則的な矩形格子を持つのに対して，海洋モデルは極点を陸上に移動させた変則的な矩形格子を持つ。更に，大気モデルが全球をくまなく覆っているのに対して，海洋モデルは陸域を除いた格子のみが意味のある値を持っている。従って，情報の交換に際してはこのような格子の差違を補正する補間計算が必要となる。時間的にも大気モデルと海洋モデルでは代表的なシミュレーションの時間刻み
幅（ΔT）が異なっており，大気側のΔT が海洋に比して短いため，大気から海洋への情報は大気の各時間ステップの平均値が渡されるようになっている。これらの状況を模式的に表したのが図１である。図中，Atm. Step は大気モデルの計算，Land Step は陸面モデル，River Step
は河川モデル，Ocean Step は海洋モデルの計算を表す。大気モデルと海洋モデルは個別のバイナリとして並列に実行され，各データ交換ステップで前ステップまでの計算結果が相互に送受信される。一方，大気と陸面や河川では同一時間ステップ内で順番にデータが渡され逐次的に計算が実行される。ここで，T N, TN+1,

TN+2 は大気モデルと海洋モデルがデータ交換する大きな

時間刻み幅を表している。一方，大気モデル(Atm. Step)の中で青い太線で表されるのが大気モ
デルの細かい時間刻み幅である。大気モデルから海洋モデルへ送られるデータが時間平均値の場合は，細かい時間刻み幅毎の値で平均値が計算される。
ここでは気候シミュレーションを例に連成計算の基本的な概念について説明したが，現代の並列計算環境下における連成計算の基本的な要素は 1)複数のモデルコンポーネントが情報（データ）を交換しながら計算を進める。2)情報交換に際しては時空間構造の差違を補整する計算が実行される。という２点に集約されると考えられる。一方，情報交換や時空間構造の補正の具体的な方法については分野や用途によって異なる対応が要求される。代表的な例として空間構造の補整（補間計算）を考える。大気モデルと海洋モデルを連成して気候のような長期的な現象を計算する場合には，量の保存が厳密に保たれることが要求される（そうでないと海が干上がったりする）。そのために，補間計算には各格子点が代表する面積に応じて値を比例配分
する面積重み法が用いられるが[5]，その際に更に問題を複雑にしているのは海陸分布の存在である。海洋モデルが陸域を除いた格子で意味のある値を持つことは前述の通りであるが，大気モデル側の格子が海洋モデル格子の陸と海の境界をまたぐ場合には海陸の割合も考慮した上で- 2 スーパーコンピューティングニュース- 50 -

Vol. 24, No.32022

値を適切に配分する必要がある。一方で厳密性を要求されないような空間補間が許容される事例もあり得る。例えば，地震動から構造物の振動を計算するような場合，構造物からの地震動への影響は無視しうるため情報の伝達方向は一方向だけで良く，物理量の厳密な保存は要求されない。そのため，この例では直方体で構成される地震モデルの格子から単純な線形内挿で構
造物モデルの格子点値を求めている[6]。
本稿で解説するカプラ h3-Open-UTIL/MP は特定の分野に特化することなく様々な用途に用いられることを目標としており，上記のような計算方法の差違や更には格子構造の差違に対して柔軟に対応されることが求められ，かつ実現している。そのための仕組みについては第 4 節以降で詳述する。
大気モデル

海洋モデル

Atm. Step

Ocean Step

TN

Land Step
River Step

TN+1
Atm. Step

Ocean Step

Land Step
River Step

TN+2

図 1 MIROC における大気モデル・海洋モデル他の連成方法

3

MPI 環境における連成計算
本節では MPI 環境における連成計算の方法について説明する。前提として，連成対象となる

個々のモデルコンポーネントは既に MPI 並列化されているものとし，複数のモデルコンポーネントを連成する場合の基本的な概念や手続きについて解説する。
MPI で複数のプログラムを実行する方法には２通りの方法がある。ひとつは Master/Worker 方
式 で あ り ， こ の 場 合 ， マ ス タ と な る プ ロ セ ス が 子 プ ロ セ ス を 生 成 す る MPI コ マ ン ド(mpi_comm_spawn)をコールする。例えばカプラが独立したプロセスとして最初に起動され，そこから連成対象となるモデルプロセスを生成する場合である。もうひとつは連成対象となるプログ
ラムを一度に起動する方式である。具体的には下の例のように mpiexec（もしくは類似）コマン
ドに対して複数のプログラムを引数として与えるようにする。

mpiexec -np 8 app1.exe : -np 4 app2.exe
これら２通りの方式では起動されるプログラムの MPI 情報が異なる。簡単なテストプログラム- 3 スーパーコンピューティングニュース- 51 -

Vol. 24, No.3

2022

で具体例を示す。まず Master/Worker 方式のテストプログラムを図 2 に示す。Master 側で MPI サ
ブルーチン mpi_comm_spawn をコールし worker プログラムを起動している。３番目の引数が起動されるプロセス数で，例では５プロセスの worker が起動される。次いでサブルーチン
mpi_comm_rank をコールして MPI のデフォルトコミュニケータである MPI_COMM_WORLD を引数として自プロセスのランク番号を取得し出力している。

program masteruse mpi
implicit none
integer :: my_rank
integer :: inter_comm
integer :: ierror
call mpi_init(ierror)
call mpi_comm_spawn("./worker", MPI_ARGV_NULL, 5, &MPI_INFO_NULL, 0, MPI_COMM_WORLD, &inter_comm, MPI_ERRCODES_IGNORE, ierror)
call mpi_comm_rank(MPI_COMM_WORLD, my_rank, ierror)
write(*,*) "my_rank = ", my_rank
call mpi_finalize(ierror)
end program maste

program worker
use mpi
implicit none
integer :: my_rank
integer :: ierror
call mpi_init(ierror)
call mpi_comm_rank(MPI_COMM_WORLD, my_rank, ierror)
write(*,*) "my_rank = ", my_rank
call mpi_finalize(ierror)
end program worker

図 2 連成計算テストプログラム（上図：Master，下図：Worker）

このプログラムを mpiexec -n 2 ./master コマンドで実行した場合の結果が図 3 左図である。一方，worker プログラムを worker1 と worker2 として mpiexec -n 2 ./worker1 : -n 5 ./worker2 コマンドで実行した場合の結果が図 3 右図である。結果からわかるように Master/Worker 方式の実行では起動されるプログラム毎に独立した MPI_COMM_WORLD が割り当てられ，その中でランク番号が取得されているのに対し，複数のプログラムを同時に起動する場合はすべてのプロセスで
MPI_COMM_WORLD が共有されている。
- 4 スーパーコンピューティングニュース- 52 -

Vol. 24, No.3

2022

master_rank =master_rank =worker_rank =worker_rank =worker_rank =worker_rank =worker_rank =

0
1
0
1
2
3
4

worker_rank =worker_rank =worker_rank =worker_rank =worker_rank =worker_rank =worker_rank =

2
5
6
4
0
3
1

図 3 連成計算テスト結果（左図：Master/Worker 方式，右図：同時起動方式）

上の例で示したように Master/Worker 方式の場合はプログラム間でコミュニケータが共有されない。そのためプログラム間の通信を行う際には mpi_comm_spawn の 7 番目の引数で MPI から返されるプログラム間コミュニケータ inter_comm を用いることになる。一方，同時起動方式では MPI_COMM_WORLD が共有されるためプログラム間通信は MPI_COMM_WORLD を用いれば良いが，一方で各プログラム内の通信を混乱なく実行するためには MPI サブルーチン
mpi_comm_split を用いてコミュニケータを分割し，プログラム毎に分割されたコミュニケータを用いるようにする必要がある。これらの状況を簡単に示したのが図 4 である。両者の手法には一長一短があるが，Master/Worker 方式の場合，複数の Worker が起動される状況では Worker 間の通信手段が限られる（ないわけではないが相応の手続きを要求される）という問題がある。従って Mater/Worker 方式で複数のモデルコンポーネントを連成する場合には，図に示すように Masterを経由して通信を行うのが一般的である。この際にカプラプログラムを Master とすることで補間計算やデータ通信の管理などをモデルとは別のプロセスで処理できるようになる。このことは連成に際しての計算性能向上（実行時間短縮）要因となり得るが，モデルプロセスに比して計算負荷が軽いカプラに専用プロセスを割り当てることは，全体としては計算効率の低下に繋がる懸念がある。一方，同時に起動する場合はカプラに個別のプロセスを割り当てることなく，モデル
プロセス同士で直接データ交換することが可能である。この場合カプラはライブラリとしてモデ
ルプロセスにリンクされ実行されることになる。h3-Open-UTIL/MP はモデルプロセスを同時に起動するタイプのカプラである。以下では，この形式での実行におけるデータ通信と補間計算について解説する。図 4 では暗黙の前提としてモデルの各プロセスは相手モデルの各プロセスと直接データ交換を行う Local To Local 通信を行うとして描かれている。相互に複数のプロセスで実行されるモデル間でデータを送受信する方法として，より単純なのは 1)送信側の代表プロセスに
送信側各プロセスのデータを集約，2)送信側の代表プロセスから受信側の代表プロセスへ集約したデータを送受信，3)受信側の代表プロセスから受信側各プロセスへデータを分配，という方法である。この際，送信側の代表プロセスもしくは受信側の代表プロセスで全領域のデータを対象として補間計算を行う。この方法は実装が容易だがデータ通信量，プロセスあたりの演算量ともに Local To Local の場合に比して大きくなり，性能上のボトルネックが生じる可能性がある。加えて，大規模並列計算ではメモリ容量の観点から全領域のデータをひとつのプロセスで保持すること自体が不可能な場合もあり得るため，単純な手法では適用できる条件が限られる。一方，Local To Local 通信方法は性能面では優位であるが，適切な格子点データを適切なプロセス間で送受信するためのアルゴリズムが煩雑で実装が難しい場合が(もちろん難易度は双方の格子の形
状や対応関係に依存するが)ある。カプラの存在意義のひとつはこの点にあり，本稿で紹介する
h3-Open-UTIL/MP においても単純な API の呼び出しだけで Local To Local 通信を実現できるよう- 5 スーパーコンピューティングニュース- 53 -

Vol. 24, No.3

2022

に設計・実装されている。

モデル A

MPI_COMM_WORLD

モデル B

mpi_comm_spawn から返される inter communicator

カプラ

mpi_comm_split で生成される intra communicator

図 4 プログラムの起動方法とコミュニケータの関係（左図：Master/Worker 方式，右図：同時起動方式）

次に格子変換機能について説明する。異なる格子形状のモデル間で情報を交換するには受信側の格子点値を送信側の複数の格子点の値から内挿する必要がある。この内挿計算には前項で述べたように，面積で比例配分する方法や線形内挿する方法など複数の手法がある。しかしながらこれらの手法の違いが影響するのは内挿時の格子点の選択と係数に対してであり，計算アルゴリズ
ムとしては同等である。すなわち受信側のある格子点値 R は送信側の複数(N 個)の格子点値 S(i)と係数 C(i)から次の式のように計算される。
� � � ���� ∗ ����

すべての受信側格子点に対して送信側の格子点番号とそれに対応する係数を列挙したものをこ
こでは補間テーブルと呼ぶ。ここで各モデルの格子形状が時間的に変わらないとすると，補間テーブルも時間変化しないため事前に計算しておくことが可能である。この補間テーブルおよびモデルの各プロセスが担当する格子の格子点番号の情報が与えられれば，モデルの各プロセスは 1)
自身が保持する各格子点値を相手モデルのどのプロセスに送信すれば良いか，2)相手モデルのどのプロセスから何番の格子点値を受信すれば良いか，が決定でき適切な Local To Local のデータ交換と各プロセスでの領域毎の補間計算が可能になる。h3-Open-UTIL/MP においては，これらの情報を入力とすることによって各モデルの格子形状そのものには依存しないで連成計算を実行することを可能としている。

- 6 スーパーコンピューティングニュース- 54 -

Vol. 24, No.3

2022

4

h3-Open-UTIL/MP

4.1 h3-Open-UTIL
h3-Open-UTIL はスーパーコンピューティングニュース前号記事[7]で解説された革新的ソフトウ
ェア基盤「h3-Open-BDEC」[8,9]を構成するソフトウェアユニットのひとつである。h3-Open-UTIL
ユニットの目的は Wisteria/BDEC-01 のようなヘテロジニアスなシステム上で，「計算・データ・
学習(S+D+L)」融合を容易に実現するための環境を提供することである[10,11,12]。h3-Open-UTIL
だけでなく h3-Open-BDEC の各ユニットを有機的に協調させ利用することによって，シミュレー
ションノード群で計算科学シミュレーションコードを実行し，データ・学習ノード群では外部から取り込んだ観測データや，機械学習による推論等に基づきパラメータを最適化し，更に計算を実施するというサイクルを容易に実現することができ，またパラメータ最適化によって計算時間を全体として短縮できることが期待される。

4.2 h3-Open-UTIL/MP の構造
h3-Open-UTIL/MP は連成計算を容易に実現するためのソフトウェア(カプラ)である。対象となるのは MPI を用いて領域分割により並列化されたソフトウェア群であり，今のところ Fortran とPython の API が提供されている。h3-Open-UTIL/MP のプログラム構造を図 5 に示す。図は Fortranプログラムと Python プログラムを連成する例である。h3-Open-UITL/MP は最下層に連成ライブ
ラリ Jcup を用いている[13]。Jcup は連成されるモデルコンポーネントの管理や MPI ルーチンコールなどの基本的な機能を提供する。その上に h3-Open-UTIL/MP のプログラムが構築される。
h3-Open-UTIL/MP のプログラムは Python の API を除いて Fortran の module 群で構成されており，
Fortran プログラムから用いる場合は API のモジュールを use して API サブルーチンをコールする。Python に関連したプログラムについては次号の記事で説明する予定である。

Fortran APP

Python APP

h3opp.pyh3-Open-UTIL/MP
h3open_py.f90
modulesh3-Open-UTIL/MP
Jcup lib

Jcup lib

MPI
図5h3-Open-UTIL/MP のプログラム構造

4.3 h3-Open-UTIL/MP の機能
前項で述べたように連成計算はモデルコンポーネント間で情報(データ)を交換しながら計算を進めることであり，情報の交換に際しては時空間構造の差違を補正する必要がある。h3-OpenUTIL/MP は MPI でデータ並列化されたモデルコンポーネントに対して連成計算を可能とするソ
フトウェアである。制約条件としては 1)データ交換の時間間隔はデータ毎に一定間隔でなければならない。2)モデルコンポーネントの格子は一意に番号づけられ相対的な位置が時間変化しな- 7 スーパーコンピューティングニュース- 55 -

Vol. 24, No.3

2022

い。の 2 つである。逆に言えば，この要求を満たすモデルや計算条件であればどのようなモデルでも適用可能である。なおデータ交換の時間間隔は一定である必要があるが，その間の積分時間
ステップは変化しても構わない。この様子を模式的に示したのが図 6 である。図の例では 3 つのモデルコンポーネントがデータを交換しており，モデル A のデータ交換間隔の間に 3 ステップと 4 ステップの時間ステップを計算している。時間構造の補正として h3-Open-UTIL/MP にはデータの時間平均値を計算する機能がある。平均値計算のアルゴリズムは単純に各時間ステップのΔT で比例配分する方法であり，式で表すと次のようになる。ここで Dmean は時間平均値，D(t)は時間ステップｔの値，ΔT(t)は時間ステップ t でのΔT，Tex はデータ交換間隔である。先述のようにデータ交換間隔 Tex は一定値でなければならず，またモデルの時間ステップの刻みと一致している，すなわち Tex=ΣΔT(t)でなければならない。なお平均値を交換するか瞬間値を交換するかは設定で切り替えることができる。設定方法については後述する。
����� � � ���� ∗ �����/���


モデル A

モデル B

モデル C

時間平均

TIME
時間平均

図 6 時間ステップとデータ交換の関係

時間積分ループ中でのデータ交換に関わるサブルーチンコールの様子を図 7 に示す。図で青の四角は時間積分ループの開始と終了，グレーの四角はモデル計算コードを表す。オレンジの四角が h3-Open-UTIL/MP の API ルーチンコールである。時間積分ループ中で連成計算に関わるルー
チンコールは h3ou_set_time, h3ou_put_data, h3ou_get_data の 3 種類のみである。h3ou_set_time は
モデル時刻をカプラに教えるためのルーチンで，時間積分ループの冒頭付近で呼ばれることが期
待されている。h3ou_put_data は相手モデルに送信するデータをカプラに与えるサブルーチン，
h3ou_get_data は相手モデルから受信したデータを取得するためのルーチンで，これらのサブルーチンは h3ou_set_time が呼ばれた後であればプログラムの任意の箇所でコールできる。データ送受信や補間計算が実際に行われるのはサブルーチン h3ou_set_time の内部である。モデル A からモデル B へデータが送受信される際のデータの流れを図 8 に示す。図中，青枠の四角は利用者がコールするルーチンを表す。緑枠とオレンジ枠はカプラ内部での動作である。緑とオレンジの２種類の枠の相違については次号で解説する。赤枠はカプラ内部で保持されるデータを表す。
h3ou_put_data でカプラに与えられたデータはカプラ内部のデータバッファに保持される。
- 8 スーパーコンピューティングニュース- 56 -

Vol. 24, No.32022

h3ou_set_time がコールされた時点で，当該データがその時刻の送受信対象データかどうかが判定され，送受信データであればバッファから取り出し(get_from_buffer)相手モデルのプロセス順に応じてデータを並び替える（rearrange_send_data）。送信と受信には MPI_Isend, MPI_Irecv が用いられる。モデル B で受信されたデータは再度並び替えられ(rearrange_recv_data)，補間計算サブ
ルーチン interpolate_data に渡される。補間計算で得られたデータはカプラのデータバッファに保持され(put_to_buffer)，API サブルーチン h3ou_get_data がコールされた時点でバッファから取り出され呼び出し側に渡される。

do t = 1, Nt
call h3ou_set_time(current_time, deltaT)

call h3ou_get_data(“data_B2A”, gdata, is_recv_ok)
if (is_recv_ok) thenmodel calculation using data_B2A
end ifmodel calculation

call h3ou_put_data(“data_A2B”, pdata, is_recv_ok)
end do

図 7 時間積分ループ中でのカプラ API コールの模式図- 9 スーパーコンピューティングニュース- 57 -

Vol. 24, No.3

2022

モデル Aモデル B

h3ou_put_data(data_name, dA)

buffered-dA
time loop end

time loop end

time loop start

time loop start

h3ou_set_time(timeA, deltaTA)

h3ou_set_time(timeB, deltaTB)

get_from_buffer(dA)do i = 1, npe_r
MPI_irecv(rA)rearrange_recv_data(rA, dA)
end dodo i = 1, npe_s
rearrange_send_data(dA, rA)
MPI_isend(rA)
end docall interpolate_data(dA, iA)

put_to_buffer(iA)buffered-iA

h3ou_get_data(data_name, data, is_recv_ok)

図 8 カプラ内部での送受信データの流れ（青枠は利用者コールルーチン，緑とオレンジ枠はカプラの内部動作を表す）

ここまで述べたのは h3-Open-UTIL/MP の基本的な機能であり，カプラとして特に新規性のあるものではない。しかしながら h3-Open-UTIL/MP は他のカプラにはない独自の機能を備えている。それらは，
1) アンサンブル連成機能
2) Python アプケーション連成機能
3) 異機種間連成機能である。これら独自機能については次号の記事で詳細を説明する予定である。以下の節では h3Open-UTIL/MP の基本的な使用方法について具体例に基づきながら説明してゆく。

5 h3-Open-UTIL/MP の使用方法
この節では具体的な事例に則り h3-Open-UTIL/MP の基本機能の使用方法について説明する。対象としているマシンは Wisteria/BDEC-01 の Odyssey である。サンプルコードおよび実行シェル
スクリプトは/work/share/h3-Open-UTIL-MP/src/sample/h3ou/test1（ディレクトリ名は変更になる可能性があります。確定版は次号記事でお知らせいたします）以下の src および run ディレ- 10 スーパーコンピューティングニュース- 58 -

Vol. 24, No.3

2022

クトリにあるので適宜参照されたい。このサンプルでは app1, app2, app3 の 3 つのアプリケー
ション（モデル）が相互にデータを交換しながら時間積分を進める構成になっている。状況を単純にするため，モデルの格子は同一で積分時間間隔やステップ数も同一としている。

5.1 設定ファイルの準備
h3-Open-UTIL/MP はカプラの動作と交換データの詳細情報を設定するために設定ファイルを用いる。テスト計算プログラムで用いられている設定ファイルを図 9 に示す。セクション
h3ou_coupling はカプラ全体の動作を規定するセクションで，今のところ設定可能なのはログフ
ァイルの出力レベルである。log_level は”SILENT”,”WISPER”,”LOUD”の３通りが設定可能であり SILENT はログを出力せず LOUD は詳細なログ情報を出力する。LOUD モードは大量のログを出力するためテストやデバッグ時に使用するモードである。debug_mode はログを標準エラー
出力に出力するかどうかのフラグである。セクション h3ou_var は２通りの記述形式が定められている。ひとつはデータ交換するモデル名と格子名のセットであり，comp_put, comp_get,
grid_put, grid_get のそれぞれに送信モデル名，受信モデル名，送信格子名，受信格子名を与える。この組み合わせに対して以下に記述される交換変数の設定が適用される。h3ou_var セクシ
ョンのもう一つの記述形式は交換データの設定に関するものである。var_put は送信側データ名，
var_get は受信側データ名である。grid_intpl_tag は補間計算時にデータを識別するためのタグ
で，特に必要ない場合は１を与える。なお，このこのタグを参照する事例については次号で解説する予定である。intvl はデータ交換間隔で単位は秒である。lag は連成計算が並列に行われる
か逐次的に行われるかを設定するフラグで，一般的な並列実行の場合は-1 を与える。layer は当
該データの鉛直層数である。後述する格子番号設定サブルーチンでも鉛直層数を与えるが，これは格子が取り得る最大の鉛直層数であり，データ毎にはこれを超えない任意の層数を設定可能である。flag はデータを時間平均するかどうかの設定で時間平均する場合は”AVR”を，瞬間値を交換する場合は”SNP”を設定する。

- 11 スーパーコンピューティングニュース- 59 -

Vol. 24, No.32022

# log_level : "SILENT" or "WHISPER" or "LOUD", default = "SILENT"# debug_mode : .true. or .false., default = .false.
&h3ou_coupling
log_level = "SILENT"
debug_mode = .false.
&end&h3ou_var comp_put = "app2", comp_get = "app1",
grid_put = "app2_grid", grid_get = "app1_grid", /&h3ou_var var_put = "app2_to_app1", var_get = "app2_to_app1", grid_intpl_tag = 1, intvl=720, lag=-1,
layer=40, flag='AVR' /&h3ou_var comp_put = "app1", comp_get = "app2",
grid_put = "app1_grid" , grid_get = "app2_grid", /&h3ou_var var_put = "app1_to_app2", var_get = "app1_to_app2", grid_intpl_tag = 1, intvl=720, lag=-1,
layer = 40, flag='AVR' /&h3ou_var comp_put = "app3", comp_get = "app1",
grid_put = "app3_grid" , grid_get = "app1_grid", /&h3ou_var var_put = "app3_to_app1", var_get = "app3_to_app1"
lag=-1, layer=40, flag='AVR' /&h3ou_var comp_put = "app1", comp_get = "app3",
grid_put = "app1_grid" , grid_get = "app3_grid", /&h3ou_var var_put = "app1_to_app3", var_get = "app1_to_app3"
lag=-1, layer = 40, flag='AVR' /&h3ou_var comp_put = "app3", comp_get = "app2",
grid_put = "app3_grid" , grid_get = "app2_grid", /&h3ou_var var_put = "app3_to_app2", var_get = "app3_to_app2"
lag=-1, layer=40, flag='AVR' /&h3ou_var comp_put = "app2", comp_get = "app3",
grid_put = "app2_grid" , grid_get = "app3_grid", /&h3ou_var var_put = "app2_to_app3", var_get = "app2_to_app3"
lag=-1, layer = 40, flag='AVR' /~, grid_intpl_tag = 1, intvl=720,, grid_intpl_tag = 1, intvl=720,, grid_intpl_tag = 1, intvl=720,, grid_intpl_tag = 1, intvl=720,

図 9 h3-Open-UTIL/MP の設定ファイル例

5.2 API ルーチンコールの概要
h3-Open-UTIL/MP の API を連成対象モデルに組み込む際の手続きは，1)カプラの初期化，2)格子の設定，3)補間テーブルの設定，4)初期時刻の設定，5)第０ステップデータの put，6)現在時
刻とΔT の設定，7)データの get, 8)データの put, 9)連成の終了，の９ステップに分けられる。
このうち 1)から 4)までが初期設定，6)7)8)が時間積分ループ内の手続きである。これらの手順を図 10 に示す。図では複数回呼び出し可能あるいは設定に従い複数回コールする必要のあるルーチンを水色で，一度だけコールされるルーチンをピンクで示している。なお時間積分ループ中のルーチンコールについては時間ステップ毎に 1 度だけコールするか複数回コール可能かで色分けされている。各ルーチンの引数などについては次節で説明される。初期化部分でコールしている h3ou_get_mpi_parameter は図 4 右図の緑の破線で表されているモデル毎のコミュニケータ
およびこのコミュニケータのグループやサイズ，プロセスのランク番号を取得するサブルーチン- 12 スーパーコンピューティングニュース- 60 -

Vol. 24, No.32022

である。連成対象プログラムが MPI 並列化されている場合，モデルがこれまで用いているコミュ
ニケータはこのルーチンから得られたコミュニケータに置き換える必要がある。

初期化

h3ou_init(comp_name, config_file)h3ou_get_mpi_marapeter(comp_name,local_comm, local_group, local_size, local_rank)

格子設定

h3ou_def_grid(grid_index,comp_name, grid_name, nz)
h3ou_end_grid_def()

補間
テーブル
設定

h3ou_set_interpolation_table(my_com_name,send_comp, send_grid, recv_comp, recv_grid,
mapping_tag, send_index, recv_index, coef)

初期時刻
設定

h3ou_init_time(itime)

データの
Put

h3ou_put_data(data_name, data)

時間積分ル�プ

現在時刻
設定

h3ou_set_time(comp_name, itime, delta_t)

データの
Get

h3ou_get_data(data_name, data, is_recv_ok)

データの
Put

h3ou_put_data(data_name, data)

連成の終了

h3ou_coupling_end(itime)
図 10 カプラ API ルーチンコールの概要

サンプルプログラムのメイン部分を図 11 に示す。9 行目のサブルーチン init_common 中で
h3ou_init と h3ou_get_mpi_parameter がコールされカプラの初期化と MPI 情報の取得を行っている。次いで 11 行目の cal_and_def_grid でプロセス毎の格子点番号を計算し h3ou_def_grid でカプラに渡した上で，h3ou_end_grid_def をコールしている。13 行目から 24 行目までが補間テーブルの設定に関わるルーチンコールである。ここでは app2→app1, app1→app2, app3→app1,
app1 → app3 の 順 序 で 補 間 テ ー ブ ル を 計 算 し 補 間 テ ー ブ ル の 設 定 ル ー チ ン
h3ou_set_interpolation_table をコールしている。26 行目で h3ou_init_time をコールした後，28 行，29 行めで第 0 ステップのデータをカプラに渡している。時間積分最初のステップの
h3ou_set_time で設定ファイルに記述されたすべてのデータが交換されるため，第 0 ステップの
h3ou_put_data は自モデルが送信すべきすべてのデータについてコールする必要がある。時間積
分ループ内の h3ou_get_data, h3ou_put_data はまとめて記述されているが，実際には必要に応- 13 スーパーコンピューティングニュース- 61 -

Vol. 24, No.3

2022

じ て プ ロ グ ラ ム の ど の 箇 所 か ら で も 順 不 同 に コ ー ル 可 能 で あ る 。 最 後 に 43 行 目 で
h3ou_coupling_end をコールし連成を終了している。
1 program app1
2
use mpi3
use common
4
implicit none
5
integer :: int_array(1)6integer :: ierror
7
integer :: i89call init_common(APP1_NAME, 1)
10
11call cal_and_def_grid()
12
13
call cal_and_set_map(APP1_NAME, &14
APP2_NAME, APP2_GRID, APP2_SIZE, &15
APP1_NAME,
APP1_GRID,
APP1_SIZE)
16
call cal_and_set_map(APP1_NAME, &17
APP1_NAME,
APP1_GRID,
APP1_SIZE, &18
APP2_NAME, APP2_GRID, APP2_SIZE)
19
call cal_and_set_map(APP1_NAME, &20
APP3_NAME, APP3_GRID, APP3_SIZE, &21
APP1_NAME,
APP1_GRID,
APP1_SIZE)
22
call cal_and_set_map(APP1_NAME, &23
APP1_NAME,
APP1_GRID,
APP1_SIZE, &24
APP3_NAME, APP3_GRID, APP3_SIZE)
25
26
call init_time(time_array)27
28
call put_data_2d("app1_to_app2", 1, i)
29call put_data_2d("app1_to_app3", 1, i)
30
31
do i = 1, APP1_STEP
32
call set_time(APP1_NAME, time_array, APP1_DELTA_T)
33
call get_data_2d("app2_to_app1")
34
call get_data_2d("app3_to_app1")
35
36
call sleep(1)3738
call put_data_2d("app1_to_app2", 1, i)
39call put_data_2d("app1_to_app3", 1, i)
40
41
end do42
43call finalize_common()44
45 end program app1
図 11 サンプルプログラムのメイン部分

6 h3-Open-UTIL/MP の API
この節では h3-Open-UTIL/MP の API について一般的な連成に用いられる主立ったものを説明する。

- 14 スーパーコンピューティングニュース- 62 -

Vol. 24, No.3

2022

6.1 初期設定 API
表 1 に初期設定に関わる h3-Open-UTIL/MP の API を示す。基本的な連成に用いられるのは
h3ou_init と h3ou_get_mpi_parameter の 2 つである。
表 1. 初期設定用 API

ルーチン名

概要

h3ou_init

カプラの初期化

h3ou_get_mpi_parameter

ローカルな MPI 情報を取得する

これらのルーチンの引数と意味は下のようになる。
(1) カプラ初期化 API
subroutine h3ou_init(comp_name, config_file_name, num_of_ensemble)
character(len=*), intent(IN) :: comp_name! モデルコンポーネント名
character(len=*), intent(IN) :: config_file_name ! 設定ファイル名
integer, intent(IN), optional :: num_of_ensemble ! アンサンブル数
 カプラの初期化プロセスを実行する。すべてのプロセスが必ず最初に呼ぶ必要がある。
カプラ内部でモデルコンポーネント名に従って MPI コミュニケータを生成する。
num_of_ensemble は optional 引数であり，次号で説明するアンサンブル結合の場合のみ意味を持つ。
(2) MPI 情報取得 API
subroutine h3ou_get_mpi_parameter(comp_name, comm, group, size, rank)
character(len=*), intent(IN) :: comp_name ! モデルコンポーネント名
integer, intent(OUT):: local_comm ! Local なコミュニケータ
integer, intent(OUT):: group! Local な MPI グループ
integer, intent(OUT):: size! local_comm に所属するプロセス数
integer, intent(OUT):: rank! local_comm 内のランク番号
 カプラ内部で生成された Local な MPI 情報を取得する。local_comm がモデル内部で使用されるコミュニケータである。group, size, rank はモデルローカルなグループ
ID, ローカルなプロセス数，ローカルな自プロセスのランク番号である。

6.2 格子設定 API
表 2 に格子設定用 API を示す。h3ou_def_grid は個々の格子の格子点番号を設定する。h3-OpenUTIL/MP はひとつのモデルコンポーネントに対して複数の格子が設定可能であり，h3ou_def_grid
も格子の数に対応して複数回呼び出し可能である。h3ou_end_grid_def は格子設定の終了をカプラに通知する。
表 2. 格子設定用 API

ルーチン名

概要

h3ou_def_grid

格子点番号の設定

h3ou_end_grid_def

格子点番号設定終了

これらのルーチンの引数と説明は下記の通りである。
(1) 格子設定 API
subroutine h3ou_def_grid(grid_index, comp_name, grid_name, num_of_layer)
integer, intent(IN):: grid_index(:)! 各プロセスの格子点番号
character(len=*), intent(IN) :: comp_name! モデルコンポーネント名- 15 スーパーコンピューティングニュース- 63 -

Vol. 24, No.3

2022

character(len=*), intent(IN) :: grid_name! 格子名
integer, intent(IN):: num_of_ensemble ! 鉛直格子数
 格子の格子点番号を設定する。このサブルーチンはデータ交換に関わる格子の数だけ複数回コールしなければならない。grid_index は各プロセスが担当する格子のグローバルな格子点番号である。番号は自然数でなければならない。格子点番号は連続している必要はなく番号に空きがあることは許される。ただし番号の重複は許されない。
カ プ ラ は 番 号 の 重 複 を チ ェ ッ ク し な い た め 注 意 が 必 要 で あ る 。 comp_name と
grid_name は格子が所属するモデル名と格子名である。nz は補間計算が水平 2 次元で行われる際に，3 次元データの鉛直格子の数を与える。この場合，格子点番号
grid_index は水平格子の分だけを与えれば良い。逆に 3 次元空間で補間計算が必要な場合は 3 次元分の大きさの grid_index を与え nz=1 とすればよい。
(2) 格子設定終了通知 API
subroutine h3ou_end_grid_def()

格子情報設定の終了をカプラに通知する。引数はなく h3ou_def_grid のコールの後に一度だけ呼び出す。このサブルーチンの内部で交換データの設定など複数の初期設定が実行される。

6.3 補間テーブル設定 API
表 3 に補間テーブル設定 API を示す。個々の引数については次に説明する。重要なのは，このサブルーチンがモデルコンポーネント間で各種情報の通信を行っているということである。そのため，送信側モデルと受信側モデルでルーチンコールが正しく対応している必要がある。呼び出しの順序を誤り対応関係が崩れると通信がデッドロックするなどの不具合が生じるため注意しなければならない。
表 3. 補間テーブル設定用 API

ルーチン名

概要

h3ou_set_interpolation_table

補間テーブルの設定

このルーチンの引数と説明は下記の通りである。
(1) 補間テーブル設定 API
subroutine h3ou_set_interpolation_table(my_name,send_comp, send_grid,recv_comp, recv_grid,
mapping_tag,
send_index, recv_index, coef)character(len=*), intent(IN):: my_name! 自モデル名character(len=*), intent(IN):: send_comp! 送信モデル名
character(len=*), intent(IN):: send_grid! 送信格子名
character(len=*), intent(IN):: recv_comp! 受信モデル名
character(len=*), intent(IN):: recv_grid! 受信格子名
integer, intent(IN):: mapping_tag ! 補間テーブル識別タグ
integer, optional, intent(IN):: send_index(:) ! 送信側格子点番号
integer, optional, intent(IN):: recv_index(:) ! 受信側格子点番号
real(kind=8), optional, intent(IN) :: coef(:)! 補間係数 補間テーブルを設定する。前述のようにこのサブルーチンは送信側と受信側で正しく- 16 スーパーコンピューティングニュース- 64 -

Vol. 24, No.3

2022

対応している必要がある。6 番目の引数 mapping_tag は同じモデルと格子の組み合わせで複数の補間テーブルを使い分ける際の識別子である。複数の補間テーブルを設定しない場合は 1 を与える。格子の格子点番号を設定する。send_index, recv_index,
coef が補間テーブルである。配列の大きさは 3 つの引数で同一でなければならない。
これら 3 引数は optional となっており，送信側か受信側のいずれかで与えれば良い。
また引数が意味を持つのはルート（0 番）プロセスのみであるためメモリを節約する
場合は 0 番以外は大きさ 1 の配列を与えるようにするとよい。

6.4 時刻設定 API
表 4 に時間設定 API を示す。h3ou_init_time は積分の初期時刻を設定する。このサブルーチ
ンは時間積分開始前に一度だけコールされる。h3ou_set_time は時間積分ループ中で毎ステップコールされる（しなければならない）。第 4 節で述べたように h3ou_set_time の中でデータ交換
や補間計算など連成に関わる多くの処理がなされる。
表 4. 時間設定 API

ルーチン名

概要

h3ou_init_time

初期時刻の設定

h3ou_set_time

現在時刻とΔT の設定

これらのルーチンの引数と説明は下記の通りである。
(1) 初期時刻設定 API
subroutine h3ou_init_time(time_array)
integer, intent(IN) :: time_array(6) ! 年月日時分秒の配列
 h3ou_init_time は積分初期時刻を設定する。引数 time_array は年月日時分秒を表す
大きさ 6 の整数配列である。このサブルーチンは時間積分開始前に 1 回だけコールされる。
(2) 現在時刻とΔT 設定 API
subroutine h3ou_set_time(comp_name, time_array, delta_t)character(len=*), intent(IN) :: comp_name! モデル名integer, intent(IN):: time_array(6) ! 現在時刻の配列
integer, intent(IN):: delta_t! ΔT h3ou_set_time は時間積分ループの中で現在時刻とΔT を設定する。comp_name は当該モデル名，time_array は現在時刻を表す年月日時分秒の配列，delta_t はそのステップのΔT である。カプラ内部では delta_t の積算時間（秒）でデータ交換判定などを行っている 1。従ってこのサブルーチンは基本的に（データ交換を行わないステップであっても）毎時間ステップコールしなければならない。

6.5 データ提供取得 API
表 5 にデータ提供取得 API を示す。これらのサブルーチンは時間積分ループ中で h3ou_set_time
1

カプラ内部での時間管理は delta_t の積算値（秒単位）が用いられており第２引数の年月日時分
秒配列はログ出力などでのみ参照されるようになっている。これはユリウス暦とグレゴリウス暦の違いなどカレンダ計算に関する面倒な問題を回避するためである。
- 17 スーパーコンピューティングニュース- 65 -

Vol. 24, No.3

2022

がコールされた後なら任意の箇所でコール可能である。また第一ステップで交換するデータをカプラに与えるため，時間積分ループ前に交換される全データについて h3ou_put_data をコールしておく必要がある。また時間平均データについては時間ステップ毎のΔT で比例配分しているた
め h3ou_put_data については毎ステップコールしなければならない。
表 5. データ提供取得 API

ルーチン名

概要

h3ou_init_time

初期時刻の設定

h3ou_set_time

現在時刻とΔT の設定

これらのルーチンの引数と説明は下記の通りである。
(1) データ提供 API
subroutine h3ou_put_data(data_name, data)character(len=*), intent(IN) :: data_name! 送信データ名
real(kind=8), intent(IN):: data(:) or data(:,:) ! 送信データ
 h3ou_put_data はカプラに対して送信データを与える。引数 data_name は送信データ名である。送信データはデータが鉛直層を持たない場合は一次元配列，鉛直層を持つ
場合は 2 次元配列を与える。なお一次元目の配列の大きさは h3ou_def_grid の引数
grid_index の大きさと同じでなければならない。
(2) データ取得 API
subroutine h3ou_get_data(data_name, data, is_recv_ok)
character(len=*), intent(IN) :: data_name! 受信データ名
real(kind=8), intent(INOUT) :: data(:) or data(:,:) ! 受信データ
logical, intent(OUT):: is_recv_ok! データ受信フラグ
 h3ou_get_data はカプラから受信データを取得する。送信用サブルーチンと同様，dataの配列は鉛直層の有無で 1 次元もしくは 2 次元となる。is_recv_ok は当該時間ステップがデータ交換のタイミングかどうかを返す。データ交換のタイミングでない場合
は is_recv_ok は.false.が返り data の値は不定となる。従って受信データを使う場
合は必ず is_recv_ok を参照し，真となるタイミングでのみ data の値を参照するようにしなければならない。

6.6 終了処理 API
表 6 に終了処理を示す。このサブルーチンは時間積分ループ終了後，プログラム終了前に一度だけコールされる必要がある。
表 6. 終了処理 API

ルーチン名

概要

h3ou_coupling_end

連成の終了

このルーチンの引数と説明は下記の通りである。
(3) 終了処理 API
subroutine h3ou_coupling_end(itime, is_call_finalize)
integer, intent(IN), optional :: itime(:)! 積分終了時刻
logical, intent(IN), optional :: is_call_finalize ! MPI 終了フラグ- 18 スーパーコンピューティングニュース- 66 -

Vol. 24, No.3

2022



h3ou_coupling_end はカプラに対して連成の終了を通知する。引数 itime は積分終了
時刻で年月日時分秒を表す大きさ６の整数配列である。is_call_finalize はこのサ
ブルーチン内で MPI の終了サブルーチン MPI_finalize を呼び出すかどうかのフラグ
である。

7

まとめ
本稿では Wisteria/BDEC-01 利用事例として汎用連成ソフトウェア h3-Open-UTIL/MP の基本機能について解説した。本稿の解説に従って h3-Open-UTIL/MP の API を組み込む事で基本的な連成機能は実現可能である。本文で述べたように h3-Open-UTIL/MP にはアンサンブル連成や Python
アプリケーション連成[14]，h3-Open-SYS/WaitIO[7]と協調した異機種間連成，など従来のカプラにはない機能が実装されている。これらについては次号で紹介する。

参考文献[1] 司馬遼太郎, 街道をゆく 24「近江散歩，奈良散歩」, 朝日文庫, 249-260[2] Manabe, S. and Bryan, K., 1969, Climate Calculations with a Combined Ocean-Atmosphere Model,
Journal of the Atmospheric Sciences 26, 786-789, https://doi.org/10.1175/15200469(1969)026%3C0786:CCWACO%3E2.0.CO;2[3] Stouffer, R. J., Manabe, S. and Bryan, K., 1989. Interhemispheric asymmetry in climate response to a
gradual increase of atmospheric CO2. Nature 342, 660–662.
[4] Tatebe, H., Ogura, T., Nitta, T., Komuro, Y., Ogochi, K., Takemura, T., Sudo, K., Sekiguchi, M., Abe,
M., Saito, F., Chikira, M., Watanabe, S., Mori, M., Hirota, N., Kawatani, Y., Mochizuki, T.,
Yoshimura, K., Takata, K., O'ishi, R., Yamazaki, D., Suzuki, T., Kurogi, M., Kataoka, T., Watanabe,M., and Kimoto, M.: Description and basic evaluation of simulated mean state, internal variability,
and climate sensitivity in MIROC6, Geosci. Model Dev., 12, 2727–2765,
https://doi.org/10.5194/gmd-12-2727-2019, 2019.
[5] Jones, P.W., 1999, First- and Second-Order Conservative Remapping Schemes for Grids in Spherical
Coordinates, Monthly Weather Review 127, 2204-2210.
[6] Matsumoto, M., Arakawa, T., Kitayama, T., Mori, F., Okuda, H., Furumura, T., Nakajima, K., 2015,
Multi-Scale Coupling Simulation of Seismic Waves and Building Vibrations using ppOpen-HPC,
Procedia Computer Science 51, 1514-1523, doi: 10.1016/j.procs.2015.05.341[7] 住元真司, 坂口吉生, 松葉浩也, 中島研吾, Wisteria/BDEC-01 利用事例(3) データ受け渡しラ
イブラリ h3-Open-SYS/WaitIO(1/2), スーパーコンピューティングニュース Vol.24 No.2,
https://www.cc.u-tokyo.ac.jp/public/VOL24/No2/10_202203Wisteria-1.pdf[8] h3-Open-BDEC：https://h3-open-bdec.cc.u-tokyo.ac.jp/[9] Iwashita, T, Nakajima, K., Shimokawabe, T., Nagao, H., Ogita, T., Katagiri, T., Yashiro, H., Matsuba,
H., h3-Open-BDEC: Innovative Software Platform for Scientific Computing in the Exascale Era byIntegrations of (Simulation + Data + Learning), Project Poster, ISC-HPC 2020[10] Wisteria/BDEC-01（「計算・データ・学習」融合スーパーコンピュータシステ
ム）:https://www.cc.utokyo.ac.jp/supercomputer/wisteria[11] 中島研吾, 塙敏博, 下川辺隆史, 伊田明弘, 芝隼人, 三木洋平, 星野哲也, 有間 英志, 河合直- 19 スーパーコンピューティングニュース- 67 -

Vol. 24, No.3

2022

聡, 坂本龍一, 岩下武史, 八代尚, 長尾大道, 松葉浩也, 荻田武史, 片桐孝洋，古村孝志, 鶴
岡弘, 市村強, 藤田航平，近藤正章，「計算・データ・学習」融合スーパーコンピュータシ
ステム「Wisteria/BDEC- 01」の概要，情報処理学会研究報告（2020-HPC-179-01），2021[12] 塙 敏博，中島 研吾，下川辺隆史, 芝隼人, 三木洋平, 星野哲也, 河合直聡，似鳥啓吾, 今村俊幸，工藤周平，中尾 昌広，「計算・データ・学習」融合スーパーコンピュータシステ
ム「Wisteria/BDEC- 01」の性能評価，情報処理学会研究報告（2021-HPC-180-22），2021[13] Arakawa, T., Inoue, T., Yashiro, H. et al. Coupling library Jcup3: its philosophy and application. Prog
Earth Planet Sci 7, 6 (2020). https://doi.org/10.1186/s40645-019-0320-z[14] Arakawa, T., Yashiro, H., Nakajima, K., Development of a coupler h3-Open-UTIL/MP, ACM
Proceedings of the International Conference on High Performance Computing in Asia-PacificRegion(HPC Asia 2022), 2022, https://doi.org/10.1145/3492805.3492809- 20 スーパーコンピューティングニュース- 68 -

Vol. 24, No.3

2022

Wisteria/BDEC-01（Odyssey）におけるOpenMP によるプログラミング入門（その 2）
中島研吾(a)，笠井良浩(b)，坂口吉生(b)(a)東京大学情報基盤センター，(b)富士通株式会社
本稿では，前号（その 1）に引き続き，Wisteria/BDEC-01（Odyssey）上での最適化について，説明する。プログラム類は Wisteria/BDEC-01 の /work/share/ompw/ompw.tar から取得できるので，興味ある方は試してみられると良い。

1. Odyssey での実行
（1）A64FX プロセッサ
Odyssey の計算ノードは，A64FX プロセッサであり，図 1 に示すように 48 個のコアから構成されている。12 コアが CMG（Core Memory Group）を構成しており，各 CMG に HBM2 による高速メモリ（8GiB）が搭載されている［1］。いわゆる NUMA アーキテクチャであるため，OpenMPによる並列化は各 CMG 単位で実施し，OpenMP/MPI ハイブリッド並列プログラミングでは，ノード当たり 4 つの MPI プロセスを立ち上げる，ことが推奨されているが，本稿では敢えて，1 ノード，48 コアに対して OpenMP 並列化を適用する。図 1 に示すように，メモリ，コアの番号は
各 CMG において，CMG#0（メモリ：#4，コア：#12-#23），CMG#1（メモリ：#5，コア：#24-#35），

CMG#2
36 37 38 39

16 17 18 19
20 21 22 23

24 25 26 27

リ
ン
グ
パ
ス

40 41 42 43
44 45 46 47

48 49 50 51

28 29 30 31

52 53 54 55

32 33 34 35

56 57 58 59

CMG#1

CMG#3

Memory #7

Memory #5

CMG#0
12 13 14 15

Memory #6

Memory #4

CMG#2（メモリ：#6，コア：#36-#47），CMG#3（メモリ：#7，コア：#48-#59）
プロセッサ名

A64FXプロセッサ数
1 (48+アシスタントコア2 or 4)(コア数)
2.2 GHz
周波数3.3792 TFLOPS
理論演算性能32 GiB
メモリ容量
1,024 GB/s
メモリ帯域幅
L1 Cache
64 KiB/core (Inst/Data)
L2 Cache
8 MiB/CMG

図 1 A64FX プロセッサの構成と諸元［1］（2）C コンパイラ
Odyssey では C コンパイラとして「trad モード」，「clang モード」の 2 種類がある（表 1 参照）。
デフォルトは trad モードである。使用する機能や性能によって使いわける必要があるが，本稿のケースの場合，問題規模が比較的小さい場合は「clang モード」の方が高速であったため，上記のサンプルプログラムでは基本的に「clang モード」を使用している。後述するように，最適化を施し，問題規模を大きくした場合には，同等，もしくは「trad モード」の方が高速である場合もある。

スーパーコンピューティングニュース- 1- - 69

Vol. 24, No.32022

表 1 C コンパイラ：2 種類のモード
trad モード（-Nnoclang オプション）（デフォルト）clang モード（-Nclang オプション）

 「京」および PRIMEHPC FX100 以前のシステム向け富士通コンパイラをベースとする。
 trad モードは，従来の富士通コンパイラとの互換を重視する場
合に適している。
 サポートしている仕様は，C89/C99/C11，OpenMP 3.1/OpenMP 4.5（一部）
 オプション省略時（デフォルト）は，-Nnoclang オプション適用
 オープンソースソフトウェアである Clang/LLVM コンパイラをベースとする。
 clang モードは，最新言語仕様を使用したプログラムや，オープ
ンソースソフトウェアを翻訳する場合に適している。
 サポートしている仕様は，C89/C99/C11， OpenMP 4.5/OpenMP
5.0（一部)（3）コンパイル・実行
まず，図 1 の CMG＃0 のみ 12 コアを使ったケースを実行してみよう。詳細は［2］をご覧いた
だくとして，ここでは簡単に概要について紹介する。
>$ cp /work/share/ompw/ompw.tar .
>$ tar xvf ompw.tar>$ cd ompw!（このディレクトリを以下<$O-ompw>と呼ぶ）>$ module load fj!（ログインしたら必ずこれをタイプする）>$ make -f makec!（Fortan であれば make -f makef）>$ cd run
“INPUT.DAT”, “c12.sh”, “f12.sh”を修正する>$ pjsub c12.sh!（Fortran であれば psub f12.sh）

図 2 ファイルのコピー，コンパイル，実行［2］C 言語の場合，make -f makc-org とすると（2）で述べた「trad」モードになる。コンパイ
ルオプションは，下記のようになっている。：



makec：-Kfast,openmp -Nclang -msve-vector-bits=512

makec-org：-Kfast,openmp-msve-vector-bits=512 は，SIMD 長を 512 に固定するオプションである。Fortran では
SIMD 長は 512 に固定されているが，clang では可変長 SIMD がデフォルトとなっている。SIMD
長を 512 に固定することによって，PCG 法の計算の大部分を占める行列ベクトル積部が高速化されたため，本オプションを採用することとしている。
図 3 は実行制御ファイル<$O-ompw>/run/INPUT.DAT の例である。ここではまず，メッシュ
数=2,097,152（=1283）の場合を実施する。
図 4 は ジ ョ ブ ス ク リ プ ト <$O-ompw>/run/c12.sh の 例 で あ る 。 Fortran 用 の <$Oompw>/run/f12.sh も solc0 が solf0 となっている以外は同様である。NUMA アーキテク
チャにおいて，できるだけローカルなメモリを使用して効率良く計算を実行するために［3］，スーパーコンピューティングニュース- -2 70- -Vol. 24, No.3

2022

numactl -l を使用する。また使用する CMG を指定するために-C でコア番号，-m でメモリ番号（図 1）を指定することもできるが，結果的に計算時間への影響はほとんどない［2］。環境変数 XOS_MMM_L_PAGING_POLICY については複数 CMG 対して OpenMP を適用する場合には「demand」を指定することが推奨されている。詳細は［2］を参照されたい。
128 128 128
1.00e-0 1.00e-00 1.00e-00
1.0e-08

NX NY NZ
!X,Y,Z 方向のメッシュ数
DX/DY/DZ!各メッシュの 3 辺の長さ
EPSICCG !収束判定値（10-8 を使用）

図 3 メッシュ数=1283 の場合の実行制御ファイル<$O-ompw>/run/INPUT.DAT の例［2］#!/bin/sh#PJM -N “c12”#PJM -L rscgrp=debug-o#PJM -L node=1#PJM --omp thread=12#PJM -L elapse=00:15:00#PJM -g gxYZ
#PJM -j#PJM -e err#PJM -o c12.lst!ジョブ名称（省略可）!実行キュー名（Resource Group）!ノード数（原則＝1）!スレッド数（1-48）!実行時間!グループ名（財布）!エラー出力ファイル!標準出力ファイル

module load fj
export OMP_NUM_THREADS=12!スレッド数（--omp thread=XX と同じ数）
export XOS_MMM_L_PAGING_POLICY=demand:demand:demand
numactl -l ./solc0
numactl –C 12-23 –m 4 ./solc0

図 4 12 コア・1-CMG を使用する場合のジョブスクリプト<$O-ompw>/run/c12.sh の例［2］また，solver_PCG.c のインタフェースが，［4］のコードと比べて若干変更となっている。図 5が変更を施した冒頭部で，配列 W へのアクセス効率向上のために，配列 W に対して連続領域を確保するように変更した。また係数行列に関連したポインタに restrict 型修飾子を適用することによって，最適化の促進を図っている。
#include <stdio.h>#include <stdlib.h>#include <string.h>#include <errno.h>#include <math.h>#include <omp.h>#include "solver_PCG.h"
extern int
solve_PCG(int N, int *restrict indexLU, int *restrict itemLU,
double *restrict D, double *restrict B, double *restrict X,
double *restrict AMAT, double EPS, int *restrict ITR, int *restrict IER){
double VAL, BNRM2, WVAL, SW, RHO, BETA, RHO1, C1, DNRM2, ALPHA, ERR;
double Stime, Etime;
int i, j, ic, ip, L, ip1, N3;
double (*restrict W)[N] = (double (*)[N])malloc(4*sizeof(double[N]));if(W == NULL) {fprintf(stderr, "Error: %s¥n", strerror(errno));return -1;}

図 5 solver_PCG.c の変更部分，係数行列に関連したポインタに restrict 型修飾子の適用と，
配列 W に対して連続領域の確保

スーパーコンピューティングニュース- 3- - 71

Vol. 24, No.3

2022

（4）実行例
表 2 は，図 3 に示す NX=NY=NZ=128 の場合にコア数（スレッド数）を 1 から 12 まで変化させた場合の PCG 法ソルバーの計算時間，並列化効率の値を示す。計算を 5 回実行して，最速時間を採用している（以下同様に測定している）。コア数（スレッド数）を増加させると，計算粒度（Granularity）の低下，メモリの実行性能が飽和するため，効率は低下するが，12 コア使用時に 75％程度の並列化効率が達成されている。
表 2 PCG 法ソルバーの計算時間（NX=NY=NZ=128）（1～12 コア）（Fortran）
Thread #sec

Speed-up

Parallel Efficiency (%)

1

50.27

1.00

100.00

2

25.24

1.99

99.60

4

12.98

3.87

96.86

6

9.24

5.44

90.73

8

7.27

6.92

86.50

12

5.27

9.54

79.49

表 3 PCG 法ソルバーの計算時間（NX=NY=NZ=128）（12~48 コア）（Fortran）
Thread #sec

Speed-up

Parallel Efficiency (%)

12

5.27

12.00

100.00

24

2.78

22.72

94.68

36

1.95

32.49

90.24

48

1.60

39.54

82.38

表 3 は CMG の数を増やして，最大 48 コアまで使用した場合である。12 コア（1-CMG）の場
合の計算性能を 12.0 としてある。48 コア使用時の並列化効率は，12 コアの場合を基準とすると80%程度となっている。スレッド数を変化させるためには，図 4 のジョブスクリプトの中の「#PJM--omp thread=XY」の「XY」の値を変化させれば良いが，<$O-ompw>/run/には，各スレッド数に対して，cXY.sh，fXY.sh（XY=01,02,04,06,08,12,24,36,48）が用意されている。

2. 複数 CMG での性能向上：First Touch Data Placement
表 3 に示すように，48 コア，すなわち 4-CMG を使用した場合の並列化効率は 12 コア，1-CMGの場合を基準とすると 80％程度である。これは決して悪い数字とは言えないが，更なる高速化を試みよう。
NUMA アーキテクチャでは，プログラムにおいて変数や配列を宣言した時点では，物理的メ
モリ上に記憶領域は確保されず，ある変数を最初にアクセスしたコア（の属する CMG）のロー
カルメモリ上に，その変数の記憶領域（ページ）が確保される［3］。
これを First Touch Data Placement（First Touch）［3］と呼び，配列の初期化手順により得られる性能が大幅に変化する場合があるため，注意が必要である。例えばある配列を初期化する
場合，特に指定しなければ 0 番の CMG で初期化が行われるため，記憶領域は 0 番 CMG のロー
カルメモリ上に確保される。したがって，他の CMG でこの配列のデータをアクセスする場合には，必ず 0 番 CMG のメモリにアクセスする必要があるため，高い性能を得ることは困難である。
配列の初期化を，実際の計算の手順にしたがって OpenMP を使って並列に実施すれば，実際にスーパーコンピューティングニュース- -4 72- -Vol. 24, No.32022

計算を担当する CMG のメモリにその配列の担当部分の記憶領域が確保され，より効率的に計算を実施することができる。1-CMG しか使用しない場合はこのような配慮は不要であり，例えばOpenMP/MPI ハイブリッドで 1-CMG 当りに 1 つの MPI プロセスを使用する場合も同様である。
1. で 使 用 し た プ ロ グ ラ ム 類 は 「 <$O-ompw>/src-c0 （ 実 行 形 式 は solc0 ）」，「 <$Oompw>/src-f0（同 solf0）」であるが，ここで述べた「First Touch」を適用したプログラム類
は，「<$O-ompw>/src-c1（同 solc1）」，「<$O-ompw>/src-f1（同 solf1）」にある。プログ
ラムの変更箇所は，係数行列を生成する poi_gen.c，poi_gen.f である。変更は配列の初期化の部分のみである。
図 6，図 7 に src-c0，src-f0 との相違点を示す。src-c1，src-f1 では配列初期化部分が計算実行時と同様に OpenMP によって並列化されている部分のみが異なっている。表 4 に First
Touch 適用の効果を示す。48 コアで約 10％の性能改善が得られている。実行にあたっては，<$Oompw>/run/に，c1_XY.sh，f1_XY.sh（XY=12,24,36,48）が用意されているので，それらを適宜編集して使用すると良い。
表 4 PCG 法ソルバー計算時間（NX=NY=NZ=128）（12~48 コア）（Fortran），First Touch の効果
Thread #sec

Speed-up

Parallel Efficiency (%)

12

5.27

12.00

100.00

24

2.78

22.72

94.68

36

1.95

32.49

90.24

48

1.60

39.54

82.38

12

5.26

12.00

100.00

24

2.70

23.39

97.45

36

1.86

33.83

93.96

48

1.44

43.77

91.18

src-f0src-f1

スーパーコンピューティングニュース- 5- - 73

Vol. 24, No.3

2022

[XYZ@wisteria01 run]$ cd ../src-c0[XYZ@wisteria01 src-f0]$ diff poi_gen.c ../src-c1/poi_gen.c
25,29c25,31
for (i = 0; i <ICELTOT ; i++) {BFORCE[i]=0.0;
D[i] =0.0;
PHI[i]=0.0;
INLU[i] = 0;}

src-c0--#pragma omp parallel for private (i)for (i = 0; i <ICELTOT ; i++) {BFORCE[i]=0.0;
D[i] =0.0;
PHI[i]=0.0;
INLU[i] = 0;}

src-c1OMP-1

88

for (i = 0; i <=ICELTOT ; i++) {indexLU[i] = 0;}

src-c0--#pragma omp parallel for private (i)for (i = 0; i <=ICELTOT ; i++) {indexLU[i] = 0;}

src-c1for(i=0; i<ICELTOT; i++) {for(j=indexLU[i]; j<indexLU[i+1]; j++) {itemLU[j]=0;
AMAT[j]=0.0;}}

src-c0--#pragma omp parallel for private (i,j)
for(i=0; i<ICELTOT; i++) {for(j=indexLU[i]; j<indexLU[i+1]; j++) {itemLU[j]=0;
AMAT[j]=0.0;}}

src-c1

図 6 First Touch を適用するためのプログラム変更（<$O-ompw>/src-c0/poi_gen.c, <$Oompw>/src-c1/poi_gen.c）

スーパーコンピューティングニュース- -6 74- -Vol. 24, No.3

2022

[XYZ@wisteria01 run]$ cd ../src-f0[XYZ@wisteria01 src-f0]$ diff poi_gen.f ../src-f1/poi_gen.f
25,29c25,31
<
<
<
<
<
---

PHI
= 0.d0
BFORCE= 0.d0
D
= 0.d0src-f0INLU= 0> !$omp parallel do private (icel)>
do icel= 1, ICELTOT>
PHI(icel)= 0.d0>
BFORCE(icel)= 0.d0>
D(icel)= 0.d0>
INLU (icel)= 0>
enddo

src-f1

OMP-1

88

71,72c73,75
<
<
<
<
<
---

indexLU= 0

src-f0do icel= 1, ICELTOT
indexLU(icel)= INLU(icel)
enddo>
indexLU(0)= 0>> !$omp parallel do private (icel)>
do icel= 1, ICELTOT>
indexLU(icel)= INLU(icel)>
enddo

src-f185,86c88,94
src-f0<<---itemLU= 0
AMAT= 0.d0

> !$omp parallel do private (icel,k)>do icel= 1, ICELTOT>
do k= indexLU(icel-1)+1, indexLU(icel)>
itemLU(k)= 0>
AMAT (k)= 0.d0
>
enddo
>
enddo

src-f1

図 7 First Touch を適用するためのプログラム変更（<$O-ompw>/src-f0/poi_gen.f, <$Oompw>/src-f1/poi_gen.f）

スーパーコンピューティングニュース- 7- - 75

Vol. 24, No.32022

3. 疎行列格納形式の効果
図 8 は，CG 法で疎行列ベクトル積 A p= q の計算を実行している部分で，<$O-ompw>/srcc0,src-c1 及び<$O-ompw>/src-f0,src-f1 では，前号記事でも述べたようにこのように
CRS（Compressed Row Storage）形式［5］と呼ばれる疎行列格納形式を採用している：（a）

CRS（Compressed Row Storage）
for(i=0; i<N; i++) {VAL = D[i] * W[P][i];for(j=indexLU[i]; j<indexLU[i+1]; j++) {VAL += AMAT[j] * W[P][itemLU[j]];}W[Q][i] = VAL;}（b）

CRS（Compressed Row Storage）
do i= 1, N
W(i,Q)= D(i)*W(i,P)
do k= indexLU(i-1)+1, indexLU(i)W(i,Q)= W(i,Q) + AMAT(k)*W(itemLU(k),P)
enddo
enddo

図 8 CRS 形式（Compressed Row Storage）［5］による疎行列格納方法，疎行列ベクトル積実装，（a）C 言語（<$O-ompw>/src-c0,src-c1）（b）Fortran（<$O-ompw>/src-f0,src-f1）
疎行列ベクトル積の特徴は，右辺に現れる W[P][itemLU[j]]，W(itemLU(k),P)が間接参照を含むため，memory-bound なプロセスとなっていることである。CRS 形式はメモリ，計算量の削減には効果的であるが，メモリアクセス効率は必ずしも良くない。Ellpack-Itpack（ELL）形
式［5］は各行における非零非対角成分数は最大非零非対角成分数に固定する方法で（図 9），実際に非零非対角成分が存在しない部分は係数=0 として計算する。計算量，必要記憶容量ともに
CRS 形式と比較してやや増加するが，高いメモリアクセス効率が得られるため，計算時間としては大幅に短縮できる場合がある［6］。非ゼロ非対角成分が存在しない列に対しては，ダミーの列
番号を参照し，係数行列は 0 として扱う（図 9）。

1
1

4

0
1

3 0 0 0
2 5 0 0
1 3 0 0

3 7 4 0
0 0 0 5

1

3

0

5

1

2

5

1

3

4

1

3

3

7

4

3

7

4

1

5

1

5

0

1

3

1

2

4

(a) CRS(b) ELL

図 9 疎行列の格納形式（a）CRS（Compressed Row Storage），（b）ELL（Ellpack-Itpack）［5］
本稿で扱うアプリケーションは，疎行列の非ゼロ非対角成分の数が最大 6 であるため，ELL 形式を容易に適用することができる。非ゼロ非対角成分数が行によって大幅に変動する場合は，よりフレキシブルな Sliced-ELL 形式［7］が使用される場合もある［6］。
図 10 は，図 8 に示す疎行列ベクトル積を ELL 形式で記述したものである。C 言語の場合は，
図 11 に示すような実装が考えられるが，A64FX では非常に計算速度が遅いため，図 10（a）のスーパーコンピューティングニュース- -8 76- -Vol. 24, No.32022

ような実装を採用している。Intel Xeon プロセッサでは，図 10（a）と図 11 の実装は同じ効率が得られる。ダミー列番号の設定方法等の実装の詳細については，プログラム本体（<$Oompw>/src-c2（実行形式は solc2）, <$O-ompw>/src-c2（同 solf2））及び講習会資料［2］を参照されたい。
（a）

ELL (ELLPACK/ITPACK)（b）

ELL (ELLPACK/ITPACK)

for(i=0; i<N; i++) {VAL = D[i] * W[P][i];for(j=0; j<6; j++) {VAL += AMAT[6*i+j] * W[P][itemLU[6*i+j]];}
W[Q][i] = VAL;}

do i= 1, N
W(i,Q)= D(i)*W(i,P)
do j= 1, 6W(i,Q)= W(i,Q) + AMAT(j,i)*W(itemLU(j,i),P)
enddo
enddo

図 10 ELL 形式（Ellpack-Itpack）［5］による疎行列格納方法，疎行列ベクトル積実装，（a）C 言語（<$O-ompw>/src-c2）（b）Fortran（<$O-ompw>/src-f2）

ELL (ELLPACK/ITPACK)
for(i=0; i<N; i++) {VAL = D[i] * W[P][i];for(j=0; j<6; j++) {VAL += AMAT[i][j] * W[P][itemLU[i][j]];}W[Q][i] = VAL;}
図 11 ELL 形式（Ellpack-Itpack）［5］による疎行列格納方法，疎行列ベクトル積実装，図 8（a）の拡張としては自然な実装であるが，本稿ではこの方法は採用していない

4. ループオーバーヘッド削減の効果
OpenMP の実行モデルは，fork-join モデル［8］と呼ばれるもので，通常はマスタースレッドによるシリアル実行であるが，OpenMP 指示文（directive）によりマルチスレッドが生成し，並列実行を実施するものである。
MasterMasterthreadthreadthreadthreadthreadMasterthreadMasterMaster

PARALLEL
fork

図 12

スーパーコンピューティングニュース

threadthreadthreadthreadthreadthreadthreadthreadEND PARALLEL
join

PARALLEL
fork

END PARALLEL
join

OpenMP の実行モデル：fork-join モデル［8］- 9- - 77

Vol. 24, No.32022

共役勾配法の各ステートメントのほとんどは各ベクトルに対するループであり，これまで紹介したプログラムでは，各ループに OpenMP 指示文を挿入している。図 13 は CG 法の後半部分の実装例（CRS 形式）であり，各ループに「#pragma omp parallel for」，「!$omp paralleldo」が挿入されている。「#pragma omp parallel」，「!$omp parallel」により，図 12 に示すような fork-join が各ステートメントごとに生じるため，これがオーバーヘッドとなる可能性がある。本章で紹介する新たな実装（<$O-ompw>/src-c3（実行形式は solc3）, <$Oompw>/src-c3（同 solc3））は ELL 法による実装（<$O-ompw>/src-c2, <$O-ompw>/srcc2）に対して，「#pragma omp parallel」，「!$omp parallel」の呼び出しを各反復で一回とし，各ループに対しては「#pragma omp for」，「!$omp do」を適用するものである（図 14）。
（a）#pragma omp parallel for private (i,VAL,j)for(i=0; i<N; i++) {VAL = D[i] * W[P][i];for(j=indexLU[i]; j<indexLU[i+1]; j++) {VAL += AMAT[j] * W[P][itemLU[j]];}W[Q][i] = VAL;}
C1 = 0.0;#pragma omp parallel for private (i) reduction(+:C1)
for(i=0; i<N; i++) {C1 += W[P][i] * W[Q][i];}ALPHA = RHO / C1;#pragma omp parallel for private (i)for(i=0; i<N; i++) {X[i]+= ALPHA * W[P][i];W[R][i] -= ALPHA * W[Q][i];}DNRM2 = 0.0;
#pragma omp parallel for private (i) reduction(+:DNRM2)
for(i=0; i<N; i++) {DNRM2 += W[R][i]*W[R][i];}ERR = sqrt(DNRM2/BNRM2);
...

（b）

!$omp parallel do private(i,VAL,k)do i= 1, N
VAL= D(i)*W(i,P)
do k= indexLU(i-1)+1, indexLU(i)VAL= VAL + AMAT(k)*W(itemLU(k),P)
enddo
W(i,Q)= VAL
enddo
C1= 0.d0!$omp parallel do private(i) reduction(+:C1)
do i= 1, N
C1= C1 + W(i,P)*W(i,Q)
enddo
ALPHA= RHO / C1!$omp parallel do private(i)do i= 1, N
X(i) = X(i) + ALPHA * W(i,P)
W(i,R)= W(i,R) - ALPHA * W(i,Q)
enddo
DNRM2= 0.d0!$omp parallel do private(i) reduction(+:DNRM2)
do i= 1, N
DNRM2= DNRM2 + W(i,R)**2
enddo

Compute r(0)= b-[A]x(0)for i= 1, 2, …
solve [M]z(i-1)= r(i-1)
ri-1= r(i-1) z(i-1)
if i=1p(1)= z(0)elsebi-1= ri-1/ri-2p(i)= z(i-1) + bi-1 p(i-1)
endif
(i)
q = [A]p(i)ai = ri-1/p(i)q(i)x(i)= x(i-1) + aip(i)r(i)= r(i-1) - aiq(i)check convergence |r|end

ERR = dsqrt(DNRM2/BNRM2)...

図 13 CG 法の後半部分の実装（CRS 形式）（a）C 言語（<$O-ompw>/src-c0,src-c1），（b）
Fortran（<$O-ompw>/src-f0,src-f1）

5. 計算結果（First-Touch，行列格納形式，ループオーバーヘッド削減の効果）
3.，4.に示した各実装例については，c2_48.sh，c3_48.sh，f2_48.sh，f3_48.sh を使用して実行することができる。これらは，全て 48 コアを使用した場合であるが，ジョブスクリプ
ト内でコア数を変更して実行することも可能である。表 5 に 48 コアを使用した場合の PCG 法の計算時間を示す。First-Touch の効果は C 言語でより大きい。ループオーバーヘッド削減の効果は
Frotran では 5％程度，C 言語（clang）ではむしろ遅くなっているが，C 言語（trad）では大きな効果が認められ，sol-c3 のレベルでは clang と trad の差はほとんど無くなっている。
表 5 PCG 法ソルバーの計算時間（sec.）（NX=NY=NZ=128）（48 コア）
FortranC（clang）

C（trad）

初期設定（sol-c0, sol-f0）

1.671

1.564

2.354

＋First-Touch（sol-c1, sol-f1）

1.480

1.122

1.720

＋ELL（sol-c2, sol-f2）

0.747

0.809

1.127

＋omp-parallel 削減（sol-c3, sol-f3）

0.707

0.834

0.854

スーパーコンピューティングニュース- 10- 78- -

Vol. 24, No.3

2022

（a）

（b）

ITR= N
Stime= omp_get_wtime()*ITR = N;
Stime = omp_get_wtime();do L= 1, ITR!$omp parallel private(i,k,VAL)

for(L=0; L<(*ITR); L++) {#pragma omp parallel private (i,j,VAL){!$omp dodo i= 1, N
W(i,Z)= W(i,R)*W(i,DD)
enddo#pragma omp for
for(i=0; i<N; i++) {W[Z][i] = W[R][i]*W[DD][i];}RHO= 0.d0!$omp do reduction(+:RHO)
do i= 1, N
RHO= RHO + W(i,R)*W(i,Z)
enddo

RHO = 0.0;
#pragma omp for reduction(+:RHO)
for(i=0; i<N; i++) {RHO += W[R][i] * W[Z][i];}if ( L.eq.1 ) then!$omp dodo i= 1, N
W(i,P)= W(i,Z)
enddo
else
BETA= RHO / RHO1!$omp dodo i= 1, N
W(i,P)= W(i,Z) + BETA*W(i,P)
enddo
endif

if(L == 0) {#pragma omp for
for(i=0; i<N; i++) {W[P][i] = W[Z][i];}} else {BETA = RHO / RHO1;#pragma omp for
for(i=0; i<N; i++) {W[P][i] = W[Z][i] + BETA * W[P][i];}}!$omp dodo i= 1, N
VAL= D(i)*W(i,P)
do k= indexLU(i-1)+1, indexLU(i)VAL= VAL + AMAT(k)*W(itemLU(k),P)
enddo
W(i,Q)= VAL
enddo#pragma omp for
for(i=0; i<N; i++) {VAL = D[i] * W[P][i];for(j=0; j<6; j++) {VAL += AMAT[6*i+j] *W[P][itemLU[6*i+j]];}
W[Q][i] = VAL;}

C1= 0.d0!$omp do reduction(+:C1)
do i= 1, N
C1= C1 + W(i,P)*W(i,Q)
enddo

C1 = 0.0;#pragma omp for reduction(+:C1)
for(i=0; i<N; i++) {C1 += W[P][i] * W[Q][i];}ALPHA = RHO / C1;

ALPHA= RHO / C1!$omp dodo i= 1, N
X(i) = X(i) + ALPHA * W(i,P)
W(i,R)= W(i,R) - ALPHA * W(i,Q)
enddo#pragma omp for
for(i=0; i<N; i++) {X[i]+= ALPHA * W[P][i];W[R][i] -= ALPHA * W[Q][i];}DNRM2= 0.d0!$omp do reduction(+:DNRM2)
do i= 1, N
DNRM2= DNRM2 + W(i,R)**2
enddo

DNRM2 = 0.0;
#pragma omp for reduction(+:DNRM2)
for(i=0; i<N; i++) {DNRM2 += W[R][i]*W[R][i];}!$omp end parallel
ERR = dsqrt(DNRM2/BNRM2)...

}
ERR = sqrt(DNRM2/BNRM2);

図 14 ループオーバーヘッドを削減した実装例（a）C 言語（<$O-ompw>/src-c3），（b）Fortran（<$O-ompw>/src-f3）
今回は，Odyssey 上での実行方法，First Touch Data Placement（First Touch）・疎行列格納形式・ループオーバーヘッド削減の効果について述べた。次回（恐らく最終回）は更なる最適化，詳細プ
ロフィラによる性能測定法について紹介する。
（第 3 回（7 月号）へ続く）

スーパーコンピューティングニュース- -7911- -Vol. 24, No.3

2022

参

考

文

献

[1] Wisteria/BDEC-01（「計算・データ・学習」融合スーパーコンピュータシステ
ム）:https://www.cc.utokyo.ac.jp/supercomputer/wisteria[2] OpenMP によるマルチコア・メニィコア並列プログラミング入門（Wisteria/BDEC-01（Odyssey，
A64FX 搭載），http://nkl.cc.u-tokyo.ac.jp/seminars/multicore2021/[3] Mattson, T.G., Sanders, B.A., Massingill, B.L., Patterns for Parallel Programming, Software Patterns
Series (SPS), Addison-Wesley, 2005
[4] P3D 関連資料
 ソースコード等： http://nkl.cc.u-tokyo.ac.jp/files/fvm.tar
 解説資料（Fortran）：http://nkl.cc.u-tokyo.ac.jp/seminars/multicore2021/omp-f-01.pdf
 解説資料（C）：

http://nkl.cc.u-tokyo.ac.jp/seminars/multicore2021/omp-c-01.pdf[5] Saad, Y.: Iterative Methods for Sparse Linear Systems Second Edition, SIAM, 2003
[6] Nakajima, K., Optimization of Serial and Parallel Communications for Parallel Geometric Multigrid
Method, Proceedings of the 20th IEEE International Conference for Parallel and Distributed Systems(ICPADS 2014) 25-32, Hsin-Chu, Taiwan, 2014[7] Monakov, A., Lokhmotov, A., Avetisyan, A., Automatically tuning sparse matrix-vector multiplication
for GPU architectures, Lecture Notes in Computer Science 5952, 112-125, 2010[8] OpenMP ARB（Architecture Review Board）：https://www.openmp.org/

スーパーコンピューティングニュース- 12- 80- -

Vol. 24, No.3

2022

分子動力学計算によるアミロイド凝集様態の理論的解析
大 滝 大 樹長崎大学 生命医科学域（医学系） 分子標的医学研究センター

１．はじめに アルツハイマー病・パーキンソン病（3'）・プリオン病など，神経変性疾患の患者の神経細胞にはアミロイドの異常蓄積が見られる。アミロイドがβシート構造を多く有することは知られているが，その構造不均一性などから通常のタンパク質に用いられる構造決定手法の多くが適用できず，詳細な立体構造の決定は極めて難しい。そのためアミロイドの詳細な分子構造情報は少な
く，変異により凝集性が大きく変化する原因など，アミロイドの分子構造と凝集性との関係は不明な点が多い。
このような中，近年の実験技術の進歩によりアミロイドの三次構造が報告されるようになった。
最近では 3' と関わりがあるとされる αシヌクレイン（α6\Q）のアミロイドの構造が次々に報告されている。α6\Q はパーキンソン病，レビー小体型認知症，多系統萎縮症の特徴となるレビ
ー小体の主要な構成タンパク質である。α6\Q は正常型では細胞質内において特定の構造を持たない状態とαヘリックスが豊富な構造とで平衡状態で存在していると考えられている>@。また，

LQYLWUR ではαヘリックス構造が豊富な四量体で存在するという報告もある>@。一方，レビー
小体中に異常蓄積している α6\Q はアミロイド構造をとり，株多様性などプリオン様の性質を示すことが知られている。プリオン病の原因となるプリオンタンパク質の構造についてはクライオ
電子顕微鏡で  年に初めてアミロイドの構造が報告された>@ものの，未だに分かっていない部分が多い。
アミロイドは一般的に疎水性相互作用を豊富に持つことが知られている。そこで本研究ではア
ミロイドの疎水性領域に着目し，①固体 105 により提案された αSyn アミロイド構造を用いた分子動力学（0'）シミュレーションを行い，②これまでの研究および①で得られた知見に基づきプ
リオンタンパク質の部分アミロイドのモデルを作成し 0' シミュレーションを行った。疎水性残基への変異を導入した変異型についても計算を行い，疎水性相互作用がアミロイドの構造安定性に及ぼす影響を調べた。


２．計算方法
２．１．α6\Q の 0' シミュレーション
α6\Q アミロイドの計算の初期構造には固体
105 により得られた構造（3'%1$）>@を用いた。構造が不安定な  残基を取り除

図：α6\Q アミロイド
3'%：1$ の第  残基部分の構造。$- の 
本の鎖が積層している。


本研究を開始したのはクライオ電子顕微鏡による構造が報告されるより前である。報告された構造と本研究で作成したモデルアミロイドの間には細かい部分で違いは見られるが，モデル作成時に仮定した SDUDOOHOLQUHJLVWHUβシート構造が実験でも観測されるなど，共通点も見られる。


スーパーコンピューティングニュース
- 81-

Vol. 24, No.3

2022

き，1 末端と & 末端をそれぞれアセチル化，1メチルアミド化することでキャップした。図に計算に用いたα6\Q アミロイドの構造を示す。
変異型のモデルは 6&:5/>@により作成した。周囲に水分子，1D イオン，&O イオンを配置
し，P0 の 1D&O 水溶液を模した系を作成した。
0' 計算は *520$&6>@を用いて 5HHGEXVK8+ 上で行った。力場は，タンパク質には $0%(5II6%,/'1>@，水分子には 7,33>@を用いた。温度は 9HORFLW\UHVFDOLQJ 法>@により . に制御し，圧力は %HUHQGVHQ 法>@により EDU に制御した。0' 計算の時間刻みは IV とした。最小化計算および平衡化計算ののち，QV のプロダクション計算を行った。各変異型について独立した 0' シミュレーションを  回（野生型は  回）ずつ行った。


２．２．プリオンのモデルアミロイドの 0' シミュレーション
プリオンのアミノ酸配列から疎水性残基が豊富な部分配列（第  残基）を取り出し，疎水性相互作用を豊富に持つ（疎水性コア）モデルアミロイドを作成した。まず，α6\Q の結果から得られた知見などに基づき 6ZLVV 3'% 9LHZHU>@を用いて一層分のコンフォメーションを作成した。これを 8&6)&KLPHUD>@を用いて  層分積層した後，0RGHOOHU>@を用いてアミロイ
ド構造の UHILQHPHQW を行った。変異型モデルは 6&:5/>@により作成した。得られたモデルア
ミロイドのタンパク質の 1 末端と & 末端をそれぞれアセチル化，1メチルアミド化することでキャップした。
0' 計算は，最小化計算および平衡化計算の後 QV のプロダクション計算を行った。各変異型について独立した 0' シミュレーションを  回ずつ行った。その他の条件はα6\Q と同様である。２．３．解析
それぞれの 0' 計算で SV ごとにスナップショットを取得し，α6\Q は QV，プリオンのモデルアミロイドは  QV のトラジェクトリを用いて解析を行った。二次構造解析には'663>@を用いて，βシート化傾向を評価した。疎水性相互作用解析には 3\,QWHUDSK>@を用いた。疎水性アミノ酸残基の側鎖の重心間距離が Å 以内だった場合に疎水性相互作用をカウントし>@，0' 計算のトラジェクトリ中に占める割合をスコアとして比較した。分子の図は 8&6)

図：α6\Q における 0' 計算の結果
$ βシート化傾向。 % *0 および */ 変異型の最後のスナップショットと第  残基近傍の 8 字ループ構
造における疎水性残基の側鎖の配向。

スーパーコンピューティングニュース
- 82 -

Vol. 24, No.32022

図：α6\Q における疎水性相互作用
各点（ノード）がアミノ酸残基を表し，疎水性相互作用がある残基間を線で結んでいる。線が太いほど疎水性相互作用が強い。

&KLPHUD>@，疎水性相互作用のダイアグラムは &\WRVFDSH>@を用いて作成した。


３．結果
３．１．α6\Q
本研究ではα6\Q アミロイドの 8 字ループ構造（第  残基）に注目した。このような 8 字型の構造は α6\Q 以外のアミロイドにも多く見られるため，本研究により得られた知見が他のアミロイドにも適用できる可能性がある。そこで，第  残基の *O\ を疎水性残基（,OH，0HW，/HXなど）に変更したモデルを作成し 0' 計算を行った。
図 $ に野生型（:7），*,，*9，*/，*0 変異型の計算から得られたβシート化傾向を示す。第  残基近辺を見ると *0 変異体のβシート化傾向が特に大きく，構造が安定化していることが分かる。一方で *, はβシート化傾向が小さく 8 字ループ構造が不安定化していることが分かる。0' 計算終了時における *0，*/ 変異型の 8 字ループ部分のスナップショットを
図% に示す。これを見ても，*0 では 0 が $ や 9 と相互作用して 8 字ループ構造が安定化していることが分かる。
図 には *,，*9，*/，*0 変異型の疎水性相互作用ダイアグラムを示す。どの変異型も第  残基と 9・$ との疎水性相互作用が見られるが，*0 変異型が一番強く，かつ再現
性良く疎水性相互作用を形成していることが分かる。この理由は 0HW の側鎖が他の疎水性残基に比べて長く，周辺の疎水性残基と相互作用しやすいためと考えられる。僅かな長さの差が部分構造の安定性に大きく影響することが示唆される。


スーパーコンピューティングニュース
- 83-

Vol. 24, No.32022

図：プリオンのモデルアミロイド
$ 作成したモデルアミロイドの構造。変異を導入したアミノ酸残基には下線を付している。 %  ( は 0' シミュレーション終了時のスナップショット。 % :7， & 09，' *9， ( $9。

３．２．プリオンのモデルアミロイド
本研究で作成したモデルアミロイドの構造を図$ に示す。変異はこれまでの実験研究などの報告に基づき，*9，09，,0，$9 を考えた。
図%( に QV の 0' 計算における最後のスナップショットを示す。野生型（:7）に比べて，09 変異型は全体的にアミロイド構造を保っているが（図 &），*9 変異型ではアミロイド
構造が大きく崩れている（図'）。09 変異は疎水性コアを大きく安定化することが分かっているが，本モデルの計算結果でも安定化されており，実験事実と矛盾しない。また，ヒトのプリ
オンタンパクのアミロイドはクロイツフェルト・ヤコブ病（&-'）と関係しているが，*9 変異
は &-' に感染し難いことが分かっている。本計算結果より，*9 変異型はアミロイドの構造の保持が難しく，蓄積が困難になることで &-' に感染し難くなる可能性が示唆される。
図  はアミノ酸残基間の疎水性相互作用のスコアを比較したものである。:7 と 09 変異型
で 8 字ループ部分（第  残基，図$ 参照）の相互作用を比較すると，:7 では 90
のスコアが $0 や 9/ に比べて大きいのに対し，09 変異型では  つのスコアが同等（〜）になっており，変異により相互作用のバランスが変化していることが分かる。さらに，09 変異型では変異箇所のスタック方向の相互作用（図，0909）のスコアが高くなっていることからアミロイドが安定化されたことが見て取れる。また，$9 および$3 では 09 変異によりスコアが減少しているのに対し，$9，$$，$,，,, では（有意性はないが）スコアが増加している。このように，変異の影響は変異箇所近辺だけでなく，より広範な領域に影響を与えながら疎水性相互作用のバランスを変化させていることが分かる。また，*9 変異における構造の不安定性は 99，90，//，// のスコアの大幅な減少からも確認できる。
$9 変異型の 0' 計算における最後のスナップショット（図 (）は :7 に比べて構造が安定化しているように見える。これは $OD から 9DO へ変わったことにより $9 の疎水性相互作用が大きくなり 8 字ループの「閉じ口」の部分（図 右下図を参照）が安定化したこと，また，
スーパーコンピューティングニュース
- 84 -

Vol. 24, No.32022

図：疎水性相互作用のスコア
エラーバーは標準誤差を示す。変異型間のスコアの差の有意性については 7XNH\ 法（α ）で比較した。
同じアルファベットが付記されている棒グラフ間には有意差がない。

それに伴い 00，// のスタック方向の相互作用や 90 の相互作用が増加したことが原因と考えられる（図）。図 にシミュレーション中における $$9 のα炭素（&α）間の距離の変化を示す。これを見ても，$9 変異型では距離が 7 Å 程度に保たれており，:7 に比べ安定化していることが分かる。
,0 変異型および 09 ,0 変異型についても，疎水性相互作用の変化やそれに伴う構造変化について知見を得ることができた。特徴的なのは，$09 や $$ の疎水性相互作用に見られるように，09 変異により強くなった相互作用が ,0 変異を導入することでさらに強くなる点である（図）。これは第  残基のβシートがシフト（図$ では左方向）することで 8 字ループ部分の相互作用が入れ替わることに起因しており，09 と ,0 が相性の良い変異であることを示唆している。詳細な議論は文献>@を参照されたい。



スーパーコンピューティングニュース
- 85-

Vol. 24, No.3

2022



４．まとめと今後の展望
本研究では α6\Q アミロイドに変異を導入したモデルを幾つか作成し，0' 計算を行った。8 字型のループ構造に着目し，疎水性コ
アの疎水性相互作用が α6\Q アミロイドの構
造安定性に大きく影響することを示した。また，これらの知見に基づき，プリオンタンパ
ク質の一部の配列を用いたモデルアミロイドを作成して 0' 計算を行った。実験などで報告されている特徴的な変異型についても計算を
図：$$9 の &α間の距離

行い，我々のモデルが実験で得られた結果と大きく矛盾しないことを確認した。さらに，疎水性相互作用に注目し，疎水性残基の変化が疎水性コア（ひいてはアミロイドの構造）の安定性に大きく影響することが分かった。今後は，近年，数多く報告されているアミロイドの構造（プリオンのアミロイドを含む）などと比較することで，疎水性相互作用とアミロイドの構造安定性について議論を深めていきたいと考えている。


謝 辞
本研究は『 年度（前期・後期）東京大学情報基盤センター「若手・女性利用者推薦」』
および『学際大規模共同利用・共同研究拠点（-+3&1）萌芽型共同研究課題』における採択課題「分子動力学計算によるアミロイド凝集様態の理論的解析」（拠点課題 ,'：(;）によって行われました。本研究における数値計算は東京大学情報基盤センターの 5HHGEXVK8+ 上で行われました。また，本研究は科学研究費助成事業（若手研究：.）の支援を受けています。この場を借りて感謝申し上げます。参 考 文 献
>] A. Pineda, J. Burré, “Modulating membrane binding of αV\QXFOHLQDVDWKHUDSHXWLFVWUDWHJ\” Proc. Natl. Acad. Sci. USA 114, 1223  >] T. Bartels, J. G. Choi, D. J. Selkoe, “αV\QXFOHLQRFFXUVSK\VLRORJLFDOO\DVDKHOLFDOO\IROGHGWHWUDPHUWKDWUHVLVWVDJJUHJDWLRQ” Nature 477, 107  >@ $ .UDXV) +R\W & / 6FKZDUW] % +DQVHQ( $UWLNLV $ * +XJKVRQ *-
5D\PRQG%5DFH*6%DURQ%&DXJKH\“+LJKUHVROXWLRQVWUXFWXUHDQGVWUDLQFRPSDULVRQRILQIHFWLRXVPDPPDOLDQSULRQV”0RO&HOO–  >@0'7XWWOH*&RPHOODV$-1LHXZNRRS'-&RYHOO'$%HUWKROG.'.ORHSSHU-0&RXUWQH\-..LP$0%DUFOD\$.HQGDOO::DQ*6WXEEV&
D. Schwieters, V. M. Y. Lee, J. M. George, C. M. Rienstra,“SolidVWDWH105VWUXFWXUH
RIDSDWKRJHQLFILEULORIIXOOlength human αsynuclein” Nat. Struct Mol. Biol. 23,
  >] G. G. Krivov, M. V. Shapovalov, R. L. Dunbrack, “Improved prediction of protein
VLGHchain conformations with SCWRL4” Proteins: Structure, Function, andスーパーコンピューティングニュース
- 86 -

Vol. 24, No.3

2022

%LRLQIRUPDWLFV  >] S. Pronk, S. Páll, R. Schulz, P. Larsson, P. Bjelkmar, 5$SRVWRORY05
Shirts, J. C. Smith, P. M. Kasson, D. van der Spoel, B. Hess, E. Lindahl, “GROMACSDKLJKthroughput and highly parallel open source molecular simulation toolkit”%LRLQIRUPDWLFV–  >@./LQGRUII/DUVHQ63LDQD.3DOPR30DUDJDNLV-/.OHSHLV52'RUU
D. E. Shaw, “Improved sideFKDLQWRUVLRQSRWHQWLDOVIRUWKH$0%(5II6%SURWHLQ
force field” PROTEINS: Struct. Funct. Gen. 78, 1950–  >@:/-RUJHQVHQ-&KDQGUDVHNKDU-'0DGXUD5:,PSH\0/.OHLQ
“Comparison of simple potential functions for simulating liquid water” J. Chem.
3K\V  >] G. Bussi, D. Donadio, M. Parrinello, “Canonical sampling through velocity
rescaling” J. Chem. Phys. 126, 014101 (2007)
>@+-. C. Berendsen, J. P. M. Postma, A. DiNola, J. R. Haak, “Molecular dynamics
with coupling to an external bath” J. Chem. Phys. 81, 3684–  >] N. Guex, M. C. Peitsch, “SWISS02'(/DQGWKH6ZLVV3GE9LHZHU$QHQYLURQPHQW
IRUFRPSDUDWLYHprotein modeling” Electrophoresis 18, 2714–  
>@()3HWWHUVHQ7'*RGGDUG&&+XDQJ*6&RXFK'0*UHHQEODWW(C. Meng, T. E. Ferrin, “UCSF ChimeraDYLVXDOL]DWLRQV\VWHPIRUH[SORUDWRU\UHVHDUFK
and analysis” J. Comput. Chem. 2  >@$Šali, T. L. Blundell, “Comparative protein modelling by satisfaction of spatial
restraints” J. Mol. Biol. 234, 779–  >] W. Kabsch, C. Sander, “Dictionary of protein secondary structure: pattern
UHFRJQLWLRQRIK\GURJHQbonded and geometrical features” Biopolymers 22, 2577
 
>@:*7RXZ&%DDNPDQ-%ODFN7$+WH%HHN(.ULHJHU53-RRVWHQ
G. Vriend, “A series of PDB related databases for everyday needs” Nucleic Acids
5HVHDUFK''  >] M. Tiberti, G. Invernizzi, M. Lambrughi, Y. Inbar, G. Schreiber, E. Papaleo, “Py,QWHUDSK$IUDPHZRUNIRUWKHDQDO\VLVRILQWHUDFWLRQQHWZRUNVLQVWUXFWXUDOHQVHPEOHV
of proteins” J. Chem. Inf. Model. 54, 1537–  >@-6DODPDQFD9LORria, M. F. Allega, M. Lambrughi, E. Papaleo, “An optimal distanceFXWRII IRU FRQWDFWEDVHG 3URWHLQ 6WUXFWXUH 1HWZRUNV XVLQJ VLGHFKDLQ FHQWHUV RI
mass”Sci. Rep. 7, 2838 (2017)
>@36KDQQRQ$0DUNLHO22]LHU16%DOLJD-7:DQJ'5DPDJH1$PLQ
B. Schwikowski, T. Ideker, “Cytoscape: A Software Environment for Integrated Modelsof Biomolecular Interaction Networks” Genome Research 13, 2498  >@+2WDNL<7DJXFKL11LVKLGD“&RQIRUPDWLRQGHSHQGHQWLQIOXHQFHVRIK\GURSKRELFDPLQRDFLGVLQWZRLQregister parallel βsheet amyloids, an α
V\QXFOHLQDP\ORLGDQGDORFDOVWUXFWXUDOPRGHORI3U36F” bioRxiv: 



スーパーコンピューティングニュース
- 87-

Vol. 24, No.3

2022



    
®vzvzØz­²¯WsÆ°z¨>Ûrª¨ÌÍ\S£{+)¬«X1@CGI1DH+¾
$ ÞÃ³¶ÞÃ³Á ÞÃ³Í À)
­² ÞÓL(2020) SPH ¤+©lo¼Òr1@CGI1DH}ÞvÁÃ³Z´wÕÉÚ+´w+q%vÁÃ³¸Ã³Í+Å)vÁ Ã³+¾$2I:I0H;CI4 Oakforest-PACS +©?<

    =46/,092'(&!

Î¹R`zn kReÑ° SPH ¤T©)Ú+ÄÊ)KN xIÞJ**L´w IÞgË´w J ¥§Ô)+¿)

ÇÔVy^ Þ
.
1&
5 4.

%
1'


).

|Þ&

(1)

Í=.8F i f])

(1)+Úc)Þ|tc¦ ¢$'*)#

ÇÔÞ

.
1
5 @ #  9&  4 &  <

%
1' 

(2)



-I9FÖ)

ÏbÔVy^ '~ *)Ïb° Þ)/`6H3FÞ

1/
&
5
3
. 1'
%

(3)

u`=.8F Ò`+¿(3)+Úc)Þ)Þ

 5





/
/
1
1& 
5 @ # ;   3  >
3
B. C
B. C
1%
1' 

(4)



aÍ=.8F)

Ïb°`Ü'MµÜM`Ü+a )MµÜ

SPH ¤iÝ)Xb+ )$)
'(

l u`+dt) `ß!#ÖUÞ­²

スーパーコンピューティングニュース
- 88 -pA7F+Ð©

Vol. 24, No.3

2022)×QÖ+ F )Þ×Q È P  5 (pt+Þ 7 t+È» )[!#(5)+ 5 + 3 + ((5)+q]»!#p!#]Â)  Þ

!#Í6H3F+A )Þ[!#Í6H3F+A

p!#Í6H3F+A h)Þt)Þ

(6)+A  5 +A 4 +A ) m Þp!#Í+A 5 )$Þ[!#Í "" !#Í)

`Í6H3F/A

?8E5.2  +©)ÞJ½c

jÙ6H3F)<5.¤^&(Þ
/A 5   +A
5



-

+A * 3+A
B 3 -CB 4 -C
3-

(7)

5 : 4 = +A * 3 +A
5 A 3 +A * ¢$'*)Y!#Í A 5 +A 4  +A * )
Ç+"Þ-B 5 !C
B 6 !C(8) 5
B 4 -CB 3 -C

(9)

* 58



>,3H¡Þ

BH/¦+¿Þ*'  {_¦ÞR±¦Õ ÖU )+A5ºhÁ·+Ð©)

 pm Þ` tc 5 )(6)+(7)O?)Þ
/A 5   +A )Þp!#Í6H3F+A¢$'*) ,A






+A 5 ,A'(

(10)

5   B+A  4 +A  C
1

1/

p/,tc¦À®2-)IÞ(11)
p>6H1(FÖ)

 

×Qn{¢ A7F m*)­²

Bui et alÆ(2008)+KÞDrucker-Prager A7F+©)
Drucker-Prager A7F `Í6H3F/A +

スーパーコンピューティングニュース
- 89-

Vol. 24, No.3

2022

/A 5 A 3 +A * 4 ,A F  0 * 3¢$)Lp/tc¦,A


,A 5

)
×QÖ

2-)IÞ



?

$ G


$ +A
?

)   0 3 ) +A

3

(12)

(13)



¿*)Þ 

(14)

B  C 5 ? 3 )  4 " `-tÔ2-)IÔÞ**0I1I`6H3

FJ-tÔÞY`6H3F  -tÔÞ
 5 /

*)$5 / 3 / 3 /  5 $ $ (15)Y`Þ`6H3F '_V`6H3F+bÞ$ 5/ 4¢$'*) #

#

(16)

/ * 

>)(14))) "

zq{)µ`Aºop¨ '¢$'*){Þ > Þ  2+©)"ÞÀÖÎ*^+©)Þp>6H1(F

Þ

) 5



1I¨

 B 4  2C

" 5

 B 4  2C

 5 ? 3   0


¿Þ0

 2

(17)

(18)

G4H1I¨Þ­² 0 5 )ÀÖÎ*^ÞG4H

0P zq pÀT)+¿'(#"

XÃ³+]s)$Þ[´wDxÑ %e:)'I4©{+¾Þ.CÃ³+¾¾e%*2 Ã³+kc)Ãm+£$À´wgX+¶:]Ñ)Ãm]GÞ
dÁIeA)´w+l1S©Ã³+¾´wE28+S)´<´wE28
S Þ* FDPS

¼b.CB§+¾FDPS  Ó(2017)ÞÓ{'(2020)Þ

¾'(2020)+K»*  S1@CGI1DH<*I (I8+
FDPS ~?)¥§·° ÞdÁIeA´wÕÇÔVy^&(|tc¦ÞÏb°&(aÍ=.8FÞÐMP&(!#Í6H3FÃ³Â1S©Ã³+¾'Þf'*!#Í6H3F+© p '`Í6H3F+¢$)e
uÕ265%wÞ¢$e¥§Ôq]}uÕ±]+¾Þ|ÞÍ=.
8FÞ8 =.8FÞ!#6H3FÞ`6H3Fvr+¾*'+uÕ265% 
0P¸)"(µÃ³+¾スーパーコンピューティングニュース
- 90 -

Vol. 24, No.3

2022

>-+  
20'>&5#=> $
 


 6:,         

/148  

%148  
7*")   ;?.8  

3 !19(<  SÇXÃ³<*I@+8;.-!#$')!%(")&(3:%*2})´w+J{Þ´wqaÃ³uÕÖU+Å
1@CGI1DH:)'I4 1 ¿X+©Þ%*2(´w+J{Þ´wqaÃ³uÕÖU+Å32 %*2Þ327,232 ´w' 2,048 %*2Þ

11,984,896 ´w1@CGI1DH¸+ 2 ¿ÞDxi+ 2 SÞ1 i+ 3 S 2 S 3 SÞ¿¥*)´w b )l´wÞ§¥*)´w b Y´w)
 1 ¿Ç 1@CGI1DH:)'I4

Dx´wÕÉÚ([m]



0.04

uÕF#(%[s]

1.0×10-4265%

10,000|.[kgm-3]

1850.0

BH/¦[kPa]

1800.0>,3H¡-0.3µ`[kPa]

0

Aºop¨2[]

25.0

G4H1I¨ 0DE

0.0










スーパーコンピューティングニュース
- 91-

Vol. 24, No.3

2022  ¿Ç ´wÃ³uÕ%*2

32

256

2,048

l´w

140,608

1,124,864

8,998,912l´w%*2

4,394

4,394

4,394

Y´w

186,624

746,496

2,985,984[´w

327,232

1,871,360

11,984,896

l´w[´w

0.43

0.60

0.75

Ã³uÕ 

6,689

9,806

29,742









  SÇ Dxi  SÇ 10,000 265%tiWeak scaling )$ÞÃ³uÕ qa §h)1 #I" 32 %*iÝ2¡²Þ8 #I" 256 %*2Ã³uÕ³uÕ

1.6 ;Þ64 #I" 2,048 %*2Ã

4.5 ;Ã³uÕ qaÀR Þ%*2(l´w+NÃ³Þ%*2 q )*[´w})l´wGM qa)
$Þb)l´wÃmÕ´w2n%´<´wE28SÃ³uÕ » » 

Â=+K)$´wÕÉÚ+vÁ

1@CGI1DH+2I:I0H;CI

4 Oakforest-PACS &]¾64 #I" 2048 %*2".CÃ³+¾ÞWeak
Scaling +Ã%*2+ 8 ;qa Ã³uÕスーパーコンピューティングニュース
- 92 -

1.6 ;Þ%*2+Vol. 24, No.32022

64 ;qa Ã³uÕ 4.5 ;Scaling ¾b ´w+  scaling &(Þb ´wGM  Ã³uÕqaJR» Æ$%)­²+]s)$Ã³°|3vzgXnH4IÞ2020 `¦j,[

E©[­²£}+©""Þ¯­¯   H+d"

Ä­+¿"* 7 1 5
Bui, Ha H., Fukagawa, R., Sako, K. and Ohno, S., “Lagrangian meshfree particles method (SPH) for large
deformation and failure flows of geomaterial using elastic-plastic soil constitutive model”, International
Journal for Numerical and Analytical Methods in Geomechanics, Vol. 32, pp. 1537-1570, 2008

¾v³ÞU4ÞL{\LÞy{¤¾Þ7ÄQOÞÓ{tZ¹ÞWA¡aÞÓJ¹´w¤1@CGI1DH0I"½ª$<GI&+I.(FDPS)½ª
ÞgXB§z6­²XPÞ
Vol.2018-HPC-167ÞNo. 22Þ2018ÓL SPH 1@CGI1DH&)Ûr{Ô«ª9Ö)­²
Þ63p.Þ®vz
vzØz­²¯Ws¬Þ 2020
Ó{tZ¹ÞÅ5Þ@~JÞ¾v³Þ^[ÁÞÓJ¹±.C´w¤1@CGI
1DH%*/)&¼b¨!IF5
ÞJournal of Plasma Fusion Research, Vol. 96ÞNo. 2Þpp.
57–63Þ2020

ÓJ¹ÎÊFDPS ?¼(1)
Þ]w1@CGI1DH­²66« “,HH$F”ÞVol. 19Þ

No. 2Þ2017

スーパーコンピューティングニュース
- 93-

Vol. 24, No.3

2022

Exploring Communication-Computation Overlap in
Parallel Iterative Solvers on Manycore CPUs using
Asynchronous Progress Control
堀越将司 a)，Balazs Gerofi b)，石川裕 c)，中島研吾 b,d)(a) インテル，(b) 理化学研究所，(c) 国立情報学研究所，(d) 東京大学情報基盤センター
本稿では，2019 年 5 月，2021 年 10 月に実施された大規模 HPC チャレンジの結果を報告する。本
大規模 HPC チャレンジの成果をまとめた論文「Masashi Horikoshi, Balazs Gerofi, Yutaka Ishikawa andKengo Nakajima, Exploring Communication-Computation Overlap in Parallel Iterative Solvers on
Manycore CPUs using Asynchronous Progress Control」は，2022 年 1 月にオンラインで開催された HPC
Asia 2022 でのワークショップ IXPUG（Intel eXtreme Performance Users Group）１に採択され，Proceedings（ACM Digital Library）に掲載された。本稿は出版元である ACM の許可を受け次ページ以降に上記論文の全文を掲載するものである。

Reprinted with permission from ACM, full credit to the original source (Masashi Horikoshi,
Balazs Gerofi, Yutaka Ishikawa and Kengo Nakajim, Exploring Communication-Computation
Overlap in Parallel Iterative Solvers on Manycore CPUs using Asynchronous Progress Control,
HPCAsia 2022 Workshop: International Conference on High Performance Computing in
Asia-Pacific Region Workshops (January 2022) 29-39) followed by the ACM copyright line c[2022] ACM. (https://dl.acm.org/doi/10.1145/3503470.3503474)

1)https://www.ixpug.org/events/ixpug-hpc-asia-2022
スーパーコンピューティングニュース- 94 -

Vol. 24, No.3

2022

Exploring Communication-Computation Overlap in Parallel
Iterative Solvers on Manycore CPUs using Asynchronous
Progress Control
Masashi Horikoshi

Balazs Gerofi

Accelerated Computing Systems and Graphics (AXG)
Group, Intel Corporation
Japan
Masashi.Horikoshi@intel.com

Yutaka Ishikawa

Kengo Nakajima

Information Technology Center, The University of Tokyo/
RIKEN Center for Computational Science (R-CCS)
Japan
nakajima@cc.u-tokyo.ac.jp

National Institute of Informatics
Japan
yutaka_ishikawa@nii.ac.jp

ABSTRACTPreconditioned parallel solvers based on the Krylov iterative method
are widely used in scientific and engineering applications. Communication overhead is a critical issue when executing these solvers
on large-scale massively parallel supercomputers. In this work, weinvestigate communication-computation overlapping by asynchronous progress control to various types of preconditioned conjugate
gradient methods for parallel finite-element applications. Performance of the developed method is evaluated using up to 4,096 nodesof the Oakforest-PACS system at JCAHPC, equipped with Intel®
Xeon Phi™ Manycore Processors. We show that the performance of
the iterative solver can be improved by up to 38% on 4,096 nodes. We
apply the IHK/McKernel lightweight multi-kernel operating systemand find that it can provide 20% and 6% improvements on 2,048 and
4,096 node respectively. Furthermore, we investigate the effects ofasynchronous communication progression on the IHK/McKernel
and find that it can provide an 2-3% improvement from 128 node to
1,024 node.

CCS CONCEPTS• Networks → Network performance analysis; Network measurement; • Applied computing → Earth and atmosphericsciences; Engineering.

KEYWORDS
iterative solver, MPI, non-blocking communication, asynchronous
progress threads, lightweight kernel
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from permissions@acm.org.
HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan© 2022 Association for Computing Machinery.
ACM ISBN 978-1-4503-9564-9/22/01. . . $15.00
https://doi.org/10.1145/3503470.3503474

スーパーコンピューティングニュースRIKEN Center for Computational Science (R-CCS)
Japan
bgerofi@riken.jp- 95 -

ACM Reference Format:
Masashi Horikoshi, Balazs Gerofi, Yutaka Ishikawa, and Kengo Nakajima.
2022. Exploring Communication-Computation Overlap in Parallel Iterative
Solvers on Manycore CPUs using Asynchronous Progress Control. In International Conference on High Performance Computing in Asia-Pacific Region
Workshops (HPCAsia 2022 Workshop), January 11–14, 2022, Virtual Event,Japan. ACM, New York, NY, USA, 11 pages. https://doi.org/10.1145/3503470.
3503474

1

INTRODUCTION

Preconditioned parallel solvers based on the Krylov iterative method
are widely used in scientific and engineering applications. Communication overhead is a critical issue when executing these solvers onlarge-scale massively parallel supercomputers. In the present work,
we introduced communication-computation overlapping by asynchronous progress control [1], which is supported by Intel® MPI Library from version 2019, to various types of preconditioned Krylov
iterative methods, such as pipelined conjugate gradient method[2]. We focus on optimization of global collective communications
for dot products in parallel Krylov iterative solvers. Target linear
equations are derived from GeoFEM/Cube [3], which is a parallel
finite-element application on massively parallel supercomputers.
Performance of the developed method was evaluated using up to
4,096 nodes of the Oakforest-PACS (OFP) system at JCAHPC withIntel Xeon Phi Manycore Processors[4], and the performance of
the iterative solver was evaluated.
In the previous works [5][6], we examined the impact of the
IHK/McKernel [10], lightweight multi-kernel OS developed at RIKEN
R-CCS, which provides efficient and scalable execution environment on large-scale systems by reducing OS noise and communication overhead. Improvement of the performance of parallel
multigrid solvers was 10-20% at 2,048 nodes of OFP. In the present
work, effects of IHK/McKernal were also evaluated for Asynchronous Progress Control.
The rest of this paper is organized as follows. Section refsect:appl
provides an overview of the target application and algorithms. Section 3 provides a brief summary of the target hardware system.

Vol. 24, No.3

2022

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

Masashi Horikoshi, Balazs Gerofi, Yutaka Ishikawa, and Kengo Nakajimaz

PE#1
Uniform Distributed Force inz-direction @ z=Zmax

Uy=0 @ y=Ymin

22
17

16

Ux=0 @ x=Xmin(Nz-1) elements
Nz nodes21

Uz=0 @ z=Zmin
x

18

7

1

14

15
10

9

y

2

PE#3

7

8

9

10

12

5

(Nx-1) elements
Nx nodes2 TARGET APPLICATION AND ALGORITHMS
2.1 GeoFEM/Cube
GeoFEM/Cube [3] is the target application, and it solves 3D linear
elasticity problems in simple cube geometries using a parallel FEM.
Tri-linear hexahedral elements are used for the discretization. Material properties are defined as homogeneous, where Poisson’s ratio is
set to 0.30 for all elements and Young’s modulus is 1.00. The boundary conditions are described in Fig 1. Large-scale linear equations
with sparse matrices derived from the application are solved by preconditioned Krylov iterative methods . The original GeoFEM/Cube
adopts the incomplete Cholesky conjugate gradient (ICCG) method[11] with preconditioning by incomplete Cholesky factorization
without fill-ins (IC(0)) [11]. The additive Schwarz domain decomposition (ASDD) for overlapped regions [12] is introduced for stabilization of parallel IC(0) with block-Jacobi-type localization. The
GeoFEM/Cube application is parallelized by domain decomposition
using the Message-Passing Interface (MPI) [3]. In the OpenMP/MPI
hybrid parallel programming model, multithreading by OpenMP
is applied to each partitioned domain. GeoFEM/Cube is written in
Fortran with MPI and OpenMP.
In GeoFEM/Cube, the entire model is divided into domains, andeach domain is assigned to an MPI process, as shown in Fig.2. The
local data structure in GeoFEM/Cube is node-based with overlapping elements, and as such is appropriate for the preconditioned
iterative solvers used in GeoFEM/Cube (Fig.3).
GeoFEM/Cube generates distributed local meshes and coefficientmatrices in a parallel manner using MPI. In GeoFEM/Cube, each
MPI process has (N x/Px) × (Ny/Py) × (N z/Pz) vertices, while thetotal number of vertices in each direction is (N x, Ny, N z) and thenumber of partitions in each direction is (Px, Py, Pz).

2

7

PE#3

14

13

4

5

10

1

2

3

8

9

11

12

10

9

11

12

4

5

10

8

4

7

8
7

1

6

2

3

PE#2

Figure 2: Node-based partitioning in GeoFEM/Cube [3]
15

SEND

11

10

5

12
9

6

3

8

4
1

2

7

6

7

RECEIVE

PE#0
14

13

4

5

10

1

2

3

8

9

11

12

10

9

11

12

PE#3

Section 4 overviews Intel’s Asynchronous Progress Control. Section 5 presents overview of IHK/McKernel, and special configuration of threads for Intel’s Asynchronous Progress Control. Section
6 describes numerical experiments and results. Finally, Section 8
concludes the paper and offers future perspective.

11

9

6

1

PE#2

3

6

15

12

11

5

4

3

6

2

3

1

Figure 1: Simple cube geometry for 3D linear elasticity problems in GeoFEM/Cube [3]スーパーコンピューティングニュース

5

20

12
8

4

25

19
13

11
6

(Ny-1) elements
Ny nodes

24

PE#0

PE#1

PE#0
23

8

4
7

1

2

11

3

10

3

PE#2

12
9

6

8

4
1

2

7

6

7

4

5

1

2

3

8

9

11

12

10

9

11

12

4

5

10

PE#3

5

15

13

14

6

5

PE#0

8
7

1

2

6

PE#2
3

Figure 3: Communications among MPI processes [3]2.2

Pipelined CG

Algorithm 1 shows the preconditioned conjugate gradient method(PCG) [11], which includes SpMV, dot products, the DAXPY computations, and preconditioning.
Algorithm 1 Preconditioned Conjugate Gradient Method (PCG)[11]
1: r (0) = b − Ax (0) ; u (0) = M −1r (0) ; p (0) = u (0) ; ρ 0 = (r (0) , u (0) )2: for k = 0, 1, . . . , until convergence do:3:
q (k) = Ap (k)α k = ρ k /(p (k) , q (k) );x (k+1) = x (k) + α k p (k)6:r (k+1) = r (k) − α k q (k) ⇒ check converдence : |r (k+1) |7:u (k+1) = M −1r (k+1)
8:ρ k+1 = (r (k+1) , u (k+1) )9:
βk+1 = ρ k+1 /ρ k
10:
p (k+1) = u (k+1) + βk+1p (k)11: end for4:5:

In computations on parallel computers with distributed memory,
SpMV (Sparse Matrix-Vector Multiplication), dot products, andpreconditioning may require communication. Although there arevarious types of communication patterns in preconditioning, SpMV
relies upon point-to-point communication with neighbors and dot
products rely upon global collective communication [3][11].
If the code is implemented by MPI, MPI_Isend and MPI_Irecv
with MPI_Wait/Waitall are used in SpMV, and MPI_Allreduce is- 96 -

Vol. 24, No.3

2022

Exploring Communication-Computation Overlap in Parallel
Iterative Solvers on Manycore CPUs using Asynchronous Progress Control

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

Algorithm 2 Preconditioned Chronopoulos/Gear Conjugate Gradient Method [15]= b − Ax (0) ; u (0) = M −1r (0) ; p (0) = u (0) ; q (0) = Ap (0) ;γ 0 = (r (0)2: for k = 0, 1, . . . , until convergence do:3:
p (k +1) = u (k ) + βk p (k )4:
q (k +1) = w (k ) + βk q (k)5:x (k +1) = x (k ) + α k p (k +1)
6:
r (k +1) = r (k ) − α k q (k +1) ⇒ check converдence : |r (k+1) |7:u (k +1) = M −1r (k +1)
8:
w (k +1) = Au (k +1)
9:
γk+1 = (r (k +1) , u (k +1) )10:
δk +1 = (w (k +1) , u (k +1) )11:
βk +1 = γk +1 /γk12:
α k +1 = γk +1 /(δk +1 − βk+1γk+1 /α k )13: end for
1: r (0)The pipelined method [2] reduces communications overhead by
overlapping global collective communications and computations.
Algorithm 3 shows Preconditioned Pipeined CG method [2]. Thismethod is derived from Algorithm 2.
In pipelined CG [2], collective communication for dot products
can be overlapped with heavier computations, such as SpMV andpreconditioning. In the original CG algorithm (Algorithm1), dot
products (α k = ρ k /(p (k ) , q (k ) ) in line-4, and ρ k+1 = (r (k+1) , u (k+1) )in line-8) are used in the next lines (line-5 and line-9), while they areused after in SpMV and preconditioning in the pipelined algorithm.
δk = (p (k ) , q (k ) ) is defined in line-3, and it it used in line-5, therefore
computing of δk can be overlapped with z (k) = M −1q (k) in line-4.
γk+1 = (r (k +1) , u (k +1) ) is defined in line-9, and it is used in line-11
after w (k +1) = Au (k +1) in line-10.

スーパーコンピューティングニュース- 97 -

Asynchronous collective communication (e.g., MPI_Iallreduce)
supported in MPI-3 is effective for such procedures.
In [16], the authors implemented pipelined CG to the original
GeoFEM/Cube with ICCG and ASDD using up to 12,288 cores(384 nodes) of the Reedbush-U system [17] with Intel® Xeon® E52695v4 (code name: Broadwell-EP) CPUs using Intel® MPI 2017. Fig.
4 compares the original and pipelined CG method for strong scaling.
Pipelined CG provides much better scalability than the original CG.
Pipelined CG is effective in the very limited case of strong scaling,where the problem size per MPI process is very small.
Algorithm 3 Preconditioned Pipelined Conjugate Gradient
Method [2]1: r (0) = b−Ax (0) ; u (0) = M −1r (0) ; p (0) = u (0) ; q (k) = Ap (k) ; w (0) =Au (0) ; α 0 = (r (0) , u (0) )/(w (0) , u (0) ); β 0 = 0; γ 0 = (r (0) , u (0) )2: for k = 0, 1, . . . , until convergence do:3:δk = (p (k) , q (k) )4:z (k) = M −1q (k)5:α k = γk /δkx (k+1) = x (k) + α k p (k)7:r (k+1) = r (k) − α k q (k) ⇒ check converдence : |r (k+1) |8:u (k+1) = u (k) − α k z (k)9:γk+1 = (r (k+1) , u (k+1) )10:w (k+1) = Au (k+1)
11:
βk+1 = γk+1 /γk
12:
p (k+1) = u (k+1) + βk+1p (k)13:
q (k+1) = w (k+1) + βk+1q (k)14: end for
6:

10000

Original CG
Pipelined CG
Ideal

8000

Speed-Up

used in dot products. The overhead for such communications is a
critical issue on massively parallel supercomputers with more than
104 MPI processes.
In recent years, many algorithms and methods for avoiding andreducing communication overhead have been proposed. Methods
based on the matrix powers kernel [13] reduce the number of global
communications at each iteration by extending the halo region in
Figs. 2 and 3. They generally require complicated data structures
and are not suitable for general preconditioning methods, such as
incomplete LU (ILU).
In [2], several methods for conjugate gradient methods, which
reduce overhead of global collective communications for dot products, are introduced. The sequence of Krylov iterations is changed
using recurrence relations without changing the original algorithm.
Because the order of computation is changed, rounding errors arepropagated differently. Therefore, convergence may be affected in
ill-conditioned problems. Authors applied computing with single
precision to such algorithms, and results show that original CG
is the most robust [14]. This does not happen for the cases withdouble precision for ill-conditioned problems in the present work.
Algorithm 2 shows PCG using Chronopouos/Gear CG method[15], where 2 dot products are combined into a single reduction.
Thus, overhead for calling MPI_Allreduce may be reduced.

6000
4000
2000
0

0

2048

4096

6144

8192 10240 12288

CORE#

Figure 4: Effects of pipelined CG [16] for GeoFEM/Cubewith ICCG and ASDD using up to 12,288 cores (384 nodes)of Reedbush-U [16] and strong scaling; total problem size:
28,311,552 DOF
Finally, Algorithm 4 shows Preconditioned Gropp’s CG method[2][18]. While this method is similar to Algorithm 3, computations
are smaller than those of Algorithm 3. Dot products in line-3 andline-4 (γk , δk ) are overlapped with preconditioning in line-5 and
SpMV in line-6.
In the present work, following four algorithms for the conjugate
gradient method are evaluated. Each method includes one SpMVVol. 24, No.3

2022

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan(Sparse Matrix Vector Multiply), one preconditioning and three dot
products for each iteration. Number of DAXPY ’s ( constant times avector plus a vector (axpy) in double-precision) in each method as
follows. 8 DAXPY’s in a iteration of Pipelined CG (Alg.3), while itis 3 in the original CG (Alg.1):• Algorithm 1: Original CG (3 DAXPY’s in one iteration) [11]• Algorithm 2: Chronopoulos/Gear CG (4 DAXPY’s) [15]• Algorithm 3: Pipelined CG (8 DAXPY’s) [2]• Algorithm 4: Gropp’s CG (5 DAXPY’s) [2][18]Algorithm 4 Preconditioned Gropp’s Conjugate Gradient Method[2][18]
1: r (0) = b − Ax (0) ; u (0) = M −1r (0) ; w (0) = Au (0) ; z (0) = q (0) =s (0) = p (0) = 0
2: for k = 0, 1, . . . , until convergence do:3:
γk = (r (k ) , u (k ) )4:δk = (w (k ) , u (k ) )5:m (k ) = M −1w (k )
6:
8:

3

library (2018) were used. Table 1 summarizes the specifications ofeach node of OFP.
Table 1: Summary of the performance of single node of the
Oakforest-PACS(OFP)
ArchitectureIntel Xeon Phi(Knights Landing)Frequency(GHz)1.40

Core # /CPU (socket) (Maximum
Effective Thread #)68 (272)

TARGET HARDWARE (OAKFOREST-PACS,OFP)The Oakforest-PACS system (OFP) [4] is the premiere supercomputer system at the Joint Center for Advanced High-Performance
Computing (JCAHPC) [4] , which was established by the Universityof Tokyo and University of Tsukuba. The system consists of 8,208
nodes of Intel Xeon Phi 7250 (code name: Knights Landing, or KNL),
and Intel® Omni-Path Architecture (Intel® OPA) provides a 100 Gbps
interconnection in a fat-tree topology with full bisection bandwidth.
Each Xeon Phi 7250 node is built using 68 modified Atom® (codename: Silvermont) cores running at 1.4 GHz, and the memory unit
consists of 96 GB of DDR4 RAM and 16 GB of stacked 3D MCDRAM,
which can be utilized as an L3 cache or high-bandwidth memory.
Each core has two 512-bit vector units and supports AVX-512 SIMD
instructions. Each core can host four threads (i.e., 272 overall logicalCPUs on the entire chip) and is equipped with 2 512-bit floatingpoint vector ALU. The total theoretical computational performanceis 25 PFLOPS, and the system achieved 13.55 PFLOPS on the HPLbenchmark. In the present work, only MCDRAM was used for memory in the flat/quadrant mode on the OFP. Intel’s compiler and MPI

スーパーコンピューティングニュース

7250

Peak Performance (GFLOPS)

3,046.4

Memory Size (GB)MCDRAM:16,DDR4:96

Memory Bandwidth (GB/sec)

MCDRAM:490
DDR4:84

Compiler & MPI LibraryIntel® Parallel Studio 2019
XE, Intel MPI 2019n(k ) = Am(k )if k > 0 thenβk = γk /γk −1 ; α k = γk /(δk − βk γk /α k−1 )
9:
else
10:
β 0 = 0; α k = γk /δk11:
end if12:z (k +1) = n(k ) + βk z (k )13:s (k +1) = m(k ) + βk s (k )14:
q (k +1) = w (k ) + βk q (k)15:
p (k +1) = u (k ) + βk p (k )16:
x (k +1) = x (k ) + α k p (k )17:r (k +1) = r (k ) − α k q (k ) ⇒ check converдence : |r (k+1) |18:
u (k +1) = u (k ) − α k s (k )19:
w (k +1) = w (k ) − α k z (k)20: end for
7:

Masashi Horikoshi, Balazs Gerofi, Yutaka Ishikawa, and Kengo Nakajima[20],

4 ASYNCHRONOUS PROGRESS CONTROL
4.1 Overview
MPI Non-blocking communication in application thread (e.g. for
MPI_Isend) is expected to run asynchronously. To do that, progress
thread is required if MPI communication is not completely offloaded.
But turning on the progress thread (e.g. for MPI_test) requires
MPI_THREAD_MULTIPLE. But in most case, MPI progress thread is
not practically used due to poor MPI performance due to serialization around one queue for all threads, thread switching overhead,and process-wide MPI objects management overhead. Because those
restrictions are closely related with MPI 3.1 standard (defined as"threads are not separately addressable: a rank in a send or receive
call identifies a process, not a thread”). Those history and practices
are well summarized in [21]. To overcome such restrictions, IntelMPI 2019 developed new asynchronous progress design, which isbased on MPICH asynchronous design. From Intel MPI version
2019, it supports the new asynchronous progress threads that users
to manage communication in parallel with application’s computation to achieve better communication and computation overlapping.
Asynchronous progress control on the Intel MPI has a full support
for MPI point-to-point operations, blocking collectives, and a partial
support for non-blocking collectives (MPI_Ibcast, MPI_Ireduce,and MPI_Iallreduce).
Setting the I_MPI_ASYNC_PROGRESS_PIN environment variable
on the Intel MPI allows to control a pinning of the asynchronous
progress threads to logical processor cores. By using this feature 1 ,we can provide separate dedicated cores for asynchronous progress
threads.

4.2

Core Configuration

By default, Intel MPI allocates cpu core resource to the asynchronous progress threads from last logical core. For the 68 cores Intel
1 To enable asynchronous progress control on the Intel MPI, environment variable

I_MPI_ASYNC_PROGRESS=on, after loading release_mt environment, is required.

- 98 -

Vol. 24, No.3

2022

Exploring Communication-Computation Overlap in Parallel
Iterative Solvers on Manycore CPUs using Asynchronous Progress Control

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

Xeon Phi processor, it has 272 logical cores so the default pinning
Computation thread
MPI process #0
MPI process #1 …
values are from 271 to 264 in the case of 8 MPI processes and 8 asynchronous progress threads, for example. It depends on application
Hardware thread #0 0
1
2
3
4
…
10
…
65 66 67
but there are several ways to allocate logical cores for asynchroHardware thread #1 68 69 70 71 72
78
133 134 135
nous progress threads on the many core processor. For simplicity
Hardware thread #2 136 137 138 139 140
146
201 202 203
on the GeoFEM application, we fixed the number of MPI process
Hardware thread #3 204 205 206 207 208
214
269 270 271
as 8 and used 8 OpenMP threads per MPI process. Total 64 logicalcore by using same number of physical core for better GeoFEM
performance (1 hardware thread per physical core used).
Figure 5: Figure of core mapping method #0 on Xeon Phi
We exclude first two physical and last two physical cores of theprocessor
Xeon Phi from GeoFEM computation by using environment variable
I_MPI_PIN_PROCESSOR_EXCLUDE_LIST=0,1,68,69,136,137,204,205
Asynchronous progress thread Computation threadin order to avoid first core (logical cores 0,68,136, and 204) which
MPI process #0
MPI process #1 …
is affected by OS noise and jitters. Logical cores from 2 to 65 are
Hardware thread #0 0
1
2
3
4
…
10
…
65 66 67
used for GeoFEM computation. Fig. 5 illustrates such situation
Hardware thread #1 68 69 70 71 72
78
133 134 135
as experimental setup. We have tested 5 different mapping of 8
Hardware thread #2 136 137 138 139 140
146
201 202 203
asynchronous progress threads (1 progress thread per MPI process)Hardware thread #3 204 205 206 207 208
214
269 270 271
in addition to the case with asynchronous progress control. First
method (Fig. 6) is using default setup of Intel MPI which uses fromlogical core 268 to 271. Second method (Fig. 7) is using first two
Figure 6: Figure of core mapping method #1 on Xeon Phi
physical cores (logical core 0,1,68,69,136,137,204 and 205). Since
processor
first two cores are not used by computation, we can allocate 8 logical cores by 2 free physical cores.Third method (Fig. 8) is using
Asynchronous progress thread Computation threadlast two physical cores (66,67,134,135,202,203,270 and 271). This
MPI process #0
MPI process #1 …
method is basically same as second method but it is not affected
Hardware thread #0 0
1
2
3
4
…
10
…
65 66 67
by OS noise and jitters. Forth method (Fig. 9) is using first two
Hardware thread #1 68 69 70 71 72
78
133 134 135
and last two cores (0,1,68,69,66,67,134 and 135). This method is
Hardware thread #2 136 137 138 139 140
146
201 202 203
using all 4 free physical core to provide 8 asynchronous progress
Hardware thread #3 204 205 206 207 208
214
269 270 271
threads. Last method (Fig. 10) is using same physical core as MPI
process (138,146,154,162,170,178,186 and 192). This method does
not use any additional physical core for asynchronous progress
Figure 7: Figure of core mapping method #2 on Xeon Phi
threads and use other hardware thread (e.g. hardware thread #2) onprocessor
the same physical core of MPI process. For example, logical core 2(hardware thread #0 on the physical core 2) is used for MPI process
Asynchronous progress thread Computation thread0, and logical core 138 (hardware thread #2 on the physical core 2)
MPI process #0
MPI process #1 …
is used one asynchronous progress thread. Since using same physHardware thread #0 0
1
2
3
4
…
10
…
65 66 67
ical core for MPI communication and computation, this method
Hardware thread #1 68 69 70 71 72
78
133 134 135
is expected to have better cache hit and to reduce internal data
Hardware thread #2 136 137 138 139 140
146
201 202 203transfer during overlapping. Table 2 is the list of core numbers for
Hardware thread #3 204 205 206 207 208
214
269 270 271
I_MPI_ASYNC_PROGRESS_PIN.
Table 2: Summary of mapping method of asynchronous
progress thread

Figure 8: Figure of core mapping method #3 on Xeon Phi
processor

Mapping method

I_MPI_ASYNC_PROGRESS_PIN=#0. Without asynchronous thread

N/A (I_MPI_ASYNC_PROGRESS=off)#1. Intel MPI default(271,270,269,268,267,266,265,264)

Hardware thread #0

0

1

2

3

4

Hardware thread #1

68

69

70

71

72

78

133 134 135#2. First 2 physical cores

0,1,68,69,136,137,204,205

Hardware thread #2 136 137 138 139 140

146

201 202 203#3. Last 2 physical cores

66,67,134,135,202,203,270,271

Hardware thread #3 204 205 206 207 208

214

269 270 271#4. First 2 and last 2 cores

0,1,68,69,66,67,134,135#5. Using other hardware threadon same core

138,146,154,162,170,178,186,192

スーパーコンピューティングニュースAsynchronous progress thread
MPI process #0

Computation thread

MPI process #1 …

…

10

…

65

66

67

Figure 9: Figure of core mapping method #4 on Xeon Phi
processor- 99 -

Vol. 24, No.3

2022

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

Asynchronous progress thread
MPI process #0

Masashi Horikoshi, Balazs Gerofi, Yutaka Ishikawa, and Kengo Nakajima

Computation thread

MPI process #1 …

Hardware thread #0

0

1

2

3

4

Hardware thread #1

68

69

70

71

72

…

78

10

…

133 134 135

65

66

67

Hardware thread #2 136 137 138 139 140

146

201 202 203

Hardware thread #3 204 205 206 207 208

214

269 270 271

Figure 10: Figure of core mapping method #5 on Xeon Phi
processor

4.3

Experiments of various mapping methods
on 512 node

Normalized time by Method #0

We evaluated which mapping method is best for GeoFEM by using
smaller test case on smaller cluster size. We set a problem size of
GeoFEM as (256, 128, 128) for 512 node test as smaller proxy offull (512, 256, 256) size, which is equivalent to 100,663,296 DOFs.
We investigate all method from #0 to #5 on the 512 node by using
best performing number during 5 executions for each algorithm.
Figure 11 shows relative performance of algorithm 4:Gropp’s CG
which is using MPI_Iallreduce. Except mapping method #2, allmethods of asynchronous progress control enabled shows better
performance than method #0. Method #4 is best performing coreconfiguration with 37% improvement. While method #1 and #5
need only free logical cores, method #3 and #4 need more hardware
resource as free physical cores. Method #4 needs 2 more physicalcores than Method #3. It is reasonable results that more hard wareresource gives more performance improvement. We are not sure
why method #2 showed poor performance. One possible reason is
OS noise and jitters. Message size of GeoFEM’s MPI_Iallreduceis 16 byte. It is well known such small size global synchronizedcollective communications are affected by OS noise and jitters [22].

3.00
2.40

2.50

2.00
1.50
1.00

1.00

0.73

0.68

0.63

0.75

0.50
0.00

Method Method Method Method Method Method
#0
#1
#2
#3
#4
#5

Figure 11: Result of 512 node experiment. Method #0 to#5 shows relative performance. Normalized by Method #0(without asynchronous progress control).

スーパーコンピューティングニュース

5

IHK/MCKERNELThis section gives a general overview of IHK/McKernel and describes developments targeted for asynchronous communication
threads on Oakforest-PACS.

5.1

Overview

The IHK/McKernel multi-kernel operating system is comprised oftwo main components. Interface for Heterogeneous Kernels (IHK)[7], a low-level software infrastructure, provides capabilities forpartitioning resources in a many-core environment (e.g., CPU coresand physical memory) and it enables management of lightweight
kernels. McKernel is a lightweight co-kernel developed on top of
IHK. An overview of the multi-kernel architecture is depicted inFig. 12.
IHK is capable of allocating and releasing host resources dynamically and no reboot of the host machine is required when altering
configuration. It is implemented as a collection of Linux kernel modules without any modifications to the Linux kernel itself, whichenables straightforward deployment of the multi-kernel stack on
a wide range of Linux distributions. Besides resource and LWK
management, IHK also facilitates an Inter-kernel Communication(IKC) layer, which is used for implementing system call delegation(discussed below).
McKernel has been developed from scratch and while it is designed explicitly for high-performance computing workloads it
retains a Linux compatible application binary interface (ABI) so
that it can execute unmodified Linux binaries. There is no needfor recompiling applications or for any McKernel specific libraries.
McKernel implements only a small set of performance sensitive
system calls and the rest of the OS services are delegated to Linux.
Specifically, McKernel implements memory management, it supports processes and multi-threading, it has a simple round-robin
co-operative (tick-less) scheduler, and it supports standard POSIX
signaling. It also implements inter-process memory mappings andit offers interfaces for accessing hardware performance counters.
For each OS process executed on McKernel there is a process running on Linux, which we call the proxy-process. The proxy process’
main role is to assist system call offloading. Essentially, it provides
the execution context on behalf of the application so that offloaded
system calls can be invoked in Linux. For more information on
system call offloading, refer to [8]. The proxy process also provides
means for Linux to maintain various state information that would
have to be otherwise kept track of in the co-kernel. McKernel for
instance has no notion of file descriptors, but it simply returns
the number it receives from the proxy process during the execution of an open() system call. The actual set of open files (i.e., filedescriptor table, file positions, etc.) are managed by the Linux kernel. Relying on the proxy process, McKernel provides transparent
access to Linux device drivers not only in the form of offloaded
system calls (e.g., through write() or ioctl()), but also via direct
device mappings. Details of the device mapping mechanism has
been described elsewhere [9].

5.2

Support for Asynchronous Progress

As shown in Fig. 12, IHK partitions CPU cores into Linux and lightweight kernel (LWK) domains. Only the LWK CPUs are exposed to- 100 -

Vol. 24, No.3

2022

Exploring Communication-Computation Overlap in Parallel
Iterative Solvers on Manycore CPUs using Asynchronous Progress Control         

SystemdaemonHPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

Proxy process

HPC Application

System callLinux
KerneldaemonCPU

Delegator
moduleIHK Linux…

CPU

McKernel

IHK co-kernel
CPU

CPU

…

CPU

Systemcall
CPU

MemoryInterrupt

Partition

ParAAonFigure 12: Architectural overview of IHK/McKernel
application running on McKernel, e.g., on the Xeon Phi processor
used in this study only 256 logical CPU cores from the overall 272
are visible in McKernel. In addition, McKernel renumbers CPUs
and provides an automatic process pinning mechanism that integrates with MPI to ease the burden on users for dealing with CPU
numbering related issues.
With respect to asynchronous progress threads, the main challenge that had to be addressed in McKernel was the enablement ofadditional CPU cores in LWK without directly exposing them tocomputation threads of the application. For this purpose McKernel’s internal CPU management code as well as the process pinningmechanism has been enhanced for asynchronous progress awareness. Specifically, CPU cores dedicated to auxiliary threads are kept
transparent from application code and MPI progress threads are
pinned automatically to those CPUs. We use the second tile of the
Xeon Phi and pin one progress thread per logical CPU on each core.

6 NUMERICAL EXPERIMENTS
6.1 Performance results on Linux (measured in2019)
Since method #4 is the best core mapping so we measured reallarge problem size up to 4096 node by using asynchronous progress
thread with method #4 in addition to method #0 as a baseline. First
measurement was done on May 2019 by using Intel tools version
2019 Update 1. We fixed the problem size as (512, 256, 256), whichhas 100,663,296 DOFs, and performed strong scaling measurements.
Fig. 13a-14b show bar graphs as best performing numbers during
5 executions on each run, which have also error bars as worst
performing numbers of 5 runs. Detailed performance numbers arealso listed on the Table 7 in the appendix as a reference.
Since Alg. 1-4 do not have global asynchronous MPI calls(MPI_Iallreduce), but using MPI_Allreduce, it is not related with
asynchronous progress setups, essentially. Fig. 13a-14b have measurement results for those algorithms marked as "Linux non async
in 2019". We can see performance improvement (or decreasing CG
Loop time) with growing the number of node from 128 to 2,048

スーパーコンピューティングニュース- 101 -

node. From 2,048 to 4,096 node, we are seeing saturation of performance or worse performance by poor scaling. These performancesaturations are derived by time increase of MPI_Allreduce on thelarge number of node executions. For example, by profiling on 2048
node, total time of MPI_Allreduce calls for Alg. 1 is 59% of total
CG Loop time while it is 15% on 128 node. It is what we would
like to hide or overlap into computation by using asynchronous
progress threads.
Performance of the original CG (Alg.1) saturates, as number ofnodes is more than 2,048. On the contrast, Chronopoulos/Gear algorithm (Alg.2) keeps scalability up to 4,096 nodes, and much better
than Alg.1, because communication overhead by MPI_Allreduce isreduced. Pipelined CG (Alg.3) and Gropp’s CG (Alg.4) are generally
slower than Alg.1, because the amount of computations per each iteration is larger than Alg.1. Alg.3i and Alg.4i with MPI_Iallreduce
are also slower, but both of them are much faster than Alg.1, andcompetitive with Alg.2. The reason of this improvement is not clear,
while MPI_Iallreduce may reduce the communication overhead
at 4,096 nodes.
Effects of asynchronous progress threads are significant withmore than 512 nodes, although performance of Alg.3i is not scaled
at 4,096 nodes. Generally, the results show Alg.3i and Alg.4i provide
much better scalability than Alg.1 by combination of MPI_Iallreduceand asynchronous progress threads. Fig. 14a-14b have the result ofasynchronous progress threads for the Alg. 3i and 4i, which haveasynchronous global MPI calls as MPI_Iallreduce. We can compare performance "Linux no async in 2019" and "Linux async in
2019" on Fig. 14a and 14b, respectively. We are seeing significant
performance improvement on Alg. 4i while Alg. 3i was expected tohave similar performance improvement by overlapping, but resultof Alg. 3i showed smaller performance improvement than Alg. 4i. It
is not clear why it shows such behavior. Table 3 show summarized
performance improvement results which have comparison of original non asynchronous algorithm (Alg. 3 and 4) and asynchronous
versions with asynchronous progress control (Alg. 3i and 4i). We
successfully got up to 19% and 38% improvements for Alg. 3 to 3i
and Alg. 4 to 4i, respectively, by overlapping effect of asynchronous
progress control.

Vol. 24, No.3

2022

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

Alg. 1

14

Linux non async in 2019

12

McKernel non async in 2021

Linux non async in 2021

10
8
6
4

14

Linux non async in 201912

Linux non async in 2021

McKernel non async in 2021

10
8
6
4
2

2
0

Alg. 216

CG Loop time [sec]16

CG Loop time [sec]Masashi Horikoshi, Balazs Gerofi, Yutaka Ishikawa, and Kengo Nakajima

0
128

256

512

1024

Number of Node

2048

4096

128

256

512

1024

2048

4096

Number of Node(a) Algorithm 1(b) Algorithm 2

Figure 13: Results without asynchronous progress on Linux and McKernel

Alg. 3 (non async) and 3i (async)
Linux non async in 2019

CG Loop time [sec]14Linux async in 2019

Linux non async in 2021

12

McKernel non async in 2021

McKernel async in 2021

8
6
4

12

Linux non async in 2019

Linux async in 2019

Linux non async in 2021

Linux async in 2021

McKernel non async in 2021

McKernel async in 2021

10
8
6
4
2

2

0

14

Linux async in 2021

10

Alg. 4 (non async) and 4i (async)

16

CG Loop time [sec]

16

0
128

256

512

1024

Number of Node

2048

4096

128

(a) Algorithms 3 and 3i

256

512

1024

Number of Node

2048

4096

(b) Algorithms 4 and 4i

Figure 14: Results comparing synchronous and asynchronous progress for algorithms 4 and 5 on Linux and McKernel
We can see growing size of error bars for all algorithms on top of"Linux no async in 2019" and "Linux async in 2019" in Fig. 13a-14b
with increasing the number of node. In [5][6], we examined theimpact of the IHK/McKernel [10], and seeing stable measurement
results (small error bars) on large-scale systems by reducing OS
noise and communication overhead. In the next section, we will discuss the efforts which we try applying IHK/McKernel for GeoFEM
with asynchronous progress control.

6.2

Table 3: Performance improvement of introducing overlaps
by MPI_Iallreduce and asynchronous progress control onLinux (measured in 2019)
Node
128
256
512
1024
2048
4096

Performance results on Linux (measured in
2021)

Since McKernel was required some modifications as described in
Section 5, we needed revisited Linux measurements with newer version of environments including newer versions of BIOS, Firmware,
OS, Interconnect driver (IFS), Parallel file system (Lustre) driver,

スーパーコンピューティングニュースAlg. 3 non asyc to 3i
with async
1.03
1.04
1.05
1.06
1.08
1.19

Alg. 4 non async to 4i
with async
1.06
1.11
1.20
1.25
1.34
1.38

macro task software (e.g. scheduler) and MPI library to get new
baseline after 2 years. We used same method #4 as the best core

- 102 -

Vol. 24, No.3

2022

Exploring Communication-Computation Overlap in Parallel
Iterative Solvers on Manycore CPUs using Asynchronous Progress Control

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

mapping with same large problem size up to 4096 node by using
asynchronous progress control in addition to method #0 as a baseline similarly in 2019. This second measurement was done on Nov.
2021 by using Intel tools version 2019 Update 9. All performance
numbers are listed on the Table 8 in the appendix as a reference.
Results marked as "Linux non async in 2021" on Fig. 13a-14b
and "Linux async in 2021" on Fig. 14a-14b show the performanceof result of re-measurements by using newer software and driver
versions. We can see similar performance behaviors in Fig. 13a-14b
without asynchronous progress control while seeing smaller run
to run variances (smaller error bars). On Fig. 14a-14b, we can see
worse performance results of "Linux non async in 2021" case than
"Linux non async in 2019". We are not sure why MPI_Iallreduceversion’s GeoFEM (Alg. 3i and 4i) show poor performance than 2019.
Since almost of all software environments are changing from 2019,
it is very difficult to identify the root cause. Also due to security
fixes and patches in two years, we can not revert entire systemsame as 2019.
We can compare the effect of asynchronous thread control, similarly, "Linux async in 2019" case and "Linux async in 2021" case on
Fig. 14a-14b. Alg. 3i and 4i show better performance by using asynchronous progress threads up to 512 and 1024 node, respectively.
But on the larger node counts, we are seeing worse performance
results by using synchronous progress threads. It is unexpected
results that effective on smaller node count while negative impact
on larger node count. In 2019, asynchronous progress threads wereeffective with growing node count up to 4,096. As same reasons
as non async 2021 results, we are not sure and have difficulties to
identify the root causes.
Table 4 show summarized performance improvement and degradation results which have comparison of original non asynchronousalgorithm (Alg. 3 and 4) and asynchronous versions with asynchronous progress control (Alg. 3i and 4i). As described in section 6.1,
We got up to 19% and 38% improvements for Alg. 3 to 3i and Alg.
4 to 4i, respectively in 2019 but we can see the positive effect ofasynchronous progress control on fewer node count only.

two physical cores only while it is expected more improvement by
allocating 4 unused physical cores to McKernel. 8 logical threads
provided by first two physical cores handle asynchronous progresscontrol in addition to IHK Linux for this time. It is almost equivalent
to Fig. 7 or the method #2. All other measurements conditions aresame as Linux in 2021.
Through Fig. 13a to 14b, which have case of non asynchronous
progress control, we can see a little performance improvement onlarger node count while almost same on lower node count. But wecan clearly see error bars on McKernel are significantly smaller
than that of Linux. This stable and less variant results are one of
the benefits by McKernel. Similarly on Fig. 14a-14b, we can see
much smaller error bars on McKernel, which are marked on top of"McKernel non async in 2021" and "McKernel async in 2021" bars.
Table 5 shows summarized performance improvement on McKernel without asynchronous progress control, compared with best
Linux result without asynchronous progress control of 2019 and2021. All other measurement results show better performance thanLinux due to less noisy and low overhead nature of McKernel. For
example, We can see up to 20% performance improvement on 2,048
node and 6% on 4,096 node for the Alg. 4. All performance numbers
are listed on the Table 9 in the appendix as a reference.
Next, discussing asynchronous progress control on McKernel. Table 6 show summarized performance improvement and degradation
results which have comparison of original non asynchronous algorithm (Alg. 3 and 4) and asynchronous versions with asynchronous
progress control (Alg. 3i and 4i). We cannot see beneficial improvement on Alg.3i. With Alg. 4i, asynchronous progress threads give
2-3% performance improvement from 128 node to 1,024 node.
Table 5: Performance improvement on McKernel vs. best ofLinux in 2019 and 2021. Note: Below 1.00 means negative effect.
Speedup
128
256
512
1024
2048
4096

Table 4: Performance improvement and degradation of introducing overlaps by MPI_Iallreduce and asynchronous
progress control on Linux (measured in 2021). Note: Below
1.00 means negative effect.
Node
128
256
512
1024
2048
4096

6.3

Alg. 3 non asyc to 3i
with async
1.01
0.98
0.95
0.87
0.70
0.53

Alg. 4 non async to 4i
with async
1.40
1.26
0.96
0.82
0.61
0.43

7

Performance results on McKernel(measured in 2021)

For simplicity and little implementation cost, the modification forasynchronous progress control on McKernel is intended to use first

スーパーコンピューティングニュース- 103 -

Alg. 1
1.01
1.02
1.07
1.10
1.15
1.01

Alg. 2
1.01
1.02
1.06
1.09
1.13
1.06

Alg. 3
1.01
1.03
1.05
1.07
1.15
1.07

Alg. 4
1.01
1.02
1.07
1.08
1.20
1.06

RELATED WORK

Non-blocking collective operations were introduced in MPI several years ago [23]. However, only a few recent studies have explored thread placement strategies for asynchronous communication progress thread placement for non-blocking collective operations. Ohlmann et. al. presented Intel MPI’s asynchronous progresscontrol with an application case study demonstrating the benefitsof progress thread placement [25].
Denis et. al. studied progress thread placement on many-coreCPUs with a special focus on symmetric multithreading. Similarly to
our findings, they also reported that running asynchronous progress
on SMT threads of an application core can degrade performancedue to cache effects in intranode communication [24].

Vol. 24, No.3

2022

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

Masashi Horikoshi, Balazs Gerofi, Yutaka Ishikawa, and Kengo Nakajima

Table 6: Performance improvement and degradation of introducing overlaps by MPI_Iallreduce and asynchronous
progress control on McKernel (measured in 2021). Note: Below 1.00 means negative effect.
Node
128
256
512
1024
2048
4096

8

Alg. 3 non asyc to 3i
with async
1.00
0.98
0.95
0.93
0.91
0.79

Alg. 4 non async to 4i
with async
1.02
1.03
1.02
1.02
0.92
0.84

CONCLUSION AND FUTURE WORK

We have demonstrated that the asynchronous progress control isvery effective with appropriate algorithm changes for CG solvers
to overlap global synchronization and computation. We achieved
38% performance improvement on 4,096 node.
Although re-measurements on Linux in 2021 are not stable andworse than what measured in 2019 on larger node count morethan 1,024, we are also able to confirm McKernel realized noise lessand stable measurement in addition to performance improvement
on GeoFEM. In most case, McKernel provided better performance
especially on large node count even if compared with 2019 Linux
results. Especially for 2,048 and 4,096 nodes, we got 20% and 6%
improvements, respectively.
Furthermore, we have modified McKernel for asynchronous
progress control and applied to real GeoFEM applications. From 128
node to 512 nodes, at least, we are able to see performance improvement by the combination of McKernel and asynchronous progresscontrol. Though the effect is limited up to 1,024 node counts, we
got at most 2-3% performance improvement from 128 node.
Work is ongoing and it is expected that we will run these performance experiments again after whole system tuning on Linuxand McKernel to address the 2021 year’s performance degradation
than that of 2019. In the case of physical 4 cores allocation to IHK
kernel for asynchronous progress control on McKernel will also be
a future work. Furthermore, to investigate an effect on SMT threads
more could lead to efficient use of asynchronous progress control
for more MPI ranks per node or pure MPI parallelism situation
without OpenMP threading.

ACKNOWLEDGMENTS
This work is supported by JSPS Grant-in-Aid for Scientific Research(S) (19H05662), and by Joint Usage/Research Center for Interdisciplinary Large-scale Information Infrastructures (jh20037-NAH, jh20041NAH). Authors would like to thank Yoshio Sakaguchi, Nobuteru
Mizoe and Toshiro Saiki from Fujitsu.

[3] Nakajima, K., Parallel Iterative Solvers of GeoFEM with Selective Blocking Preconditioning for Nonlinear Contact Problems on the Earth Simulator, ACM/IEEE
Proceedings of SC 2003, 2003
[4] Joint Center for Advanced High Performance Computing (JCAHPC): http://jcahpc.
jp/[5] Nakajima, K., Gerofi, B., Ishikawa, Y., Horikoshi, M., Parallel Multigrid Methods
on Manycore Clusters with IHK/McKernel, IEEE Proceedings of 10th Workshop
on Latest Advances in Scalable Algorithms for Large-Scale Systems (ScalA 2019)
in conjunction with SC19, Denver, CO, 2019[6] Nakajima, K., Gerofi, B., Ishikawa, Y., Horikoshi, M., Efficient Parallel Multigrid
Method on Intel Xeon Phi Clusters, ACM Proceedings of IXPUG HPC Asia 2021,
2021[7] Taku Shimosawa, Balazs Gerofi, Masamichi Takagi, Gou Nakamura, Tomoki Shirasawa, Yuji Saeki, Masaaki Shimizu, Atsushi Hori and Yutaka Ishikawa, Interface
for Heterogeneous Kernels: A Framework to Enable Hybrid OS Designs targeting
High Performance Computing on Manycore Architectures, 21th Intl. Conference
on High Performance Computing HiPC, 2014[8] Balazs Gerofi, Akio Shimada, Atsushi Hori and Yutaka Ishikawa, Partially Separated Page Tables for Efficient Operating System Assisted Hierarchical Memory
Management on Heterogeneous Architectures, 13th Intl. Symposium on Cluster,
Cloud and Grid Computing CCGRID, 2013[9] Balazs Gerofi, Masamichi Takagi, Atsushi Hori, Guo Nakamura, Tomoki Shirasawa
and Yutaka Ishikawa, On the Scalability, Performance Isolation and Device Driver
Transparency of the IHK/McKernel Hybrid Lightweight Kernel, IEEE International
Parallel and Distributed Processing Symposium IPDPS, 2016[10] Gerofi, B, Riesen, R., Takagi, M., Boku, T., Nakajima, K., Ishikawa, Y., Wisniewski,
R.W., Performance and Scalability of Lightweight Multi-kernel Based Operating
Systems, IEEE Proceedings of IPDPS 2018, 116-125, 2018[11] Saad, Y., Iterative Methods for Sparse Linear Systems (2nd Edition), SIAM, 2003[12] Smith, B., P. Bjostad, and W. Gropp, Domain Decomposition, Parallel Multilevel
Methods for Elliptic Partial Differential Equations, Cambridge Press, 1996[13] Demmel, J., Hoemmen, M., Mohiyuddin, M., Yelick, K., Avoiding communicationin sparse matrix computations, IEEE Proceedings of 22nd International Symposium
on Parallel and Distributed Processing, 2008 (IPDPS 2008), 2008[14] Nakajima, K.and Ogita, T., Evaluations of Stability of Parallel Conjugate Gradient
Methods based on Pipelined Algorithmss, IPSJ SIG Technical Reports 2018-HPC167-26 (in Japanese), 2018[15] Chronopoulos, A.T. and Gear, C.W., s-Step iterative methods for symmetric linear
systems. Journal of Computational and Applied Mathematics. v25 i2. 153-168[16] Hanawa, T., Nakajima, K., Ohshima, S., Hoshino, T., Ida, A., Performance Evaluation of Pipelined CG Method, IPSJ SIG Technical Report, Vol.2016-HPC-157, No.6,
2016 (in Japanese)[17] Supercomputing Research Division, Information Technology Center, The University of Tokyo (ITC/U.Tokyo): http://www.cc.u-tokyo.ac.jp/[18] Gropp, W., Update on libraries for blue waters, https://wgropp.cs.illinois.edu/bib/talks/tdata/2011/Stream-nbcg.pdf[19] Horikoshi, M., Nakajima, K., Gerofi, B., Ishikawa, Y., Parallel Preconditioned
Itertative Solvers on Oakforest-PACS, 28th Seminar of MEPA (Algorithms for
Matrix / Eigenvalue Problems and their Applications, JSIAM (Japan Society for
Industrial and Applied Mathematics)), 2019[20] STREAM Benchmark: https://www.cs.virginia.edu/stream/[21] Amit Ruhela, Hari Subramoni, Sourav Chakraborty, Mohammadreza Bayatpour,
Pouya Kousha and Dhabaleswar K.(DK) Panda, Efficient design for MPI asynchronous progress without dedicated resources, Parallel Computing 85,13-26, 2019[22] Horikoshi, M., Meadows L., Elken T., Sivakumar P., Mascarenhas, M., Erwin J.,
Durnov D., Sannikov A., Hanawa T., Boku, T., Scaling collectives on large clusters
using Intel(R) architecture processors and fabric, ACM Proceedings of IXPUG
HPC Asia 2018, 2018[23] Hoefler T., Kambadur P., Graham R.L., Shipman G., Lumsdaine A. (2007) A Casefor Standard Non-blocking Collective Operations. In Recent Advances in Parallel
Virtual Machine and Message Passing Interface. EuroPVM/MPI 2007. Lecture
Notes in Computer Science, vol 4757. Springer, Berlin, Heidelberg[24] Alexandre Denis, Julien Jaeger, Hugo Taboada, Progress Thread Placement forOverlapping MPI Non- Blocking Collectives using Simultaneous Multi-Threading.
COLOC: 2nd workshop on data locality, in conjuction with Euro-Par 2018, 2018[25] Sebastian Ohlmann, Fabio Baruffa, Markus Rampp, Overlapping communication and computation using the Intel MPI library’s asynchronous
progress control, IXPUG Meeting 2020, https://www.ixpug.org/resources/
overlapping-communication-and-computation-using-the-intel-mpi-library-sasynchronous-progress-control

REFERENCES[1] Intel’s Asynchronous Progress Control: https://www.intel.com/content/www/
us/en/develop/documentation/mpi-developer-guide-linux/top/additionalsupported-features/asynchronous-progress-control.html[2] Ghysels, P. and W. Vanroose, Hiding global synchronization latency in the preconditioned Conjugate Gradient algorithm, Parallel Computing 40-7, 224-238,
2014

スーパーコンピューティングニュース- 104 -

Vol. 24, No.3

2022

Exploring Communication-Computation Overlap in Parallel
Iterative Solvers on Manycore CPUs using Asynchronous Progress Control

HPCAsia 2022 Workshop, January 11–14, 2022, Virtual Event, Japan

A APPENDIX
A.1 Table of measurement data in 2019

Table 7: Results on Linux (measured in 2019). Alg. 3i and
4i used asynchronous progress threads while others did notuse. From 128 to 4,096 nodes.
128
256
512
1024
2048
4096

Alg.1 [sec]1.39E+01
9.21E+00
6.37E+00
5.00E+00
4.51E+00
4.50E+00

Alg.2 [sec]1.37E+01
9.01E+00
6.10E+00
4.69E+00
4.16E+00
4.03E+00

Alg.3 [sec]1.42E+01
9.34E+00
6.24E+00
4.75E+00
4.22E+00
4.91E+00

Alg.3i [sec]1.38E+01
9.01E+00
5.95E+00
4.49E+00
3.89E+0
4.14E+00

A.2

Tables of measurement data in 2021

Alg.4 [sec]1.42E+01
9.39E+00
6.40E+00
4.91E+00
4.58E+00
4.55E+00

Alg.4i [sec]1.34E+01
8.47E+00
5.33E+00
3.93E+00
3.41E+00
3.29E+00

Table 8: Results on Linux (measured in 2021). Alg. 3i and
4i used asynchronous progress threads while others did notuse. From 128 to 4,096 nodes.
128
256
512
1024
2048
4096

Alg.1 [sec]1.39E+01
9.15E+00
6.49E+00
4.91E+00
5.09E+00
3.60E+00

Alg.2 [sec]1.38E+01
9.06E+00
6.24E+00
4.68E+00
4.74E+00
3.34E+00

Alg.3 [sec]1.43E+01
9.35E+00
6.43E+00
4.80E+00
4.82E+00
3.36E+00

Alg.3i [sec]1.42E+01
9.58E+00
6.78E+00
5.50E+00
6.88E+00
6.33E+00

Alg.4 [sec]1.43E+01
9.47E+00
6.56E+00
4.88E+00
5.05E+00
3.54E+00

Alg.4i [sec]1.35E+01
8.92E+00
6.08E+00
4.79E+00
6.27E+00
5.89E+00

Table 9: Results on McKernel (measured in 2021). Alg. 3i and
4i used asynchronous progress threads while others did notuse. From 128 to 4,096 nodes.
128
256
512
1024
2048
4096

Alg.1 [sec]1.38E+01
9.01E+00
5.96E+00
4.45E+00
3.91E+00
3.56E+00

Alg.2 [sec]1.36E+01
8.81E+00
5.77E+00
4.29E+00
3.68E+00
3.16E+00

Alg.3 [sec]1.40E+01
9.10E+00
5.96E+00
4.44E+00
3.66E+00
3.14E+00

スーパーコンピューティングニュースAlg.3i [sec]1.40E+01
9.32E+00
6.24E+00
4.78E+00
4.00E+00
3.99E+00

Alg.4 [sec]1.40E+01
9.20E+00
5.99E+00
4.52E+00
3.82E+00
3.36E+00- 105 -

Alg.4i [sec]1.37E+01
8.95E+00
5.85E+00
4.43E+00
4.13E+00
3.99E+00

Vol. 24, No.3

2022

科学技術計算Ⅱ／コンピュータ科学特別講義Ⅱ／ハイブリッ
ド分散並列コンピューティング：「並列有限要素法入門」
（オン
ライン）
中島研吾
東京大学情報基盤センター
本稿では，2021 年度冬学期に実施した，科学技術計算 II（大学院情報理工学系研究科数理情報学専攻）／コンピュータ科学アライアンス特別講義 II（同 コンピュータ科学専攻）／ハイブ
リッド分散並列コンピューティング（大学院工学系研究科電気系工学専攻）「並列有限要素法入門」1について紹介する。
「新型コロナウイルス感染症」のため，前年度に引き続き，全ての講義を Zoom によるオンラインで実施した。
2014 年度までは，夏学期，冬学期に，科学技術計算 I・II／コンピュータ科学特別講義 I・II
「科学技術計算プログラミング（有限要素法）」2を実施してきた。偏微分方程式の数値解法として，様々な科学技術分野のシミュレーションに使用されている有限要素法（Finite-Element
Method，FEM）について，背景となる基礎的な理論から，実用的なプログラムの作成法まで，連立一次方程式解法などの周辺技術も含めて講義を実施し，プログラミングの実習を実施してきた。題材としては一次元及び三次元弾性静力学を扱い，プログラミング言語としては C 言語を使用していた。夏学期（I）と冬学期（II）に分けて，夏学期は有限要素法の理論とプログラ
ミングの基礎，冬学期はその並列化についての講義・実習を行い，冬学期は東大情報基盤セン
ターのスーパーコンピュータを使った実習を実施してきた。2011 年度までは T2K 東大を使用していたが，2012 年度からは Fujitsu PRIMEHPC FX10（Oakleaf-FX，2012 年 4 月運用開始），
2016 年度からは「データ解析・シミュレーション融合スーパーコンピュータシステム（Reedbush）3」のうち，汎用 CPU（Intel Broadwell/EP）のみから構成される Reedbush-U（2016年 7 月運用開始）を使用してプログラミング実習を実施してきた。更に，2019 年度冬学期から
は，「大規模超並列スーパーコンピュータシステム（Oakbridge-CX，OBCX）4」を使用している。OBCX は 2019 年 7 月に運用を開始し，各々2 基の Intel Xeon Platinum 8280 から構成される計算ノードを 1,368 ノード搭載している。
2014 年度までの講義では，冬学期（Ⅱ）の履修は夏学期（Ⅰ）の履修を前提としていたが，昨今の大学の国際化に伴い，10 月に入学する留学生が増加しており，そのような条件を満たさない履修者が増えてきた。そこで 2015 年度からは，方針を変更し，両者をある程度独立した科
目として履修できるよう：

夏学期（Ⅰ）：計算ノード内のマルチスレッド並列化に関する内容5

冬学期（Ⅱ）：分散並列環境における並列化に関する内容

1

http://nkl.cc.u-tokyo.ac.jp/21w/
http://nkl.cc.u-tokyo.ac.jp/14s/, http://nkl.cc.u-tokyo.ac.jp/14w/
3
https://www.cc.u-tokyo.ac.jp/supercomputer/reedbush/service/4
https://www.cc.u-tokyo.ac.jp/supercomputer/obcx/service/5
http://nkl.cc.u-tokyo.ac.jp/21s/
2

スーパーコンピューティングニュース-- 1106- -Vol. 24, No.32022

のように実施することとした。留学生の受講，国際化に配慮して英語版教材のみを提供するとともに，2017 年度からは英語で講義を実施している。
表 1 に講義日程と内容を示す。上記のように，様々な分野で広く利用されている有限要素法を題材とし，一次元・三次元定常熱伝導方程式を扱った。一次元・三次元有限要素法，MPI（Message Passing Interface）による並列プログラミング，並列要素法の順番で講義・演習を実施した。また，ハイブリッド並列プログラミングモデルの重要性を考慮して，MPI＋OpenMP
ハイブリッド並列プログラミングに関する講義・演習を実施した。MPI による並列有限要素法のプログラムの各プロセスに OpenMP を適用して並列化を実施した。
登録者は 35 名（うち 17 名が留学生），オンラインということもあり常時出席者は 25 名程度，単位を取得したのは 19 名（留学生 11 名）であった。2020 年度は登録者 36 名，単位取得者12 名であったのに比べると，単位取得者の割合は増加している。

表 1：講義日程，内容

Date

Time

Title

1

Oct.06(W)0830-1015 Introduction, Introduction to FEM (1/2)

2

Oct.13(W)0830-1015 Introduction to FEM (2/2), 1D/3D FEM (1/4)

3

Oct.20(W)0830-1015 1D/3D FEM (2/4)

4

Oct.27(W)0830-1015 1D/3D FEM (3/4)

5

Nov.03 (W)0900-1015 1D/3D FEM (4/4)

6

Nov.10 (W)

0830-1015 Introduction to Parallel FEM, Login to OBCX, MPI (1/5)

7

Nov.17 (W)0830-1015 MPI (2/5)

8Nov.24 (W)0830-1015 MPI (3/5)

9Dec.01 (W)0830-1015 Report S1, MPI (4/5)

10 Dec.08 (W)0830-1015 MPI (5/5)

11 Dec.15 (W)0830-1015 Report S2, Parallel FEM (1/4)

12 Dec.22 (W)0830-1015 Parallel FEM (2/4)

13 Jan.05 (W)0830-1015 Parallel FEM (3/4)

Jan.12 (W)(No Class)

14 Jan.17 (M)0830-1015 Parallel FEM (4/4), Hybrid OpenMP/MPI (2/3)

15 Jan.19 (W)0830-1015 Hybrid OpenMP/MPI (2/3)

16 Jan.26 (W)0830-1015 Hybrid OpenMP/MPI (3/3)

スーパーコンピューティングニュース- 2 -- 107

Vol. 24, No.3

2022

教育活動報告：&RPSXWDWLRQDO(DUWKTXDNH(QJLQHHULQJ計算地
震工学 (
市村強・藤田航平
東京大学地震研究所
 本稿では、 年度 $ セメスターに実施した、&RPSXWDWLRQDO (DUWKTXDNH (QJLQHHULQJ計
算地震工学 (（工学系研究科・社会基盤学専攻大学院生、工学部・社会基盤学科学部  年生対象、
月・木  限#オンライン講義、英語で実施）について紹介する。本講義では、地震工学分野における数値計算に焦点を当てた数値解析の基礎的な知識の習得を目的に、数値関数展開（有限差分法・有限要素法）、時間積分、数値積分、線形方程式の求解手法、及び、高性能計算 6,0' に関する座学・演習を行った（表１参照）。本講義は例年、座学部分は工学部  号館、実習部分は情報基盤センターの大演習室においてそれぞれ対面で行い、実習における計算機環境として教育用計算機システム (&&6 を用いてきたが、本年度においては昨年度に引き続き座学・実習ともにオンライン =RRP で行い、実習における計算機環境として情報基盤センターの 2DNEULGJH&; を教育利用させて頂いた。評価は例年通りレポートの評点で行った。対面の演習において学生の画面を見つつ個別の議論が可能であった状況を再現できるよう、オンライン演習においては =RRP のブレイクアウトセッションを活用し、また、講義時間外の質問受付時間 =RRP を数回設定するな
ど、個々の学生の理解に応じた個別の議論ができる体制を取った。数値計算・高性能計算に馴染みのない受講生でも自宅にいながら数値計算・高性能計算に少しでも興味を持ってもらえる機会を提供したと考えられ、将来のこの分野の人材育成につながると期待される。

表 講義日程
回数

日付

形式

内容



 座学 

導入





座学 

有限差分法・数値解の収束性





座学 

 次元有限要素法、動的・静的問題

 実習 

実習環境説明 座学 

時間積分・クーラン条件 座学 

吸収境界条件・ 次元有限要素法・ドロネー分割

 座学 

数値積分、共役勾配法、前処理 実習 

レポート   次元有限要素法 





実習 

レポート   次元有限要素法 





実習 

レポート   次元有限要素法・ドロネー分割 





実習 

レポート  6,0' 演習 





実習 

レポート   次元動的有限要素法・吸収境界条件 うち、 次元動的有限要素法





実習 

レポート   次元動的有限要素法・吸収境界条件 うち、吸収境界条件

スーパーコンピューティングニュース
- 108 -

Vol. 24, No.3

2022

第 173 回お試しアカウント付き並列プログラミング講習会
OpenMP によるマルチコア・メニィコア並列プログラミング入門（Wisteria/BDEC-01（Odyssey，A64FX 搭載））（オンライン）中島研吾
東京大学情報基盤センター
本稿では，2022 年 3 月 9 日（水）にオンライン開催した第 173 回お試しアカウント付き並列
プログラミング講習会「OpenMP によるマルチコア・メニィコア並列プログラミング入門（Wisteria/BDEC-01（Odyssey，A64FX 搭載））1」（共催：東京大学情報基盤センター、PC クラ
スタコンソーシアム（実用アプリケーション部会・HPC オープンソースソフトウェア普及部会））について紹介する。
東京大学情報基盤センター（以下，本センター）では 2007 年からスーパーコンピュータを使用した「お試しアカウント付き並列プログラミング講習会」を開催しているが，新型コロナウ
イルス感染症対策のため，2020 年 4 月からは全ての講習会を Zoom 使用による「オンライン」
講習会として実施している。
「OpenMP によるマルチコア・メニィコア並列プログラミング入門」
は，オンラインとなってから，第 131 回（2020 年 4 月 27 日），第 143 回（2020 年 11 月 2 日），
第 151 回（2021 年 4 月 21 日）と 3 回，Oakbridge-CX（OBCX）2を使用して実施してきた。2019年度までは 2 日にわけて実施していたものを，2020 年度からは 1 日にまとめて実施している。
近年マイクロプロセッサのマルチコア化が進み，様々なプログラミングモデルが提案されている。中でも OpenMP は指示行（ディレクティヴ）を挿入するだけで手軽に「並列化」ができるため，広く使用されており，様々な解説書も出版されている。メモリへの書き込みと参照が同時に起こるような「データ依存性（data dependency）」が生じる場合に並列化を実施するには，
適切なデータの並べ替えを施す必要があるが，このような対策は OpenMP 向けの解説書でも詳しく取り上げられることは余り無い。第 151 回以前の講習会では，「有限体積法から導かれる疎行列を対象とした ICCG 法」を題材として，科学技術計算のためのマルチコアプログラミングにおいて重要なデータ配置，reordering などのアルゴリズムについての講義，スパコンを使用した実習を実施した。内容は筆者が本学大学院工学系研究科・情報理工学系研究科の講義として実施している「計算科学アライアンス特別講義Ⅰ」，「科学技術計算Ⅰ」，「スレッド並列コンピューティング」の内容に準拠している3。本来であれば 105 分×10 回程度の講義の内容を 1 日（正味 7.5 時間（450 分）程度）に圧縮しての内容となっているため，アンケートでも「1 日に詰め込む内容としては項目が多すぎる」が散見され，第 151 回のアンケートでは満足度が 3.73
（満点 5.00）と比較的低い値となった。
2021 年度からは，2021 年 5 月 14 日に運用を開始した Wisteria/BDEC-01（Odyssey）4導入に合わせて内容を一新し，データ依存性に関連した内容を完全に削除したカリキュラムを策定した。大体 105 分の講義にして 4 回程度の内容であり，1 日，450 分程度で実施するには手頃な量1

https://www.cc.u-tokyo.ac.jp/events/lectures/173/
https://www.cc.u-tokyo.ac.jp/supercomputer/obcx/service/3
http://nkl.cc.u-tokyo.ac.jp/20s/
4https://www.cc.u-tokyo.ac.jp/supercomputer/wisteria/service/2

スーパーコンピューティングニュース- 109 -

Vol. 24, No.3

2022

であった。また，Wisteria/BDEC-01（Odyssey）に搭載されている A64FX についても詳細な解説を実施した。内容もやや簡単になったため，満足度も高めとなったことから，今回もこの路線を踏襲した。
運用開始から 1 年近くが経過し，5 月の時点では性能にやや問題があった C コンパイラの性能等も改善された。また性能評価のための詳細プロファイラの使用法など新たな項目を追加するなど，内容としては前回と比較して充実したものとなった。
合計 14 名の参加申込みがあり，受講者は 10 名（大学・研究機関教職員：2，大学院生：2，
学部生：4，企業：1）であった。アンケート結果（回収 9 名）について表 2 に示す。平均満足度は 4.44 と高めであった。
表 1 本講習会の概要
09：00-11：00

有限体積法

11：00-12：30

OpenMP 入門

13：30-16：00

オーダリング

16：00-17：30

OpenMP 並列化

17：30-18：00

質疑

表 2 アンケート集計結果
評点

1

2

3

4

2

4

3

（a）講習会時間

短い⇔長い（b）講習会講義内容（プレゼン）

簡単⇔難

7

2

（c）配布資料内容

簡単⇔難

8

1

（d）サンプルプログラム内容

簡単⇔難

7

2

（e）満足度（平均 4.44）

不満⇔満足

5

5

4

講義内容の詳細については，ウェブページから資料及び録画ビデオをダウンロードできるのでそちらを参照いただきたい（https://www.cc.u-tokyo.ac.jp/events/lectures/173/）。また，
従来実施していたデータ依存性を含むケースについては，3 日にわけてプログラムを再編成し，10 月以降に実施する予定である。

スーパーコンピューティングニュース- 110 -

Vol. 24, No.3

2022

第 174 回お試しアカウント付き並列プログラミング講習会
一日速習：有限要素法プログラミング徹底入門（オンライン）
中島研吾
東京大学情報基盤センター
本稿では，2022 年 4 月 14 日（木）にオンライン開催した第 174 回お試しアカウント付き並列
プログラミング講習会「一日速習：有限要素法プログラミング徹底入門1」（共催：東京大学情報
基盤センター、PC クラスタコンソーシアム（実用アプリケーション部会・HPC オープンソース
ソフトウェア普及部会））について紹介する。
有限要素法（Finite Element Method，FEM）は偏微分方程式の数値解法として，様々な科学技術
計算に使用されている。基礎的な研究開発の他，NASTRAN に代表される有限要素法による商用コードも既に半世紀近く産業利用も含む様々な分野で設計・安全評価などに使用されている。有限要素法は要素単位のローカルな演算から構成されているところから，並列化が比較的容易であることが知られている。
本センターでは，本センターのスーパーコンピュータの利用促進と並列プログラミング技術の普及を目的として，様々な並列有限要素法の講習会2 を実施してきた。
有限要素法の理論，手法は大学教養程度の数学，物理の知識があれば充分に理解できるものであるが，並列化を実施するためには，単に個々の事項の理解に留まらず，数学的背景，数値アルゴリズムとプログラミングを結びつけて理解している必要がある。有限要素法そのものと並列化
を 1 日で全て解説するのは，スケジュール的にも困難で，細かいところは省略せざるを得ないた
め，受講者にとっても消化不良となる傾向があった。
本センターでは，2020 年 6 月 12 日に第 134 回講習会3で，初めての試みとして，並列化には立ち入らず，スパコンを使用したハンズオンも実施せず，有限要素法を構成する基礎的な理論，数値アルゴリズムとその実装に主眼を置いた講習会を 1 日で実施したところ，比較的好評であり需要が高いことも確認できた。その後，2020 年 11 月 10 日，2021 年 12 月 21 日に同様の内容で第 145 回4・第 171 回5講習会を実施し，今回はそれらのフィードバックから得られた知見も踏まえ，更に改良した詳細な教材を提供した。
本講義の内容（表 1）は 2021 年度冬学期に講義として実施した，科学技術計算 II（大学院情報理工学系研究科数理情報学専攻）／コンピュータ科学アライアンス特別講義 II（同 コンピュータ科学専攻）／ハイブリッド分散並列コンピューティング（大学院工学系研究科電気系工学専攻）「並列有限要素法入門」6 の導入部と同じ内容を日本語で実施したものであり，最初の「有限要素法入門7」については，時間の都合もあり，受講者に教材を予習してもらい，当日は簡単な説明に留めた。
1

https://www.cc.u-tokyo.ac.jp/events/lectures/174/
https://www.cc.u-tokyo.ac.jp/events/lectures/116
3
https://www.cc.u-tokyo.ac.jp/events/lectures/134/4
https://www.cc.u-tokyo.ac.jp/events/lectures/145/5https://www.cc.u-tokyo.ac.jp/events/lectures/171/6
http://nkl.cc.u-tokyo.ac.jp/21w
7
http://nkl.cc.u-tokyo.ac.jp/FEM/01-FEMintro.pdf
2

スーパーコンピューティングニュース- 111 -

Vol. 24, No.3

2022

今回は，前述のようにスパコンは利用せず，各自の PC に一次元・三次元有限要素法プログラム（Fortran・C）をダウンロードしてもらい，数学的・理論的な背景から，実問題（定常熱伝導）まで，実習も交え，大規模連立一次方程式の反復解法（前処理付き共役勾配法）も含めて解説した。詳細はホームページ（https://www.cc.u-tokyo.ac.jp/events/lectures/174/）を参照されたい。
当日利用した資料，サンプルプログラムの他，録画したビデオを見ることもできる。
09：00-09：45

表 1 本講習会の概要

13：30-16：00

一次元有限要素法

17：00-17：15

並列有限要素法への道

09：45-12：30

有限要素法入門

16：00-17：00

三次元有限要素法
討論・質疑等

事前登録者は 11 名，出席者は 7 名（学生：2 名，大学・研究機関：3 名，企業：2 名）となった。講習会終了後にアンケートを実施した（回収本数：4）。全体的な満足度の平均値は 5 点満点
で 4.75 となった。オンライン講習会も大分定着してきており，気軽に参加できるということで概して好評である。当日は，学内ネットワークのトラブルで 10 分ほどの中断を余儀なくされる
時間帯があったが，急遽スマートフォンによるテザリングに切り替えた。受講者の皆さんにご迷惑をおかけしたこと，この場を借りてお詫び申しあげる次第である。
アンケートの自由記述欄のコメントを以下に示す：



丁寧に説明いただきありがとうございます。有限要素法の並列計算の講習会にも日程の都合がつけば出てみたいと思います。



今後もオンラインで開催していただけると参加しやすいです。
サンプルプログラムの説明を詳細にしていただいて，FEM の理論とプログラムの対応が理解しやすかった。

スーパーコンピューティングニュース- 112 -

Vol. 24, No.3

2022

第 175 回お試しアカウント付き並列プログラミング講習会「スーパーコンピュータ超入門」
芝隼 人

東京大学情報基盤センター
2022 年 4 月 22 月に、第 175 回お試しアカウント付き並列プログラミング講習会「スーパーコ
ンピューター超入門」（共催：東京大学情報基盤センター、PC クラスタコンソーシアム（実用アプリケーション部会・HPC オープンソースソフトウェア普及部会））を開催したので、本稿にてその実施報告を行う。
東京大学情報基盤センターにおいて「超入門」と題した講習会は、2020 年 9 月 18 日（第 138回）以来３回にわたっておよそ半年おきに実施しており、いずれも好評を博している。以前より
Linux の簡単な操作・ログインなどの事柄から始めてスーパーコンピュータを用いるための基本を学ぶ講義及び実習を行ってきたが、今回は内容について少し見直して、機械学習をスーパーコ
ンピュータで行うためのチュートリアルを追加した。アジェンダは次の通りであるが、後半の「より進んだ利用に向けて」は、今回は時間の不足で結果として取り扱うことができなかった。
13:00 – 14:00 ガイダンス・初めてのログイン（講義・実習）
14:15 – 15:45 サンプルプログラムによる並列計算超入門（講義・実習）
16:00 – 17:00 スパコンにおける機械学習実行超入門（講義・実習）より進んだ利用に向けて（講義）申込受付時にいずれの言語を使用するかのアンケートを行っているが、今回参加申込のあった22 名での内訳は次の通りとなった。
・FORTRAN

8名

・C/C++

4名

・Python

10 名

通常通り、地球惑星科学や機械系、物理学など、科学技術計算分野への従来的なスパコン利用分
野からの参加が多かったようである。一部の参加者は、これら分野での研究活動を行う中で機械学習などへの応用を考えていると見られ、このことが、Python の選択者の多さに現れていると見受けられる。
今回は、事前に日本語が得手でない、という参加者２名から個別に問い合わせをいただいた。
今回は既に日本語での講習会の開設をアナウンスしていたため、講義については日本語で行うことを伝えた上で、ページ数を揃えた英語版の同内容の資料を用意しお渡しすることで対応した。
演習に際しては日本語でのやりとりのほか、必要に応じて英語による説明を挟む形とした。
次の表１には、受講者からのアンケートの結果の集計を示す。当日の出席者数は 19 名であったが、当日参加者のうち 17 名から回答をいただくことができた。

スーパーコンピューティングニュース- 1 -- 113

Vol. 24, No.32022

表１ アンケート集計結果
評点

1

2

3

4

(a) 講習会時間

短い⇔長い

1

15

1

(b) 講習会講義内容

簡単⇔難

6

5

6

(c) 配布資料内容

簡単⇔難

8

2

7

(d) サンプルプログラム内容

簡単⇔難

8

2

7

(e) 参加した満足度

不満⇔満足

1

3

2

5

11

同じシリーズの以前 3 回におけるアンケート結果と異なる傾向として、(b)(c)(d)の項目について内容が「簡単である」という側に回答が偏っている。かなりの割合の参加者は、本講習会のうち、スパコンでの機械学習実行についてのチュートリアルが追加されたことをきっかけに申し込んでおり、結果として以前の回と異なる層の参加者があったようである。今回のような参加者の構成であれば、Linux におけるコマンドの使用、公開鍵認証などの項目については不要であったかもしれない。
アンケートの自由記述欄には次のような意見が寄せられた。
・ 機械学習のチュートリアルまであったのは有難かった。
・ とても分かりやすく、自身の教育活動にも役に立ちそうです。
・ 今後、有限要素法や線形計算の並列化についての講習が開催されれば参加したい。
・ Oakbridge-CX にインストールされている Quantum Espresso の使用を検討しているので、ジョブ投入の仕方の説明が利用支援ポータルにあるとありがたい。
・ スパコン初心者の私が知りたい内容で、解説もとても理解しやすかったです。講習中だ
けでなく講習後にも質問時間をいただき、疑問についても自身の経験をふまえて親身に教えていただきました。
・ 複数のプログラム言語を使っていて煩雑になっていた。
また、Zoom によるオンライン開催については次のような感想が寄せられた。
・ リアルタイムで演習を交えながら、スパコンに関する講義を受ける事ができました。
・ オンラインなので参加しやすい。
・ リアルタイムで演習を交えながら、スパコンに関する講義を受ける事ができました・ 移動時間が不要、旅費が不要で大変ありがたい（地方からの参加です）。大型ディスプレ
イで作業ができてやりやすい。
・ Lecturer kindly took the time to answer questions and helped in English as well. Also, the slides
translated into English were very helpful.

・ ターミナル上のエラーを zoom の画面共有ですぐに確認して解決していただくことができて良かった。

スーパーコンピューティングニュース-- 2114- -Vol. 24, No.3

2022

今回は参加者による熱心な質問が随時行われたこと、また英語の説明を並行して行う箇所があったことなどにより、やや時間が押してしまった。担当者自身の講義能力は、経験の蓄積により前回までより部分的に改善したものの、最後のほうがやや駆け足となってしまった。説明がわか
りにくくなるとともに不正確な言い回しが目立つ結果となり、担当者として少し反省を感じている。
当日の講習会は、前回に引き続きビデオ収録を行い、YouTube 上での公開を行った。講義資料
および実習資料と併せて、当センターの第 175 回講習会ホームページ（ https://www.cc.utokyo.ac.jp/events/lectures/175/ ）からアクセスすることが可能である。特に第 3 部の講義はスパコ
ン上での機械学習の環境構築および実行についての説明という点で価値あるものになったと考えている。今後に向けた改善点や要望などをお寄せいただければ幸いである。
次回の同種の講習会は、9〜10 月に実施する予定である。今回の反省内容を踏まえて時間割と内容を再検討したい。今回まで 4 回にわたって、PuTTY かターミナル系か、いずれかを選択してもらっていたが、前者の利用者が減少の傾向にあるようである。これは、Windows 10 以降でコ
マンドプロンプトから容易に OpenSSH が利用可能とな機能が実装されたことが関係していると思われる。この理由から、次回以降 PuTTY のサポートは廃止することにしたいと思う。また、センター利用者についても外国から新たに来られる方々など背景が多様化していることを踏まえて、次回の当該講習会は英語で試行する予定である。内容的には、前回までを踏まえたものとする予定であり、もちろん日本語を通常使われる方々の受講も歓迎したい。

スーパーコンピューティングニュース- 3 -- 115

Vol. 24, No.3

2022‫ॄ ู ߚ ݬ‬ຌࢿͲͺཤ༽ं͹և༹͖Δ͹‫ߚݬ‬Νูॄ͢ͱ͏ΉͤɽҐԾ͹ࣧජགྷߴͶ‫ͱ͏Ͱخ‬౦ߚ͢ͱ͚ͫ͠͏ɽ
ࣧ ජ གྷ ߴ಼༲ͺɼຌιϱνʖ͹ηʖϏʖαϱϒϣʖνʖεητϞ͹ཤ༽ंͶͳͮͱ༙қٝ͵৚ๅ͹఑‫͵ͳڛ‬Ζ‫͢ͳߚݬ‬Ήͤɽ‫ࡎܟ‬Ն൳Ͷͯ͏ͱͺ౲ฦॄҗҽճͲ݀ఈͦ͠ͱ͏ͪͫ͘Ήͤɽ‫ࡎܟ‬Նͳͪ͢౦ߚ‫ߚݬ‬Ͷଲ͢ͱɼՅঈఙਜ਼Νߨ͑͞ͳ͍͗ΕΉͤɽ‫ߚݬ‬ທ਼ͶͺಝͶࢨఈͺ͍ΕΉͦΞ͗ɼεϨʖθͶ෾ׄͤΖ͞ͳ΍͍ΕΉͤɽϕϫήϧϞ͹ࣰྭ͗୉ྖͶ͵Ζ৖߻ʤ֕͸  นΝ௔͓ΖʥͺɼຌชͶͺҲ෨͹ΊΝ‫ى‬फ़͢ɼ౦ߚं͹ :HE Ϙʖζ౵ͶસରΝ‫͢ࡎܟ‬ɼͨ͹ 85/ ΝӀ༽ͤΖΓ͑Ͷ͢ͱ͚ͫ͠͏ɽ‫ߚݬ‬ͺԥॽ͘Ͷ͢ͱ͚ͫ͠͏ɽ‫ߚݬ‬ͺɼ$ γ΢θͲɼϘʖζ͹༪പͺ৏Ծ PPɼࠪӊ PPɼϖρξʖPPɼϓρνʖPP Ͷઅఈ͢ͱ͚ͫ͠͏ɽ৆͚͢ͺ‫༹ࣞߚݬ‬Ν͟ࢂল͚ͫ͠͏ɽ3') ‫ࣞܙ‬ʤϓΧϱφດΌࠒΊʥ͹‫׮‬સ‫ߚݬ‬ΝుࢢϟʖϩͶͱ XNHWVXNH#FFXWRN\RDFMS ΉͲ͟఑ड़‫ب‬
͏Ήͤɽ



ࡀ༽͠Ηͪ‫ߚݬ‬ͺɼຌιϱνʖ͹ :HE ϘʖζͶ‫ͪ͢͏ࡎܟ‬Ήͤɽ
KWWSVZZZFFXWRN\RDFMSSXEOLFQHZVSKS

スーパーコンピューティングニュース- 116 -

Vol. 24, No.3

2022

࠙⦅㞟ࠚ
ࠉࠉᮾி኱Ꮫ᝟ሗᇶ┙ࢭࣥࢱ࣮ࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢸ࢕ࣥࢢ◊✲㒊㛛ࠉࠉᮾி኱Ꮫ᝟ሗࢩࢫࢸ࣒㒊᝟ሗᇶ┙ㄢࢫ࣮ࣃ࣮ࢥࣥࣆ࣮ࣗࢸ࢕ࣥࢢࢳ࣮࣒
ࠉࠉࠉࠉࠉࠉࠉࠉࠌࠉࠉࠉࠉ᝟ሗᡓ␎ㄢ◊✲ᨭ᥼ࢳ࣮࣒࠙Ⓨ⾜ࠚࠉࠉᮾி኱Ꮫ᝟ሗᇶ┙ࢭࣥࢱ࣮ࠉࠉࠛࠉ༓ⴥ┴᯽ᕷ᯽ࡢⴥ
ࠉࠉࠉ㸦㟁ヰ㸧 㸦ࢲ࢖ࣖࣝ࢖ࣥ㸧ࠉࠉࠉ