計算工学ナビ

ものづくりにHPCを活用するための ツールとケーススタディー

サイト内検索

ABINIT-MP Openシリーズ

abopen00

2018年2月版に関する新しいページがあります

はじめに

logoABINIT-MPは、フラグメント分子軌道(FMO)計算を高速に行えるソフトウェアです[1]。専用GUIのBioStation Viewerとの連携により、入力データの作成~計算結果の解析が容易に行えます。4体フラグメント展開(FMO4)による2次摂動計算も可能です。また、部分構造最適化や分子動力学の機能もあります。FMOエネルギー計算では、小規模のサーバから超並列機の「京」まで対応しています(Flat MPIとOpenMP/MPI混成)。

特徴

ABINIT-MPは使いやすいFMOプログラムで、4体フラグメント展開までが可能です。研究室単位のLinux/Intel系サーバに標準搭載されているMPI環境で動作しますし、特別な設定も必要ありません。また、煩雑で注意深さを要するフラグメント分割を伴う入力データの作成は、随伴GUIのBioStation Viewer(Windowsで動作)を使うなどすれば容易に作成できます。また、フラグメント間相互作用エネルギー(IFIE)などの計算結果は膨大となりプリントからの理解はしばしば困難ですが、Viewerを使うと可視的・直観的に対象系の相互作用の様態を把握できます。

開発の経緯

ABINIT-MPプログラムは、東京大学生産技術研究所を拠点とする「戦略的基盤ソフトウェアの開発」、「革新的シミュレーションソフトウェアの開発」、「HPCI戦略分野4 次世代ものづくり」の一連のプロジェクト(代表:東京大学 加藤千幸教授)、さらにJST-CREST「シミュレーション技術の革新と実用化基盤の構築」(代表:神戸大学 田中成典教授)と立教大学SFR(担当:望月祐志)などの支援を得て、10年以上に渡って開発が進められてきました。Intel Xeon (IA64)系バイナリは、Ver.7が東京大学生産技術研究所の革新的シミュレーション研究センターで、また「京」向けのVer.6+が理化学研究所計算科学研究機構で利用可能となっています(2017年1月時点)。
現在は、東京大学工学研究科を代表拠点とする「フラッグシップ2020 重点課題6」(代表:東京大学 吉村忍教授)の中で、Openシリーズとして機能強化・高速化とリリースが行われています(取り纏め責任者:立教大学 望月祐志)。2016年12月の段階でまとまった第一版がVer. 1 Rev. 5になります。

Open Ver.1 Rev.5 (2016年12月版)の主な機能

Open Ver. 1 Rev. 5はこれまでバイナリで公開してきましたVer. 7に準拠していますが、モデル内殻ポテンシャル(MCP)が追加され、メモリ管理の改良によって動作の安定性が向上しています。

・エネルギー
→ FMO4: HF, MP2 (CD)
→ FMO2: HF, MP2, MP3
・エネルギー微分
→ FMO4: HF, MP2
→ FMO2: MP2構造最適化, MD
・その他機能
→ SCIFIE, CAFI, 重要データ書出し
→ MCP, PB水和, BSSE-CP
→ GUI(BioStation Viewer)
・並列化環境(PC~スパコン)
→ MPI, OpenMP/MPI混成
→ 最深部はBLAS処理

[図を表示]



Open Ver.1 Rev.5 (2016年12月版)の開発者(所属)

望月祐志*(立教大学 理学部), 中野達也(国立医薬品食品衛生研究所 医薬安全科学部), 坂倉耕太(NEC),沖山佳生(国立医薬品食品衛生研究所 医薬安全科学部), 秋永宜伸(ヴァイナス), 渡邊啓正(HPCシステムズ), 加藤幸一郎(みずほ情報総研), 山本純一(NECソリューションイノベータ), 山下勝美(元 NECソフト), 村瀬匡(元 NECソフト), 石川岳志(長崎大学 医歯薬学総合研究科), 古明地勇人(産業技術総合研究所 バイオシステム部門), 加藤雄司(元 立教大学 理学部), 渡辺尚貴(みずほ情報総研), 塚本貴志(みずほ情報総研), 森寛敏(お茶の水女子大学大学院 人間文化創成科学研究科), 田中成典(神戸大学大学院 システム情報学研究科), 加藤昭史(みずほ情報総研), 福澤薫(星薬科大学 薬学部), 渡邉千鶴(理研 横浜)
(*取り纏め責任者)

応用分野

ABINIT-MPのFMO計算は、開発当初から生体分子関係、特にタンパク質とリガンド(薬品分子)の複合系に対して主に用いられてきました。これは、計算で得られるフラグメント間相互作用エネルギーがアミノ酸残基間、あるいはリガンド-アミノ酸残基間の相互作用の状態を理解するのに好適なためです[1]
しかし、FMO計算は生体系に限られるだけでなく、水和凝集系や一般の高分子、あるいは固体なども扱える潜在力を持っています。実際、「フラッグシップ2020 重点課題6」の研究開発活動の中では、有効相互作用パラメータをFMOで求めて高分子の粗視化シミュレーションを行うマルチスケール計算手法と応用が進められています。ABINIT-MPの応用は、今後はこうした一般の化学工学や材料科学、あるいは応用物理関係の分野へも広がっていくことを期待していますし、そのための整備とエビデンスの集積を推進していきます。また、統計的な多構造サンプルの計算結果を機械学習によって自動的に解析する試みも始まっています。

abopen03

Openシリーズの今後のリリース

ABINIT-MPには、主に開発の経緯的な事由から「ローカル版」が存在しています[1]。これらでは、励起エネルギーや動的分極率の算定、さらに結合クラスター展開による高精度エネルギー計算などが利用出来ます。こうした機能に関心を持たれる方も居られますし、手持ちのマシン環境によっては再コンパイルやチューニングのためにソースを所望される場合もあります。こうした状況を改善すべく、「フラッグシップ2020 重点課題6」の研究開発の中で産官学を交えたコンソーシアム的な組織でABINIT-MPのソース共有を行い、継続的なコード開発・改良と保守を図っていく活動の中でリリースされていくのがOpenシリーズです。
2016年度に整備しているOpen Ver.2では、密度汎関数(DFT)のモジュールなどを分子科学研究所の石村和也研究員のSMASHから、また2電子積分の恒等分解(RI)のモジュール(C言語で記述)を長崎大学の石川岳志准教授のPAICSから移植しています。Open Ver. 2のリリースは2017年度内を予定しています。また、Open Ver. 1 Rev. 5をベースにメニーコアのIntel Xeon Phi (Knights Landing)に対応する作業も開始しました。Open Ver. 3では、「ローカル版」の機能も統合して公開とする予定です。BioStation Viewerについても、随時Openシリーズへの対応を図っていきます。

ソースの共有とは別にOpenシリーズでも従来のバイナリでの提供も続ける予定で、以下のようなプラットフォームを対象にしています(2017年1月時点)。

・PC: Wndows 7 (64 bit)
・小規模サーバ: Intel Xeon (IA64) & Xeon Phi (Knights Corner & Landing)
・スーパーコンピュータ: 富士通系{「京」, FX-10, FX-100, OakForest-PACS}

今後、PCではMac、スーパーコンピュータではNEC系のSXも対応していきます。

HPCIセンターでは「京」、東京工業大学TSUBAME、東京大学・筑波大学OakForest-PACSにOpen Ver. 1 Rev. 5が導入される予定です(2016年度内)。

FMO創薬コンソーシアム

2015年度から「FMO創薬コンソーシアム」(代表:星薬科大学 福澤薫 准教授)が産官学で組織され、「京」を計算資源としてABINIT-MPによるFMO計算基づくタンパク質・リガンドの相互作用解析が進められています。重要な創薬ターゲットが設定されており、当該領域の共有基盤となる知見(特にIFIEのデータセット)の蓄積が期待されます。ABINIT-MPはOpenシリーズとして今後も改良が続けられていきますが、このコンソーシアムは実践的な利用者コミュニティとして重要な役割を果たしていくことになります。

開発系コンソーシアム

ABINIT-MPのOpenシリーズの開発や保守にソースレベルでコミットしていただくための産官学枠組みです(コンタクト先:立教大学 望月祐志)。バグ情報と対策、新規開発の機能のシェアなど意図していますが、参画される企業様が商用に独自の高速化や改良を図ることは基本的に可とする方針です。現初期段階では、個別にご参画をお願い・確認させていただいて立上げようとしているところです。今後、このコンソーシアムについても情報を更新していく予定です。

