＜関連情報＞ スパコンクラウド® （Up&Coming '11 新緑の号掲載）
| ■ LuxRenderレンダリングサービス NEW！ |
|
LuxRenderは、作成した3DCGモデルを基に画像化処理を行う「レンダラ」と呼ばれるソフトウェアの一種です。視点、光源、作成したモデルのそれぞれの情報から陰影付け等を行い、画像を作成します。このレンダラの中でも、LuxRenderは光の挙動を物理的に正確に計算して画像化することを特徴としており、写真のようなリアルなイメージを得ることができます。
LuxRenderでは性質上レンダリングの終了という概念がなく、レンダリング時間は作業者が決定します。レンダリング品質は時間をかけるほど上がるため、品質とコストとのバランスをみてレンダリング時間を決定します。
本サービスでは、受領した3dsMaxのシーンについてLuxRenderを用いてレンダリングを行い、静止画及び動画を作成します。サービスの流れは次の通りです。
- シーン内容の確認
- 見積もり
- レンダリングサンプル作成
- 契約
- 品質決定
- レンダリング
- レビュー
- 納品
最初に、受領するシーンがLuxRenderでレンダリング可能か調査を行います（ステップ1）。
レンダリング可能であることが判明すれば見積もりに進みます（ステップ2）。
見積もり作業後にレンダリングサンプル作成となります（ステップ3）。
このステップでは実際に受領シーンをLuxRenderでレンダリングしますが、まだいわゆるプレビューの様な段階です。マテリアル変換も簡単で、レンダリング画像も短時間で作成可能な小さなものとなります。ここで完成品のイメージを依頼者に掴んでもらいます。作成したサンプルにおいて依頼者の了解を得られたら、契約に進みます（ステップ4）。
契約完了後にレンダリング品質の決定を行います（ステップ5）。
ステップ3で作成したイメージをもとに、手動変換を含めたマテリアルの設定や、ライティング調整といったシーン全体の微調整等、詳細なシーンの修正内容を決定します。加えてレンダリング時間の決定も行います。レンダリング品質が決定したら、品質内容に沿って受領シーンの修正を行った後に本番のレンダリングを実施します（ステップ6）。
この本レンダリングで得られた画像をもとにレビューを行います（ステップ7）。
レビューにおいて依頼者が更なる品質向上を求めた場合は契約の更新を行い、シーンの再修正内容・追加のレンダリング時間を決定します。シーンを再修正後、再びレンダリングと結果のレビューを行います。依頼者が満足する品質になるまで、契約〜レンダリング〜レビューを繰り返します。依頼者が品質に納得すれば納品となります。右にサービスの流れを表した図を示します。
|
|
dsMaxに標準搭載されている標準（Standard）マテリアルをLuxRender向けマテリアルに自動変換します。また拡散反射光カラー、鏡面反射光カラー、バンプ、ディスプレイスメントのいずれかのマップチャンネルにおいて、これらチャンネルに設定されているビットマップ、ミックスマップを自動的にLuxRender用に変換します。
シーン中の変換できなかったマテリアル・テクスチャについては手動変換となります。（変換に失敗したものはテキストファイルに一覧が出力されます）
以下に標準マテリアルとLuxRenderマテリアルのレンダリング画像の比較を紹介します。
●ツヤのないマテリアル
 |
▲ツヤのないマテリアルの比較
左：標準マテリアル、右：LuxRenderマテリアル |
●ツヤがあり、反射も表現できるマテリアル
・反射なしの場合
 |
▲ツヤがあり反射も表現できるマテリアルの比較（反射なし）
左：標準マテリアル、右：LuxRenderマテリアル |
・反射ありの場合
 |
▲ツヤがあり反射も表現できるマテリアルの比較（反射あり）
左：標準マテリアル、右：LuxRenderマテリアル |
●透明感を表現するマテリアル
 |
▲透明感を表現するマテリアルの比較
左：標準マテリアル、右：LuxRenderマテリアル |
●透明感を表現するマテリアル
 |
