pointwiseによる格子生成、及びpimpleDyMFoamでのプロペラ回転計算の再現

454 views
Skip to first unread message

simano

unread,
Jun 16, 2021, 1:52:09 AM6/16/21
to OpenFOAM
お世話になります。simanoと申します。

現在、pimpleDyMFoamを用いてプロペラの回転を再現しようと考えています。
具体的には静止領域の内部に回転領域(プロペラ回転領域)が存在する解析条件です。

はじめに、私の場合pointwiseを用いた格子生成を前提としております。
次に、今後プロペラの回転を派生させた場合のことを考慮し、AMI機能の使用を検討しています。

計算領域を簡単にご説明しますと、添付画像のように六面体の領域の内部に、円柱の回転領域を含んでいる状況です(AMIによる回転を第一目的としているため画像のプロペラはただのデータのみであり今回は格子に関係しておりません)

本解析はpointwiseからopenFoam仕様にpolyMeshで出力し、その後AMI境界の設定に苦難し、解決方法を模索したのですが、未だ解決に至らなかったため、ご質問させて頂きました。

以下、試行錯誤した手順になります。
1. pointwiseにより回転領域と静止領域を作成し、polyMeshで出力
   回転領域の境界条件は  cyclic にしており、その静止領域の境界は添付資料の通りです
2. topoSetによりダミーのfaceSetを作成
3. createpPatchによりAMi1,AMI2を仮想的に作成(??)
4. 回転面の設定をしようとcreateBaffleを試みるが、エラー

といった流れになります。
過去のAMIを用いた計算例を調査していましたがコマンドが変化していたり、pointwiseからcyclicの境界条件を設定できるようになったりと、以前と変化している部分が見られ、どのような流れが現在では主流なのかが分からず困惑しております。

最終的な流れとしては、回転領域をcellzoneとして設定し、それをdynamicMeshDictの中に記載し、pimpleDyMFoamで計算するということは理解しているのですがcellzoneの設定までが理解できていないため、皆様からアドバイスを頂きたいと思っております。


topoSetとcreatePatchは添付資料の通りです。




境界条件.pdf
Dictの記述.pdf
全体領域.png
回転領域の拡大図.png

simano

unread,
Jul 13, 2021, 6:03:42 AM7/13/21
to OpenFOAM
お世話になっております。

前回の投稿から依然として回転計算が行えずにいます。
実際は計算は回っているものの、境界の初期値がおかしくなってしまい、計算結果が不確かなものになっている状況です。

簡単にご説明しますと、試行錯誤していく中で前回とは少し異なる方法でアプローチしました。
手順としては
1, pointwiseにより回転領域と静止領域を作成し、polyMeshで出力
　この時のboundryファイルが図1,図2になります。
2, renumberMeshを行う
3, topoSetで回転領域となるcellzoneを作成　(topoSetDictが図3です)
4, mergeMeshにより２つのメッシュを結合する
5, changeDictionaryによりboundryのAMI1,2のtypeをpatchからcyclicAMIに変更(changeDictionaryDictを図4に添付します)
6, dynamicMeshDict内に回転領域となるcellZone名を記述し、pimpleDyMFoamを実行

このような手順の元行なってみると、計算は回りますが、ただの空っぽの回転メッシュを直方体内部で回転させているだけなのに
速度分布、圧力分布に変動があり流れが乱れてしまっています。（図５；中心付近に存在する円が回転領域の円柱の断面になります）
その後原因を調査したところ、changeDictionaryにて　手順5を行ったところから回転領域となるcellZoneにあり得ない速度分布(図6)が与えられていることがわかりました。
  圧力分布などは0のままですが、なぜか速度分布だけこのようになり、これが原因となり計算中でも流れの乱れに繋がっていそうです。
手詰まりとなり、非常に苦労しております。どなたかお力添えしていただければ幸いです。



2021年6月16日水曜日 14:52:09 UTC+9 simano:
図６cellzone表面の異常な速度分布.png
図３topoSetDict.png
図４changeDictionaryDict.png
図５計算終了後の断面.png
図１回転領域boundry.png
図２静止領域boundry.png

haruka tsubota

unread,
Jul 13, 2021, 9:02:48 AM7/13/21
to OpenFOAM
使用しているOpenFOAMのバージョン情報と問題の起きるデータ一式が無いと誰も回答はできないのではないでしょうか。

