jgpプロジェクトファイル適合ツール



DEXCS2019に新しく搭載したjpgプロジェクトファイル適合ツールについての説明です。

はじめに

jgp(JAVA gnuplot GUI)は、従来(DEXCS2012)からDEXCS for OpenFOAM に標準搭載されており、その使い方については解説ページにて紹介してあり、個人的にはよく使っているし、お客さんにも重宝してもらっているソフトです。

ただ上記解説ページにも記してあるように何かと注文の多いソフトですが、現時点でもいまだこれに優るGUIツールは見当たらず、開発元からの更新情報もなく、本体には手を付けられそうにないので、インタフェースで改良できないかという着眼です。

問題は何であったのか

さまざまなデータ系列に対して様々なデータ処理方法を定義しておいて、それらをプロジェクトファイルに保存しておける・・・という嬉しさがあるのですが、問題はこのプロジェクトファイルの使い回しが容易でないという点です。

たとえばOpenFOAMのケースフォルダ中でポスト処理をする際に、プロジェクトを保存したケースフォルダ内であれば、計算をやり直した際などプロジェクトを再読み込みして、簡単にグラフを書き直してくれるのですが、ケースフォルダ毎コピーした別名のケースフォルダや、ケースフォルダの名前を変えてしまうと使えなくなってしまうという点です。

課題と対策

その理由は、プロジェクトファイル中でデータファイルを絶対パス名で記録している為です。小職はこれまで、プロジェクトファイルを使い回しした場合に、このパス名をエディタで手修正して使っていたんですが、そろそろ堪忍袋・・・ということで、これを自動修正するスクリプトとして実装したものです。

補足・注意事項など

  • 使用方法は冒頭のムービーをご覧ください。
  • TreeFoamの「十徳ナイフ」⇒「汎用gnuplot-GUI(jgp)の起動」メニューから起動することもできますが、こちらはメッセージダイヤログの日本語表示が出来ていません。
  • OpenFOAMのポスト処理データ(postProcessingフォルダ中のデータファイル)を対象としており、そうでないデータに対しては何ら適合されません。

DEXCS2019 for OpenFOAM(R) リリースノート

解析シーン毎にTreeFoamのサブセット機能(グリッドエディダ等)を、FreeCADのツールボタンで起動できるようマクロ化してあります。

ダウンロードはこちら(2019/10/16〜)



DEXCS for OpenFOAM(R) は、OpenFOAMと、これをより簡単・高度に活用できるようにする為の様々なツールをすべてインストール済のオール・イン・ワンパッケージで、誰でも(と言ってもCAEに無縁の人は対象外ですが・・・)簡単・即使えるようにしたマシンイメージ(isoファイル)です。

詳しくはこちら

DEXCSランチャーのヘルプメニューからも参照できます

DEXCS2019では、

  • ベースOSはUbuntu-18.04.03 (LTS)
    • DEXCS2017まではMintを採用していましたが、再々度、Ubuntuに復帰しました(GNOMEデスクトップに戻った為)。
  • OpenFOAMやその他の組み込みツールのヴァージョンアップに対応
    • OpenFOAM-v1906
    • cfMesh v1.1.2 。

(cfMeshはOpenFOAM-v1712以降、modules としてOpenFOAM本体に組み込まれています)

  • ここまでは通常の毎年更新作業ですが、今回はDEXCSランチャーを仮想風洞試験という題材はそのままで、GUI操作方法を全く作り変えました
  • pyFoam は、OpenFOAM-v1906への対応はアナウンスされておりません。DEXCSランチャーやTreeFoamで使っている機能(pyFoamPlotWatcher.pyやFoamCleaCase.pyなど)についてのみ動作確認しており、その他の機能については動作未確認です。

インストールと利用法

詳しくはこちら(日本語と英語の切り替え方法も含む)

マシンイメージなので、DVDにイメージ書き込みすれば、DVDから起動してそのまま利用することができます。 (DEXCS初体験の人はこのライブDVDとして「まずは使ってみる」方法をお薦めします。)

  • 継続利用では起動後にインストール機能により、HDD等に直接インストールできる上、使用するユーザー名等を選択することができます。
  • VMWare Playerや、VirtualBox等の仮想環境で起動して、仮想環境を作成することも簡単です。
  • VirtualBoxにインストールする方法は、書籍「OpenFOAMによる熱移動と流れの数値解析」の付録AにDEXCS2015について詳しく記されていますが、基本は同じです。また、DEXCS2011までは、”Guest Additions”が入っておりませんでしたが、DEXCS2016では導入済みなので、共有ファイルの設定など(インストール方法メモの24〜26ページ)も同様に実施可能です。
  • 国際化対応のレベルはDEXCS2015に同じ(英語版のみに対応)ですが、日本語⇆英語のベース環境切り替え方法が、DEXCS2015に比べやや煩雑になっています。(インストール方法メモの8〜13ページ)
  • 一部動作に不具合が確認されています(インストール方法メの18〜19ページ)。解決方法が見出だせませんでした。お判りの方、またこれ以外の不具合に気づかれた方はご連絡下さい。