▲透明感を表現するマテリアルの比較
左：標準マテリアル、右：LuxRenderマテリアル |
標準マテリアルが設定されているオブジェクトを含む3dsMaxシーンにマテリアルコンバートスクリプトを適用した時の変換プロセスを示します。
コンバートスクリプトを実行すると、まずシーン中のオブジェクトを調べます。オブジェクトごとにマテリアルが設定されているか確認し、設定されている場合はそのマテリアルの種類を調べます。マテリアルの種類が3dsMax標準添付の標準マテリアルだった場合、各種パラメータから自動的にLuxRender用マテリアルの種類を選び適用します。オブジェクトに設定されているマテリアルが標準マテリアルだった場合、マテリアルはそのままの状態で置かれます。この時は手動変換となります。
標準マテリアルの自動変換が行われたものについては、次のステップでテクスチャの自動変換を行います。テクスチャの変換ステップでは2つの条件を判定し、両方とも条件に合うようなら自動変換を行います。
一つ目の条件はテクスチャの種類です。テクスチャの種類が”Bitmap” もしくは、”Mixマップ”である必要があります。
2つ目の条件は、テクスチャが設定されているチャンネルです。このチャンネルが”拡散反射カラー”、”鏡面反射カラー”、”バンプ”、”ディスプレイメント”のいずれかである必要があります。
これら2つの条件を満たしている場合に、設定されているテクスチャをLuxRender向けテクスチャに変換します。一方、条件を満たせない場合は手動によるテクスチャ変換となります。 |
▲変換プロセス |
|
| Engineer's Studio®は、弊社でプレ処理〜メイン処理〜ポスト処理までのすべてを自社開発した3次元有限要素法(FEM)解析プログラムです。静的解析、動的解析、固有値解析を行うことができ、材料非線形、幾何学的非線形に対応。はり要素、ファイバー要素、平板要素を使用した構造解析が可能です。 |
このたび、Engineer's Studio®における解析規模のスケールアップと解析時間の短縮化を目指し、メイン処理部をFOCUSスパコン(※1)に対応させた、Engineer's
Studio®クラウドサービスを開始しました。Webアプリケーション上でオンラインでデータを作成・登録し、そのデータを自動的にFOCUSスパコンと連携させることで、ユーザは最終結果データをWebアプリケーション上から取得できます。必要に応じて、結果データはメディアに保存して送付もいたします。
|
|
 |
|
▲Engineer's Studio®解析サービス
処理イメージ |
|
１．Engineer's Studio®で
入力データ作成、保存 |
|
２．UC-1 for SaaSサーバに
ログイン |
|
３．入力データのアップロード
（ジョブの投入） |
|
|
 |
 |
 |
|
 |
|
|
４．解析結果のダウンロード |
|
５．Engineer's Studio® を使用して
結果表示、レポート作成 |
|
 |
|
 |
- 複数ノードに対応した並列化
- 膨大な解析データから必要な結果だけを取得するため、解析前に結果データを選択できるオプションを追加 他
| ■ スパコンオプション解析支援サービス |
従来のEngineer's Studio®解析支援サービスのオプションです。
Engineer's Studio®では、非線形平板要素をサポートしており、大規模モデルでは計算時間やメモリ消費量が問題となる場合がありました。スパコンを利用することで、このようなモデルに対しても計算時間の短縮や、さらにより精緻なモデルを作成しても解析が可能となり、解析精度の向上が見込まれます。また、独立行政法人 防災科学技術研究所
強震ネットワークK-NETで公開されている、「K-NET築館(MYG004)」に代表される平成23年東北地方太平洋沖地震で計測された300秒(1/100秒間隔で30,000ステップ)の解析なども、スパコンを用いることで計算時間の短縮が見込まれます。さらに同ネットワークでは、相次ぐ余震で計測された地震波形も公開されており、本震＋余震の影響を考慮した、非常に多くのステップ解析(50,000ステップ以上)をより高速に解析することが可能になります。
■ 参考・出典：
独立行政法人 防災科学技術研究所 強震ネットワーク K-NET http://www.k-net.bosai.go.jp/k-net/
 |
 |
