DebugOutput

Command ElementDebugOutputコマンドは、MotionSolveからデバッグ出力を生成します。これらの追加の診断は一般に、MotionSolveの解析エラーを理解するために使用されます。そうすることで、モデリングの問題を修正し、シミュレーションパラメータを変更して、これらのエラーを解決できます。

説明

デバッグ出力は、次の2つのカテゴリに分類されます:
  • 静解析、擬似静解析、および動解析におけるニュートン-ラプソン反復計算の時間ステップアルゴリズムと収束履歴のトレース。
  • 収束履歴を視覚的に検証できるようにするための、反復計算ごとのアニメーション情報の出力。

以下の属性は、モデリングの問題を見つけて修正するために使用されます。

フォーマット

<DebugOutput
[ switch_on       = "TRUE" || "FALSE" ]
[ debug_anim      = "TRUE" || "FALSE" ]
[ screen_output   = "TRUE" || "FALSE" ]
/>

属性

switch_on
特に、静解析、擬似静解析、および動解析で使用されるニュートン-ラプソン数値手法に関して、ソルバーの解析ステップに関するデバッグ情報の生成を制御する論理フラグ。このメッセージを使用して、最大の収束エラーを引き起こしているモデリングエンティティを特定できます。MotionSolveのエラーについては、ソルバーエラーの直前に積分器の問題をもたらしているエンティティを参照し、まずこれらを調べます。モデリングエラーがなければ、一般的には、モデルに不連続性がないか確認し、MotionSolveによって報告されるエラーメッセージを参照します。このパラメータに指定できる値は、"TRUE"または"FALSE"です。
  • "TRUE"の場合は、反復計算ごとに、追加のデバッグ情報が画面とログファイルに出力されます。
  • "FALSE"の場合は、追加のデバッグ情報は画面にもログファイルにも出力されません。
指定しない場合、switch_onはデフォルトで"FALSE"になります。
注: デフォルトでは、デバッグ情報はログファイルにのみ書き込まれます。これを変更するには、screen_outputをご参照ください。
debug_anim
デバッグのために、各反復計算におけるアニメーションフレームの生成を制御する論理フラグ。このアニメーションは、ニュートン-ラプソン法でモデルがどのように修正(すなわち、位置変更)されているのかを確認するのに役立つことがよくあり、収束解を見つけるためにモデリングやMotionSolveの設定をどのように変更すればよいかに関する手がかりとなる可能性があります。指定できる値は、"TRUE"または"FALSE"です。
  • "TRUE"の場合、反復計算ごとに、追加のアニメーション情報がH3Dファイルに出力されます。
  • "FALSE"の場合、追加のアニメーション情報はH3Dファイルに出力されません。
指定しない場合、debug_animはデフォルトで"FALSE"になります。
H3DファイルをHyperViewに読み込んで、ニュートン-ラプソン反復法の結果を視覚的に調べることができます。 3
screen_output
デバッグ情報が出力される場所を制御する論理フラグ。"TRUE"または"FALSE"を選択します。
  • "TRUE"の場合、デバッグ情報は画面とログファイルに出力されます。
  • "FALSE"の場合、デバッグ情報はログファイルのみに出力されます。
指定しない場合、screen_outputはデフォルトで"FALSE"になります。

<DebugOutput
 switch_on   = "TRUE" 
/>