そもそもOpenFOAMユーザーでpointwiseを使っている人の割合も高くは無いと思うので、お金を払ってプロプライエタリなソフトウェアを使用しているのであればお金を払っている先のサポートに質問した方が確実だと思います（pointwiseのベンダーがそうしたサポートをしているのかは知りませんが）。

参考までに Foundation版 OpenFOAM 8 での手順の1例（自分がよくやるやり方）を書くと

1. snappyHexMesh でメッシング。その際に回転させたい領域を定義しておき、フェイスゾーンとセルゾーンを作成しておく(snappyHexMeshDict使用)。
2. createBaffles でフェイスゾーンからバッフル（内部壁）を作成。バッフルには「cyclicAMI」を設定しておく（createBafflesDict使用）。
3.「mergeOrSplitBaffles -split」でバッフル部を切り離して、静止側メッシュと回転側メッシュに切り分ける
4. dynamicMeshDictを配置してpimpleFOAMで実行

となります。その他fvSolutionにpcorrを定義とか、0/UでmovingWallVelocityを設定とか細かい編集は必要ですが、そのあたりは無ければpimpleFOAMの実行時にエラー メッセージ が出るのでその都度対応すればいいかと思います。

なおFoundation版の最近のバージョンではpimpleDyMFoamは廃止されてpimpleFOAMに機能が吸収されているはずです。

2021年7月13日火曜日 19:03:42 UTC+9 simano:

simano

unread,
Jul 13, 2021, 11:11:40 AM7/13/21
to OpenFOAM
アドバイスいただき誠にありがとうございます。
確かに仰る通り一度pointwiseのサポートに掛け合ってみようと思います。

引き続き貴重なご意見いただきたいと思っておりますので、より詳細な情報を記させていただきます。

OpenFOAMのバージョンはOpenFOAM-4.x を使用しております。
少し古いバージョンかと思いますので、バージョンアップも検討しております。

また、pointwiseを使用する理由としてはモデル形状がやや複雑なため、snappyを用いたメッシュ作成が少し困難であると判断し変更しております。
(今回はAMIによる計算の実行を確認するための計算ですので、モデルは含んでおりません)

また
pointwiseにより格子データはpolyMeshデータとしてboundry,face,owner、、、といった形で出力されております。
回転、静止領域は別々に出力するものの、すぐにマージさせ１つのpolyMeshデータとして扱うことになるので、参考にマージ後のboundryファイル(図１)を添付させていただきます。ここでのAMI1は回転体側(円柱側の境界面)、AMI2は静止領域側(円柱を囲う直方体側の境界面)として定義しています。

ここからの流れは　過去のzukki様の[AMI境界付近の結果の不連続に関して]　https://groups.google.com/g/openfoam/c/S5WsjYF0lFw/m/7YXaNo7ZU3oJ　
を参考に進めたものになるのですが、なぜか私のケースでは前投稿の図6のようなcellset, cellzoneの表面で異常な速度分布が出てしまいました。
コマンドは違うものの、大筋の流れはsnappyを用いた場合のように
cyclicAMIとしたAMI1,2境界の作成と回転領域となるcellzoneの作成は共通しているのではないかと思うのですが。。。


また、snappyは使わないもののharuka様と似たような手順で以前取り組んでいました。
しかし、こちらでも問題が発生しましたので助言いただけますでしょうか。
1, pointwiseによる回転、静止領域を別々にpolyMesh出力　その後マージする（作成されたboundryファイルが図２になります）
2, topoSetもしくはsetSetを使用してcellset,faceset,それらからfacezoneとcellzoneを作成。toposetによりdummyface作成(topoSetDict図３)
3,createpatchにより仮想的に境界面AMI1,AMI2を作成(createPatchDict図４)
これ以降はharuka様の2,~と同様のような流れで
4, createBaffles　でfacezoneの情報をもとにAMI1、AMI2のバッフルを作成(createBafflesDict図５)
5, mergeOrSplitBaffles -split」でバッフル部を切り離して、静止側メッシュと回転側メッシュ切り分ける
といった流れで行ったのですが、問題点としてAMI2パッチの形状がギザギザになるという結果になりました。(図6がAMI1、図7がAMI2です)
なお、こちらの流れは、
を参考したものになります。
どんなご意見でも構いませんので、助言いただければ幸いです。


