最適化のガイドライン

最適化のログファイルを必ず確認する

最適化のログファイルには、実行した最適化プロセスに関する情報が出力されます。このログファイルを必ず確認して、最適化が問題なく実行されたことを確認します。最適化に失敗している場合、その理由をログファイルから知ることができます。その情報に基づいて、問題の根本原因に関するヒントが得られます。

設計制限が厳しいことから、解析がその境界条件で“停止”したような状態になることがあります。このような場合、最適化がきわめて低速になることや進行しなくなることも少なくありません。ログファイルによってこの状況が検出され、通知されます。以下に例を示します。

4つのバーで区切ったこの例は、上記の状態を示すために、設計制限が厳しくなるように変更されています。XBとYBの上限を故意に小さくして、この状況が発生するようにしています。設定した境界条件までは、最適化エンジンによって解析が想定どおりに進行しますが、その境界条件に違反した状態にすることはできないので、解析がそれ以上は収束しなくなります。

Results from Optimization
-------------------------
Initial Cost   = 11367.896
Final Cost     = 57.334
Cost reduction = 99.496

Individual Responses
--------------------
Weight = 1.00 Final cost of objective Coupler-DX  = 31.55   
Weight = 1.00 Final cost of objective Coupler-DY  = 19.11   
Weight = 1.00 Final cost of objective Coupler-PSI = 6.67    


Final Design Table
------------------

DV                Lower Bound        Upper Bound        Initial Value      Optimized Value
------------------------------------------------------------------------------------------
XA                -5.0000e+01        +5.0000e+01        -4.5000e+01        -9.9618e+00
YA                -5.0000e+01        +5.0000e+01        +4.5000e+01        -1.1489e+01
XB                +2.0000e+01        +3.0000e+01        +2.5000e+01        +3.0000e+01  **** U
YB                +1.8000e+02        +1.9000e+02        +2.6000e+02        +1.8940e+02
XC                +2.4000e+02        +3.8000e+02        +3.0000e+02        +3.6508e+02
YC                +4.0000e+02        +6.2000e+02        +5.0000e+02        +6.0576e+02
XD                +1.8000e+02        +5.2000e+02        +5.1500e+02        +3.9105e+02
YD                -1.0000e+02        +2.0000e+01        -8.5000e+01        +1.6394e+01


**** You may consider expanding bounds for these DVs and re-run

MotionSolveによって、最終設計表に**** Uまたは**** Uが追加されます。****は、境界条件で設計が行き詰っていることを警告しています。Uは、設計が上限に達していることを示しています。Lは、設計が下限に達していることを示しています。この例で、より優れた解を最適化で見出すには、XBの設計上限を大きくする必要があります。

問題に適した組み合わせの設計変数を選択する

設計問題をパラメータ化する方法は数多くあります。パラメータ化の中には、他のパラメータ化よりも安定しているものがあります。次に例を示します。

カムのプロファイルを合成する作業を検討します。

プロファイルをパラメータ化する方法として、プロファイル上にある特定のポイントの(x ,y)座標に設計変数を作成する方法があります。この様子を上側の図に示します。
別のパラメータ化の方法として、特定の角度値における半径の長さを設計変数と見なす方法があります。この場合は角度の増分θを選択できます。この様子を下側の図に示します。

曲線形状の合成には、半径の長さによるパラメータ化（下側の図）の方が適しています。その最適化では、下図のような異常が存在する曲線が見出されることがないからです。

設計のパラメータ化が正しいことを確認する

不完全な設計がパラメータ化されると検出が困難です。個々のシミュレーションは問題なく実行できるにもかかわらず、目的とする結果が最適化から得られないことがあるからです。

不完全なパラメータ化を検出する方法として、さまざまな設計パラメータで複数のモデルを生成し、シミュレーションを実行してその結果を検討する方法があります。結果を詳しく検討することで、パラメータ化に存在する欠陥を特定できます。
不完全なパラメータ化を検出するには、設計変数に対する応答の感度を確認する方法もあります。この方法では、感度に関する一定の知識が必要です。いくつかの明白な誤りがこの方法で特定できます。例えば、特定の設計変数に対してどの応答も感度が必ずゼロであれば、その設計変数にはシステムのパフォーマンスに対する効果がないことがわかります。これは、パラメータ化の誤りが原因であることが考えられます。

