昔OpenFOAMのGUIを作ったときのことをメモする

昔OpenFOAMのGUIを作ったときのことをメモする

 昔OpenFOAMの設計者向けGUIを開発する仕事をしていた時、気を付けていたことを今後のためにメモることにした。片手間にGUIを開発していたのと、専従者ではなかったので色々と苦労したことも書くことにした。

 まず、当時開発していたGUIの仕様を簡単に説明する。①指定したフォルダで②指定したSTLの形状に対して、周辺を囲む領域を作り③メッシュを作成し④入力された境界条件、物性に従って⑤計算を実行し、⑥結果の画像を出力する。割とベーシックな設計者向けワンオフGUIの仕様だと思う。

 以降は開発時に気にしていたことの中で今でも覚えている重要なことを書いている。

GUIを何で作るか

 最初は非常に簡単なパラメータ変更だけの仕様だった。仕様を以下に示す。

・計算実行フォルダのパス
・STLファイルのパス、スケール
・入口流速、k、omega
・物性(動粘性係数)

 言語としては社内でのメンテナンスを考えて、Pytonにした。対象OSがLinuxだったので、この選択はそう悪くないものだったと思う。で、tkで作ることにした。これは悪手だった。後の改修を考えていなかったのである。


 仕様の増加とともにtkでは厳しくなってしまったため、PySideに切り替えた。書き換えにはそこそこの時間を要した。


 PySideはグラフィカルなエディターが内蔵されており、レイアウトをtkに比べて非常に簡単に構築できた。また、スロットの考え方は理解に少し時間を要したが、慣れればそれほど難しいものではなかった。

機能は単機能の集合で作成する

 GUI開発をやっている方でAPIとかも考えている人からすると当たり前かもしれないが、とにかく関数は単一の機能で実装するように心がけた。複雑な処理は関数を組み合わせて作るように設計をした。当時は部内でこういったコーディングをしている人間はいなかったので、受け入れられるまで時間がかかったが、最終的にはいい判断だったと思う。

 例えばOpenFOAMではDictファイル内のパラメータを書き換える処理が必要になるが、括弧が入れ子になっている構造のデータがたびたび登場する。この時に当時の部署では括弧1つ用、2つ用と関数をケースバイケースでそれぞれ別々に実装していた。非常にナンセンスだった。

 「括弧内の特定のキーワードの行を書き換える」という関数があれば再帰的に呼び出すことで、ファイルの書き換えができる関数がコンパクトに出来上がる。こういったプログラミングの技法が伝承も伝達もされていない部署だったので、いろいろなソースを見たり、書籍をあさったりして技法を身に着けることに終始する時期が一時あったが、今となってはそれも自分の財産になっている気がする。

複数人開発の時は最低限のコーディングルールをもうける

 社内の思惑で他の人間も開発に参加させることになった。このときに発生したのは、作業者毎にネーミングが異なってしまうという点だった。私はスネークケースで名前を書くが、合流した人間はキャメルケースだった。出来上がったのは命名規則がバラバラのソースコードだった。お互い変数なのか関数なのかがわからないソースコードになったので、統一することになった。これにも工数がかかってしまった。

中間ファイルは手抜きしてはいけない

 GUIで入力されたパラメータは中間ファイルに落として保存することにした。この中間ファイルがあると次にGUIを起動したときにパラメータ類を引き継いで表示させる(作業コンティニューできる)仕様にしていた。この方法は悪くないと思っていた。

 ただし中間ファイルの記法を間違えた。カンマ区切りの連続データにしてしまった。ユーザーサイドで簡単にいじれないようにということで、わかりにくい気泡を選択したが、結果、作業引継ぎ時に後任者が混乱する基になった。

 今思うと作った人間(=私)しかわからない仕様のファイルになっていたので、JSONやXMLなど構造を持ったファイルにすべきだった。後に趣味で作ったCode-Aster用のGUIではこの反省を生かして、コンフィグファイルをちゃんと作った。

https://github.com/mmer547/wizaster-gui/blob/master/config.ini

バージョン対応

 あきらめた。互換性は捨てていく方針をとった。ここに関しては互換性を維持する方法についてもっと調べていきたいと思う。

結果出力

 ParaViewのスクリプト実行で自動的に画像ファイルを出力するようにした。困った点はカメラワークだった。試験体と実機で10倍ほどの長さの違いがあり、ParaViewで画像出力するときにカメラが両方に対応した動きをしなくて非常に困った。画像を見ると、極端に小さく映っているか、見切れているかのどちらかになっていた。当時は補正係数を入れてカメラのズーム具合を調整していたが、汎用的ではなかった。ParaViewのカメラポジションとフォーカルは現在も課題になっている。

まとめ

 覚えていることをつらつらとメモった。こういった開発途中の話はおおよそ自分の手から離れた段階でどんどん忘れていくので、なるべくメモを取るようにしていこうと思う。手が覚えている経験なら忘れにくいが、頭で覚えている経験はふとしたタイミングで思い出せなくなるので、チラシの裏ではないが後で参照できる場所に書いていこうと思う。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ありがとうございます
CAEやったりプログラム書いたりしてる人です。オープンCAE勉強会@関西の幹事。サークル「はんままにあ」のページはこちら→https://hammamania.tech/ 勉強会についてはこちらから→ https://ofbkansai.sakura.ne.jp