Article

2018年2月6日

昨年の12月9日に名古屋大学で開催されたオープンCAEシンポジウム2017に投稿と発表をしてきました。

OpenFOAMスレッド並列化のための基礎検討
著者
富岡稔(*)、伊藤優希、丸石崇史、吉藤尚生
講演概要集
HPCセッション、講演番号C22
発表資料

今回は、これらの概要集と発表資料が公開されましたので、そのお知らせを兼ねて、どんな投稿だったのかを少し紹介したいと思います。

今回投稿したオープンCAEシンポジウムとは、オープンCAE学会の主催するオープンCAEに関する大会です。
オープンCAEという言葉はあまり聞き慣れないかもしれませんが、簡単に言うと「オープンソースで開発されているCAE(Computer Aided Enigineering、計算機援用工学)」のことです。
現代においては一般的にソフトウェアがオープンソースでありフリーに利用できるFLOSSであることは大きな価値があります。
特に、機械部品の設計から天気予報まで様々な分野で用いられるCAE分野においては、その計算手法の透明性および結果の検証性という観点から、ソフトウェアがオープンであることは大変重要です。

今回は、そのようなオープンCAEソフトウェアの代表格であるOpenFOAMについて、ソフトウェアをスレッド並列化し計算時間を短縮するための基礎的な検討をおこないました。
OpenFOAMは数値流体力学・連続体力学のオープンCAEソフトウェアの実質的なデファクト・スタンダードとも言えるものですが、現在はフラットMPIによるプロセス並列にしか対応していません。
OpenFOAMが最初に開発された当時はそれでも良かったのですが、しかし、比較的小規模な演算器を大量に並べるというメニーコア化が進む現代のコンピューターにおいて、プロセスによる並列コストは相対的に高いものとなっています。
そのため、軽量プロセスであるスレッドも用いた並列化を導入しハイブリッド並列とすることで、現代的なハードウェアでもOpenFOAMをより高速で利用でき、オープンな環境でも各種応用分野の諸問題をより短時間で解決可能になります。

私たちより以前にもOpenFOAMをスレッド並列化する研究が複数存在しています。ただし、どれもあまり効果がなかったり実装が公開されていなかったりしており、先述の通り少なくとも現在でもOpenFOAM本体にスレッド並列が取り込まれるに至っていません。
未だにスレッド並列化できていない理由については種々の問題があるようですが、OpenFOAMの有識者に聞いたところ「ソフトウェアの構造上難しい、特にオープンCAEの人はソフトウェアや並列化の専門家ではないから」というようなことをおっしゃっていました。
そのようなことを聞きながら私は「これはソフトウェアの高速化を生業としているフィックスターズにとってのある種の挑戦ではないか?」と感じました。
先ほどスレッド=軽量プロセスと書いた通り、プロセス並列ができているのにその軽量版であるスレッドで並列化できないということは原理的には不思議な事です。
一方で、日頃から「私はコンピューターは専門でなく、専門は土木工学・計算力学である」と称している者としても、特に数値流体分野において、それほど分野特有の特殊な事情があるようにも考えられませんでした(事実、私が自作したものも含め、世の中には多くのスレッド並列化された数値流体ソルバーが存在します)。
また、もし仮に本当に難しいのであれば、その困難な原因を明らかにしておくことは、フィックスターズの今後の業務においても、そして計算力学分野にとっても非常に有用なことになるはずです。

ということで、今回、学生アルバイトの富岡さん、伊藤さん、丸石さんに手伝ってもらい、実際にOpenFOAMをどうやったらスレッド並列化できるのかを検討しました(論文の主執筆および発表は富岡さんによる)。
結果は概要集と資料にある通り、手始めとして一部の機能に制限した基礎検討ではありますが、スレッド並列化を原理的に阻害する原因はなく、実際にスレッド並列化するための見通しを立てることができました

