finiteVolume系クラスからfvOptions系クラスのメンバ関数のアクセス

[jimi3776]

只今、fvOptions系pressureGradientExplicitSourceクラスの平均圧力勾配gradPをfiniteVolume系のクラスで参照したいと考えています。
上記gradPはクラスの中でprivate変数にされていますが、これは書き換えるわけではないので、参照getterメンバ関数gradP()を作れば外のクラスで活用できるところまでは理解できたのですが、呼び出し側での参照法まで理解が足りていません。
ここで、参照法には、
①pressureGradientExplicitSourceインスタンス？を作って、そこからgradP()関数を呼ぶ。
②pressureGradientExplicitSourceクラスを継承して、this->gradP()で呼ぶ。
と二つの選択肢があると考えていますが、
取り敢えず使う関数はgradP()だけなので、①で十分かと考えていますが、fvOptionsは、finiteVolumeと独立のクラスなので、オブジェクトの初期化:コンストラクタの定義(？ここから怪しいです)のところでコンパイルが蹴られてしまいます。->独立したクラスのコンストラクタを定義するのは、結構数が多いのと定義すべきコンストラクタがよく理解できていない。
(只今、スマホ入力のため、ログなどは示せないでないですが)この辺りを具体的事例などありませんでしょうか？
私の理解が的外れの場合は別として、ご回答へのログ提示などは問題ありませんので、ご回答の方、何卒宜しくお願い致します。

[nakagawa]

jimi3776 さん

なかがわです。興味ぶかい投稿，ありがとうございます。

私もfvOptionsについて知りたいと思っているところです。コードの読み込みは不十分ですが，議論の中で理解が深まればありがたいです。

実装したい機能がどのようなものか分からないところですが，fvOptionsを利用する必要があるのでしょうか？

fvOptions は，基本的には，fvOptions.H冒頭の説明にあるように，ソースorシンク項を式に追加するためのものだと理解しています。

Note:

    On evaluation, source/sink options are to be added to the equation rhs

fvOptions系統のクラスでは，その内部でaddSup関数を使って，受け取った式のソース項に必要な値を入れるためのものだと思います。

ですから，外部クラスでfvOptionsの計算値を取り出して使うということは，本来の使い方から外れると思います。

目的の異なるクラスを改造するのは，設計方針として良くないのではないでしょうか。

本来の趣旨で使いたいのなら，gradPを取り出すのではなく，addSup関数等を修正して，fvOptions内で必要な計算をした値を式に追加するべきではないでしょうか。

あるいは，fvOptionsを使わずに，もともと作成されているfiniteVolume系クラス(？)内で，圧力勾配を計算したり必要な計算をする方が良いのではないでしょうか。

なお，pressureGradientExplicitSourceクラスからインスタンスを生成するという部分も，本来とは異なる使い方と思います。

fvOptionsを使うソルバでは，createFvOptions.Hをインクルードして，fv::IOoptionListクラスのfvOptions (mesh)インスタンスを生成しています。

このインスタンスが，fvOptionsDictから読み取ったtypeのfvOptionsを使う準備をするはずです。

十分な情報が無い状況ですので，的外れなコメントになっていましたら，申し訳ありません。

さらに詳しい方のアドバイスもお待ちしております。

なかがわ

2015年7月9日木曜日 22時35分14秒 UTC+9 jimi3776:

[jimi3776]

fvOptionsを使う理由ですが、今回周期境界を使ってチャンネル流れを発達させたいということはご理解いただけると思います。
このとき、fan境界を使って圧料勾配を指定し同様なことを行うことは可能だと思いますが、この方法だとバルクの平均速度が
結果として出てくる値となってしまい、バルクレイノルズ数を固定したい場合に少し回り道をすることになるので
fvOptionsのpressureGradientExplicitSourceを使いたいということがあります。
（ログを見ればgradPも知ることはできるので、あまり固執することでもないですが）
次になぜgradPを知りたいかというと、上記ソース項を使った方法で流れ場を計算した場合、チャンネル内の圧力は一定となり、場のpから
私の知りたいgradPは得ることができません。->なのでfiniteVolumeクラスのメンバ関数では得ることはできないと考えています。
pressureGradientExplicitSourceの使い方としてgradPを外で使うことが想定されていないことは、.Hを見ればその変数が
private指定されていることから一目瞭然ですが、そのことはあまり気にせず、メンバ関数にgetter関数return (gradP_)を
定義してfv::pressureGradientExplicitSource::correct(U)を呼んだ後にそのインスタンスのgradP()で呼べるのでは？と考えた次第です。
createFvOptions.Hの情報、ありがとうございます。ここでどのようにインスタンスが作られているのかを参考にしたいと思います。
->.Hを見る限り、meshがないと初期化できないのかな？と思っていたところです。