■図5 強震観測網(K-NET、KiK-net)により観測された地表での最大化速度分布(左)と
K-NET築館(MYG004)観測点の強震動波形(右)(いずれも防災科学技術研究所HPより) |
|
|
POV-Rayにより作成した高精細な動画ファイルを提供するサービス。スパコンを利用することで現実的に実現不可能な高精細な動画ファイルの提供が可能。また、POV-Rayを利用しているため、UC-win/Roadで出力後にスクリプトファイルをエディタ等で修正することが可能です。
 |
 |
 |
▲ポリゴン数 低：
FORUM8宮崎支社VRモデル |
▲ポリゴン数 中：
東京中目黒駅周辺VRモデル |
▲ポリゴン数 高：
中国北運河生態修復VRモデル |
- UC-win/Roadのシーンを作成
- 動画内容の調整
- POV-Rayスクリプトの作成
- フレーム単位レンダリング（スパコン利用）
- レンダリング結果からの動画ファイル作成
- 納品
 |
| ▲UC-win/RoadCGムービ作成例 「灯台と島のドライビングモデル」 |
- 動画ファイルの作成の対応
- Ver.5.2でPOV-Ray出力未対応のオブジェクト（雨、雪、火（煙））への対応
 |
|
 |
| ▲POV-Rayを利用した大気設定（霧の効果） |
 |
|
|
| ▲POV-Rayを利用したレンダリングの例。中国北運河生態修復VRモデル |
 |
|
 |
| ▲UC-win/Roadから出力されたモデル（左）と、スパコンで「POV-Ray」によってレンダリングしたCG（右） |
 |
|
 |
|
| ■ 3dsMax・CGムービーサービス |
京のトライアルユース採択 採択日：2013/5/17 |
FOCUS（計算科学振興財団）のスパコンを用いて、現実の物理方程式に基づいた膨大な演算を行うことで生成することができる、限りなく精密で写真と見紛うようなフォトリアリスティックな画像を提供するサービスです。建築におけるBIMモデルやインテリアコーディネートのデザイン検討の他、自動車や部品等の企画、設計段階でのレビュー、プレゼンテーション、広報、マーケティングなど、様々な用途に活用することができます。
 |
 |
▲FOCUS スパコンで100ノード並列
での1000秒レンダリング結果 |
▲LuxRender レンダリング例 |
|
| ■ 風・熱流体解析スパコン解析・シミュレーションサービス |
汎用流体解析ツール「OpenFOAM」を用いた解析・シミュレーション支援サービスとなります。「OpenFOAM」は、OpenCFD社が開発しGNUのGeneral_Public_Licenseのもとでフリーかつオープンソースとして配布されているものです。乱流・熱伝達を含む複雑な流体の流れをシミュレートすることが可能です。本サービスでは、フォーラムエイトが中間でスパコンとアクセスすることで、利用環境を持たない多くのユーザーにとって、より身近にスパコンを用いた高度な解析環境をご利用頂けます。
- 風の解析 （ビル周辺の風解析）
- 水 （単一流体場、固定あるいは自由境界）
- 多相流体場の解析 （空体と液体、液体と固体など）
 |
|
 |
| ▲中目黒GTタワーによる風解析 |
 |
|
 |
| ▲渋谷モデルによる風解析 |
 |
|
 |
| ▲圧力コンタ図。Timeを変更することで各時間の圧力、各時間毎の流線の確認が可能 |
- (1)新宿副都心の建物群
「市街地風環境予測のための流体数値解析ガイドブック−ガイドラインと検証用データベース−日本建築学会」に例示されているモデルです。解析の規模と概要は以下のとおりです(解析時間：2時間程度)。
・解析領域：1700m×1700m×700m
・節点数：約750,000
・要素数：約1,300,000
 |
 |
▲事例(1)新宿副都心の建物群：
メッシュと風速分布図(コンター) |
▲事例(1)新宿副都心の建物群：
風速分布図(ベクトル) |
(2)中目黒駅周辺の建物群
中目黒駅周辺の解析例になります(解析時間：1時間程度)。
・解析領域：400m×500m×300m
・節点数：約530,000
・要素数：約950,000
 |
 |