コンタクト

ABINIT-MPのOpenシリーズのご利用、あるいは開発系コンソーシアムにご関心のある方は、立教大学の望月祐志(fullmoon -at- rikkyo.ac.jp)にメールにてご連絡いただければと思います(-at-を@に変換してください)。ご所望の利用形態に応じて、個別に契約書面の取り交わしをさせていただき、ご提供したいと思います。

[1] “Electron-correlated fragment-molecular-orbital calculations for biomolecular and nano systems”, S. Tanaka, Y. Mochizuki, Y. Komeiji, Y. Okiyama, K. Fukuzawa, Phys. Chem. Chem. Phys. 16 (2014) 10310-10344.

Windows10のubuntu互換環境でオープンソース流体ソフトウェアを動かしてみた

東京大学生産技術研究所 革新的シミュレーション研究センター

鵜沢 憲 (uzawa@iis.u-tokyo.ac.jp)

14274439_10208515693423093_1321850254_o

背景

2016年8月3日に提供された64ビット版Windows10のバージョン1607(ビルド番号14393, Anniversary Update)から,Windows上でubuntu互換の実行環境(Windows Subsystem for Linux, 以降WSL)[1],及びシェル(Bash on Ubuntu on Windows, 以降BUW)が使用可能となった.

これまでWindows上で流体ソフトウェアを動かす場合,Windowsのバイナリで提供してもらって実行する,もしくはVMware[2], VirtualBox[3]等の仮想環境やCygwin[4]等のエミュレータでUNIXのバイナリを実行するようなケースがほとんどであろう.

Microsoft社のWSL開発グループによれば,それらの仮想環境と比較して,今回リリースされたWSLは必要とするリソース(CPU, メモリ, ストレージ)が少なくて済むと述べている[5].また,これまでの仮想環境やエミュレータで不便を感じることもあったWindowsとLinuxとの間でのファイルやディレクトリ,コマンドの互換性の問題も回避されている.これらの特徴は,Windowsで流体解析を行う際のハードルが下がる可能性がある.

そこで,試しにオープンソースの流体ソフトウェアをインストールし,流体解析の一連の流れを通じてWSLの使い勝手を調べるともに,簡単なベンチマーク問題を対象に計算性能を評価し,WSLにおける流体解析の可能性を調査することとした.

なお,流体ソフトは文科省フラッグシップ2020プロジェクト重点課題8「近未来型ものづくりを先導する革新的設計・製造プロセスの開発」サブ課題A「設計を革新する多目的設計探査・高速計算技術の研究開発」で開発が進められているFrontFlow/violet-Cartesian(FFV-C)[6]を用いた.FFV-Cは任意のアーキテクチャ対応の性能評価ライブラリPMlib[7]をデフォルトで実装しており,計算終了後に計算時間の測定や計算負荷のホットスポット同定等を検証することができる.

今回,PMlibを利用してWSLでの計算時間や計算性能について調査したところ,いくつか興味深い結果が得られたので,WSLの使用感とともに,まずは第一報としてここに報告する次第である.

WSL及びBUWのインストール及び動作確認

WindowsへのWSL及びBUWの導入手順や不具合,使用感などはこれまでに多く報告されている[8-11].

今回筆者も上記の手順をなぞることにしたが,日頃の行いが悪いのだろう,第一歩目のバージョン1607へのアップデートに失敗してしまった.プリインストールされていたWindows10 HomeにAnniversary Updateをかける度に,途中でフリーズしてしまうのである.頑張って心折れずに調べたところ,システムをSSDに入れているPCにアップデートをかけるとフリーズする場合がある[12] とのことで,今回の原因もどうやらそのようであった.

対処方法として,今回はプリインストールされていたWindows10を完全に削除し,イメージ形式で取得したバージョン1607[13]をUSBからクリーンインストールすることとした.クリーンインストール後は,上記の記事通りになぞることで,無事WSL及びBUWを入手することができた.

インストールが上手くいくと,スタートメニューに「Bash on Ubuntu on Windows」が現れるようになる(図1).インストール時間を正確に測定したわけではないが,感覚的には,従来の仮想環境やエミュレータ環境を構築する場合と比較してはるかに短時間かつ容易に構築することができた.一般的なWindowsアップデートに毛が生えた程度の印象である.

図1Bash on Ubuntu on Windows on スタートメニュー

図1Bash on Ubuntu on Windows on スタートメニュー

クリックすると,普段使っているubuntuと同様のbashが立ち上がった.ubuntuとbashのバージョンは,それぞれ14.04と4.3.11である.(図2)

図2 夢にまで見たWindowsでのbash

図2 夢にまで見たWindowsでのbash

BUWを一通り触り,ネイティブbashと同様の操作感であることを確認.

FFV-Cのインストール及び動作確認

引き続き,流体ソフトウェアのFFV-Cをインストールする.なお,WSLには必要最低限の機能しか入っていないので,FFV-Cの計算やプリ・ポスト処理に必要なソフトウェアやライブラリを予めインストールしておく.

GNUコンパイラ(gcc, g++, gfortran)及びgnuplotのインストール

ネイティブubuntu下と同様に,それぞれsudo apt-get install * とすれば良い.

$ sudo apt-get install build-essential
$ sudo apt-get install gfortran
$ sudo apt-get install gnuplot-x11

(もちろん,まとめてインストールしても良い.)

なお,sudo実行時に「***の名前解決ができません」と出るときは,WindowsのIPアドレスをetc/hostsに記入すれば,毎回怒られずに済む.(図3)

図3 /etc/hosts ファイル

図3 /etc/hosts ファイル

OpenMPIのインストール

FFV-Cは,OpenMPIによるプロセス並列とOpenMPによるスレッド並列を組み合わせたハイブリッド並列でコーディングされている.したがって,OpenMPIのソースコードを公式サイト[14]等から入手し,所望のディレクトリ下で展開,コンパイル・実行しておく.

この際configure用に以下のスクリプトを用意しておくと便利である[15].

 

$ vi config.sh
#!/bin/bash
export CC=gcc
export CFLAGS=-O3
export CXX=g++
export CXXFLAGS=-O3
export F77=gfortran
export FFLAGS=-O3
export FC= gfortran
export FCFLAGS=-O3
./configure --prefix=$1

問題なくconfigureできたら,コンパイルとインストールをする.

 

$ make
$ make install

MobaXterm のインストール

プリ・ポスト処理のために,Windows上の代表的なXサーバであるMobaXterm[16]をインストールする.MobaXtermをインストールしておくと,入力ファイルを外部エディタで修正したり,計算結果を可視化したりできるようになるので便利である.

インストールはほぼ一直線なので割愛する.無事にインストールが完了すると,MobaXtermを立ち上げることができる.(図4)

図4 MobaXterm の初期画面

図4 MobaXterm の初期画面

MobaXterm を確認すると,WindowsのIPアドレスが192.168.103.2:0.0と表示されているので,BUW側で

$ export DISPLAY=192.168.103.2:0.0

と設定する.これでXサーバが利用可能になる.

V-Isio のインストール

ポスト処理のために,軽量のオープンソース可視化ソフトウェアV-Isio[17]もインストールしておく.手順は以下の通り.

 

alien パッケージのインストール

$ sudo apt-get install alien

alien で rpm 形式のパッケージを deb 形式に変換

$ sudo alien Visio-2.4-6.el6.x86_64.rpm

成功するとvisio_2.4-7_amd64.debができる.

 

deb パッケージのインストール

$ sudo dpkg -i visio_2.4-7_amd64.deb

パスを通す

$ export PATH=/usr/local/Vtools/bin:$PATH

事前に足りないライブラリを入れておく

$ sudo apt-get install libgtk2.0-0
$ sudo apt-get install libpangox-1.0-0
$ sudo apt-get install libjpeg62

これでも

$ Visio: error while loading shared libraries: libtiff.so.3:
 cannot open shared object file: No such file or directory

と怒られるので,libtiff.so.* を適当に探し,シンボリックリンクを作成する.

$ sudo find . -name libtiff.so.*
$ ./usr/lib/x86_64-linux-gnu/libtiff.so.5
$ sudo ln -s /usr/lib/x86_64-linux-gnu/libtiff.so.5 \
/usr/lib/x86_64-linux-gnu/libtiff.so.3
$ Visio

アクセス許可を求めるポップアップが出るが,ここで「はい」とすることで,無事にV-Isioが立ち上がる.(図5)

図5 V-Isio の初期画面

図5 V-Isio の初期画面

 

