/
chap-simulationapp.re
219 lines (126 loc) · 22.9 KB
/
chap-simulationapp.re
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
= スパコン用アプリ開発ことはじめ
本書ではアプリ開発に関するさまざまなノウハウや知見が紹介されていますが、スーパーコンピュータ(スパコン)上で実行されるプログラムもまた広義のアプリケーションといえます。
この章ではスパコンにおけるアプリケーションとして一般的に認識されている@<em>{シミュレーションアプリ}の開発について、俯瞰的に・広く浅く紹介できればと思います。
なお今日ではシミュレーションという言葉が包含する領域はきわめて広く、筆者(雛形)の力量ではそれらすべてをカバーすることはできません。
本章では狭義のシミュレーションとして、計算科学分野において実施される、現実世界の物理現象の模擬を目的に実行されるものを取り扱います。
また、執筆にあたってはできる限り最新の事情を反映するよう心がけましたが、日進月歩で発展する領域であることから、すでに時代遅れになっている箇所があるかもしれません。
ご容赦いただくとともに、間違い等あればご指摘いただけますと幸いです。
== スーパーコンピュータ(スパコン)で何をする?
本稿を執筆しているのは2019年11月ですが、毎年11月になるとスパコン情報サイトTOP500 (https://www.top500.org/) において最新のスパコン性能ランキングが発表されます。
ランキングは年2回更新され、執筆時点での最新版である2019年6月のTOP500ランキング@<fn>{lists201906}では、第1位から第500位までの@<em>{すべての}システムでベンチマーク演算性能が1ペタフロップスを超え、名実ともにペタフロップスコンピューティングの時代に突入しました。
国内の動向に目を向ければ、2011年6月のスパコン性能ランキングで1位を獲得し、その後も稼働を続けてきた理化学研究所のスーパーコンピュータ「京(けい)」が2019年8月で運用を終了、それに先立って2019年5月には次世代機の名称が「富岳(ふがく)」に決定されました@<fn>{fugaku}。
これら「京」と「富嶽」はいずれも富士通によるスパコンですが、一方でNECはその手がけてきたスパコンシリーズの最新版「SX-Aurora TSUBASA」について、核融合科学研究所より受注したことを2019年11月に発表しました@<fn>{sxaurora}。
//footnote[lists201906][https://www.top500.org/lists/2019/06/ この注釈を含め、以降のウェブサイトはすべて2019年11月閲覧。]
//footnote[fugaku][ポスト「京」の名称 「富岳(ふがく)」に決定: https://www.riken.jp/pr/news/2019/20190523_1/]
//footnote[sxaurora][NEC、核融合科学研究所から次期スーパーコンピュータシステムとしてSX-Aurora TSUBASAを受注: https://jpn.nec.com/press/201911/20191112_03.html]
そんな話題の尽きないスーパーコンピュータが実際にはどのように使われているのか、スーパーコンピュータ「京」「富嶽」を紹介する理化学研究所 計算科学研究センター (R-CCS) のウェブサイト (https://www.r-ccs.riken.jp/jp/) では、いくつかの利用例が挙げられています。
「スーパーコンピュータ『富嶽』でできること」@<fn>{target}として述べられている9つの重点課題を束ねる大項目を次に引用してみましょう。
//footnote[target][https://www.r-ccs.riken.jp/jp/post-k/target]
* 防災・環境問題
* エネルギー問題
* 産業競争力の強化
* 基礎科学の発展
* 健康長寿社会の実現
そして、課題に対する具体的な取り組み事例として「創薬」「気象予測」「宇宙」「自動車の開発」の4つのテーマが同ウェブサイトで紹介されていますが、これらはいずれも現実世界の現象をより良く理解することが課題解決につながります。
実現象の模倣から課題への理解を深め、また解決につながる新たな知見を得る、そうした活動には時として膨大な計算リソースが必要になることがあります。
スパコンはこうした活動を支えてくれるものであり、そうしたスパコン上で走るアプリケーションのひとつが、現実世界の物理現象を模擬するシミュレーションです。
計算機性能の発達し続ける現代において、シミュレーションによる数値解析は理論や実験と並ぶ「第三の科学」として、その位置づけを確たるものにしています。
理論を構築し、実験をこなすことと同じくらいに、シミュレーションをうまくやることは今後ますます重要になってくるでしょう。
== シミュレーションアプリの特徴
では、スパコン上で走るこうしたシミュレーションアプリは、PCやスマートフォンで動くいわゆる普通のアプリとはどう違うのでしょうか? 筆者なりの考えでは、次の2点が挙げられます。
* 実際の物理法則に即していること
計算科学分野におけるシミュレーションは、現実世界の現象をできるだけ模倣し、それによって現象への理解を促進するために実施されます。そのため、物理法則に則ったうえで実際の挙動を再現することがもっとも重要になってきます。
たとえばシミュレーションの対象でもある流体や火炎の振る舞いについては、イラスト表現@<fn>{MdN246}あるいはエフェクト表現@<fn>{MdN259}に見られるように、種々の誇張表現が視覚的な気持ち良さをもたらしてくれるケースがあります。
しかし物理シミュレーションでは実際をあるがままに再現することが要請されるため、こうした表現が導入されることは原則的にありません。
このように物理法則ファーストであることは、詳しくは後述しますが、アプリのvalidationを難しくする要因のひとつでもあります。
//footnote[MdN246][『MdN 2014年10月号 特集:イラスト表現の物理学』エムディエヌコーポレーション、2014年]
//footnote[MdN259][『MdN 2015年11月号 特集:エフェクト表現の物理学』エムディエヌコーポレーション、2015年]
* 非常に多くの分散メモリ型計算機による並列実行性能が要求されること
前節で述べた課題解決を支えるうえでスパコンは膨大な計算リソースを提供していますが、そうしたリソースは単一のCPU、単一のメモリで実現されるものではなく、非常に多くのCPUとメモリによって構成されています。
すると、これら多数のCPUを効率的に使いこなし、また必要な情報をメモリ間でやり取りすることには、通常のアプリケーションとはまた別の難しさがあり、相応の知見が必要です。
「京」におけるアプリケーションの高並列化・高性能化の詳細については、京のアプリケーション紹介ページ@<fn>{application}が参考になりますが、並列数は82,944ときわめて大きいことがお分かりいただけるかと思います。
これだけ大きな並列数を活かすためには、並列処理できるところは可能な限り並列化し、またそれぞれのCPUの演算負荷ができるだけ等しくなるように工夫することが求められます。
//footnote[application][https://www.r-ccs.riken.jp/jp/k/application.html]
===[column] コラム:実際の並列数はどのくらい?
京のシステム紹介ページ@<fn>{system}によれば、システムの総ノード数は82,944ですが、CPU当たりのコア数が8であるため、コアベースで可能な最大並列数はノード数に8を掛けた約66万という数字になります。
その一方で、システムの全ノードを一度に専有して計算するというのはあまり現実的ではなく、実際にはこの総数を多くの計算で分け合いながら使うこととなります。たとえば前述の重点課題でいえば全部で9つあるため、9課題でリソースを等分するとすれば使えるノード数は9分の1になります。重点課題はさらに3〜4つのサブ課題に分かれており、すると使えるノード数はさらに3分の1、4分の1と減っていきます。
加えて、たいていの計算においては並列数を上げていくと性能は向上するものの、その向上率は徐々に悪化していき、いつかは並列数を上げても性能が向上しない頭打ちの状態になります。このため多数の計算を実施するときには、並列数の大きい計算をひとつずつ実行するよりも、並列数は小さくとも複数の計算を同時並行で実行したほうが、トータルで見た場合の計算時間が短くなる場合もあります。
実際の計算での並列数は、こうした要素を総合的に判断して決定される場合がほとんどです。
//footnote[system][https://www.r-ccs.riken.jp/jp/k/system.html]
===[/column]
== シミュレーションの手順
前節で挙げたR-CCSのアプリケーション紹介ページ@<fn>{application}には、シミュレーションの手順を示した図@<fn>{intro_application_sim_032}が載っています。図中の手順を次に引用してみましょう。
//footnote[intro_application_sim_032][https://www.r-ccs.riken.jp/wp-content/uploads/2015/05/intro_application_sim_032.jpg]
//list[simprocess][シミュレーションをするとき、どんなことが行われているのでしょうか?]{
1. 知りたい現象について、式をたてる。
2. 方程式を、+−×÷の式にする。
3. 解き方(アルゴリズム)を考え、プログラムにする。
4. スーパーコンピュータで計算する!
5. シミュレーション結果。
//}
いわゆるアプリ開発ではデータ構造やプログラム構造の設計とコーディング、実行が主な作業ですが、それらは引用中の手順3と4に相当します。
シミュレーションではこれらに加えて、実際の物理法則に由来する手順1と2、実行結果を解釈する手順5が付帯しています。
以降の項ではこれらの手順をもう少し具体的に眺めていきますが、その前に、一点だけ大事なことを補足させてください;
* @<em>{なぜやるか}
そもそも論として、「@<em>{何のために}このシミュレーションをやろうとしているのか?」ということを、実際にシミュレーションに取り掛かる前によく考え・明確化していただければと思います。
シミュレーションにも数多くの手法があります。実際に取り掛かってみると、どの手法を使えば良いのかにはしばしば頭を悩ませます。
また、シミュレーションでは一般に計算リソースを投下すればするだけ現実味のある結果が得られますが、無限にあるわけではない計算リソースの投入をどこで打ち切れば良いのか、そしてその判断はどうする、といった問題は常について回ります。
もしこうした要素で迷ったなら、そのときは冒頭の問い「@<em>{なぜやるか}」に立ち戻りましょう。
手法を試していくことが目的なのか? デモンストレーションとして解が得られればそれで良いのか、それともそれなりの現実味のある結果でなければならないのか? 現実味のある結果でなければならないならば、その定量性がどれくらい要求されているのか? といった感じです。
なぜやるか、の大元の問いに対してしっかりと答えを持っていれば、それが今の迷いに対してどう対処すれば良いのか、適切な判断を手助けしてくれるはずです。
準備はできましたか? それでは、手順1から5までを追って見ていくことにしましょう。
=== 定式化・離散化(手順1, 2)
まずは知りたい現象について式を立てます。
基礎方程式、もしくは現象を支配するという意味で支配方程式 (governing equation(s)) と呼ばれることもあります。
さきに挙げた京のアプリケーション紹介ページ@<fn>{application}では、種々の計算対象について代表的な方程式が紹介されています。
自分が計算したいと思っている対象に合った方程式を選ぶか、もしくは新たに式を考え出しましょう。
式を考えるうえで大切なのは、現象の本質的な部分だけを上手く取り出すことであり、それは裏を返せば本質でない部分は大胆に切り落とす、ということです。
たとえば佐藤雅昭の著書『なぜあなたの研究は進まないのか?』@<fn>{whyre}で述べられている通り、式(著書の表現では "モデル")にすることで「@<em>{複雑なものをシンプルにするから有益な情報が得られる}」のであって、複雑なものを複雑なままシミュレーションで再現しても(それはそれで手間のかかる作業ですが)、現実世界への理解を促進するという観点ではあまり役に立ちません。
そうではなく、現象の裏に潜むシンプルな本質を見いだすことで、それがたとえ複雑な現象であったとしても、単純な法則を通して理解できるようにする。
定式化(著書の表現では "モデル化")とはそういったことを期待する作業です。
//footnote[whyre][佐藤雅昭『なぜあなたの研究は進まないのか?』メディカルレビュー社、2016年]
式が決まったら、次はコンピュータでも取り扱えるよう四則演算の形にします。
この作業は離散化と呼ばれ、先ほどの京のアプリケーション紹介ページ@<fn>{application}でも、方程式と対応する形で離散化の各手法が紹介されています。
ここで紹介ページの分類表の概要にあるように、それぞれの手法によって得手不得手があり、「計算量を低くおさえることが出来るが通信は増える」であるとか「様々な形状に適合するが、精度を上げることは困難とされる」といった違いがあります。
自分が解きたい問題や得たい結果に合わせて、適切な手法を選択することが重要です。
=== アルゴリズムの検討、コーディング(手順3)
アルゴリズムの検討やプログラムの設計、それにコーディングについては、いわゆる普通のアプリと同様ですので、本書の別章の内容が参考になるでしょう。
シミュレーションアプリ向けのコーディングルールとしては、たとえば気象研究所が過去に策定している標準コーディングルール@<fn>{codingrule}が参考になります。
//footnote[codingrule][https://www.metsoc.jp/tenki/pdf/2002/2002_01_0091.pdf]
書き起こしたコードが一発で想定通りに動くことは少なく、デバッグ作業が必要になるケースがほとんどだと思います。
そもそもコンパイルが通らなかったり、実行できないという場合には、解決の手がかりはエラーメッセージにあります。
エラーメッセージをそのままコピーアンドペーストで検索すれば、やはり同じエラーで苦しめられた先人たちの記録がヒットするケースがほとんどです。
たいていはそれらが直接的な解決策の提示になっているか、あるいは解決のヒントをくれるものと思います。
実行はできても計算ですぐにエラーになる、ということであれば、アプリ実行中の変数の様子を見ていくことが解決への早道です。
単純な方法としてprintデバッグ、そこから踏み込んで各種デバッガの使い方、またコンパイルが必要な言語であれば、デバッグ用のコンパイルオプションを知っておくと便利です。
実行はできて、エラーが出ることなく計算も終了し、計算結果が得られるという状態になったら、計算結果のvalidation作業に移ります。
ここが最も難しいところであり、その難しさは佐藤らの著書『ソフトウェア開発実践』@<fn>{softdev}に端的に指摘されています。
その詳細は書籍に譲ることとして、同書ではvalidationの方法として「@<em>{現実世界で得られる実験結果との比較}」「@<em>{現実世界のシステムに近いようなモデルで視覚化して、人間の目で確認}」などの項目を挙げています。
いずれも現実世界に立脚したやり方であること、それはシミュレーションに対応する実験なり現象なりが現実世界に無い場合には、シミュレーションのvalidationが困難であることを意味しています。
そしてvalidationでの判断は、いわゆる普通のアプリの論理構造のように真偽の二値でわりきれるものではなく、同書で指摘されている通り「@<em>{最終的には人間の判断能力に依存するものが大部分}」である、幅や広がり、グレーゾーンを伴ったものになります。
この良し悪しの勘所を得るためには、現実の実験なり現象なりをよく理解していなければなりません。
すなわち、@<em>{シミュレーションをうまくやるためには、その立脚点である現実世界をより良く知ることが大事}、というわけです。
//footnote[softdev][佐藤文俊、加藤千幸編『ソフトウェア開発実践』東京大学出版会、2015年]
=== 計算の実行(手順4)
簡単なテストケースであれば手元のPCでも出来ますが、本格的な計算となるとちょっと大きなクラスターマシン、もしくはスパコンを利用して計算を実行することになるでしょう。そこでは高速化のために、マシンに合わせたチューニングが必要になる場合もあります。
コンパイルが必要な言語であれば、うまく最適化してやることで計算機の性能を最大限に引き出すことができます。
たとえばインテルコンパイラであれば、ウェブで閲覧可能な「最適化クイック・リファレンス・ガイド@<fn>{intelopt}」が参考になります。
スパコン上でのコンパイラについては、各ベンダーが独自のコンパイラを用意していることが通例ですので、そうしたベンダーが公開している最適化ガイドを参照しましょう。
//footnote[intelopt][https://jp.xlsoft.com/documents/intel/compiler/16/Quick-Reference-Card-Intel-Compilers-v16_JA.pdf]
最適化にあたり注意すべきこととして、前述の最適化クイック・リファレンス・ガイドでも言及されている通り「パフォーマンス・チューニングを開始する前に、/Od (-O0) を使用して@<em>{最適化を行わずにアプリケーションをビルドし、正常に動作することを確認してください}(強調筆者)」。強力な最適化には副作用を伴うものもあり、ときには意図しない動作が起きる可能性もあります。正常でないとおぼしき動作が見られた場合に、それが最適化の過程で生じたものであることをはっきりさせるために、最適化前の動作状況をきちんと確認しておきましょう。
===[column] コラム:スパコンはどうやって使う?
コンピュータとしてのスパコンではなく、事務的な利用手続きの話です。
一般財団法人 高度情報科学技術研究機構が運営するウェブサイトHigh Performance Computing Infrastructure (HPCI) (http://www.hpci-office.jp/) では、全国の大学や研究機関のスパコン、ストレージを一元管理し、それらを必要に応じて提供しています。
スパコンの計算リソースが使いたくなった場合には、このウェブサイトから利用申請を出しましょう。
また、同ウェブサイトにあるイベントのページ@<fn>{hpcievent}では、各種ワークショップの開催情報と、ワークショップでの発表資料が掲載されており、資料ではさまざまなシミュレーションの事例を見ることができます。自分でシミュレーションアプリを開発、実行するにあたっては、こうした資料も参考になると思います。
//footnote[hpcievent][http://www.hpci-office.jp/pages/symposia?parent_folder=492]
===[/column]
=== シミュレーション結果の可視化(手順5)
シミュレーション結果は数字の羅列として与えられるため、これらを何らかの方法で人間にとって理解しやすくすることが必要です。
こうした作業は可視化と称され、たとえば天気予報での雨雲の分布や、雨雲が時間に沿って流れていく様子は可視化のひとつといえます。
可視化は単に絵を作るだけでなく、そこからいかにして新しい発見や情報を得るか、という知識抽出 (knowledge extraction) の側面も含んだ作業であり、ひとつの学問領域にもなっています。
可視化研究の全体像を知るうえで、少し古い資料になりますがIEEEのVisualization and Graphics Technical Communityがまとめた研究レポート@<fn>{nihnsf}が参考になります。現在ではARやVRといった新たな技法も普及しつつあり、そうした技法の可視化における活用が期待されます。
//footnote[nihnsf][http://vgtc.org/sites/vgtc.org/attachments/NIH-NSF-VRC-Report-Final.pdf]
== おわりに
スパコンにおけるアプリケーションとして一般的に認識されているシミュレーションアプリの開発を俯瞰的に解説しました。
普段は見慣れないスパコンがどのように使われているか、いわゆる普通のアプリケーションとの違い、そしてスパコンでのアプリケーションをどのように開発、実行していけば良いのか、本章がその理解の一助となれば幸いです。