▲事例(2)中目黒駅周辺の建物群：
風速分布図(ベクトル) |
▲事例(2)中目黒駅周辺の建物群：
風速分布図(コンター) |
- サービスの基本価格は、下記により算出いたします。
| 基本価格 |
| 直接人件費 |
［見積もり面積×作業工数×形状割増］×技術者工数単価 |
| 一般管理費 |
直接人件費×100% |
| 経費 |
技術経費、急行料金 |
前述の2つのモデルでは下記金額となります。
|
工数 |
見積金額 |
| (1)新宿副都心モデル |
22.2 |
¥1,879,852- |
| (2)中目黒モデル |
12.2 |
¥1,033,072- |
※価格は税別表示です。
- ※具体的な金額は別途お見積もりとなります。
|
| ■ 騒音音響スパコン解析・シミュレーションサービス 2011/08/09 リリース |
VR上で展開される3D・VR空間上に音源および受音面を配置することで、一般的な音の広がりをシミュレートするものです。地表面や構造物および建築物などの影響を考慮し、受音面上の各受音点における音圧レベルを解析します。
解析処理をスーパーコンピュータで実行するものであり、特に大規模なデータの処理に威力を発揮します。
騒音シミュレーションはプリプロセッサ（入力部）、メインプロセッサ（解析部）、ポストプロセッサ（結果表示部）から構成されています。
- プリプロセッサ
データ入力について、音源の配置、受音面の設定、解析条件パラメータの指定を行います。
- メインプロセッサ
機能としては音の経路を設定し、地表面やモデル面などでの反射と透過とを考慮します。解析処理では、音源や音の経路などの相互間でデータを独立して処理することが可能です。この特徴を生かしてスパコン上で並列計算を行い、大規模データを効率よく処理します。
- ポストプロセッサ
さまざまな視点からシミュレーション結果を捉えることが可能となっています。コンター図やコンターラインに加え、格子形状または球体形状によって音圧レベルを可視化するなどのユニークな機能も備えています。
１． プリプロセス
- 地域データ、地形の取り込み
- 道路や橋等の構造物の定義
- ビル等の建築物の定義
- 音源や受音面の定義
- 解析条件の定義
 |
 |
| ▲音源の設定 |
▲受音面の一括配置 |
| データ入力について、音源の配置、受音面の設定、解析条件パラメータを指定。 |
２．メインプロセス
| 音の経路を設定し、地表面やモデル面などでの反射と透過とを考慮。解析処理では、音源や音の経路などの相互間でデータの独立処理が可能。 |
３．ポストプロセス
 |
 |
 |
| ▲コンタ図表示 |
▲コンタライン表示 |
▲球体表示 |
| さまざまな視点からシミュレーション結果を捉えることが可能。コンタ図やコンタラインに加え、格子形状または球体形状によって音圧レベルを可視化するなどのユニークな機能も搭載。 |
- スパコンの性能を引き出す最適な並列化アルゴリズムの開発
- シミュレーション結果表示の高度化
- VR-Studio® 騒音シミュレーションオプションの開発
| ■ 騒音測定シミュレーションサービス(オプション) |
|
「騒音音響スパコン解析・シミュレーションサービス」に加えて選択可能なオプションで、現場での建設工事・交通等の騒音測定（任意計測）とその結果を提供します。測定現場のVRモデリングおよび騒音解析シミュレーション結果の可視化と併せて実際の測定結果をご利用いただくことで、解析結果の確認や比較検討に役立ちます。
●騒音測定シミュレーションサービスの概要
|
騒音測定を大別すると下記がありますが、本サービスでは「任意計測」をサポートします。 |
- 任意計測
特定の基準を考えない、オーダーメイドの計測
- 道路騒音測定
「騒音に係る環境基準の評価マニュアル II．地域評価編（道路に面する地域）」平成12年4月 環境庁 準拠
- 建設騒音測定
「建設工事の騒音測定要領（案）」平成19年度 （独）土木研究所 準拠
●一般的な騒音の種類
|
以下の騒音の種類について、評価および測定のためのマニュアルが整備されており、（ ）内はそれぞれの予測モデルの名称を示します。 |
- 一般環境騒音
- 道路交通騒音 （ ASJ RTN-Model2008 ）
- 在来鉄道騒音
- 新幹線鉄道騒音
- 航空機騒音
- 建設工事騒音 （ ASJ CN-Model2007 ）
|
本サービスでは、これらの騒音のうち、道路交通騒音と建設工事騒音に着目します。 |
●測定機材
- 騒音計（サウンドレベルメータ） ： JIS C 1509-1
- 校正器 ： JIS C 1515
- レベルレコーダ ： JIS C 1512（今後予定）
- データレコーダ ： JIS規定なし、20Hz〜10kHz対応（今後予定）
- 周波数分析器 ： JIS C 1513（今後予定）
|
| ■ 騒音測定シミュレーションサービス ： 見積り事例 |
●騒音解析例
|
騒音解析（建設騒音）の現場状況としては、解析領域内の上方に一つの音源があり、音源脇を通り右上から左下にかけて長さ約20mの壁を設置しました。条件は以下のとおりです。 |
- 受音領域サイズ ： 80m×80m×2面
- 音源レベル ： 112dB
- 音源周波数 ： 1000Hz
- 解析上の経過時間 ： 0.26秒
- 解析時間きざみ ： 0.01秒
●騒音測定例
|
騒音測定（建設騒音）の現場状況としては、建設機械（対象音源）の周囲に測定用騒音計4台、図中の下方に通日測定用騒音計1台を設置し、測定するケースを想定しました。 |
 |