2021年7月13日火曜日 22:02:48 UTC+9 haruka....@gmail.com:
図2_boundryファイル.pdf
図５createBafflesDict.pdf
図６AMI1パッチ.pdf
図７AMI2パッチ.pdf
図１polyMesh_boundry.pdf
図３dummyface_topoSetDict.pdf
図4createpatchDict.pdf

kominami

unread,
Jul 18, 2021, 10:20:00 AM7/18/21
to OpenFOAM

>1, pointwiseによる回転、静止領域を別々にpolyMesh出力　その後マージする（作成されたboundryファイルが図２になります）

mergeMeshes ユーティティは、別々のメッシュデーターを結合するだけで、パッチやノードは変更しません（たぶん）。したがって、回転領域にAMI1を、静止領域にAMI2を予め作っておけば良いと思います。つまり、2～5の手順は不要ではないかと思います。
2021年7月14日水曜日 0:11:40 UTC+9 simano:

simano

unread,
Jul 19, 2021, 2:07:58 AM7/19/21
to OpenFOAM
貴重なアドバイス誠にありがとうございます。

頂いたアドバイスをもとに以下のことを行ってみました。
1. 格子は別々にExportするのではなく、そのまま一括でExport
2. changeDictionaryによりboundryのAMI1,2のtypeをpatchからcyclicAMIに変更
3. toposetによりdynamicMeshDictに記述する用の回転領域となるcellzoneを作成
4. paraviewにて確認
その結果、やはり以前と同様に回転領域となるcellzoneとcellsetの表面に異常な速度分布が見られました。

これは私の格子作成の手順が間違っているからなのでしょうか？
図1にpointwise上での全体格子の画像
図２に回転領域(円柱)側となるAMI1の向きが分かる画像
図３に静止領域(円柱)側となるAMI2の向きが分かる画像
図４に異常分布が見られるcellzone表面の速度分布の画像
を添付させていただきます。

どんな意見でも非常にありがたいので、引き続き皆様にご指導いただければ幸いです。
よろしくお願いいたします。

2021年7月18日日曜日 23:20:00 UTC+9 kominami:
図2,7_19_boundryファイル＿回転領域側.pdf
図4,7_19_回転領域のcellzone.pdf
図3,7_19_boundryファイル＿静止領域側.pdf.pdf
図1,7_19_全体格子の詳細.pdf

simano

unread,
Jul 30, 2021, 11:08:23 AM7/30/21
to OpenFOAM
その後の報告と現在直面している問題のご相談になります。

「回転領域となるcellZoneにあり得ない速度分布が生じる」という問題に対しては、初期条件0フォルダ内の各パラメータのinternalFieldの値を0にすることで収まりました。
しかしその後計算しようとすると発散が生じています。

また新たなケースとしてこれまでと同じ様な直方体、円柱、そして円柱内部にプロペラのメッシュを作成したパターン(図_mesh　のような)の計算を試しています。
手順は
1. 格子は別々にExport(そのまま一括でExportも試しました)
2. changeDictionaryによりboundryのAMI1,2のtypeをpatchからcyclicAMIに変更
3. toposetによりdynamicMeshDictに記述する用の回転領域となるcellzoneを作成
4. pimpleDyMFoamを実行する
そうすると図2_log_pimpleDyMFoamのようなメッセージが出てコアダンプが生じています。
こちらの対処法のアドバイスを頂きたく存じます。

なお、checkMeshはエラーは出ていません。
参考として初期条件のU,k,nut,omega,pのファイルを添付させていただきます。
それとfvScheme,fvSolutionも添付させていただきます。
pointwiseのみならず、openFOAMをご利用の皆様にご助言頂きたいので何卒宜しくお願いします。mesh.png


2021年7月19日月曜日 15:07:58 UTC+9 simano:
0_p.png
0_k.png
0_nut.png
0_omega.png
log_pimplyDyMFoam.pdf
fvScheme.pdf
fvSolution.pdf
0_U.png

Masashi Imano

unread,
Jul 30, 2021, 10:41:43 PM7/30/21
to OpenFOAM
今野です．

例えば次のような過程でエラーの原因を特定していったら如何でしょうか?

1. ログでのエラーメッセージで内のキーワードを拾って，エラーの原因のあたりをつける．