[nakagawa]

jimi3776 さま

なかがわです。

fvOptionsを使う理由ですが、今回周期境界を使ってチャンネル流れを発達させたいということはご理解いただけると思います。

基本的には，通常通りに使いたいということだったのですね。 

次になぜgradPを知りたいかというと、上記ソース項を使った方法で流れ場を計算した場合、チャンネル内の圧力は一定となり、場のpから
私の知りたいgradPは得ることができません。->なのでfiniteVolumeクラスのメンバ関数では得ることはできないと考えています。

ソルバのコードで，gradPを求めるという方法(pressureGradientExplicitSource内と同様に)もあるかと思いますが，2度手間になりますね。 

pressureGradientExplicitSourceの使い方としてgradPを外で使うことが想定されていないことは、.Hを見ればその変数が
private指定されていることから一目瞭然ですが、そのことはあまり気にせず、メンバ関数にgetter関数return (gradP_)を
定義してfv::pressureGradientExplicitSource::correct(U)を呼んだ後にそのインスタンスのgradP()で呼べるのでは？と考えた次第です。

pressureGradientExplicitSourceのインスタンスは，fvOptionsインスタンス内でoptionList内に格納されていると思います。そこから関数を呼べば，欲しい情報は得られそうですね。

　ただし，あらたに別のpressureGradientExplicitSourceのインスタンスを作っても，必要とされている情報は得られないのではないでしょうか。（staticとしてクラス共通の変数にするのもおかしいでしょうし。）はじめのメールでコンストラクタの定義などのお話がありましたが，これがどこから出てきたのかが理解できていません。

 

[jimi3776]

なかがわさま
私のやりたいと考えていることをこれまでの限られた情報でほぼ100%ご理解いただき有難うございます。

fvOptionsの特性上、それに関わるインスタンスの初期化は、ソルバーの初期段階で行うべきで、時々刻々呼ばれるfv::press〜::correctを呼ぶためにその都度初期化するのはまずいと思い、私の使いたいクラスでは、staticでインスタンスを定義した方がいい？(できるかわからん…やったことがない！(^_^;))とか想像していたところです。(ソルバーまで遡って何か呼べるようにするとかも考えました)
要はfvOptionsクラスが呼ばれるときのdictが必要なのだと考えています。
と、ここまで考えてからなかがわさまのコンストラクタの定義の疑問に答えようとした時、上のstatic定義するくらいなら、ローカルに？newでインスタンスを作るのではなく、クラスのメンバ変数にしたり、fv::press〜クラスを継承する方がいいのかな？とも思い直しました。
->この時には、私の作りたいクラスのインスタンスが呼ばれたときのためにコンストラクタが必要だと思います。最初の①と②が今までごっちゃになってました。
このコンストラクタにはやはりdictが重要で、こうなれば、私の派生クラスのDictionaryにfvOptionsと同じ内容を転記するしかないか、と思い始めました。
->私の派生クラスからは絶対にfvOptionsのDictionaryは読めないと判断。
なかがわさまご指摘のようにgradPを二度計算することになりますが、元々独立にやるべきことを同時にやろうとしているので少し不恰好になりそうですが、再利用をあまり考えなくていい？末端派生クラスなのでまぁいいかなと感じる次第です。

[jimi3776]

自己否定です。二度手間というのが、気になり始めました。
(ソルバー改造に手をつけたことがないので曖昧ですが)
OpenFOAMの構造から予測するに、ソルバーは、使われるすべてのクラスのインスタンスが持っていると考えるとfvOptionsのインスタンスからgradPをgetして、私の派生クラスのsetter関数を渡すとgradP計算は1度で済むでしょうか。
同期をどこで取るか、ソルバーの中で適当な場所があるか探してみるのも選択肢かもしれません。

[jimi3776]

前記「setter関数を渡す」ではなく「setter関数へ渡す」が＜正＞です。

[jimi3776]

なかがわさま

私の使いたいソルバーにfvOptions.correct(U);があり、この点が同期点と見定め、

const scalar& gradP=fvOptions.gradP();

でgetし、自分の使いたいクラスのsetter関数へ値を引き渡すことができました。

議論の中で理解が深まっていく感覚がよくわかりました。

この度は誠にありがとうございました。