| 騒音測定（建設騒音） |
 |
|
| 騒音解析条件・見積り金額 |
騒音測定条件・見積り金額 |
| 項目 |
データ |
| 固定音源数 |
1 |
| 移動音源数 |
なし |
| 受音面数 |
1 |
| 受音点数 |
289個 |
| 指定受音点数（時系列データ整理対象） |
0個 |
| 見積金額 |
¥82,738 |
|
| 項目 |
データ |
| 対象ユニット数 |
1ユニット |
| ユニットの作業サイクル |
3サイクル |
| 通日測定点数 |
1個 |
| 移動車両騒音測定点数 |
0個 |
| 当日作業時間 |
9時間 |
| 見積金額 |
¥434,295 |
|
| ※価格は税別表示です。 |
 |
 |
| ▲騒音解析（建設騒音） |
●騒音解析例
|
2枚のコンター図それぞれの下端中央に音源となる車両を配置しました。条件は以下のとおりです。 |
- 受音領域サイズ ： 100m×400m×2面
- 音源レベル ： 100dB
- 音源周波数 ： 85Hz
- 解析上の経過時間 ： 2.0秒
- 解析時間きざみ ： 0.02秒
●騒音測定例
|
騒音測定（道路騒音）の現場状況としては、選択した道路断面（2ヶ所）の両側に測定用騒音計各１台設置し、断面を車両が通過する瞬間の音圧レベル分布を測定するケースを想定しました。 |
 |
| 騒音測定（道路騒音） |
|
|
| 騒音解析条件・見積り金額 |
騒音測定条件・見積り金額 |
| 項目 |
データ |
| 固定音源数 |
2 |
| 移動音源の考慮 |
考慮する |
| 受音面数 |
2 |
| 受音点数 |
880個 |
指定受音点数
（時系列データ整理対象） |
0個 |
| 見積金額 |
¥469,940 |
|
| 項目 |
データ |
| 測定断面数 |
1 |
| 測定点数 |
2個 |
| 交通量測定 |
あり |
| 走行速度測定 |
あり |
| 背後地騒音測定 |
なし |
| 測定時間 |
24時間 |
| 見積金額 |
¥1,573,113 |
|
| ※価格は税別表示です。 |
 |
 |
| ▲騒音解析（道路騒音） |
|
道路騒音（Build Live Tokyo 2010）解析事例 |
|
開発中の住宅地の道路騒音のシミュレートです。鉛直面、水平面を各1面設定し、面の中央付近を車両が通過する瞬間の音圧レベルを計算しました。条件は以下のとおりです。 |
- 受音領域サイズ ： 40m×100m×2面
- 音源レベル ： 100dB
- 音源周波数 ： 500Hz
- 解析上の経過時間 ： 0.2秒
- 解析時間きざみ ： 0.01秒（スパコン解析時間は9分間）
 |
 |