最適化の前にシミュレーションが堅牢であることを確認する

最適化の失敗で多く見られる原因として、基盤となるシミュレーションが何らかの理由で失敗していることが挙げられます。したがって、さまざまな面で高コストの最適化に着手する前に、基盤となるシミュレーションが設計変更に対して堅牢であることを確認する必要があります。

初期の設計を手動で変更し、いくつかのシミュレーションを実行します。警告が発生せずにシミュレーションを実行できること、静解析が正常に完了すること、予期しない収束の失敗が発生せずに静的および動的な時間ステップが進行することが必要です。このような動作が得られない場合、モデルまたはシミュレーションの設定を検討し、堅牢性のあるシミュレーションになるように変更します。

設計変数に現実的な上限と下限（b_L、b_U）を指定する

すべての設計変数に必ず意味がある上限と下限を指定する必要があります。

ゼロより小さくすることができない設計変数には、ゼロより大きい下限を設定します。この条件に該当する設計変数として、スプリング定数、減衰係数、リンク長さなどがあります。これらの値は必ずゼロより大きい必要があります。
例えば、設計空間に対する制約などの下限や上限には、最初は控えめな値を設定し、その可変幅を小さい値に抑えます。設計空間に対する制約の緩和を繰り返し、最適値が存在する値の範囲が最適化エンジンで見出されるようにします。

システムを最適化するためにcrawl-walk-run手法を使用する

この手法は、以下の指定に適用できます：

設計変数
不等式の制約条件
等式の制約条件
コスト関数

多数の設計変数を使用する複雑な問題の解析を試みる前に、一度に導入する設計変数を少なくして、設計の部分的な問題を正常に解析できるようにします。

制約条件の導入に対しても同じ手法に従います。一度に導入する制約条件を少なくして（理想的には制約条件を1つにします）、最適化が中断せずに実行でき、意味のある結果が得られることを確認したうえで、導入する制約条件を多くします。

等式の制約条件が、最適化エンジンで問題が発生する原因となることがあります。このような場合には、これらを不等式の制約条件に置き換えます。つまり、等式の条件としてf(q, b) = 0がある場合、これをf(q, b) < 0 AND f(q, b) > 0に置き換えます。

多目的問題を解析する場合は、コストが1つのみの場合に最適化エンジンで解が見出されるようにします。この方法でコスト関数を1つずつテストした後で、これらすべてをコストとして指定します。

中間結果を確認する

最適化プロセスでは、すべての中間結果が保存されます。最適化の失敗では、多くの場合、最適化エンジンのどの動作で問題が発生したかを確認するうえで、中間結果の確認が効果的です。これにより、最適化の失敗の原因を把握できます。

設計に対する制約条件の指定を忘れていた場合は、理想的には作成が認められない設計が最適化エンジンで作成されることがあります。

機構に対しては、可能であればグラスホスの基準を適用する

4本のバーでリンクするシステムの機構を設計している場合は、制約条件として必ずグラスホス基準を追加します。下の図は、ダブルロッカー機構に対するグラスホスの基準を示しています。

この基準を指定しない場合、ダブルクランク機構やクランクロッカー機構など、4本のバーで構成する別のバリエーションを使用することになります。これらの機構に対するグラスホスの基準は、上記とは異なるものになります。クランクロッカー機構に対するグラスホスの基準を次に示します。

最適化モジュールに組み込まれたデバッグ機能を使用する

どの応答も、必要に応じてそのデバッグプロパティをTrueに設定して定義できます。応答のデバッグプロパティがtrueの場合、その応答を評価するたびに応答の値が出力されます。

クラス変数Response.debug = Trueを設定することもできます。この設定では、すべての応答から、その評価のたびに値が出力されます。

これにより、設計変更に伴って最適化で応答が示す挙動を把握できます。