今回は割愛するが,V-Isioの他にも,ParaViewやVisIt等の可視化ソフトウェアもインストールできるので,必要に応じて試して頂きたいと思う.

FFV-Cのインストール

GNU コンパイラ(もしくは Intel コンパイラ)と OpenMPI があれば FFV-C のインストールが可能になる.

$ http://avr-aics-riken.github.io/ffvc_package/

で最新版FFV-C(バージョン2.4.3)をtar.tz形式もしくはzip形式でダウンロードしたのち,所望のディレクトリに展開し,インストール.

なお,FFV-C には GNU 環境用と Intel 環境用の両方に自動インストールスクリプトが付属しているので,これを利用すると良い

$ tar xvfz avr-aics-riken-ffvc_package-x.x.x.tar.gz
$ cd avr-aics-riken-ffvc_package-x.x.x
$ ./install_intel.sh

お茶を一杯飲んでいる間にインストールが終わる.

試しに組み込み例題の2次元キャビティ問題を計算する.プリ処理としてviエディタで入力ファイルに問題ないことを確認した後,実行.

無事にFFV-Cが動作することが確認できた.(図6)

図6 FFV-C on Bash on Ubuntu on Windows

図6 FFV-C on Bash on Ubuntu on Windows

計算ログをgnuplotで確認.(図7)

速度の発散値や相対残差ノルム値の時間発展を確認し,収束性に問題がないかどうかを確認する.

図7 gnuplot を用いた計算ログの表示

図7 gnuplot を用いた計算ログの表示

速度の絶対値をV-Isioで可視化してみる.(図8)

物理的に奇妙な挙動を示していないことを確認する.

図8 2次元キャビティ問題における速度の絶対値のプロット図.ubuntuにインストールしたV-Isioで可視化

図8 2次元キャビティ問題における速度の絶対値のプロット図.ubuntuにインストールしたV-Isioで可視化.

ここまでで,プリからポストまでの一連の流体解析が問題なく実行できることが確認できた.

 

ところで,今回のWSLで筆者が個人的に大変便利だと感じていることは,ubuntuのファイルやディレクトリをWindows操作できる点である.このことにより,一連の流体解析の操作性が従来の仮想環境やエミュレータと比較して格段に向上している.本稿はこのために書いたといっても過言ではない.

WSLは,Windowsのファイルシステムの

C:¥Users¥「username」¥AppData¥Local¥lxss

に格納されている.(図9)

ただし,これを見るためには,「エクスプローラー」→「オプション」→「フォルダーと検索のオプションの変更」→「フォルダーオプション」→「表示」で,「保護されたオペレーティングシステムファイルを表示しない(推奨)」のチェックを外しておく必要がある.(図10)

図9 Windowsファイルシステム内のWSL格納箇所

図9 Windowsファイルシステム内のWSL格納箇所

図10 フォルダーオプション内のチェックを外す

図10 フォルダーオプション内のチェックを外す

すると,計算ディレクトリをWindows側からも見ることができるようになる.(図11)

Windows側からはファイルがフルコントロールになっているので,入力ファイルをWindows側のエディタで操作することもできる.(図12)これは,ちょっとした感動である.リンクを張っておくと,さらに操作性は向上する.もちろん,ファイルやディレクトリの名前変更や移動等も可能になっている.

図11 Windows から ubuntu のディレクトリが丸見え

図11 Windows から ubuntu のディレクトリが丸見え

図12 Windows のエディタで ubuntu の入力ファイルを直接編集することができる

図12 Windows のエディタで ubuntu の入力ファイルを直接編集することができる

同様に,Windowsファイルシステム内のファイルを読み込んで可視化することができる.先程はWSL内のV-Isioで可視化したが,今度はWindowsにインストールしたV-Isioで可視化してみる.V-Isioを立ち上げて,Windowsファイルシステム内のファイルを選択する.(図13)

すると,問題なくWindows側のV-Isioで可視化することができた.(図14)

当然だが図8と同様の可視化結果が得られている.

図13 Windows のV-Isioでubuntuの可視化データを直接読み込む

図13 Windows のV-Isioでubuntuの可視化データを直接読み込む

図14 2次元キャビティ問題における速度の絶対値のプロット図.Windows にインストールしたV-Isioで可視化.

図14 2次元キャビティ問題における速度の絶対値のプロット図.Windows にインストールしたV-Isioで可視化.

性能評価結果

これまでに,プリからポストまでの一連の流体解析を通じ,従来の仮想環境やエミュレータと同等以上の操作性を実感した.

とは言っても,計算性能に難があるようではやはり実用的には使い物にならないため,簡単にWSL上での計算時間や実行性能を調査することとした.

方法として,仮想環境(VMware)上にWSL環境と同一のバージョンのubuntuとFFV-Cを用意し,計算時間や計算性能を両者で比較した.ベンチマークテストとしては,2次元キャビティ問題を選んだ.総セル数は64×64×1=4096であり,圧力ポアソン方程式の反復法は点過緩和SORで,反復回数は最大20回とし,相対残差の閾値は10-4とした.なお,MPIプロセス数は1とし,スレッド数は4とした(図15中の(1)).

それぞれのプロファイルレポートを,図15と図16に示す.

Total execution time (マスタープロセスの経過時間)を両者で比較すると,後者が約3.80秒なのに対し前者は2.78秒で済んでおり,WSLでの計算が約1.37倍早いことが分かった(図15, 16中の(2)).総計算時間に対する各サブルーチンの割合を調べると,どちらの場合にも上位2つはProjection_Velocityと,Poisson_PSORであり(図15, 16中の(3)),これはどちらもフラクショナルステップの一部であり,ナビエ-ストークス方程式の演算部分にあたる.flop counts or byte counts 欄を見ると,どちらのサブルーチンもWSLのほうが1.1-1.2倍程度高い実効性能が出ていることが分かり,WSLは仮想環境と比較して独自のOSを立ち上げる必要がないためにCPUやメモリ等のリソースを有効活用されていることが示唆される.

その一方で,WSLでのFile_Outputはたった40回のコールで総計算時間の20パーセント弱を食っており,実効性能値を見てもVMwareでのそれと比較して1/10以下であることが分かった.他のファイルI/Oサブルーチンである History_outも同様の傾向を示しており,WSLでのファイルI/Oの性能がVMwareでのそれと比較して,極めて高コストであることを示している.

図15 プロファイルレポート(WSL)

図15 プロファイルレポート(WSL)

図16 プロファイルレポート(VMware)

図16 プロファイルレポート(VMware)

まとめ

Windows10上の ubuntu互換環境(Windows Subsystem for Linux, WSL)にオープンソースの流体ソフトウェアFFV-Cをインストールし,流体解析の一連の流れを通じてWSLの使い勝手を検証するともに,流体ソフトウェアの簡単な性能評価を行い,WSLにおける流体解析の可能性を調査した.

FFV-Cのインストールでは,必要とされるライブラリやソフトウェアがほとんどubuntuネイティブ環境下と同等であることが分かった.また,プリからポストまでの一連の流体解析も,従来のubuntuネイティブ環境下と全く同様に実行できることが確認できた.

もっとも,記事執筆時(2016/9/9)において WSLはベータ版であり,64ビット版限定での提供やシェルの日本語が一部文字化けする等,多少機能に不十分な点も見受けられた.しかし, Microsoft社の本気度(開発項目の優先順位などは[5]参照),導入の容易さ等から考えると,近い将来に従来の仮想環境やエミュレータを脅かす,ないしは置き換える存在になり得るものと考えている.

2次元キャビティ問題を対象にWSLの計算性能を調査した.その結果,WSLでの計算が従来の仮想環境での計算と比較して約1.37倍早いことが分かった.これは,WSLが仮想環境と比較して独自のOSを立ち上げる必要がないため,CPUやメモリ等のリソースが有効活用されていることを示唆している.一方で,WSLのファイルI/Oの実効性能値がVMwareでのそれと比較して1/10程度に留まり,WSLのファイルI/Oが極めて高コストであることが分かった.WSLでの計算では,以上の特性を留意しておく必要があると考えられる.今後は,プロセス/スレッド数依存性の調査や,他のオープンソース流体ソフトウェア(FrontFlow/BlueやOpenFOAM等)を対象とした同様の検証を行うことも検討したい.

近年,PCの性能向上や計算手法・格子生成技術の発達等により,ある程度大規模な計算がローカルPCでも可能になってきた.一般に業務用PCはWindowsマシンであるが,プリからポストまでの流体解析をほぼWindows操作することが可能なubuntu互換環境WSLを用いることで,従来の流体解析がさらに身近になったのではないかと考えられる.

 