log_pimplyDyMFoam
```
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?

//sigFpe→浮動小数点例外シグナル

#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) at ??:?

//divide→除算→浮動小数点例外と併せて考えると，恐らく0割りのエラー

#4 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#5 Foam::kOmegaSST<Foam::eddyViscosity<Foam::RASModel<Foam::IncompressibleTurbulenceModel<Foam::transportModel> > >,Foam::IncompressibleTurbulenceModel<Foam::transportModel> >::F2() const at ??:?
#6 Foam::kOmegaSST<Foam::eddyViscosity<Foam::RASModel<Foam::IncompressibleTurbulenceModel<Foam::transportModel>>>,Foam::IncompressibleTurbulenceModel<Foam::transportModel> >::correctNut() at ??:?

//kOmegaSSTモデルでのcorrectNut() で0割りをしている可能性が高い

#7 ? in "/home/hirota/OpenFOAM4.0/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/bin/pimpleDyMFoam"
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9 ? in "/home/hirota/OpenFOAM4.0/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/bin/pimpleDyMFoam"

浮動小数点例外 (コアダンプ)
```

2. エラーが発生した箇所のソースを読むために，ソースコードをgrep等で検索するか，
Foundationのソースのdoxygenドキュメントのサイト(  https://cpp.openfoam.org/  )で検索する．

例えば，以下の検索語でググると，沢山ヒットするが，kOmegaSSTのクラスのページ( https://cpp.openfoam.org/v5/classFoam_1_1kOmegaSST.html )を見る．

site:https://cpp.openfoam.org/ Foam::kOmegaSST<Foam::eddyViscosity<Foam::RASModel<Foam::IncompressibleTurbulenceModel<Foam::transportModel> > >,Foam::IncompressibleTurbulenceModel<Foam::transportModel> >::correctNut

3. kOmegaSSTのクラスのページから, correctNut を検索する．

```
◆ correctNut() [1/2]
void correctNut ( const volScalarField & S2,
const volScalarField & F2 
)
protectedvirtual
Reimplemented in kOmegaSSTSato< BasicTurbulenceModel >.

Definition at line 115 of file kOmegaSSTBase.C.
```
'Definition at line 115 of file kOmegaSSTBase.C.' とあるので，kOmegaSSTBase.C のリンクに飛ぶ．

5. ソースコード kOmegaSSTBase.C   のページ内で，correctNut を検索し，ソースコードの中身を見る．

```
template<class TurbulenceModel, class BasicTurbulenceModel>
 void kOmegaSST<TurbulenceModel, BasicTurbulenceModel>::correctNut
 (
     const volScalarField& S2,
     const volScalarField& F2
 )
 {
     this->nut_ = a1_*k_/max(a1_*omega_, b1_*F2*sqrt(S2));
     this->nut_.correctBoundaryConditions();
     fv::options::New(this->mesh_).correct(this->nut_);
 
     BasicTurbulenceModel::correctNut();
 }
```

6. 除算をしている箇所が無いか調べる．

```
a1_*k_/max(a1_*omega_, b1_*F2*sqrt(S2));
```

確かに割っている．

7. 0に設定されている変数を調べる．

a1_ と b1_ は，kOmegaSSTBase.C 内でデフォルト値が適宜されているので，
これらの乱流モデルパラメータを0に設定していない限り0でない．

F2やS2は複雑に算出された値(場)なのですぐにはわからないが，
残るomega_ は0ではないか?

なお，omega_は，ソースコードより，元々場ファイルomegaを読んだもの．

kOmegaSSTBase.C
```
     omega_
     (
         IOobject
         (
             IOobject::groupName("omega", U.group()),
             this->runTime_.timeName(),
             this->mesh_,
             IOobject::MUST_READ,
             IOobject::AUTO_WRITE
         ),
         this->mesh_
     )
```

8. 場ファイルomegaの初期値を調べる．

9. RASモデルを用いて解析する時に，乱流統計量の場k, omega, epsilon (k-epsilon系の場合)に必要な条件を調べる．
2021年7月31日土曜日 0:08:23 UTC+9 simano:
Message has been deleted
Message has been deleted
Message has been deleted

simano

unread,
Aug 4, 2021, 2:17:42 AM8/4/21
to OpenFOAM

今野様

非常に丁寧なご助言誠にありがとうございます。

また返信が大変遅くなり申し訳ございません。

 

ご指摘をいただきました通り、乱流統計量omegaの場(internalField)の値を入力したところ計算が回り始めました。誠にありがとうございます。

 

次に、乱流統計量k,omegaの値を再計算し、より正確だと思われる値を入力し再度この条件で計算を行いました。

しかし、計算して数十ステップ後に残差(fig1.残差)から分かるようにあるステップから計算が進まず、永久的に同じステップ(T=2.94239e-06)での計算を繰り返すというエラーが生じてしまう事象が起こりました。

(計算が回っているのはこれまで使用してきたk,omegaの値を入力したものです)

変更前　k ; 4.698e-08   ,   omega ; 4.698

変更後　k ; 5.21e-05   ,   omega ; 0.03552

 

k,omegaの算出式としては、https://www.cfd-online.com/Wiki/Turbulence_free-stream_boundary_conditionsを参考にしており、乱流の長さスケールlに関しては理解が曖昧なため、http://ichrome.com/blogs/archives/342のサイトを利用して求め、最終的にk,omegaを算出しました。

このようなエラー(?)を引き起こす原因の検討が付かなかったため、ご助言いただきたいと感じています。

  

また他の気になる問題として、複数のパターンのk,omegaを入力して試していたところ(fig2.error_メッセージ2)のように発散が生じました。

以下の文を調査していたところ、時間刻み幅の調整やメッシュの品質改善などが有効だと考え、

メッシュの非直交性を85→81に下げることやfvsolutionの修正等を行いましたが、計算の発散はあまり改善されませんでした。

これも(fig2.error_メッセージ2)のエラーメッセージにちらほらみられるような乱流関係の要素(k,omega)の値等による影響が大きいと考えられるのでしょうか？

>,Foam::GaussSeidelSmoother::smooth(Foam::word const&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::Field<double> const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, unsigned char, int) at ??:?

 

非常に拙い文で伝わりづらく恐縮ですが、何卒引き続きアドバイスいただければ幸いです。

宜しくお願いいたします。



2021年7月31日土曜日 11:41:43 UTC+9 Masashi Imano:
fig1.残差.png
fig2.error_メッセージ2.pdf

kominami

unread,
Aug 5, 2021, 5:36:03 AM8/5/21
to OpenFOAM
kominamiです。

0/*ファイルで
internalField uniform 0;
というふうに指定した値は初期値なので、あまり拘る必要はないかと思います。もっともshimanoさんはpimpleDyMFoamという非定常計算ソルバーを使っているので、(疑似非定常計算を意図していないならば)初期条件が重要だと考えているのでしょう。

0/*ファイルで、各々の境界条件を指定する時に
value $internalField
というふうに引用していると、そのあとの時刻でも値が引き継がれる場合があります。（計算中に更新される場合もあります。以前にアップロードされているomega.pngを見ると更新されるような記述だから問題ないと思います。）

shimanoさんの意図が不明なので、適切な助言ができるかどうか分かりませんが。

＞(疑似非定常計算を意図していないならば)初期条件が重要だと考えているのでしょう。
初期条件による結果への影響が大きい、すなわちカオス的な挙動だと思っているのですか？　カオス的な挙動により初期値によっては発散してしまうとしたら、設定する初期条件が不適切なのか、もともと計算が困難なのだと思います。

実現象はそれなりに安定的だからカオス的な現象では無いと考えているのですか？（つまり疑似非定常計算を意図していますか？）　引用先の記載を参考にして「或る前提をおいて試算」したkとωの値で「計算領域の全体の初期値を代表」させるという方針が不適切だと思います。

＞Foam::GaussSeidelSmoother::smooth(Foam::Field<double>&, Foam::Field<double>const&, unsigned char, int) const at ??:?
というエラーから、代数方程式ソルバーを発散し難いものに変えるとか。

以上　よろしくお願いいたします。


2021年8月4日水曜日 15:17:42 UTC+9 simano:

Masashi Imano

unread,
Aug 5, 2021, 10:03:12 PM8/5/21
to OpenFOAM
今野です．

発散の原因が不明な場合，それを特定すべく，様々に条件を変えてソルバの挙動を調べると思いますが，
その際，精度が悪くなるものの最安定化にできる設定があれば，それらは一旦最安定な設定にしたほうが，
症状の切り分けが容易です．

精度を度外視して最安定化にできる設定の最たるものが，
離散化スキームにおける移流項のスキームと，
ラプラシアン項・法線方向勾配項などの非直交補正パラメータです．

- 移流項のスキーム: 高精度なスキームは不安定 → 一旦一次風上にする
- 非直交補正パラメータ: 格子の非直交性がある場合には，補正を強めると不安定 → 一旦0にする(uncorrectedでも良い)

従って，system/fvSchemeにおける，divSchemes内のdiv(phi,hoge) (hogeは輸送を解いている場．U, k, omega等)は，
一旦Gauss upwindにすると良いと思います．

また，laplacianSchemesやsnGradSchemesのlimited corrected 以降の非直交補正パラメータは
一旦0にすると良いと思います．

さらに，以下の事も検討ください．

- simpleFoamなどの定常解法で解けるかチェックする．(解けたら，それを初期値にして非定常解法に進むとより安定)
- 非定常ソルバで回転を止めてソルバが動くか検討する．
- 格子の回転だけを行うソルバがあるはずなので，それで一回転して格子の品質を確認する．
- fvSolutionsを一旦tutorialsの同様のケースの設定に戻す．
- 一旦流入風速や回転数を落す．

私からは以上です．
Message has been deleted

simano

unread,
Sep 1, 2021, 4:05:58 AM9/1/21
to OpenFOAM
kominami様

お世話になっております。返信が遅くなり申し訳ございません。

k,omega等の初期条件による結果への影響は、それほど大きなものだと考えていません。
といいますか、そこの影響を気にするよりプロペラを回転させた際の後流の要素をある程度求めれれば満足と考えていますので、初期条件の選定は「計算が回れば良い」という少し安易ですが、個人的にはそのような考えで現在行っています。

omega.pngに関して、例えば AMI1のpatchですと value $internalField　ではなく、value uniform 0;　と記述しているのですが、この場合値が更新されずAMI１のpatchで不連続面が生じる原因となってしまわないのでしょうか？

また現在としては、代表長さを間違えて計算していたので、それを修正してk,omega等を再計算しました。またそれらを初期条件とした計算が発散せずに長らく回っています。
kominami様のご指摘としては、不明確な初期条件を代表させるのではなく、internalField uniform 0;と定義し、それ以降の値はvalue $internalFieldで更新してくれる方が、安定的である。という認識で合っていますでしょうか。
知識が及ばず、至らない点ばかりですがご返信いただけると幸いです。

2021年8月5日木曜日 18:36:03 UTC+9 kominami:

simano

unread,
Sep 1, 2021, 4:43:38 AM9/1/21
to OpenFOAM
今野様

お世話になっております。返信が遅くなり申し訳ございません。

一旦移流項のスキームは一次風上にし、非直交補正も0に変更、k,omegaの値の修正を行ったことにより発散せず回るようになりました。
ご助言頂き誠に感謝しております。

ご提案いただいたことに関しては
simpleFoamでの計算の確認、pimpleDyMFoamでの回転offでの計算の確認、回転格子動作の確認のmoveDynamicMeshの実行、を行い問題ありませんでした。

１つ課題点として計算時間が非常に長いことがあり、目標としてはT=1.0まで計算したいのですが、32並列計算で三週間でT=0.13程度です。格子数は約600万、クーラン数は0.8です。
半ば諦めておりますが、この程度の進み具合が至って普通なのでしょうか。
曖昧なご質問で申し訳ありませんが、何かアドバイス等いただければ幸いです。

これ以降本投稿とは内容がずれてしまうので無視していただいて構いません。
最近としては、この研究の最終目標がプロペラの回転を考慮した船体周りの解析であることから、プロペラの計算はAMIではなくMRF法で行い、その結果を船体の計算に体積力として付加する方法を検討しています。
MRFを用いる要因としてAMIより計算コストが軽いためです。デメリットもありますが…
プロペラの計算で生じた体積力を付加する方法をOpenFOAMで調査していますが、難航していますので、もし助言いただける方がいらっしゃいましたら宜しくお願いいたします。
2021年8月6日金曜日 11:03:12 UTC+9 Masashi Imano:
Reply all
Reply to author
Forward
0 new messages