OS-E:0830 マルチモデル最適化(MMO) – 掘削機のアームのパターン繰り返し

この例題では、2つのモデル間でリンクされているトポロジー最適化の設計変数を使用した掘削機の例を取り上げています。

設計空間は、各モデルについて、PSHELL要素の2つのプレートからなる掘削機のアームで構成されています。掘削機のバケットは各モデルで異なります。



図 1. 設計空間として掘削機のアームを有し、バケットが異なる2つのMMOモデル

モデルファイル

必要なモデルファイルのダウンロードについては、モデルファイルへのアクセスを参照してください。

この例で使用されているモデルファイルには以下のものが含まれます:

excavator_arm_mmo.zip

モデル概要

Model 1は掘削機のバケットから成り、Model 2はハンマーが取り付けられています。作動する荷重には各モデルについて異なる数、異なる種類のサブケースが含まれます。Model 1には3つの線形静的サブケース、Model 2には4つの線形サブケースが含まれ、これらは作動中に遭遇し得る境界条件をシミュレーションします。

掘削機のアームはトポロジー最適化の設計空間として選択されます。各アームは、PSHELL要素のプレートのペアとしてモデル化されています。トポロジー最適化のセットアップは、1つのプレートからもう1つのプレートへ設計を再現させるために各モデル内でパターン繰り返しを含んだDTPLエントリ(1つのメインと1つのセカンダリ)です。1つのプレートはメインとして、2つ目のプレートはセカンダリとして各モデル内で選択されます。

掘削機の設計については、バケット部分が多用途のもので複数のツールセット(バケット、ハンマー、など)を組み込む予定である場合、掘削機構造の残りの部分は様々な異なる境界条件化で作動するよう設計されるべきです。特にこのケースでは、バケットとハンマーの両方について最適化される掘削機アームを設計することに焦点を当てています。

このシミュレーションは、別々のランのそれぞれが、対応する特定のコンフィギュレーションと使用ケースに適したアームについての最適化設計をもたらすため、個々のモデルベースのトポロジー最適化では単純なものではありません。

ユーザーは、異なるコンフィギュレーションおよび / または境界条件下で異なるモデルに渡ってパートを最適化するためのマルチモデル最適化を利用することができます。
FE Model
ベースとジョイント
CHEXA
CPENTA
剛体要素
シリンダー
CBEAM
アーム、バケット、ブーム
CQUAD4
CTRIA3
線形材料プロパティは:
MAT1
ヤング率
2.1E5
ポアソン比
0.3
初期密度
7.9E-9
マルチモデル最適化のセットアップ
各モデルの最適化セットアップは:
最適化のタイプ
トポロジー最適化
応答
重み付きコンプライアンス(WEIGHT = 1.0)
体積率
目的関数
重み付きコンプライアンスの最小化
制約条件
体積率(VOLFRACを0.3に制約)

マルチモデル最適化はMPIベースの並列化手法で、実行するためには、最適なOptiStruct MPI実行ファイルとMPIインストレーションが必要です。OptiStruct MPI実行ファイルは含まれており、MPIインストレーションもSolversインストレーション(Altairホームディレクトリ内のmpiフォルダー)で利用可能となっています。既存のソルバーデックは追加の入力なしで簡単に含めることができ、MMOモードと完全な互換性を持ちます。MMOでは、構造間でコンポーネントを最適化するための非常に大きな柔軟性が提供されます。–mmo実行オプションを使用してOptiStructでマルチモデル最適化をアクティブ化できます。

まず個々のトポロジー最適化モデルをセットアップし、続いて、実行中にエラーや重大な警告がないか、それらを別々にテストします。

マルチモデル最適化に含まれるべきモデルを特定するために、メイン入力デックはASSIGN,MMOエントリを活用して作成されます。モデル名はASSIGNエントリの3つ目のフィールドで指定できます。この名称は、DRESPM継続行で使用される応答を特定、修正するために使用することが可能です(適用可能な場合)。現在のランでは、メインファイルはmain.fem、マルチモデルはexcavation_hammer.femおよびexcavation_bucket.femと名付けられます。
注: メインファイルでは、個々のモデルはmain.femファイルと同じディレクトリ(作業ディレクトリ)になければなりません。
$
ASSIGN,MMO,bucket,excavator_bucket.fem
ASSIGN,MMO,hammer,excavator_hammer.fem
$
BEGIN BULK
$
ENDDATA
少なくとも1セットの設計変数または設計領域が、マルチモデル最適化に使用される複数モデル間でリンクされている必要があります。リンク付けは、設計変数または領域について同じIDを使って行われます。これは、最適化された結果が1つのモデルにマッチするようパターン繰り返しを内部的に適用するために使用されます。
注: リンクされていない設計変数や領域の存在は、複数モデル内の共通した設計空間について異なる最終最適化設計を導くことになりかねません。

リンクされた設計変数と領域はすべての点で(COORDおよびSCALE継続行を除き)全く同じでなければなりません。付与される設計パラメータと製造用制約条件は、すべてのモデルでマッチする必要があります。この制約は、リンクされていない領域には適用されません。また、内部的なパターン繰り返しを円滑にするために、COORD継続行が対応する設計変数または領域のエントリ上で必要となります(DTPLDSIZE、など)。これにより、リンクされた設計領域に渡って繰り返されるパターンの方向と位置が認識可能となります。

設計領域は次のようにリンクされます:

Model 1ではDTPLエントリ(ID 1および2)、Model 2ではDTPLエントリ(ID 1および4)がMAINおよび対応するSECONDで指定されています。これは、各モデル内で(両モデル間ではなく)パターン繰り返しに使用されるもので、MMOには関係しません。このような各モデル内のパターン繰り返しはもちろんオプションで、使用ケース次第となります。現行のモデルでは、設計空間の2つのプレートには、製造が容易となるようマッチングしたパターンが必要とされます。

モデル間のリンクは、両モデル内でID 1のDTPLエントリによって認識されます。OptiStructは内部的にそれらの1つをメインとして選択し、モデル間の内部設計マッピングを適用します。


図 2. バルクデータの設定

COORD継続行は、アンカーポイントの特定と複数のモデル間の設計のマッピングを可能にします。この継続行は必須ではありません。パターン繰り返しがすべてのモデル内で(MAIN/SECONDを介して)セットアップされていない場合、MAIN/SECOND継続行とは別に、COORD継続行を指定する必要があります。

マルチモデル最適化はMPIをベースとしており、MPIプロセスの数(-np)はモデルの数で決定されます。-npは、モデルの数に1を足したものと等しく設定されなければなりません。現在のランでは、メインファイルはmain.fem、マルチモデルはexcavation_hammer.femおよびexcavation_bucket.femと名付けられます。

-mmo実行オプションは、MMOランを特定するために必要とされます。最適化に2つのモデルが含まれるため、実行オプション-npは3に設定しなければなりません。Intel MPIはデフォルトで自動的に選択されます。この例はWindows GUIランとして示されており、このモデルはWindowsまたはLinux上でコマンドラインを介して実行します。ユーザーズガイドマルチモデル最適化をご参照ください。

結果

図 2では、設計パターンが両方のコンフィギュレーションで同じになっています。


図 4. 異なるコンフィギュレーションの複数モデルについてマッピングされた設計領域の結果. 最終設計は同等