| ▲騒音解析（鉛直面） |
▲騒音解析（水平面） |
|
|
本サービスは、2011年3月11日に発生した東北地方太平洋地震のような超巨大地震に伴う津波が、日本列島に押し寄せる状況をシミュレーションし、その結果を提供するものです。
本サービスでは、東北大学の今村文彦教授に提供いただいた津波解析ソルバーを用いて、主に南海トラフの巨大地震による津波を想定したシミュレーションを行います。津波の発生から沿岸まで押し寄せる状態をシミュレーションします。シミュレーションの結果として、津波が押し寄せる様子や、津波高が最も高い地域、選んだ地点における津波高の時刻歴を得ることができます。
このサービスではFocus（（公財）計算科学振興財団、神戸市）が所有するスーパーコンピュータ（Focusスパコン）を用いてシミュレーションを行います。スパコンを用いることで、計算規模が大きくても素早く計算を実行することができます。
 |
 |
| ▲図1 インド洋津波（2004年）の解析アニメーション（東北大学津波工学研究室） |
東北大学 津波工学研究室の今村文彦教授に提供いただいたソルバーをもとにしています。本ソルバーの特長は次の通りです。
1.浅水長波理論をもとにした津波の伝播計算
2.ネスティングによる大規模な範囲での解析
3.地震による津波の発生から伝播までの一括シミュレーション
4.堤防や河川などの沿岸部の細かな再現
1.浅水長波理論をもとにした津波の伝播計算
本ソルバーでは、「浅水長波理論」と呼ばれる理論をもとにしています。外洋部と比べて、水深が50m以下の浅い領域での津波は、波高が高くなるなどの特徴的な挙動を示します。浅水長波理論ではこのような水深の浅い部分での津波伝播に特有な現象を考慮することで、沿岸部における津波の挙動をより詳細に再現することができます。この浅水長波理論に基づく方程式を、直交格子状のメッシュ上で有限差分法を用いて計算します。
2.ネスティング手法を用いた大規模な範囲での解析
津波の伝播は発生地点から日本沿岸まで100キロメートル以上に及ぶことがあります。ところが100キロメ―トル四方をメッシュ化して計算を行う場合、詳細な分析をしようとメッシュ間隔を小さくすると、膨大なメッシュの数となり現実的な時間でシミュレーションできません。一方で、メッシュ間隔を大きくすると、計算量は小さくなり時間は短縮できますが、詳細な分析が難しくなります。
そこで本ソルバーでは、津波による被害が大きいと思われる沿岸部のメッシュサイズを細かくし、反対に外洋部ではメッシュサイズを大きくして、間隔が大きいメッシュの中に、小さな間隔のメッシュを含ませる「ネスティング手法」を採用しています。この手法によって解析する範囲の規模を小さくすることなく、沿岸部においては小さい間隔のメッシュを用いることで詳細な津波のシミュレーションを行うことができます。また、計算時間の短縮にも貢献します。
3.地震による津波の発生から伝播までの一括シミュレーション
本ソルバーでは、地震の原因となる断層運動から津波の初期波高を計算し、その初期波高をもとに津波の伝播を計算します。
これにより、仮想的な初期波高を設定するよりも、より現実的な津波現象を再現できます。
4.堤防や河川などの沿岸部の細かな再現
本ソルバーでは、堤防の有無を設定することで、沿岸部において詳しいシミュレーションが行えます。また、河川を考慮することで、津波の河川遡上を再現することができます。
本サービスでは、内閣府の「南海トラフ巨大地震モデル検討委員会」で検討された地震をもとに津波解析を行います。
本サービスで解析可能な範囲は、茨城県以南の太平洋側、瀬戸内海、九州地方の日本海側、沖縄地方周辺です。解析可能範囲の全体を図2に示します。図2の範囲において、次の各メッシュサイズの地形データが用意されています。
 |
|
|
10m |
|
|
30m |
|
|
90m |
|
|
270m |
|
|
810m |
|
|
2,430m |
|
| ▲図2 解析可能範囲 |
本サービスでは、津波シミュレーションにより次の結果を得ることができます。
津波が伝わっていく様子のアニメーション
地震発生地域において、津波が発生してからその伝播の様子をアニメーションで見ることができます。
その際、津波が伝播する時間は指定することができます。アニメーション再生にUC-win/Roadを用いることで、360°の様々な角度から津波の伝播の様子を確認することができます。
 |