参考文献およびウェブサイト

[1] https://msdn.microsoft.com/en-us/commandline/wsl/about

[2] http://www.vmware.com/jp.html

[3] https://www.virtualbox.org/

[4] https://www.cygwin.com/

[5] https://msdn.microsoft.com/en-us/commandline/wsl/faq

[6] http://avr-aics-riken.github.io/ffvc_package/

[7] https://github.com/avr-aics-riken/PMlib

[8] http://pc.watch.impress.co.jp/docs/column/nishikawa/1017333.html

[9] http://www.atmarkit.co.jp/ait/articles/1608/08/news039.html

[10] http://rcmdnk.github.io/blog/2016/06/05/computer-windows-ubuntu-bash/

[11] http://cabonera.hateblo.jp/entry/2016/08/04/003300

[12]http://answers.microsoft.com/ja-jp/windows/forum/windows_10-performance/anniversary-update/66e03b07-4845-4a66-be07-0feda12bd34e

[13] https://www.microsoft.com/ja-jp/software-download/windows10

[14] https://www.open-mpi.org/

[15] User Guide of FFV-C Frontflow/violet Cartesian

[16] http://mobaxterm.mobatek.net/

[17] http://avr-aics-riken.github.io/V-Isio

『分野4次世代ものづくり』シンポジウム最終成果報告会レポート

 去る3月23、24日に行われた文部科学省HPCI戦略プログラム『分野4次世代ものづくり』シンポジウム〔最終成果報告会〕のレポートをお届けします。
6年間に及んだ研究開発の成果に関する詳細な報告を求める方は今後発表される別の資料も参照してください。計算工学ナビ・ニュースレター(ダウンロードページ)でも加藤千幸教授による総括を読むことができます。ここでは、シンポジウムで感じることができた『次世代ものづくり』の今と未来の可能性について概要をお伝えします。

第1日

成果の概要とその先への展望

sympotop まず、分野4統括責任者の加藤千幸教授(東京大学生産技術研究所 革新的シミュレーション研究センター長)より、プロジェクトの所定の目標を達成したことが宣言されました。研究課題ごとの達成状況を見ると「大幅に達成」と評価された研究項目がいくつかあります。これはものづくりのイノベーションにつながる分野4の特徴的な成果に対する評価であると筆者は捉えました。そのあと、この2日間のシンポジウムで発表される各課題の概要が示され、最後に「これはスターティングポイントであり、今後につなげることが重要。このシンポジウムでは近未来のものづくりを実現するHPCについて議論したい」と、会の位置づけを明らかにして締めくくり、各研究課題の担当者による成果発表へと移りました。

課題1:輸送機器・流体機器の流体制御による革新的高効率化・低騒音化に関する研究開発

sympo_k1f 課題責任者の藤井孝藏教授(東京理科大学、JAXA宇宙科学研究所)は、この研究を通じて示したかったのは「計算機の中で新しいアイデアを試す」ことである、という話から発表を始めました。翼の形状の工夫によって性能を向上させることが限界に達してしまった現状を、プラズマアクチュエータという動的に機能する小さなデバイスによって打開することがこの課題の目的ですが、それに必要な知見を計算機(HPC)の活用によって得ることが重要ということでしょう。
藤井教授のチームは京コンピュータを活用して、低・中レイノルズ数領域における現象理解を深め、デバイスの効果的な利用方法を見つけました。この知見を設計の指針として提供できたことが、最大の成果であると藤井教授は位置づけています。そして、この成果のものづくりへの適用が企業との共同研究を通じて始まっています。
次の講演者、株式会社東芝の田中元史参事は、同社のメガワット級発電用風車にアクティブ流体制御技術を適用する実証研究について発表しました。変動する自然風のなかでも流れを制御できる見通しが得られつつあること、そして、すでに鹿児島の2MW風車を用いて約1年間のフィールド実験を進めてきたことが公開され、プレゼンテーションの最後には、巨大な風車をドローンで撮影した雄大な映像が紹介され、会場から大きな拍手が起こりました。
共同研究事例の2社目として登壇したのは、マツダ株式会社の清水圭吾氏です。プラズマアクチュエータをクルマの車体に装着し、デザイン自由度を損なわずに空力性能を高めるという野心的な研究です。具体的には、デザイン上重要な車体後部の丸みを残したまま、プラズマアクチュエータによって気流の剥離を促してドラッグを軽減するというアイデアの有効性を、京を使った大規模流体計算によって確認しました。冒頭で藤井教授が述べた、「計算機の中で新しいアイデアを試す」ことの威力が証明された事例であると感じました。
本課題最後のプレゼンテーションは、産業技術総合研究所瀬川武彦主任研究員による、実験研究者の視点によるプラズマ気流制御技術に関する現状の報告でした。瀬川氏らは、一般的なシート型プラズマアクチュエータよりも設置が容易で空力性能に影響を与えにくい、ひも型プラズマアクチュエータを開発しています。分野4の成果として示された剥離制御に関するデータや知見が、実験データとの比較対象としてきわめて有効であること、無限にあるパラメータの最適化に役立つことが発表されました。分野4の取り組みが、志を同じくする他の研究グループにも利用されている事例として興味深く見ることができました。

課題2:次世代半導体集積素子におけるカーボン系ナノ構造プロセスシミュレーションに関する研究開発

sympo_k2 シリコンカーバイド(SiC)やグラフェンといった新しい材料を採用したデバイスの開発に、従来のシリコンベースの技術を適用するのは難しいため、今まさに新しい知見が求められていると、課題責任者の大野隆央氏(物質・材料研究機構NIMS特命研究員)は研究開発の背景を説明しました。大野氏らのグループは、第一原理分子動力学計算プログラムPHASE/0を京に対して最適化して、高精度長時間の解析を繰り返すことで、グラフェン成膜プロセスとSiC酸化プロセスに関する世界初と言っていい画期的な知見を得ることに成功しました。それぞれの成果に関する3名の講演者による発表の概略を順に紹介します。
NIMS特別研究員の山崎隆浩氏は、高品質なグラフェンの生産手法=レシピを確立するために必要な、SiC表面上での個別原子レベルの成長機構を解明するために、PHASE/0と京を用いて原子数900〜2000規模のシミュレーションを実施し、その結果、炭素の鎖が成長・移動して2次元的構造を形成することを示しました。プレゼンテーションでは、精細なアニメーションが上映され、動画ベースの観察が現象の理解に効果的であることが強調されました。
続いて、NTT物性科学基礎研究所の高村真琴氏は、シミュレーションと実験の両輪で研究を進めることの重要性を、SiC上グラフェンの成長メカニズムを例に指摘しました。特に成長の初期過程でどのようなメカニズムが作用しているかを知る上で、今回得られた知見は重要だったとし、今後はシミュレーションによって実験の指針を得ることができるのではないかという期待を明らかにしました。
株式会社東芝研究開発センター研究主幹の清水達雄氏からは「SiCパワーデバイス特性向上を目指したシミュレーション研究」と題して、市場の拡大が進む次世代パワーデバイスの重要性と開発における課題についてわかりやすい解説がありました。現在進められているSiCベースのパワーデバイス(縦型MOSFET)の開発にはまだ技術課題がいくつか残っていますが、大規模シミュレーションによって改善のヒントが得られることが期待されており、今回NIMSと東芝の共同研究から得られた成果もそのひとつとなることが望まれています。

課題3:乱流の直接計算に基づく次世代流体設計システムの研究開発

