バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はダミーFMUに向けての大雑把な方針を提示。
- ダミーFMUの作り方のアタリを付ける
- ダミーFMUの利用方法を決める
- 実際にダミーFMUを使ってみる
- ダミーFMUでシミュレーション時間と実時間を合わせて見る
まずは「ダミーFMUの作り方のアタリを付ける」に当たって
FMUのロード時の関数引数である_connect_dllに着目。
しかし、これを利用しても時間の制御はできなさそう。
というわけで、実は別のロードの仕方があるのでは？
という観点でいろいろ調べた結果の話となる。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
FMUロード関数整理
前回のFMUのロードの仕方だと時間制御はできないってことだったけど、
他に目的にあったロードの仕方があるの？
まずは一旦FMUロード関数を整理してみよう。
ほう？
何種類かあるんだっけか？
うん。
PyFMIのソースコードを漁って見つけてきた、
(「ソースコードを漁って」って・・・。)
とりあえず列挙しよう。
- FMUModelCS1
- FMUModelME1
- FMUModelCS2
- FMUModelME2
- Dummy_FMUModelCS1
- Dummy_FMUModelME1
- Dummy_FMUModelCS2
- Dummy_FMUModelME2
ダミー系のFMUモデル定義
あれ？！
DummyなんとかってのがそれぞれのFMUモデル別に存在してる！！
そう。
どうやら元々はPyFMI自体のテスト用のモックを作るのが目的っぽいのだが、
構造としてはFMUに見える構造になってるんだよね。
ということはこれを使えば今回の目的の時間制御ができるってこと？
まぁ可能性はあるだろう。
とりあえず、Dummy_FMUModelCS2を題材として紐解いていこう。
Dummy_FMUModelCS2
まず定義は以下になってる。
class Dummy_FMUModelCS2(FMUModelCS2):んー？
Dummy_FMUModelCS2がクラスなのはわかるが、
その後ろのFMUModelCS2は何をあらわしてるんだろう？
これはPythonに於いてのクラス継承だね。
FMUModelCS2を継承してDummy_FMUModelCS2を定義しているってこと。
内部のパラメータやメソッドをある程度使い回してることになる。
なのだが、
結構オーバーライドしてるね。
オーバーライドしてる中で割と重要なのが以下。
cpdef int do_step(self, FMIL.fmi2_real_t current_t, FMIL.fmi2_real_t step_size, new_step=*)
↓
def do_step(self, current_t, step_size, new_step=True):これをオーバーライドしてると何が重要ってことになるの？
元々のdo_stepがcpdefなのがちょっと問題で、
これだと外部から上書きができない。
上書き？
利用する側がメソッドの中身を書き換える。
そもそもどうしてメソッドの中身を書き換える必要があるのかがわからないんだけど・・・。
うーん、そこは次回説明しよう。
まとめ
まとめだよ。
- FMUロード関数を一旦整理。
- Dummy_*という謎関数が各FMUタイプ別に存在。
- Dummy_FMUModelCS2を題材として掘り下げ。
- FMUModelCS2を継承している。
- オーバーライドしているメソッド多数。
- 重要なのはdo_step。
- cpdef定義なので外部から上書きできないのを回避している。
バックナンバーはこちら。
コメント