| ▲図3 宮崎での解析例 |
本サービスで用いる津波解析ソルバーでは、ネスティングといった計算時間短縮のための手法がとられていますが、それでも計算量は大きくなりがちです。そこで、本サービスではFocusが所有するスーパーコンピュータ「Focusスパコン」を用いてシミュレーションを行います。スパコンで計算を行うためにMPIによる並列処理が施されています。
一般のPCでは10日以上かかるシミュレーションでも、Focusスパコンを用いることで5日ほどで計算することができます。
※MPI（Message Passing Interface）
並列処理における標準規格。複数台のコンピュータをまたがる並列化も可能です。
津波解析ソルバーのさらなる高速化や安定化、利便化などを行っていきます。より使いやすく、低コストで津波シミュレーションを実行できるようになることが期待されます。
 |
 |
 |
| ▲図4 UC-win/Road津波シミュレーション |
参考
・気象庁：津波について
http://www.jma.go.jp/jma/kishou/know/faq/faq26.html
・内閣府：南海トラフの巨大地震検討会
http://www.bousai.go.jp/jishin/nankai/model/
|
■ 平成25年度 HPCIシステム利用研究課題 利用報告
「スパコン京におけるレンダリングエンジンの構築」 |
|
京の利用については、トライアルおよび追加応募の本採択において、それぞれ下記の期間で実施してきました。
・トライアル（課題番号：hp130034） 2013/05/17〜2013/11/16
課題名：「フォトリアリスティックレンダリングエンジンを使用した高速レンダリング環境の構築」
・追加応募の本採択（課題番号：hp130093） 2013/10/01〜2014/03/31
これらの結果について、以下のように報告致します。
|
| |
２）トライアル（課題番号：hp130034） 2013/05/17〜2013/11/16 |
オープンソースのレンダリングエンジンである LuxRender が京において動作するかについての検証を目的として、トライアルを実施しました。
FOCUS においては既にLuxRenderの動作が実現しており、３０ノード程度の動作を確認していました。 京においてはノード数が約80000と膨大であり、どの程度まで高速化が見込めるのかについて検証可能な環境にありますが、トライアルではまず
LuxRender を動作させることと、通信のない低並列数での並列化を行いました。最終的に作成した環境において、 FOCUS ではノード数不足により実現できなかった
LuxRender によるアニメーションの作成環境が構築されました。
2-1) 京における LuxRender の移植
京においては、富士通製のコンパイラによるコンパイル実行が基本でしたが、オープンソースでは gcc 、cmake 等でのコンパイルが必要となりました。また、インテル
CPU ではなく、sparc CPU であったために SSE 命令を使用することができませんでした。
まず、cmake や gcc でのコンパイルが可能であるかを調査し、できない部分については独自にツールをインストールするなどしてコンパイル環境を作成しました。次に、SSE
命令をエミュレートするライブラリを作成し、LuxRender に組み込むことにより、最終的に LuxRender のコンパイルに成功しました。
2-2) 通信のない並列化
LuxRender はソケット通信による並列化の仕組みを持っていますが、京においてはソケットは空いておらず通信は MPI で行う必要があり使用できないことが判明しました。そこで、画像を分割して並列化するアルゴリズムを開発しました。図Aは画像分割による並列化の結果画像です。
 |
| 図Aレンダリング結果(bath) |
 |
| 図B 分割数に対する S/pixel |
分割数による高速化は図Bのようになりました。Samples/pixel はピクセルごとのサンプリング数を示します。リニアに高速化されていますが、３０分割程度で画像品質が悪くなり限界となりましたが、高速化のアルゴリズム検証としては良い結果が得られました。
2-3) LuxRender によるアニメーションレンダリング環境の構築
Blender での LuxRender 形式のアニメーション出力を京において高並列でレンダリングする環境を作り、アニメーションのレンダリングを行いました。
 |
