OpenFOAMのcase fileをgitで管理する
お久しぶりです。くれなゐです
gitをソースコードの管理以外で使ったことがない方っていませんか?
gitは非常に便利なツールで、様々な履歴を残すことができます。
今日はOpenFOAMのケースファイルを例に、ソースコードだけじゃないんだぞと言うところをお見せしたいと思います。
このブログの対象
git
の使い方をまだ良くわかっていない人- ソースコードの管理以外に
git
の使用価値を見いだせない人 - OpenFOAMの計算条件の履歴を残したい人
バージョンを管理する対象
今回も、いつものcavity
を使用しています。
OpenFOAMのバージョンはちょっと古いですが2.4.0を使用しています。
gitのバージョン管理をする本質ではバージョンはあまり関係ないと考えています(blockMesh等のパスは少し変わりますが…)
OpenFOAM/OpenFOAM-2.4.0/tutorials/incompressible/icoFoam/cavity
あと忘れないうちに
blockMesh
しておきましょう
まずは init, first commit
init
gitでバージョン管理していくために、まずはバージョン管理の環境を用意してあげる必要があります。 それをするコマンドが
git init
です。
こんなメッセージが出てればOKです
Initialized empty Git repository in /home/kurenaif/Desktop/cavity/.git/
add
とりあえず今の状態をcommit
しておきましょう
commitとは簡単に言うとセーブポイントを設置するような感じです。こうしておくことあとでこの状態に復元できますね。
commitをする前に、どのファイルをコミットするか選択しなければなりません。それがadd
になります。すべてのファイルをadd
する場合は、
git add --all
などとしましょう。
status
add
をしたら、 statusを確認しましょう
git status
add
されたファイルが確認できます。
On branch master Initial commit Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: 0/U new file: 0/p new file: constant/polyMesh/blockMeshDict new file: constant/polyMesh/boundary new file: constant/polyMesh/faces new file: constant/polyMesh/neighbour new file: constant/polyMesh/owner new file: constant/polyMesh/points new file: constant/transportProperties new file: system/controlDict new file: system/fvSchemes new file: system/fvSoluti
commit
commitメッセージは必ず付けなければなりません。 commitメッセージは、その変更に対する理由付けだとかそういうものです。あとでこのコミットメッセージを参照して、必要なときに戻ってきたりするわけです。 たとえば、今回の場合、「計算が回ってくれた」「良い計算結果が出た」、「前つまっていたTimeが突破できた」 などなどといったケースで使うことができます。
最初のcommitはfirst commit
とすることが通例です。(これも流派があるので、一概にfirst commitではないです。)
git commit -m "first commit"
計算結果をバージョン履歴に残さないようにする
これで最初の準備が整いました。それではicoFoamを実行しましょう。
icoFoam
blockMesh忘れてなければ実行できると思います。忘れてたらblockMeshしてからicoFoamしましょう。
計算結果は出ましたが、これは私はバージョン管理対象に含めるべきではないと考えています。(というのは、ファイルが膨大になることがおおいため、.gitディレクトリが大変になることが予想される)
では、計算結果がgit add --all
の対象に含まれないようにしてあげましょう
そのために、.gitignore
を設定します。
現在、
git status
を見てみると、
On branch master Untracked files: (use "git add <file>..." to include in what will be committed) 0.1/ 0.2/ 0.3/ 0.4/ 0.5/ nothing added to commit but untracked files present (use "git add" to track)
このようになっています。このメッセージは、add
されてないよーという趣旨ですので、これからの目標はstatus
をした時にこいつらを消してやることにあります。
消すためには、以下のように.gitignoreを書きます。 .gitignoreファイルがない場合は、ファイルを作ってディレクトリに配置しましょう。
[0-9]*/ !0
そしてふたたび
git status
をすると、
On branch master Untracked files: (use "git add <file>..." to include in what will be committed) .gitignore nothing added to commit but untracked files present (use "git add" to track)
というメッセージが出てきます。 .gitignoreがaddされてないよーというメッセージですね。 .gitignoreはバージョン管理したほうがいいので、追加しましょう
git add .gitignore # .gitignoreを選択 git commit -m "[add] git ignore" # コミット
ではここでgit logを見てみましょう
git log
commit 6a3b160619f88ec23816b707e32e61b2ade96848 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:08:56 2017 +0900 [add] git ignore commit 30351f767bce8d5665d0a1dc95f3d1a35fa1d927 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:00:40 2017 +0900 first commit
2つのコミットが確認できますね
では、計算条件を変えてみましょう。
変更を加えてそれをcommitする
流速を100m/sにしてみましょうかね
0/Uの該当する部分を100m/sに変更してみましょう。
そして、
git diff
コマンドを入力します。 すると前回の計算と今のどこが違うのかわかるようになります。
diff --git a/0/U b/0/U index a12d708..5a2a2a0 100644 --- a/0/U +++ b/0/U @@ -23,7 +23,7 @@ boundaryField movingWall { type fixedValue; - value uniform (1 0 0); + value uniform (100 0 0); } fixedWalls
解説不要ですね。では
icoFoam
計算は止まります。流速が早すぎるからですね では、その旨をコミットしてみましょう
git add --all git commit -m "流速を100m/sに変更 計算が止まりました。" git log
commit b699f012c914037fb499dad001737234cbe2478f Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:18:28 2017 +0900 流速を100m/sに変更 計算が止まりました。 commit 6a3b160619f88ec23816b707e32e61b2ade96848 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:08:56 2017 +0900 [add] git ignore commit 30351f767bce8d5665d0a1dc95f3d1a35fa1d927 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:00:40 2017 +0900 first commit
追加されましたね。
計算が失敗したので、計算が動いていた頃に戻したいです。そういう場合はgit reset
を使用します。
"[add] git ignore"のcommit id が "commit b699f012c914037fb499dad001737234cbe2478f" となっていますので、最初数文字をとって
git reset --hard 6a3b160
としてやります。このidは人によって違うと思うので、自分でlogをして確認してください。 0/Uのディレクトリを見ていると、確かに流速が1m/sに戻ってますね。
ではもう一度icoFoamを実行してみましょう
icoFoam
計算が回りましたね。
ケースファイルをコピーして編集してみる
こういう事例、ありませんか?
ある計算Aの計算結果がイマイチでした。 原因の候補はいくつか思い当たるのですが、どれが正しいのかはわかりません。
よくある話だと思います。 この際によくやる手続きとして、
- 計算結果を"含めずに"コピーを行う
- 編集を行う。
- 良かった結果を今後採用する
があると思います。
では順番にやっていきましょう。
計算結果を含めずにコピーする
計算結果をgitignoreしてますので、実は
cd .. # gitで管理してるディレクトリの一個上へ git clone cavity cavity-A git clone cavity cavity-B
こんな感じで複製できます。計算結果は入っていないはずです。
編集を行う。
それでは、cavity-A
を編集しましょう。
cavity-Aでは、出力タイムステップを短くしてみましょう.
このように、cloneしてファイルを編集する場合は、branchを切ります。利点は後でわかります。
バージョンが枝分かれするイメージですね
git checkout -b fine-delta
こうするとfine-delta
というブランチを作ってそのブランチに移動することができます。
master
に戻りたいときは
git checkout master
となります。移動したらまたfine-deltaに戻っておきましょう
git checkout fine-delta
では、controlDictを以下のように編集して
diff --git a/system/controlDict b/system/controlDict index 084dc33..b8f6631 100644 --- a/system/controlDict +++ b/system/controlDict @@ -25,7 +25,7 @@ stopAt endTime; endTime 0.5; -deltaT 0.0005; +deltaT 0.005; writeControl timeStep;
icoFoam # ねんのため確認 git add --all git commit -m "出力タイムステップを短くしました"
良かった結果を今後採用する
よいな!と思ったら元のディレクトリに変更に還元しましょう
git push origin fine-delta
これはfine-deltaブランチを元のディレクトリにアップロードするという意味です。
元のディレクトリはmasterブランチ(デフォルト)で作成してますので、新しくブランチが生成されます。(即座にmasterに反映されるわけではありません。)
cavity-Bでも変更する
cavity-Bでも同湯に変更を加えます。 今回はmesh幅を変えましょう
diff --git a/constant/polyMesh/blockMeshDict b/constant/polyMesh/blockMeshDict index aac305a..5fdcfd2 100644 --- a/constant/polyMesh/blockMeshDict +++ b/constant/polyMesh/blockMeshDict @@ -30,7 +30,7 @@ vertices blocks ( - hex (0 1 2 3 4 5 6 7) (20 20 1) simpleGrading (1 1 1) + hex (0 1 2 3 4 5 6 7) (40 40 1) simpleGrading (1 1 1) ); edges
倍細かくなりましたね
git checkout -b fine-mesh blockMesh icoFoam git add --all git commit -m "メッシュを細かくしました" git push origin fine-mesh
元のディレクトリで変更を反映する
cd .. cd cavity # もとのディレクトリ git br
とすると、
fine-delta fine-mesh * master
となっていることがわかります。 時間間隔を短くしたやつとメッシュを細かくしたやつがいますね。 ここから
git checkout fine-mesh
とすると、メッシュが細かい計算のケースファイルに移行しますし、
git checkout fine-delta
とるすと出力の時間間隔が短い計算のケースファイルに移行することができます。 もちろん
git checkout master
とすると、大本の状態にもどることができます
さて、それでは変更をmasterに反映します。反映するためには、merge
を使います
git checkout master # masterに移動 git merge fine-delta
これでmasterに時間間隔が短くなる変更が適応されました。
git log
commit 39611f0253452a1165b26b62fa358435e41cac2c Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:31:28 2017 +0900 出力タイムステップを短くしました commit 6a3b160619f88ec23816b707e32e61b2ade96848 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:08:56 2017 +0900 [add] git ignore commit 30351f767bce8d5665d0a1dc95f3d1a35fa1d927 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:00:40 2017 +0900 first commit
logを見てもいい感じですね。 実際に実行してみると
icoFoam
確かに時間間隔が短くなってます。
mergeができたものは削除してOKです
git br -d fine-delta
それでは、メッシュの方も反映しちゃいましょう
git merge fine-mesh
先ほどとは違い、なんかテキストエディタが出てきますが今回は気にせず閉じちゃってOKです
これは"mergeが走る"という現象ですが、説明するのはそろそろ手がつかれたので割愛します。 変更が衝突したりした時に、いろいろしなければならくなるやつです。(例えばcavity-Aとcavity-Bで同じUを編集した場合、どちらを採用するのか等)
git log
をみてみると
commit 24e3b70e11e407086533ed4ae9d42b096d71e6e3 Merge: 39611f0 35c342c Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:49:32 2017 +0900 Merge branch 'fine-mesh' commit 35c342c111ecd706f10b0bf6c0fdbc8a28800578 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:43:17 2017 +0900 メッシュを細かくしました commit 39611f0253452a1165b26b62fa358435e41cac2c Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:31:28 2017 +0900 出力タイムステップを短くしました commit 6a3b160619f88ec23816b707e32e61b2ade96848 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:08:56 2017 +0900 [add] git ignore commit 30351f767bce8d5665d0a1dc95f3d1a35fa1d927 Author: kurenaif <antyobido@gmail.com> Date: Thu Nov 2 14:00:40 2017 +0900 first commit
のように、なんか変なのが混じってますがメッシュを細かくした内容が反映されています。
icoFoam paraFoam
とすると、確かに時間ステップも短いし、メッシュも細かいケースができました。
おわりに
研究する上で、研究ノートやログを取る。という試行錯誤を残すことは非常に重要なことです。 今回のように、gitを使えば、直接ファイルを見ながらバージョン管理できますし、コメントアウトしながら計算条件をバックアップする必要はなくなります。
commitごとに計算結果を残しておきたい場合は, commit idに対応したディレクトリを用意して、gitignoreすると良いでしょう。 そのcommit idに対応したcommitに移動した時にそれを戻してくればいいです。
このようなgitの使い方はまだまだ初歩の初歩で、git-flowやgitHubを有効にあつかったGitHub-Flow. 編集の衝突などちょくちょく問題が起きるのでそれの対応が必要になります。
もしこの記事がgitの使用価値について気づける機会になれば幸いです。