このセッションでは、自動車、船舶、燃焼器といった複雑な工業製品の設計に京クラスのHPCを導入することでどのようなイノベーションが起こるかが、多くの具体例とともに示されました。特に自動車会社10社、サプライヤー4社、大学研究7機関が参画するコンソーシアムによる、自動車関連の実証研究の成果が多く発表されたので、まずそこから紹介します。
sympo_k3 まず、神戸大学の坪倉誠教授からは、0.5mmを解像する極めて大規模な空力解析により、2%以内の誤差で自動車の風洞実験を代替可能という明確な成果が発表されました。風洞では実現が難しいレーンチェンジによる蛇行や、風がクルマに与える影響などを加味した評価が行える点も、この技術の革新性です。
スズキ株式会社の飯田桂一郎氏からは、ADVENTUREclusterやFrontFLow/blue-Acousticsといったソフトウエアを使って連成解析を行うことで、車室内の騒音を良好な精度で予測できることが示されました。設計上「一番知りたい」とされる、4KHz以下の周波数特性が予測できたことから、今後の実用化が期待されます。
株式会社本田技術研究所主任研究員の寺村実氏からは、「Hondaでの京を活用したアクティビティ」として、ミラー騒音解析の事例が紹介されました。ミラー単体に対して4.2億セルというメッシュ解像度を適用することで、実験値に近い流れ現象の解析が可能であることが示されました。
富士重工株式会社の小林竜也氏からは、「車両運動性能向上を目指した非定常空力シミュレーション」というテーマで、従来は困難だった、高速走行時に揚力の低周波振動を生み出す流れの評価を、スーパーコンピュータによる非定常シミュレーションで行う事例が紹介されました。
続いて、一般財団法人日本造船技術センターの西川達雄課長より、次世代数値曳航水槽の現状に関する報告がありました。すでに、従来型の曳航試験に対して誤差1%以下という極めて高精度なCFD計算が可能になっています。今後は、実用化を加速するための研究開発を進めていくと述べました。
この研究開発課題最後の発表は、京都大学・武藤昌也特定助教による燃焼器設計支援のための燃焼シミュレーションに関する発表でした。ガスタービン燃焼器、環状燃焼器、発電用のマルチバーナ微粉炭ボイラなど、様々な実機を対象に大規模計算を実施した結果得られた知見が紹介され、産業界での応用に向けた手応えが共有されました。

第2日

課題4:多目的設計探査による設計手法の革新に関する研究開発

多目的設計探査とは、多目的進化計算の結果に基づいて多ケースのシミュレーションを実行し、設計における複雑なトレードオフの関係を明らかにする手法です。
JAXAの大山聖准教授を中心とするチームは、大規模な設計問題にこの手法を適用するため、アルゴリズムとソフトウエアの開発を進めてきました。京コンピュータを使うことで初めて可能となった成果が次々とあがっています。
sympo_k4 東京理科大学の立川智章講師からは「京で可能になったロケット射点形状の空力音響多目的設計探査」と題して、ロケットの打ち上げ時に超音速ジェットから発生する強い音響波の影響を射点(発射台)の形を適切に設計することで低減する試みとその成果について発表されました。射点の形状をパラメータ化し、多目的進化計算に基づいて異なる形状を生成して、それぞれについて流体ミューレションを実行することで最適解を探索します。京の6500ノード(約7%)を用いて約2週間の計算を実行した結果、音響強度最小化、表面圧力最小化および形状簡略化の間のトレードオフを明らかにしました。そのプロセスをふんだんなビジュアルを使って説明するプレゼンテーションは興味深く見応えがありました。
続いての発表は企業における製品開発への適用です。横浜ゴム株式会社の小石正隆理事・研究室長によるプレゼンテーションは、多目的設計探査の大きな可能性をわかりやすく伝えるものでした。第1世代のフィンタイヤ(タイヤ側面にフィン状突起を設け空気抵抗を低減した自動車タイヤ)を改良して、空気抵抗だけでなくリフト(揚力)も低減する第2世代フィンタイヤを開発するために多目的設計探査の手法とFrontFlow/redが使用されました。事前計算を含め100万ノード時間を超えるパラメトリックスタディを実施した結果、抵抗とリフトを同時に低減できる革新的な知見が得られ、それを裏付ける実車試験結果も得ることができました。プロトタイプは2015年の東京モーターショーにおいて公開され、注目を浴びました。
マツダ株式会社の小平剛央アシスタントマネージャーからは、「スパコン京を用いた複数の車体構造の同時多目的設計最適化」というテーマで先進的事例が紹介されました。同社では複数の車種の基本構造となるコモンアーキテクチャ構想を進めています。従来の最適化技術は単一車種にしか対応していないため、同社とJAXAの共同研究によって複数車種同時最適化という課題に取り組みました。京の525万ノード時間を使って16,320回の衝突シミュレーションを行う過程で、「予測はしていたが本当にあるのかわからなかった解」が見つかったといいます。将来は新しい商品の創造にも適用したいと、この技術の可能性に対する高い評価が印象的でした。

課題5:原子力施設等の大型プラントの次世代耐震シミュレーションに関する研究開発

sympo_k5 課題責任者である日本原子力研究開発機構(JAEA)の中島憲宏副センター長から、耐震シミュレーション技術の京での利用とその高度化状況、具体的なプラントや機器を対象とした数値実験などの成果について報告がありました。JAEA内の課題に対する取り組みとしては、高温工学試験研究炉(HTTR)に対する実証計算の事例が紹介されました。約30万点の部品からなる大規模な組立構造物の解析を可能とし、HTTRの観測値と比較することでシミュレーションの精度が検証されました。
産業界との共同研究については、千代田化工建設株式会社の松川圭輔主席技師長から「石油・化学プラントにおける次世代耐震シミュレーションの活用」、株式会社荏原製作所の杉山道子構造・振動解析グループ長から「一般産業機械における次世代耐震シミュレーションの活用」 というテーマで、京によって可能になった耐震シミュレーションの世界が紹介されました。

計算科学技術推進体制の構築

sympo_h 5つの研究開発課題に関する発表のあと行われたのが、計算科学技術推進体制の構築に関するセッションです。責任者の畑田敏夫特任教授(東京大学生産技術研究所)は、この事業の取り組みを「(プロジェクトの成果を)使いやすくする」「知ってもらう」「活用できる人材を育てる」「実際に使ってもらう」という4つにカテゴリーに分類して説明しました。産業界への貢献を重視する分野4の特徴的な事業と言えるでしょう。
成果を使いやすくすることを目的とした具体的な取り組みとして、次に理化学研究所 計算科学研究機構の小野謙二チームリーダーよりHPCプラットフォーム(HPC/PF)の開発と成果に関する発表が行われました。HPC/PFは最先端の大規模並列シミュレーション技術を研究・設計の現場で使える「道具」にする基盤ソフトウエア群の名称です。一般的なPCクラスタから京コンピュータまでの多様な環境で運用でき、ソフトウエアだけでなく解析事例のデータベースも提供するこのプラットフォームは、すでにハンズオンセミナー等を通じて体験可能な状態です。
一連の発表の最後に、川鍋友宏特任研究員(東京大学生産技術研究所)からアウトリーチ活動の成果について報告がありました。アウトリーチ活動の中心的な役割を果たしているのが、いま皆さんがご覧になっているWebサイト『計算工学ナビ』です。2015年3月までの訪問者は43,000人、印刷版ニュースレターの発行部数は10,000部となりました。また、解析事例データベースには200件を超えるデータが登録済みで、簡単なユーザー登録によって全件を検索・閲覧することが可能です。今後も情報の拡充を図っていきます。

パネルディスカッション「今後の実用化に向けて」

2日間のシンポジウムの最後に、下記のパネリストを迎えて、今後の実用化をテーマにパネルディスカッションが行われました。後半には会場からも多くの意見が出され、大変活発な議論となったことが印象的でした。

sympopanel司会:
加藤 千幸(東京大学生産技術研究所 教授)
パネリスト:
藤井 孝藏(東京理科大学 教授)
大山 聖(宇宙航空研究開発機構 宇宙科学研究所 准教授)
西川 達雄(一般財団法人日本造船技術センター 課長)
農沢 隆秀(マツダ株式会社 技術研究所 技監)
福島 伸(株式会社東芝 研究開発センター 首席技監)

この記事では、各パネリストの発言について個別に紹介することはしませんが、加藤千幸教授による冒頭言について簡単に紹介したいと思います。
京を活用する高性能なアプリケーションソフトを開発し、企業との共同開発等を通じてその有効性を実証するという当初の目的は十分果たしたと加藤教授は述べました。次に「本当に京でしかできない革新的な成果はできたのか?」と自問し、これについても「できた」と答えます。シンポジウムで発表された印象的な成果として、JAXAと東芝による風車へのプラズマアクチュエータの適用、NIMSと東芝によるSiC酸化プロセスのメカニズム発見、日本造船技術センターの数値曳航水槽、1ペタフロップス級のスパコンがあれば大規模設計探査が可能であるとするマツダの検証結果、千代田化工による耐震裕度の解析技術などに触れました。しかし、一方で「スッキリしないものが残っている」とも発言し、会場を刺激しました。開発したアプリがすぐさま実用化できるレベルにないことが、その理由です。ポスト京に進む上で、今後どのような体制が必要か、もういちどよく考えることが重要だと呼びかけました。

レポート:計算工学ナビ編集部

ABINIT-MP Openシリーズ

abopen00
 
2016年12月版に関する新しいページがあります