コメント

  1. ニュートン-ラプソン法

    このコマンドのほとんどの出力の中心にあるのが、ニュートン-ラプソン(N-R)と呼ばれる数値手法です。この手法を使用して、一連の非線形代数方程式(NLAE)が解かれます。これは一般に“ニュートン法”と呼ばれるよく知られた手法であり、多くの資料で解説されています。この手法では、NLAEの根を求めます。N-Rは、“修正子”と呼ばれる解析プロセスの一部です。このように呼ばれるのは、これが初期値を修正して、NLAEのより良い解を求めるためです。

    N-Rでは、誤差を小さくしながら方程式の解を徐々にに見つけることを目的として、システムの状態(感度)に関する非線形代数方程式の偏導関数が使用されます。状態に関するこれらの方程式の偏導関数のマトリクスは”ヤコビアン”と呼ばれます。したがって、ヤコビアンはN-R法を解くために不可欠です。

    静解析、擬似静解析、および動解析では、運動方程式は一連の非線形代数方程式に変換されます(静解析と擬似静解析では、すべての速度をゼロに設定することで変換され、動解析では、積分法によって変換されます)。反復計算ごとに、N-Rは誤差トレランス内に収まるNLAEの解を見つけようとします。解が誤差トレランスに収まらない場合、N-Rはヤコビアンを使用して状態を更新し、より良い解を見つけようとします。誤差トレランスが満たされるか、反復計算の最大回数に達するまで、このプロセスが繰り返されます。

    動解析では、反復計算の最大回数を超えると、ソルバーはより小さいステップサイズを使用して、再度運動方程式の求解を試みることができます。ただし、積分器がそれ以上ステップサイズを小さくできない場合、解析は失敗します。静解析では、反復計算の最大回数を超えると解析は失敗するため、このコマンドの出力を調べる必要があります。

    N-Rを理解するには、N-Rを視覚的に確認するとよいでしょう。次の図は、非線形代数方程式y= f(x)のプロットです。この図は変数が1つの方程式を示していますが、一般に変数がいくつの方程式にも当てはまります。



    図 1. ニュートン-ラプソン法

    この方程式は、 f(x) = 0となるようにいつでも書き直すことができ、N-Rはこの方程式を解くことで、f(x*) < error toleranceという条件を満たす根x*を見つけます。

    ここで、状態値xの初期推測値はx0です。f(x0)が誤差トレランスを超えている(すなわち、誤差条件を満たさない)場合、N-Rは、x0におけるf(x0)の線形方程式を計算し、この結果を使用してx1における(理想的には)より良い解を計算します。この新しい状態値x1を使用してf(x1)の値を評価し、この値が指定された誤差トレランス内に収まるかどうかを確認します。この例のような非線形方程式では、N-Rによる反復計算が繰り返されるたびに、精度が高まっていくことがわかります。一部の非線形方程式については、このことは当てはまらず、N-Rは実際には発散する可能性があります。

    次の状態に更新するために使用される線形方程式の勾配(図中の点線)は、実質的にはヤコビアンマトリクス(システム内の状態に関するすべての方程式の偏導関数)です。反復計算ごとのヤコビアンの更新は、一般に大きな計算負荷がかかるプロセスであり、全体的な解析プロセスの効率を高めるために、このマトリクスを前の反復計算から再利用することがあります。 .

    switch_ondebug_animにより得られるデバッグ出力では、それぞれ表形式とグラフィック形式でN-Rの収束情報が表示されます。解が収束しない場合は、モデル内で起こっていることをできるだけ詳しく把握し、モデリングエンティティを追加、削除、または修正して、解析に関するMotionSolveの設定を変更する必要があります。問題が発生する可能性があるのは、ヤコビアンに適切な情報が含まれていない場合(不連続な(滑らかでない)モデリングエンティティの場合)や、システムの初期コンフィギュレーションが最終解とかけ離れている場合です。

    詳細については、以降のコメントをご参照ください。

  2. switch_on
    switch_onを使用すると、多くの情報が生成される可能性があり、その結果としてパフォーマンスが大幅に低下します。したがって、これはモデルのデバッグ時にのみ使用してください。生成される出力の詳細については、コメント5をご参照ください。この出力を使用することで、以下のシナリオをより詳しく理解し、診断できます:
    • 修正子のエラー
    • 積分器のエラー
    • 小さいステップサイズ
    • 低い積分次数
  3. debug_anim

    この属性の目的は、HyperViewポストプロセッサのアニメーションH3Dを介して、静解析の視覚的デバッグを支援することです。debug_anim属性を使用すると、静的シミュレーションの反復計算ごとに、結果がアニメーションH3Dと出力MRFファイルに出力されます。このパラメータは、静的シミュレーションのデバッグ時にのみ使用してください。debug_anim"TRUE"に設定して、複数のシミュレーションを実行すると、MotionSolveは警告メッセージを発行して終了します。

    多くの解析を含むモデル内で静解析をデバッグする場合は、<Save>および<Load_Model>コマンドステートメントを使用して、目的の静的シミュレーションを分離できます。その後、debug_anim属性を使用して、静的平衡の収束を視覚的にデバッグできます。

    debug_anim"TRUE"に設定した場合も、多くの情報が生成され、大きいH3Dファイルが作成される可能性があります。この属性を使用すると、パフォーマンスが大幅に低下します。したがって、これはモデルのデバッグ時にのみ使用してください。

  4. switch_on = "TRUE"の出力

    図 2 は、switch_on属性をvに設定した場合の、ログファイルへの一般的な出力を示しています。



    図 2. 擬似静解析の収束履歴

    図 2 は、FIM_Dを使用して実行された擬似静解析時の1ステップについて、解析プロセスのニュートン-ラプソン収束履歴を詳しく示しています。

    上部には、時間ステップ履歴が示されています。上記図 2のとおり、以下の情報(赤レンガ色で表示)が提供されています:
    • 解が得られた時刻、Tn=3.17964E+01
    • 試行されているステップサイズ、Step=4.47657E-01
    • 解析に成功した場合の新しい時刻、Tn+1=3.22441E+01
    • 積分器の次数、Order=3

      これに続いて、ステップの収束履歴が示されています。各反復計算に関する情報は1行に収められています。情報を容易に特定できるよう、データは列ごとに揃えられています。ここでも図2のとおり、各行には以下のデータが含まれています:

    • 反復計算の回数。これにより、N-Rによって実行された反復計算の回数がわかります。
    • 運動方程式内の最大残差(誤差)。
    • 最大誤差を伴う方程式のインデックス。 .
    • 最大残差を伴うモデリングコンポーネント。
    • ニュートン-ラプソン反復計算によって計算された最大変化。
    • 最大変化を伴う状態のインデックス。
    • 最大変化を伴うモデリングコンポーネント。
    • この反復計算でヤコビアンが評価されたかどうか。行末の"J"は、新しいヤコビアンが評価されたことを示します。

      モデリングエラーが発生している場合や、いずれかのパラメータ値(ブッシュ剛性など)がスケール外の場合は、デバッグデータを使用して、エラーが発生している可能性のあるモデリング要素を特定できます。これは問題の徴候であり、必ずしもモデル内で変更される必要があるエンティティではありません。例えば、ステアリングシステムの回転運動をラックの並進運動に連結するカプラー拘束が適用された、ラックアンドピニオン式のステアリングシステムについて考えてみましょう。このカプラー拘束が正しく定義されておらず、ラックを想定外の方法で動かそうとすると、カプラー拘束自体の問題が報告されるのではなく、ラックのボディや拘束内での最大誤差が報告される可能性があります。

      次の表では、よく使用されるモデリングコンポーネントの略称を示します。
      略称 バリエーション 説明 親モデリング要素
      拘束要素      
      APJt   同一点ジョイント Constraint_Jprim
      CVJt   等速ジョイント Constraint_Joint
      CJ   接触ジョイント 内部表現
      CP   カプラー Constraint_Coupler
      CVCV XI、YI、ZI

      XJ、YJ、ZJ

      曲線間ジョイントの位置拘束 Constraint_CVCV
      CVSF XDI、YDI、ZDI、XDJ、YDJ、ZDJ 曲線-サーフェス間ジョイントの位置拘束の導関数 Constraint_CVSF
      CYJt   円筒ジョイント Constraint_Joint
      DCV X, Y, Z X、Y、Zにおける変形可能曲線関数 Reference_DeformCurve
      FXJt   固定ジョイント Constraint_Joint
      FRJt   フリージョイント Constraint_Joint
      GR   ギアジョイント Constraint_Gear
      GCON   一般拘束 Constraint_General
      HKJt   フックジョイント Constraint_Joint
      ILJt   インラインジョイント Constraint_Joint
      IPJt   面内ジョイント Constraint_Joint
      ORJt   方向ジョイント Constraint_Joint
      PAJt   平行軸ジョイント Constraint_Joint
      PRJt   垂直ジョイント Constraint_Joint
      PLJt   平面ジョイント Constraint_Joint
      PC XJ、YJ、ZJ 曲線関数拘束 Reference_ParamCurve
      PS X, Y, Z サーフェス関数拘束 Reference_ParamSurface
      PTCV   ポイント-曲線間拘束 Constraint_PTCV
      PTSF   ポイント-サーフェス間拘束 Constraint_PTSF
      RVJt   回転ジョイント Constraint_Joint
      BLJt   球ジョイント Constraint_Joint
      TRJt   並進ジョイント Constraint_Joint
      UVJt   ユニバーサルジョイント Constraint_Joint
      UCON   ユーザー拘束 Constraint_UserConstr
      RB DJC 距離ジャッキ拘束 内部表現
      FB DJC 距離ジャッキ拘束 内部表現
      RB RTC 剛性トライアド拘束 内部表現
      RB RFC 剛性力拘束 内部表現
      RT   剛性ジョイントトライアド 内部表現
      FT   弾性ジョイントトライアド 内部表現
      SFSF   サーフェス間拘束 Constraint_SFSF
      ET   相対トライアド 内部表現
      MTN   ジョイントモーション拘束 Motion_Joint
      MTNAUX   ジョイントモーション拘束(時変モーション) 内部表現
      MTNGC   ジョイントモーションの一般化座標 内部表現
      MTNVAR   モーションマーカー拘束 Motion_Marker
      VAR_MT   ジョイントモーション - 並進 内部表現
      VAR_MR   ジョイントモーション - 回転 内部表現
      VAR_MC   ジョイントモーション - 円筒、回転 内部表現
      MTNAUX   ジョイントモーション - 円筒、並進 内部表現
      Diff要素      
      SDF   陽解法ソルバーDiff Control_Diff
      SDIV   陰解法ソルバーDiff Varcoord Control_Diff
      SDI   陰解法ソルバーDiff Control_Diff
      CS X 制御状態 Control_SISO
        Y 制御力 Control_SISO
      LS X 線形状態 Control_StateEquation(線形)
        Y 制御力 Control_StateEquation(線形)
      GS X 制御状態 Control_StateEquation
        Y 制御力 Control_StateEquation
      力要素      
      BM DX、DY、DZ ビーム力 Force_Beam
        RX、RY、RZ ビームトルク
      FLD DX、DY、DZ 場の力 Force_Field
        RX、RY、RZ 場のトルク
      SF   スカラー力 Force_Scalar
      TS   並進スプリング Force_SpringDamper
      BSH FX、FY、FZ ブッシュ力 Force_Bushing
        TX、TY、TZ ブッシュトルク
      VAR_F   ベクトル力 Force_VectorOneBody Force_VectorTwoBody
      VAR_X   ベクトル力 内部表現
      VAR_T   ベクトルトルク Force_VectorOneBody Force_VectorTwoBody
      VAR_TQ   ベクトルトルク 内部表現
      VAR_TP   ベクトルトルク反作用 内部表現
      VAR_ST   スカラートルク Force_ScalarTwoBody
      PFORCE   ペナルティ力 Reference_Variable
      PFO   ユーザー変数タイプのペナルティ力 Reference_Variable
      VAR_UFX   ユーザーベクトル力 / トルク Force_VectorOneBody Force_VectorTwoBody
      VAR_UFY
      VAR_UFZ
      VAR_UTX
      VAR_UTY
      VAR_UTZ
      VAR_US   ユーザースカラー力 Force_ScalarTwoBody
      VAR_FX   ユーザーYForceおよびYTorque Force_StateEqn
      VAR_FY
      VAR_FZ
      VAR_TX
      VAR_TY
      VAR_TZ
      PB X, Y, Z ポイントボディ力 Body_Point
      RB X、Y、Z、RX、RY、RZ 剛体力 Body_Rigid
      FB X、Y、Z、RX、RY、RZ 弾性体力 Body_Flexible
      NFO   多点力 Force_MultiPoint
      他の要素      
      SV   ソルバー変数 Reference_Variable

      上記に加え、変数セクション(図 2の濃い緑色の箇所)については、要素の略称の後ろに1文字が付加されることがあります。この文字は、最大の変化が見られるエンティティの種類を示しています:

      L - ラムダ(Lambda)の頭文字であり、拘束要素の項を指します。

      A - 加速度(Acceleration)の頭文字であり、加速度の項を指します(2次積分器の場合のみ)。

      V - 速度(Velocity)の頭文字であり、速度の項を指します。

      D - 変位(Displacement)の頭文字であり、変位の項を指します。

  5. 修正子エラーの理解

    図 3 は、発散している反復計算のシーケンスを示しています。この結果として、“修正子のエラー”が発生します。



    図 3. 発散しているニュートン-ラプソン反復計算のシーケンス

    図 3では、方程式内の誤差が反復計算ごとに減少せず、むしろ増大していることがわかります。デバッグ情報(青色で表示)でも、モデリング要素G1-517に含まれている方程式517に最大の問題があることが示されています。この時点で入力デックに戻って、このような状況が起こり得る理由を究明します。

    逆に、反復計算ごとに誤差は減少しているが、ソルバーが反復計算を続行できなくなった場合(すなわち、指定された反復計算の最大回数を超えた場合)は、反復計算の最大回数を増やし、ソルバーが収束できるか試します。

  6. 積分のエラー

    修正子は収束している可能性がある一方で、積分器は局所誤差条件を満たせていない可能性があります。switch_onの出力を使用することで、この状況が発生している理由を理解し、モデル内の根本原因を特定できる場合があります。

    図 4 は、Stabilized Index-1定式化を使用してDSTIFFによって実行されたステップのシーケンスを示しています。積分の誤差トレランスとして1.0E-3が指定されているとします。

    switch_on出力(Time=3.43331E-02秒)を例示します。



    図 4. 失敗した積分ステップのシーケンス

    図 4に示されたswitch_onの情報から、修正子は問題なく解に収束していることがはっきりとわかります。しかし、積分器は局所誤差試験に合格できていません。この出力から、Rigid_Body 2内で関連付けられたシステム速度が最大の誤差を示していることもわかります。

    考えられる原因の1つとして、不連続なモーションがRigid_Body 2に作用している可能性があります。したがって、この情報により、Rigid_Body 2上のすべてのモーション入力を確認できます。変位は収束するように見えますが、速度はそうではないため、微分不可能なモーション(“鋭角なコーナー”を持つ信号)が原因であることが考えられます。

  7. 小さいステップサイズ

    switch_onの出力は、積分器で小さいステップが実行され取られているかどうかを確認し、考えられる原因を特定するのにも役立ちます。小さい積分ステップが取られるのは、積分器で修正子の収束問題が生じている場合や、大きい積分誤差が発生している場合です。どちらの場合でも、switch_onの出力を調べ、問題の原因が、モデル内の可能性のある誤差や非現実的なパラメータ(質量、剛性、減衰、非連続性など)にあることを突き止めることができます。

  8. 低い積分次数

    switch_onの出力を使用して、積分器が低い積分次数で止まっているように見える状況を検出および診断できます。各ステップの履歴を調べて、次数を確認できます。次の例のように、次数が低く(常にOrder=1である場合など)、ステップサイズが小さい場合は、状況を調べることをお勧めします:



    図 5. 低い次数と小さいステップサイズで停止するシミュレーション

    上の図 5は、誤差トレランスが1.0E-3の、Index-3 DAE定式化を使用した一連のステップのswitch_on出力を示していますす。このシミュレーションの次数は1で止まっているように見えることがわかります。さらにこのシミュレーションは、ステップサイズが2.5E-05のときは正常に実行されているように見えますが、5.0E-05というステップが試行されると失敗します。原因は常に、修正子が収束しないことです。DSTIFFによってヤコビアンが自動的に評価されていることも確認できます。

    この状況を解決するには、次の方法を使用できます:
    • 最大の誤差を引き起こしているモデリングエンティティを調べ、非連続性を除去したり、システムを“滑らかに”(力、モーション、剛性、減衰など)する。
    • ヤコビアンの評価頻度を高めて修正子のエラーを最小限に抑えることで、ヤコビアンの評価パターンを変更する。