今後は、今回つけた見通しのとおりに実際にスレッド並列を実装し、メニーコアプロッサ上での性能測定をしていく予定です。
また、その後、並列化されたコードを公開し、来年度以降のオープンCAEシンポジウム他で引き続き論文を投稿し成果を公開していきたいと考えています。
その折にはまた本ブログ等でお知らせいたしますので、ご期待下さい!

なお本成果は、著者4人以外にも社内有志各位からの助言を得たものです。この場でお礼申し上げます。開発は引き続き社内公開で続行しますので、本記事を読んで新しく興味を持った社内の方はぜひお声がけください。

発表の様子

About Author

YOSHIFUJI Naoki

yoshifujiです。計算力学的なプログラムを高速化することが得意です。プログラミング自体はチョットダケワカリマス。 Twitter: https://twitter.com/LWisteria

4 Comments

  • 自分も研究室でOpenFOAMを使っているのですが、吉藤さんの目から見た感想としてOpenFOAMは「綺麗」なソフトウェアですか?
    ここで言う「綺麗」という言葉の意味は、クラス階層が秩序立っており、run timeでの内部動作のメカニズムを追うことが出来ると言う意味です。
    海外のサイトなどなるべく探してはみたのですが、APIの全体像のようなものを把握させてくれるサイトは今の所見つけられていません。

  • 私もOpenFOAMのプロではないので本当にただの感想でしかないのですが、一言で言えば「今まで見てきたCAE関連ソフトウェアでは上位にあるぐらいの綺麗さだが、一般的なソフトウェアと比べると綺麗と言えるほどではない」と感じています。

    まず、これほど大きなソフトウェア、しかも流体・連続体ソルバーという並大抵ではない複雑さを持ったものでありながら、クラスや関数などのモジュール分離の設計哲学は、ある程度一貫していると思います。書き散らしたものではなく、ソフトウェアとして成り立たせるために必要な骨がしっかりしていると言えばいいでしょうか。

    一方で、クローズドソースの時代、あるいは大学の研究室でFORTRANで書かれていた時の名残もところどころにあり、命名規則やディレクトリ構造などは改善の余地が多分にあるんではないかなと思います。
    また、(使いやすさとのトレードオフなのですが)ランタイムで関数ポインタを使った実行挙動の動的変更などは、保守性や可読性をかなり落としているとも思います。

    OponFOAMのユーザーの多くは、ソースコードの中身まであまり興味がない(知る必要がない)ようで、ソフトウェアとしてのOpenFOAMの全体像を解説する記事は私も見かけたことがありません。ただ、普通のソフトウェアでソースコードの説明書が別に用意されていることはほとんどないですし、読めばなんとか分かるレベルなので、あまり需要もないのかもと思っています。

    • ご返事いただき大変ありがとうございます。
      ディレクトリ構造に関して言及されていますがまさにそれと同じことを自分も感じていまして、クラス間の関係がなかなか見えづらい構成になっています。
      同じCFDでもSU2あたりはかなり読みやすいように感じるのですが、、、
      特に一番難しいメッシュに関して、データ構造やインターフェースに関する説明などがあればあとは相当理解が進むと思うのですが、そんなドキュメントは存在しませんしとてもソースコードを追いきれません。
      FOATRANに関してはもともとそれで書いていたけれど全部データが消えてしまったからC++で書き直したと言う歴史的経緯があるそうですから、「C++のクラスとテンプレートを使ってモジュール化には成功したが、ソフトウェア工学の観点からは適切なアプローチでは組まれなかったコード」と言う感想を抱いています。

      • ソフトウェアとしての質という点もそうですが、そもそもOpenFOAMを使う人たちは(私自身含めて)ソフトウェア屋さんばかりではないので、余計に難解になっているのだと思います。

        ソースコード読解をやりたいという話は、オープンCAE勉強会@関東でもよく話題に挙がりますね。もしご興味ありましたらぜひそちらもご参加ください(たまに弊社が会場になったりしています)
        https://opencae-kanto.connpass.com/

Leave a Comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

Recent Comments

Social Media