同梱プログラム

その他のドキュメントについて

  • DEXCSランチャーのヘルプメニュー(上図)を参照下さい。
  • SLURMというリソースマネージャは今回もインストールしてありませんが、下記記事の方法によって追加インストールは可能(のはず)です。
  • JAVA gnuplot GUI の使用方法
    • http://dexcs.net/ocse2/?p=747
    • 上記記事で作成したプロジェクトファイルをケースファイルの在所を変えたり、別ケースで転用利用する際に、プロジェクトファイル中に記されているデータ在所(絶対パス名)を適合するツールを同梱しました。
  • 上記適合ツールは、DEXCSランチャーの左図ボタンにて起動します。⇒ 解説ページ
  • または、TreeFoam /十徳ナイフ /「汎用gnuplot-GUI(jgp)起動」メニューでも起動できます。
  • 但し、十徳ナイフ版では、実行時のダイヤログメッセージが日本語ではありません。

  • TreeFoamの基本的な使い方はTreeFoamのヘルプメニューから、「使い方」を参照して下さい。
    TreeFoamに関する情報は、DEXCS公式HPの AboutTreeFoamの記事にまとめてあります。
    DEXCS2019に搭載のTreeFOAMは、+dexcsSwakとして、上記公式ページに掲載ヴァージョンに対して独自のカスタマイズが加えてあります。

苦労譚

  • ParaViewビルド
  • FreeCAD AppImage版
  • FreeCADビルド版
  • リマスター容量の問題
  • /bin/sh の問題
  • VirtualBox Guest Additions

VerUp of FreeCAD on DEXCS2018

現時点で公開されているFreeCADの安定公開版のヴァージョンは0.17で、DEXCS2018 for OpenFOAM(R)にも搭載されているのですが、Arcワークベンチにパイプツールというのがあって、Windows版ではちゃんと機能するんですが、Linux版というかDEXCS上では機能してくれません。

一方、FreeCADには開発版がリリースされており、少し前に入手したVer-0.18やVer-0.19では、上記機能もちゃんと使えたので、これにアップデートし、とある仕事では活用出来ました。

しかし最近のFreeCADのLinuxバイナリ版はAppImageという形式で配布されており、DEXCS2018からもこのAppImageをベースに、メニューなどもカスタマイズされており、アップデートは簡単ではありません。

つまり、基本的には入手したAppImageを直接実行して最新VerのFreeCADを起動できるのですが、それだけではDECXSのメニューバーから起動したり、FreeCADで作成したファイル(.fcstd)を直接ダブルクリックして起動することは出来ないということです。

なお、AppImageUpdateというアップデートツールがあって、これを使うとAppImageそのもののアップデートをやってくれるようですが、現時点ではうまく動いてくれておりません。まぁ、そのうちにちゃんと機能するようにはなると思うので、次回(DEXCS2019〜)はこれを使うという前提でパッケージを考えますが、DEXCS2018の作成時点ではこの情報も知らなかったので、手探りでメニュー回りをカスタマイズしてあり、アップデートが簡単でないのは尚更でした。

そこで以下アップデート備忘録です。

安直なVerUp方法

入手したAppImageファイルを既存のファイル(FreeCAD-13522.glibc2.17-x86_64.AppImage)と同一の名前に変更して使用する。

$ sudo mv [FreeCAD_verUp].AppImage /opt/
$ sudo rm /opt/FreeCAD-13522.glibc2.17-x86_64.AppImage
$ sudo mv [FreeCAD_verUp].AppImage /opt/FreeCAD-13522.glibc2.17-x86_64.AppImage

上記、[FreeCAD_verUp]の部分は、入手して自身の環境で動作確認出来たAppImageの名前に置き換えて実施して下さい。

もう少しちゃんとしたVerUp方法

前項の方法だと、ファイル名でVer確認出来なくなってしまいますね。また、Verを戻すことも出来ません。