| 図C サンプルシーンのレンダリング高速化率 |
図Cはサンプルで作成したアニメーションシーンを京でレンダリングした時の高速化の度合いになります。 横軸はアニメーションを１ノードでレンダリングした場合に掛かる時間、縦軸は京で高並列実行したときの高速化倍率となります。
実際に使用する場合、京の実行には空き状況により待ち時間が発生する場合があります。ここでは実際の使用を想定したため、実行を始めてから結果が得られるまでを測定しました。
一般の PC で行った場合と比較して、待機時間なしで1400 倍程度の高速化が見込まれる結果となりました。
|
| |
３）追加応募の本採択（課題番号：hp130093） 2013/10/01〜2014/03/31 |
追加応募では、静止画１枚の画像を10000ノード程度で並列化し、どの程度の速さが得られるかについて検証を行いました。
LuxRender の並列化には、ライトレイをノード間で分散できる仕組みがあります。しかし、京においてはノード間での通信にソケット通信が使えず、MPI で行う必要があり、コードを大幅に追加する必要があります。
また、高並列化することによりノード間通信が多くなりそれがボルトネックとなり速度が遅くなってノード数を増やしても高速化されない現象が発生しますが、その対策も行いました（I/Oの並列化）。
3-1) 通信の MPI 化による静止画像の高並列化
ノード間通信はソケット通信により行っていましたが、新たに MPI によるエミュレートライブラリを作成し、通信を MPI による通信に置き換えることができました。 この変更により、京での静止画が高並列で実行可能となりました。
 |
| 図D レンダリング結果(port) |
 |
| 図E MPI 通信による並列度における全作業時間 |
全レンダリング時間はレンダリング開始から結果が得られるまでの時間、シーンロード時間は全ノードがシーンをロードし終わるまでの時間、結果集約時間は各ノードの結果を集めて１枚の画像を作成する時間です。実際のノードごとのレンダリング時間は４分にしており、そのため付帯処理(シーンロード時間、結果集約時間)の割合が多く見えていますが、ノードごとのレンダリング時間を増やしても付帯処理の時間に変化はありません、また、並列度を増すと全体のレンダリング量(一ピクセル当たりのレンダリング量
Samples/pixel) の値は向上します。
図では 1000 ノードまで行っていますが、処理時間はノード数に従って上昇しており、ノード数が１０００を越えたあたりでハングアップして停止する結果となりました。
3-2) I/O の並列化
ハングの原因は、１０００ノードものプログラムが NFS の１つのファイルに集中してアクセスすることによる、ファイルアクセスの不具合でした。
そこで、京に備わっているノードごとのファイル分散の仕組みを使用することにしました。事前にノードごとにファイルを分散しておくことで、ノードごとに個別のファイルアクセスとなり、ハングの発生はなくなりました。
もう1つの問題は、各ノードが作成したレンダリング結果を１つの画像にまとめる処理があり、10000 ノードともなると１つ１分としてもこの処理に１００００分かかることになり、現実的に不可能であることが判明しました。
これには、結果画像を隣り合ったノードごとに集約していき、最終的に１つの画像に集約するアルゴリズムをプログラムすることで対策を行いました。これにより、画像の集約時間をO(ノード数) から O(log2(ノード数))とすることができました。
また、ステータス通信などが並列化されていない部分についても、すべて並列化を行いました。
 |
| 図F I/O 並列化後の並列度におけるレンダリング量 |
図FはI/O並列化後の並列度に対するレンダリング量のグラフとなります。10000 ノードまでリニアに速度が向上することが確認できました。
 |
| 図G I/O 並列化後の並列度における作業時間 |
図Gは I/O 並列化後の並列度における作業時間のグラフとなります。各ノードごとのレンダリングは１分しか行っていないため、付帯処理の割合が大きくなっていますが、各ノードごとのレンダリング時間を増やした場合でも変化はありません。
最初はだんだん遅くなりますが、１０００ノードを超えたあたりより、速度がほぼ横ばいになり、10000 ノードまで処理時間の変化が抑えられています。 |
| 今後は、より安定性を高めるための対応が課題となります。最適化がまだ行われておらず、速度の向上が必要です。図Gより、作業時間において結果集約にかかる時間が多くなっており、この部分で改善できると考えられます。 |
|
■ 地盤エネルギーシミュレーション「GeoEnergy」
■ 3DVRクラウド “VR-Cloud®サービス”
- クラウドとスパコンの連携により大量の計算処理およびデータ転送を実現
|
|
.gif)
.gif)