はじめに

logoABINIT-MPは、フラグメント分子軌道(FMO)計算を高速に行えるソフトウェアです[1]。専用GUIのBioStation Viewerとの連携により、入力データの作成~計算結果の解析が容易に行えます。4体フラグメント展開(FMO4)による2次摂動計算も可能です。また、部分構造最適化や分子動力学の機能もあります。FMOエネルギー計算では、小規模のサーバから超並列機の「京」まで対応しています(Flat MPIとOpenMP/MPI混成)。
 

特徴

ABINIT-MPは使いやすいFMOプログラムで、4体フラグメント展開までが可能です。研究室単位のLinux/Intel系サーバに標準搭載されているMPI環境で動作しますし、特別な設定も必要ありません。また、煩雑で注意深さを要するフラグメント分割を伴う入力データの作成は、随伴GUIのBioStation Viewer(Windowsで動作)を使うなどすれば容易に作成できます。また、フラグメント間相互作用エネルギー(IFIE)などの計算結果は膨大となりプリントからの理解はしばしば困難ですが、Viewerを使うと可視的・直観的に対象系の相互作用の様態を把握できます。

主な機能

・エネルギー
→ FMO4: HF, MP2 (CD)
→ FMO2: HF~CCSD(T)
→ FMO2: CIS, CIS(D)系
・エネルギー微分
→ FMO4: HF, MP2
→ FMO2: MP2構造最適化, MD

続きを表示

・その他機能
→ SCIFIE, PB, CAFI, FILM, α(ω)
→ GUI(BioStation Viewer)
→ MPI, OpenMP/MPI混成
→ 最深部はBLAS処理

■BioStationViewer / GUI
abopen01
 

開発の経緯

ABINIT-MPプログラムは、東京大学生産技術研究所を拠点とする「戦略的基盤ソフトウェアの開発」、「革新的シミュレーションソフトウェアの開発」、「HPCI戦略分野4 次世代ものづくり」の一連のプロジェクト(代表:東京大学 加藤千幸教授)、さらにJST-CREST「シミュレーション技術の革新と実用化基盤の構築」(代表:神戸大学田中成典教授)、科学研究費補助金:特定領域研究「実在系の分子理論」(代表:京都大学 榊茂好教授)、立教大学SFR(担当:立教大学望月祐志教授)などの支援を得て、10年以上に渡って開発が進められてきました。Intel IA64系バイナリは、Ver.7が東京大学生産技術研究所の革新的シミュレーション研究センターで、また「京」向けのVer.6+が理化学研究所計算科学研究機構で利用可能となっています。

今後は、東京大学工学研究科を代表拠点とする「フラッグシップ2020 重点課題6」(代表:東京大学 吉村忍教授)の中でものづくり系への応用を指向して改良とリリースが行われていく予定です。後述のように版管理の枠組みも変わってOpenシリーズに移行します。

ABINIT-MPの開発とその先導的な実証応用には多数の機関から多くの方が関わってきましたが、物理的な活動の場所としては東京大学生産技術研究所の一角に置かせていただいてきました。こうした経緯もあり、ABINIT-MPの新しいポータルHPを「計算工学ナビ」の中に設けていただくことになりました。

開発者(所属)

望月祐志*(立教大学 理学部), 中野達也(国立医薬品食品衛生研究所 医薬安全科学部), 坂倉耕太(NEC), 山本純一(NEC), 沖山佳生(元 東京大学 生産技術研究所), 山下勝美(元 NECソフト), 村瀬匡(元 NECソフト), 石川岳志(長崎大学 医歯薬学総合研究科), 古明地勇人(産業技術総合研究所 バイオシステム部門), 加藤雄司(元 立教大学 理学部), 渡辺尚貴(みずほ情報総研), 塚本貴志(みずほ情報総研), 森寛敏(お茶の水女子大学大学院 人間文化創成科学研究科), 田中成典(神戸大学大学院 システム情報学研究科), 加藤昭史(みずほ情報総研), 福澤薫(日本大学 松戸歯学部), 渡邉千鶴(元 東京大学 生産技術研究所)
(*取り纏め責任者)

応用分野

ABINIT-MPのFMO計算は、開発当初から生体分子関係、特にタンパク質とリガンド(薬品分子)の複合系に対して主に用いられてきました。これは、計算で得られるフラグメント間相互作用エネルギーがアミノ酸残基間、あるいはリガンド-アミノ酸残基間の相互作用の状態を理解するのに好適なためです[1,2]

続きを表示

しかし、FMO計算は生体系に限られるだけでなく、水和凝集系や一般の高分子、あるいは固体なども扱える潜在力を持っています。ABINIT-MPの応用は、今後はこうした一般の化学工学や材料科学、あるいは応用物理関係の分野へも広がっていくことを期待していますし、そのための整備とエビデンスの集積も進めています。

abopen03
 

FMO創薬コンソーシアム

2014年11月から「FMO創薬コンソーシアム」(代表:日本大学 福澤薫助教)が産官学で組織され、「京」を計算資源としてABINIT-MPによるFMO計算に基づくタンパク質・リガンドの相互作用解析が進められています。重要な創薬ターゲットが設定されており、当該領域の共有基盤となる知見(特にIFIEのデータセット)の蓄積が期待されます。ABINIT-MPは改良が続けられていきますが、このコンソーシアムは実践的な利用者コミュニティとして今後も重要な役割を果たしていくことになります。

Openシリーズと今後のリリース

ABINIT-MPには、現在からバイナリで利用可能なVer.7(東京大学生産技術研究所からのインテル向け)とVer.6+(理化学研究所の「京」向け)とは別に、主に開発経緯的な事由から「ローカル版」が存在しています[1]。そちらでは、励起エネルギーや動的分極率の算定、さらに結合クラスター展開による高精度エネルギー計算などが利用できます。こうした機能に関心を持たれる方も居られますし、手持ちのマシン環境によっては再コンパイルやチューニングのためにソースを所望される場合もあります。こうした状況を改善すべく、産官学を交えたコンソーシアム的な組織でABINIT-MPのソース共有を行い、継続的なコード開発・改良と保守を図っていく活動の中でリリースされていくのがOpenシリーズになります。

続きを表示

Ver.7に準拠し、モデル内殻ポテンシャル(MCP)機能を追加した最初のOpen Ver.1については準備が整いました(2016年3月31日)。また、「フラッグシップ2020 重点課題6」のプロジェクト活動の中で2016年度に整備するOpen Ver.2では、密度汎関数(DFT)のモジュールなどを分子科学研究所の石村和也研究員のSMASHから、また2電子積分の恒等分解(RI)のモジュール(C言語で記述)を長崎大学の石川岳志准教授のPAICSから移植する他、「ローカル版」のいくつかの機能を含める予定です。また、ホットスポットの洗い直しやメモリ割り当ての見直しなども行い、パフォーマンスの総合的な向上も図ります。Open Ver.3以降も機能充実を順次進めていきます。また、BioStation Viewerについても随時Openシリーズへの対応を図ります。

ソースの共有とは別にOpenシリーズでも従来のバイナリでの提供も続けるつもりですが、これまでのIntel IA64系と富士通系だけでなく、NECのベクトル系(SX-ACE)、さらにパソコン用にWindows 64ビット系を提供しようと考えています。準備ができましたら、このページで順次ご案内します。

開発系コンソーシアム

ABINIT-MPのOpenシリーズの開発や保守にソースレベルでコミットしていただくための産官学枠組みです。バグ情報と対策、新規開発の機能のシェアなど意図していますが、参画される企業様が商用に独自の高速化や改良を図ることは基本的に可とする方針です。現初期段階では、個別にご参画をお願い・確認させていただいて立上げようとしているところですが、規模的には産官学で20拠点程になります。今後、このコンソーシアムについても情報を更新していく予定です。

コンタクト

ABINIT-MPのOpenシリーズ、あるいは開発系コンソーシアムにご関心のある方は、立教大学の望月(fullmoon -at- rikkyo.ac.jp)、中村(mnakamura -at- rikkyo.ac.jp)にメールでご連絡いただければと思います。

[1] “Electron-correlated fragment-molecular-orbital calculations for biomolecular and nano systems”, S. Tanaka, Y. Mochizuki, Y. Komeiji, Y. Okiyama, K. Fukuzawa, Phys. Chem. Chem. Phys. 16 (2014) 10310-10344.
[2] “The Fragment Molecular Orbital Method: Practical Applications to Large Molecular Systems”, edited by D. G. Fedorov, K. Kitaura, CRC Press, Boca Raton, Florida, 2009 ISBN 978-1-4200-7848-0.