入手したAppImageファイルを名前もそのまま使って、DEXCSでカスタマイズしてある部分を書き換えるのが真っ当なやり方でしょうね(カスタマイズの舞台裏備忘録ということです)。ついでに、DEXCS2018では、よく解らないままのやっつけ仕事だったので、次のDEXCS2019では、もうちょっとちゃんとやってみようと、その試行版です。

まずは、カスタマイズの実体を確認。

つまり、freecadというコマンドでFreeCAD-13522.glibc2.17-x86_64.AppImageを実行できるようにしていることと、メニューボタンからAppImageを起動できるように、~/.local/share/applications/appimagekit-freecad.desktopにおいて、AppImageの実体ファイル名(FreeCAD-13522.glibc2.17-x86_64.AppImage)を直接指定してあるということです。

この直接指定をやめて汎用的な名前(FreeCAD.AppImage)で指定する。つまり入手したVerUp版AppImageファイルを/opt/フォルダに移動して、これをFreeCAD.AppImageというシンボリックリンクで参照できるようにしてやれば、VerUpした際に、このシンボリックリンクを作り直すだけで済むとなる。

$ sudo mv [FreeCAD_verUp].AppImage /opt/
$ sudo ln -s /opt/[FreeCAD_verUp].AppImage /opt/FreeCAD.AppImage

異なるVerのAppImageを同梱しておいて、上記シンボリックリンクを作り直す事で使い分けすることも可能になる。

前記カスタマイズファイル中の実体ファイル名の部分を、FreeCAD.AppImageという名前に置き換えるには、以下のようにすればよい。

$ sudo rm /usr/bin/freecad
$ sudo ln -s /opt/FreeCAD.AppImage /usr/bin/freecad

$ sed -e “s/FreeCAD-13522.glibc2.17-x86_64/FreeCAD/g” ~/.local/share/applications/appimagekit-freecad.desktop > ~/.local/share/applications/tmp.txt

$ mv ~/.local/share/applications/tmp.txt ~/.local/share/applications/appimagekit-freecad.desktop


なお、 ~/.local/share/applications/フォルダ中、FreeCAD関連で使用していないdesktopファイルがあり、後の作業で邪魔になるので、これらを削除しておく。

$ rm ~/.local/share/applications/fcstd.desktop

$ rm ~/.local/share/applications/freecad.desktop

おまけ

FreeCADを端末からコマンドラインで起動すると、

と警告が出る。致命的ではなさそうだが鬱陶しい。以下にて解消できる。

$ sudo apt install libcanberra-gtk-module libcanberra-gtk3-module

注記

FreeCADのAppImageは、AppImageUpdateというアップデートツールがあって、基本これでアップデートできるはずだが、現時点では機能していない。

一方、githubのページから主要Ver毎に直接ダウンロード出来るようにはなっているが、Linux版についてはVerに応じてリリース情報があったりなかったりする。1ヶ月ほど前には、

FreeCAD_0.18.16093.glibc2.17-x86_64.AppImage 

を入手できたが、現在(2019/4/10)ではそのリンクは存在せず、

FreeCAD_0.19.16207_Conda_Py3Qt5_glibc2.12-x86_64.AppImage

が使えている。

筆者の環境では、一応どちらも動いてくれてはいる。一応としたのは、環境によって、具体的には、

  • 仮想環境かそうでないかの違い
  • 仮想環境の違い(VMPlayer / VirtualBox / …)
  • ライブモードかそうでないかの違い
  • グラフィック3Dアクセラレータの使用有無

等の違いによっては動かない(すぐ落ちる、あるいは固まってしまう)事もあるということ。上記2つのヴァージョンの動作も、これらの環境次第で挙動が変わる。

したがって、実際に使用予定の環境での動作する事を確認してからインストール作業することを推奨する。

SLURM on DEXCS2018 for OpenFOAM(R)

諸般の事情により、DEXCS2018ではSLURMを搭載していないので、ここにインストールと設定方法を記しておきます。

インストール方法

普通にパッケージインストールが可能になりました。

$ sudo apt install munge slurm-wlm

というか、これまでは認証を秘密鍵方式でやっていたのを、デフォルトのMUNGEでも出来るようになり、設定がだいぶ楽チンになりました。

(実はこれまでもMUNGEで出来るはずだったのが、うまく動かせていなかっただけの事なんですが・・・)

設定(slurm.conf)

SLURMの設定ファイルは、/etc/slurm-llnl/slurm.conf として、以下の内容を記述(コピペ)しておく(要管理者権限)。