RaspberryPiクラスタ製作記 第4回「BareMetal並列計算」

最終回 BareMetal環境で並列計算をしてみよう

manga4

前回はOSの実行にかかるコストを削減するため、BareMetal環境で開発を行いましたが、実行時間はLinux上での結果に負けてしまいました。悔しいです。何とかしてリベンジできないでしょうか。

前回を思い返してみると、Linux上でmpichを用いてLU分解を並列化した結果は、ノード数を増やせば増やすほど通信コストの増加により実行時間は長くなっていました。 ということは、BareMetal環境を活かして通信コストを削減できれば、並列計算時の実行時間は勝てるかもしれません。

そこで今回は、このアイデアを実行し、リベンジを図りたいと思います。また、本連載は今回が最後なので、 記事の終わりに今までの振り返りと要点をまとめます。

通信コスト削減による高速化

冒頭のマンガで述べられているように、BareMetal環境は何もないので、 Ethernetを用いたネットワーク通信を行うには、 LANコントローラのドライバを書き、TCP/IPプロトコルスタックを実装しなければなりません。 この作業を行うとそれだけで1冊本が書けてしまうので、今回はもっと簡単な通信を用います(この後マンガの主人公は、チップの仕様書とUSBの規格書、TCP/IPプロトコルの解説書とにらめっこする日々を過ごすことになるでしょう)。

一般にBareMetal環境やマイコンなどで用いられる通信方法には、以下の3つがあります。

・UART
・SPI
・I2C

これら全てに共通するのは、通信仕様がUSBなどに比べ非常に簡単であり扱いやすく、通信にかかるコストが非常に少ない点です。 この点を活かせば、BareMetal環境上で通信コストを削減した並列計算が行えるはずです。

Raspberry PiのSoCに実装されている中で、最も速度の出る通信方式はSPI(Serial Peripheral Interface)です。 SPIは親(Master)と子(Slave)という役割に分かれ、4本の線を用いて行うシリアル通信です。

SPIconnect

通信は、マスターからスレーブセレクト線(SS)で選択されたスレーブのみが、クロック線(SCLK)から供給されるクロックに合わせて、1bitずつデータの送受信を行います。

SPIwave

SPIの通信クロック(SCLK)は、ペリフェラルマニュアルの156ページより、

SCLK = Core Clock(default: 250MHz) / CDIV(=2^n)  # ただしn=0の場合はCDIV=65536

で計算されるので、n=1の場合に最大の125MHz、つまり理論的には最大125Mbpsで通信が行えます。
しかし、私がRaspberry Pi同士のSPI通信を試したところ、Slave側がうまく動作せず、通信できませんでした。問題解決のため、配線、マスタ側からの出力、Slave側のGPIO設定、SPI Slaveレジスタ設定などの確認を行いましたが問題はなく、加えて受信処理プログラムのミスを確認するためSPI Slaveテストレジスタを用いたテスト通信を行いましたが、こちらも問題なく動作しました。つまり、Slave側でIOポートを通した通信を受信することができていないようですが、今のところ私にはなぜうまくいかないのかわかりません。この問題については引き続き調査を続けますが、記事の締め切りがあるため今回は別の方法を用いることにしました。

2番目に高速なのはUART(Universal Asynchronous Receiver Transmitter)です。 これは通常9600 baudや115200 baud程度の低いボーレート(1秒間に行われる変復調の回数)で、パソコンやマイコン間で文字列を送受信するために使われていますが、設定を変更することでボーレートをMbaudまで上げた高速通信が可能です。

代わりにSPIと違い、基本は1対1での通信しか行えません。 この点は非常に残念ですが、ほかに高速で簡単に扱えるものが見つからないためBareMetal環境の通信はUARTを用いて行います。

Ethernet&TCP/IP vs UART

BareMetal環境の通信にはUARTを用いることにしましたが、 理論的にはEthernet&TCP/IPと比べてどれだけ速くなるか気になります。

そこで、ここではEthernet&TCP/IPとUART&独自プロトコルの速度を調べて比較します。

Ethernet&TCP/IP

ご存知のように、ネットワーク通信は送受信するデータを細かく分けたパケットという単位で行います。 このパケットは入れ子構造になっており、例えばTCP通信のパケットは、Ethernet, IP, TCPパケットに包まれた3重構造になっています。

各パケットには宛先などの情報が記されたヘッダがついており、Ethernet、IP、TCPパケットのヘッダを合わせると、長さは66byteになります(オプションなしの場合)。 一番外殻であるEthernetパケットの長さは最大で1526byteなので、 Ethernetを用いた通信は、データ1460byteにつき66byteのオーバーヘッドが発生します。 このオーバーヘッドを考慮して最大通信速度を考えると、100Mbps * 0.96 = 96Mbpsとなります。

UART

Raspberry PiのUARTのボーレートは、ペリフェラルマニュアルの183ページより、次の計算式で求められます。

baudrate = F_UARTCLK(default: 3MHz) / (16 * BAUDDIV)

この計算式のうち、F_UARTCLKとBAUDDIVは変更可能であり、前者は起動スクリプトを修正、後者はレジスタの設定を行うことで変更できます。

F_UARTCLKは通常3MHzとなっていますが、SDカードの第1パーティションにあるconfig.txtに次の一文を追記すると変更できます。

init_uart_clock=416000000

ここに設定する値は、Raspberry PiのSoCが搭載しているUARTペリフェラル(PL011)マニュアルによると、Core Clock(250Mhz)* 5/3 までの値が推奨されているので、F_UARTCLKは416MHzが最大となります。

BAUDDIVはIBRDとFBRDレジスタで設定でき、 どちらも0にした場合にBAUDDIV=1となり、 最大ボーレートは以下の計算式より26Mbaudとなります。

baudrate = 416(MHz) / (16 * 1) = 26(Mbaud)

UARTは1度に1bitの変復調を行うので、通信速度の最大は26Mbpsとなります。

実際に設定してオシロスコープで見てみると、確かに26MHzの波形が出ていることが確認できます。

UART_freq_26MHz_recvtest

UARTの通信は8bitずつ行われ、データの開始と終了を判定するためにスタートビットとストップビットが最小で1bitずつ付きます。

UARTsignal

つまり、8bitあたり2bitのオーバーヘッドが発生するので、これを考慮した最大通信速度は 26Mbps * 0.8 = 20.8Mbpsとなります。

Ethernet&TCP/IPとUARTの比較

以上で述べた、EthernetとUART通信のオーバーヘッドを含めた最大速度を以下に示します。

通信方式 最大通信速度(Mbps)
Ethernet&TCP/IP 96
UART 20.8

この結果はEthernetの圧倒的勝利のように見えます。しかし、現在考慮しているEthernet&TCP/IPのオーバーヘッドはトランスポート層までであり、セッション層以降のオーバーヘッドについては考慮していません。 つまり、セッション層以上にまだまだ多くのオーバーヘッドが存在するはずです。 対するUARTは1対1通信のため送信先選択などを行う必要がなく、オーバーヘッドは少なくなるはずです。 この差を考慮すれば、もしかするとUARTを用いた並列計算のほうが速くなるかもしれません。

まだ希望はあるはずです。 やって確かめてみましょう。

ソフトウェアの実装

UARTは1対1通信なので、前回作成した並列計算プログラムをノード数2に限定し、行列Aを2つに分けた前半を処理するノード0と、後半を処理するノード1のコードを作ります。

MPI関数を用いて行っていた枢軸ベクトルや計算後のLU行列の転送は、以下のUART通信を用いた関数に置き換えて行います。

void Serial_send(uint8_t *buf, int len) 第1引数bufで指定されたアドレスから第2引数len(byte)データを送信する
void Serial_receive(uint8_t *buf, int len) 第1引数bufで指定されたアドレスから第2引数len(byte)データを受信する
void uart0_putc(int c) 第1引数cで指定された値の下位8bitを送信する
int uart0_putc() 受信した8bitの値を返す

この変更を行ったコードをこちらで何度か動かしたところ、UARTで10byte程度以上の連続通信を行うと、データの整合がとれなくなる問題が発生しました。そのため、データの転送は4byte(double型の1つ分)ごとに 開始文字’s’と終了文字’e’を互いに送り合い、同期を取るようにします。

以上を行ったコードが以下の2つになります。

baremetalLU_node0.zip
baremetalLU_node1.zip