# slurm.conf file generated by configurator easy.html.
# Put this file on all nodes of your cluster.
# See the slurm.conf man page for more information.
#
ControlMachine=localhost
#ControlAddr=
#
#MailProg=/bin/mail
MpiDefault=none
#MpiParams=ports=#-
ProctrackType=proctrack/pgid
ReturnToService=1
SlurmctldPidFile=/var/run/slurm-llnl/slurmctld.pid
#SlurmctldPort=6817
SlurmdPidFile=/var/run/slurm-llnl/slurmd.pid
#SlurmdPort=6818
SlurmdSpoolDir=/var/lib/slurm-llnl/slurmd
SlurmUser=slurm
#SlurmdUser=root
StateSaveLocation=/var/lib/slurm-llnl/slurmctld
SwitchType=switch/none
TaskPlugin=task/none
#
#
# TIMERS
#KillWait=30
#MinJobAge=300
#SlurmctldTimeout=120
#SlurmdTimeout=300
#
#
# SCHEDULING
FastSchedule=1
SchedulerType=sched/backfill
#SchedulerPort=7321
SelectType=select/cons_res
SelectTypeParameters=CR_CPU
#
#
# LOGGING AND ACCOUNTING
AccountingStorageType=accounting_storage/none
ClusterName=localhost
#JobAcctGatherFrequency=30
JobAcctGatherType=jobacct_gather/none
#SlurmctldDebug=3
SlurmctldLogFile=/var/log/slurm-llnl/slurmctld.log
#SlurmdDebug=3
SlurmdLogFile=/var/log/slurm-llnl/slurmd.log
#
#
# COMPUTE NODES
NodeName=localhost CPUs=4 Sockets=1 CoresPerSocket=4 ThreadsPerCore=1 State=UNKNOWN
PartitionName=debug Nodes=localhost Default=YES MaxTime=INFINITE State=UP

太字部分は、自分のマシンのスペックに合わせて変更しておいて下さい。

SLURMの起動

$ sudo systemctl enable slurmctld
$ sudo systemctl start slurmctld
$ sudo systemctl enable slurmd
$ sudo systemctl start slurmd

動作確認方法

うまく動かない時

/var/log/slurm-llnl/ の下に、ログファイルが出力されているので、これを読めば何とか対処できるんでないかと思います。

自分の経験では、slurm.confの記述間違いに起因するエラーが大半でした。

また、sinfo コマンドでSTATEが drain と表示されていると、ジョブを投入してもペンディング状態のまま、いつまでたってもジョブは実行されません。

この場合、ペンディングされたジョブをキャンセル(scancel)して、

$ scancel <job-id>

$ sudo scontrol update nodename=localhost state=idle

実行スクリプトの例

#!/bin/bash
#SBATCH -n 4
#SBATCH -J OpenFOAM
#SBATCH -e submit.sh.e%J
#SBATCH -o solve.log
. /opt/OpenFOAM/OpenFOAM-v1806/etc/bashrc
rm -rf ./processor*
cartesianMesh
checkMesh
pyFoamDecompose.py . ${SLURM_NPROCS}
mpirun simpleFoam -parallel
reconstructPar -latestTime

諸般の事情

基本的には、SLURMの設定方法がよくわからないというか、すんなり動いてくれないという点です。

普通には、

file:///usr/share/doc/slurmctld/slurm-wlm-configurator.easy.html

をブラウザで開くと、

ここで、色々設定してSubmitボタンを押すだけで良いはずなのですが・・・

今回も、下記のセクションにて、デフォルト(Linear)

はうまく動いてくれたのですが、これだとひとつのノード(CPU)に一つのジョブしか投入できない。マルチコアCPUでコア数をすべて有効に使うには、Cons_res を選択するのが一般的ですが、これに変更するとうまく動いてくれない、という状況でした。

ちなみに、現時点でパッケージインストールされるslurmのヴァージョンは、17.11.2であるのに対し、上記設定ツールで対象としているのは、16.05とあります。これが原因なのかどうかわかりませんが、最終的には上記ログファイル中にCRパラメタがなんたらというメッセージがあったので、

SelectTypeParameters=CR_CPU

の1行を追加して、今のところ動いているという状況です。

ちなみにこの一文は、上記ツール上では、以下のように

メニューとして選択可能になってはいるのですが、submitしても何故か出力してくれませんでした。やむなく手入力で追加したという顛末です。

マシンのスペック確認方法

論理プロセッサ数
$ cat /proc/cpuinfo | grep “processor”
⇒ CPUs
物理CPUの数
$ cat /proc/cpuinfo | grep “physical id” | uniq
⇒ Sockets
物理コアの数
$ cat /proc/cpuinfo | grep “cpu cores” | uniq
⇒ CoresPerSocket