今回は通信にUARTを用いるため、UARTを用いた計算結果や実行時間の出力が行えません。そこで出力はSPI通信で別のマイコンに転送し、そのマイコン経由でパソコンに表示します。

マイコンには開発の容易さからmbed LPC11U24を用います。マイコンのソースコードは以下からダウンロードして使用してください。

spi2serial_full

なお、mbed LPC11U24のボーレートは115200bpsに設定しています。

ハードウェアの接続

データの通信を行うUARTと、結果の出力を行うmbed LPC11U24の接続を以下に示します。

raspi_uart

この図を参考に配線を行ってください。
なお、ログ出力用のマイコンはUSBケーブルを用いてパソコンと接続してください。

動作比較

プログラムのコンパイルを行い、出てきたバイナリをRaspberry Piにセットし、電源を入れるとプログラムが動作します。果たして、通信にUARTを用いた結果、通信コストの削減とそれにともなう処理の高速化はできたのでしょうか。以下に結果を示します。

exec time: 6278386

結果は6278ミリ秒。

Linux上で2ノード並列計算を行った際の結果は1600ミリ秒程度だったので、約4倍も遅くなってしまいました。通信速度で既に大きな差があった上に、データの同期を取るため8byteにつき2byteの大きなオーバーヘッドを作ってしまったことが敗因でしょう。

結局、私によるBareMetalの挑戦は残念な結果に終わりました。
もちろん、Linuxも同じRaspberry Piで動いているのですから、同じ設定をハードウェアに行えば、BareMetal環境でも同等かそれ以上の性能が得られるでしょう。しかし、そのためにはより多くの時間と労力が必要になり、難しいです。

片桐さんの著書「スパコンプログラミング入門 並列処理とMPIの学習」の35ページには、次のように書かれています。

「実装する処理によっては,スパコンのメーカー製やフリーソフトウェアによる数値計算ライブラリが利用できることがあります.この場合は,自らプログラミングするのではなく,提供されている数値計算ライブラリを利用する方が,性能が格段に良いことが多いです.〜中略〜最適化されたBLASの性能は,個人で開発した行列と行列の積に対して,10倍以上高速であることも珍しくありません」

私の挑戦が失敗したことからわかるように、既存のOSや計算ライブラリは既に高度な最適化を施されており、高速に動作します。そのため、計算処理の高速化は既存のOSや計算ライブラリを基にチューニングを行うほうが、手軽に期待する性能が得られるでしょう。しかし、そのチューニングのためには、ハードウェアやCPUアーキテクチャについての知識が必要となります。BareMetal開発はこの知識を得るために行い、そこで得た知識を既存のものに対し適応するという手法が良いのではと考えます。

連載のまとめ

本連載は今回が最後なので、今までのまとめとふりかえりを行います。

第0回

第0回では、

・そもそもスパコンとはなにか
・スパコンで計算される問題は本当にスパコンを用いる必要があるのか

を確認するため、現在の一般的なパソコンとスパコン「京」の性能を比べ、 実際に「京」で使われているPHASE0というプログラムを動かして、 実行時間が指数関数的に増えていく様子をグラフで確認しました。

現在はパソコンの性能が上がり、以前はスパコンを用いていた計算も、パソコンで行えるようになりました。 そのため、大学でコンピュータを学んでいる人の中でも、実際にスパコンに触れられる方は少なく、 スパコンとはなにか、何故必要なのかがわからない方もいるのではと感じています。 しかし、調べてみるとスパコンが必要となる計算は確かに存在し、 それらは私たちの生活に深く関わっています。 それを少しでも感じていただけたなら幸いです。

第1回

第1回では、

・クラスタとはなにか
・自作スパコンの作り方

について説明しました。

現代のスパコンは、複数のマシンをつなげてクラスタを作り、高い性能を得ています。 この「クラスタマシンを作る」というと、実用重視で高性能高価格なマシンを繋いだものを想像し、個人では手を出せないと考えてしまうかもしれません。 しかし、勉強のためと割り切って考えれば性能は必要なく、今回のように安価なRaspberry Piを使って作ることも可能です。

また、今回は16台でクラスタマシンの制作を行いましたが、 並列計算の学習を行うだけであれば4台もあれば十分でしょう。 そうすると、コストは1/4の3万円程度になるので、手を出しやすいかと思います。

第2回

第2回では、第1回で制作したRaspberry Piスパコンを用いて、

PAHSE/0の動作確認
・Linpackを用いた性能評価
・スパコン「京」との性能&コスト比較

を行いました。

PAHSE/0 と Linpack、どちらもノード数を増やすごとに処理速度は上がりましたが、その伸びは非常に悪くなっていきました。 ノード数(プロセッサ)と処理速度の関係には「アムダールの法則」という法則があり、 この法則よりノード数を増やせば増やすほど並列処理に含まれる並列化できない部分がネックになり、 速度の向上の伸びは非常に悪くなっていくことが示されます。

第3回

これまでは既存のソフトウェアを用いて性能評価などを行いましたが、 第3回では実際に自分でMPIを用いて並列処理を書いてみました。

これまでのPHASE/0とLinpackを実行した結果は、プログラムの並列化を行えば(伸びが悪くなることはあっても)必ず高速化されていました。 しかし、自分で並列化したコードはノード数を増やすごとに実行時間が増えるという結果になり、 並列化によりきちんと高速化されるプログラムを作るのは難しいことがわかりました。

今回用いた初代Raspberry PiはCPU性能が低く、並列化のためのコストが結果に大きく響きます。 逆に言えば、正しく効率的な並列化を行った場合のみ性能が向上する素直なマシンであり、 分散メモリ型の並列プログラミングの教材として最適なマシンと言えます。

一方、2015年2月3日に発売された新型のRaspberry Pi 2は、CPUが ARM11 700MHz シングルコア から Cortex-A7 900MHz クアッドコア(4コア)に変更され、性能が大幅に向上しました。発売直後、個人的に購入した1台のRaspberry Pi 2上でコアを4つ用いてLinpackを実行してみたところ、1台で旧型(Raspberry Pi Model B+)6台分の性能が得られました(詳細についてはブログ記事を参照してください)。コアを4つ持っていることを活かして、旧型では行えなかった共有メモリ型の並列プログラミング学習も行えます。

もし今からRaspberry Piスパコンを作るのであれば、 学習の目的に応じて、新型・旧型を使い分ければ良いと思います。

おわりに

本連載を読んでいただき、ありがとうございました。

第0回でも述べたように、 スパコンは私たちの生活をより豊かなものとするため必要不可欠なものです。 スパコンを自作するという本連載を通して、 スパコンの必要性や、高度な技術により支えられていることを感じていただき、 興味を持っていただけたなら幸いです。

最後に、スパコンについてより詳しく知りたい方のため、 本連載を書く際に参考にした書籍をご紹介します。

・絵でわかるスーパーコンピュータ 姫野龍太郎 著 ISBN: 978-4061547643
・スパコンプログラミング入門 片桐孝洋 著 ISBN: 978-4130624534
・スーパーコンピューターを20万円で創る 伊藤智義 著 ISBN: 978-4087203950
・ARMで学ぶ アセンブリ言語入門 出村成和 著 ISBN: 978-4863541269
・ルーター自作でわかるパケットの流れ 小俣光之 著 ISBN: 978-4774147451

 
 

著者プロフィール

西永俊文 1992年生まれの情報系大学生。一人前のエンジニアを目指して日々勉強中。PDA全盛期の影響から、組み込み機器が好き。今欲しい物は、現代の技術で作られた物理キーボード付きで4インチ以下の小さなスマートフォン。著書に『BareMetalで遊ぶ Raspberry Pi』がある。
〈四コママンガ:

OLYMPUS DIGITAL CAMERA
著者近影(手にしているのは今回製作したRasPiクラスター初号機)

連載目次

2014-12-01 RaspberryPiクラスタ製作記 第0回「スパコンって本当にスゴイの?」
2014-12-01 PHASE/0のインストール方法
2014-12-16 RaspberryPiクラスタ製作記 第1回「スパコンを作ろう」
2014-12-16 Raspberry Piの初期設定
2014-12-29 RaspberryPiクラスタ製作記 第2回「スパコンで遊ぼう」
2014-12-29 HPLのインストール方法
2015-02-11 RaspberryPiクラスタ製作記 第3回「並列プログラミング」
2015-02-11 MPIを用いた並列プログラミングの概要
2015-02-11 LU分解アルゴリズムのおさらい
2015-03-01 RaspberryPiクラスタ製作記 第4回「BareMetal並列計算」


↑前のページ次のページ↓