モデリングとシミュレーションのヒント

このトピックには、MotionSolveモデルを構築する際に従う一般的なガイドラインが含まれています。

全般的なガイドライン

  • 非常にシンプルなモデルから開始し、ステップごとに複雑にします。
  • 各ステップでモデルを実行し、結果が理に適っているかをチェックします。モデル全体の完成を待って実行するのではありません。複雑なモデルのデバッグ作業は通常非常に困難なタスクです。

剛体パートのモデリング

  • モデル内のボディについて、物理的に非現実的な質量や慣性の使用を避けます。例えば、下記のプロパティは質量と慣性の一般的なデフォルトです： (1)
    M=1Kg,Inertia=[ 1 0 0 0 1 0 0 0 1 ] Kg-mm 2
    ボディが球形であると仮定すると、この質量と慣性モーメントは密度が鋼鉄の密度の7,000倍となり、それは物理的に非現実的です。物理的に非現実的な質量や慣性を使用すると、通常ソルバーのスピードを落とし、シミュレーションを失敗する場合もあります。より優れたデフォルトは：(2)
    M=1Kg,Inertia= [ 1000 0      0   0 1000 0   0   0 1000 ] Kg-mm 2
  • 適用可能なところにはPoint_Mass要素を使用し、モデル内の自由度を小さくします。この要素は、モデルに3つの自由度のみを追加し、一方、剛体要素は6つの自由度を追加します。
  • ボディが他の剛体および/または弾性体と固定ジョイントで結合されている場合、質量ゼロのダミーボディを使用することは問題ありません。

フォース要素のモデリング

  • 非減衰のブッシュやバネの使用を避けます。これらは物理的に非現実的です。非減衰のブッシュやバネは、散逸しない小さな非減衰振動を考慮することをソルバーに要求するため、ソルバーのスピードが落ちてしまいます。そのような振動は、多くの場合、シミュレーションで着目する対象ではありません。すべてのブッシュおよびバネに小さな減衰を追加することを考慮してください。開始ポイントとして良いのは、1%の剛性値です。多くの場合、そのような小さな減衰は、シミュレーションをスピードアップするのに十分です。
  • 上記と同じ理由から、減衰がゼロであるImpact関数の使用を避けます。
  • IF関数を使って定義された非連続のフォースの使用を避けます。非連続性は、積分器の失敗を生じさせる場合があります。そのような要素を使用する必要がある場合、シミュレーションの失敗であれば、最大ステップサイズ（H_MAX）の積分器パラメータを小さくしてみます。
  • ブッシュ要素は、1つの回転軸についてのみ大きい角偏向を有することが可能です。複数の軸について大きい角偏向を有する場合、結果は正しくない可能性があります。

拘束のモデリング

余分な拘束条件の回避
  • 必要な拘束条件のみを正しく付加し、余分な拘束の導入を回避するために、ジョイントプリミティブを使用します。複雑な機能の場合、これには熟考を要することがあります。
  • 上記のステップが実現不可能な場合、弾性体の使用を考慮します。弾性体はモデルに自由度を追加し、余分な拘束の可能性を減らします。これもまた、より正確な結果を与えることがあります。
動解析モデル内の動きの拘束の定義
  1. 微分は、入力シグナル内のノイズを増幅する傾向があります。したがって、入力として提供されるすべての式と実験データはスムーズで2回微分可能であることを確実にすることが重要です。実験データを介して補間する際は、AKIMA()補間法の使用は回避します。AKIMA()は、良好な1次および2次導関数を計算しません。代わりにCUBSPL()を使用してください。
  2. 積分は、入力シグナル内のノイズを削減する傾向があります。したがって、運動入力方程式として補間された実験データまたは表形式のデータを与える際に、速度の入力の使用が適切です。
  3. できる限りポイントの数が少ないカーブを定義します。3次曲線内に補間ポイント数が極端に多いと、カーブ自体がスムーズに見えても、1次導関数に揺れが、2次導関数に激しい揺れが生じます。
  4. モーションの初期速度が、それに影響するボディの初期速度に一致することを確実にします。例えば、初期静的状態からシミュレーションが開始される場合、入力するモーションの初速はゼロであることを確認する必要があります。モーションの入力は、ボディの初期速度と一致しない場合にそれを無効とします。
  5. 速度の入力を使用することを決定した場合、位置は、PARAM_TRANSIENTに指定された積分エラーに対してのみ満たされる点にご留意ください。同様に、加速度の入力については、速度と位置のみが、指定された積分エラーに対し満足されます。したがって、解析的なソリューションからは多少逸れるかもしれません。これは、数値積分に基づいたあらゆる手法の限界です。
  6. モーションの拘束による反力/トルクの時刻歴を確認することは役に立ちます。この履歴により、指定したモーションを達成するためにどれだけの反力/トルクが必要かを知ることができます。それが現実的であるかどうかは、ユーザーが判断します。さらに、モーションを適用されるフォースに置き換え、制御則を加味すると、物理的に、より意味をなすようになる場合があります。動解析におけるモーションは、コンプライアンスの余地のない"ハード"な拘束として扱われる点に留意する必要があります。
  7. モーションは時間のみの関数です。現在のインプリメンテーションでは、他のシステム変位、速度、加速度、反力および適用されるフォースの関数であることは許可されません。

接触力のモデリング

MotionSolveの接触機能：

  • 接触力モデルは、ペナルティの定式化に基づいています。これは、ADAMSで使用可能な衝撃関数ベースの接触力と同様です。MotionSolveではPoissonと呼ばれていますが、そのインプリメンテーションは、ADAMSソルバーにおけるPoissonアプローチと似てはいません。
  • 衝突、ローリング、スライディング、および回転を含む、周期的かつ連続的な接触がサポートされています。
  • 摩擦はサポートされています。
  • 複数の接触もサポートされます。接触は、複数のポイントまたは頂点、および/または同一の対象物上に存在するエッジや面において起こり得ます。
  • 任意の接触サーフェスは、任意の多角形の集合体を使って定義されることが可能です。
  • 接触サーフェスは、完全に一般的であり得ます。MotionSolveは、サーフェスのくぼみや連続性、またはサーフェスの湾曲または接続性に関するその他のあらゆる制限を仮定しません。
MotionSolveは下記のものをサポートしません：
  • 非サーフェス物体間の接触。例えば、カーブ、ラインやポイント。
  • 拘束ベースの接触モデル。例えば、最も高速なゲームマルチボディソルバーで広く使用されているLinear Complementary Programming（LCP）ベースの接触アルゴリズム。
  • 接触力定義用ユーザーサブルーチン
  • Parasolid形状ファイルのソルバーによる直接使用。
接触モデリングのヒント：
  • Contact frictionをOffにセットして、モデリングを開始します。
  • 現実的かつ安定した結果を得るには通常、ペナルティと反発係数の値についてある程度の実験が必要です。
  • モデルが非スティフで接触が断続的である場合、ABAM積分器を使ったほうがよいかもしれません。スティフなモデルは通常、非常に大きな負の実数部をもった固有値を有しています。
  • 比較的小さいINTEGR_TOLとHMAXから開始し、必要に応じて大きくしていきます。
  • サーフェスが硬いか、薄いか、またはその両方である場合、ソルバーパラメータHMAXを小さくします。薄いパートとの接触の場合、HMAXの設定が大きすぎると、接触イベントが失われることがあります。
  • 多くの場合、接触摩擦力パラメータmu_static、mu_dynamic、およびstiction_trans_velは、接触の挙動とシミュレーションスピードに大きな影響を与えます。現実的で安定した結果を得るには、多少の調整が必要な場合が多くあります。
  • 摩擦力の追加が数値的な困難もしくはシミュレーションのスピード低下を生じる場合、速度推移の値を徐々に増やし、摩擦係数を小さくします。
  • 貫通サーフェスがエッジに遭遇した場合、接触についての現在のインプリメンテーションには、困難が伴います。接触の法線に非連続なジャンプが生じ、その結果、接触サーフェスに隆起ができてしまいます。剛体形状のエッジをスムーズ化することが役に立つかもしれません。それが不可能である場合、エッジが剛体‐剛体接触と遭遇しないように接触形状を延長することを考えます。
下の一覧は、一般的に見られるシミュレーションの問題点とその対策を示したものです。
問題点
対策
接触が検出されない
  • H_MAXを小さくする
  • エラートレランスを小さくする
  • ペナルティを大きくする
積分器の失敗
  • H_MAXを小さくする。
  • ペナルティを小さくする
  • エラートレランスを大きくする
  • 摩擦係数を小さくする
  • 速度推移を増やす
  • モデル内の非減衰エンティティに減衰を与える
初期条件にて積分が困難
  • モデルのコンフィギュレーションにおいてパートが貫通されているかを確認する
接触力は、ボディに反発する代わりに、ボディを一緒に引っ張る
  • サーフェスの法線ベクトルがボリュームでサーフェスから逆を指していることを確実にします。サーフェスの法線は、HyperMeshを使って可視化できます。

弾性体のモデリング

  • 互いに近すぎる取り付け節点の選択を避けます。これによりモードがほどんど1次従属である（ソリューションで困難を生じる）見込みが高くなります。
  • 弾性体の減衰を注意深く設定します。モード減衰比が部分モードに適用され、それは、一般的には、コンポーネントの物理的な振動モードに対応しません。
  • 使用前に弾性体を検証し、適切な数の固定インターフェース固有モードが選択されていることを確実にします。
  • 区分モード合成では、細かすぎるメッシュは必要ありません。これは、少数の固有モードしか必要とされないためです。最も一般的には、粗すぎるメッシュではなく、より細かいメッシュを使用します。
  • マルチボディシミュレーションでは、全てのモードを使用します。それらのうちの幾つかが、計算スピードを上げるために非アクティブ化されることを回避します。これは、積分の失敗を生じる場合もあります。モデルのセットを減らすために、節点自由度の幾つかを開放できます。詳細については、OptiStructオンラインヘルプのトピックASETをご参照ください。
  • OptiStructには、精度を犠牲にすることなくファイルのサイズを小さくするためのオプションがいくつか用意されています。OptiStructチュートリアルのオンラインヘルプのトピック、MotionSolveで使用するための弾性体の作成 - OS-1930をご参照ください。

ソルバーパラメータの調整

  • 一般的に、MotionSolveでの動解析結果は、出力間隔に依存しません。しかしながら、タイムステップより小さい出力間隔が指定されている場合、MotionSolveはタイムステップを出力間隔と同じになるよう変更します。しかしながら、擬似静解析および運動学解析の結果は、これらの場合はステップサイズに等しい出力間隔によって大きく影響を受けます。このパラメータの値が大き過ぎると、シミュレーションが失敗する場合があります。
  • 通常、MotionSolveによる動解析の安定性は、エラーの許容値とH_MAXパラメータが小さくなるに従って向上します。ただし、ランタイムは長くなる可能性があります。

ユーザー定義のサブルーチン

  • 1つのDLLでFortranとCのソースファイルを混用することは可能でしょうか？その答えは、どのタイプのサブルーチンが使用されるかに依ります。ユーザー定義のサブルーチンは次のとおり分類されます：
    • Type 1　-　GFOSUB、DIFSUB、COUSUBなどのモデリングサブルーチン。これらはソルバーに特別な意味を持ちます。
    • Type 2　–　Type 1以外のすべてのサブルーチン。通常、Type 2 サブルーチンはType 1サブルーチンから、もしくはその他のType 2サブルーチンからコールされます。
  • FortranとCで書かれている複数のType 1サブルーチンがある場合、それを別々のDLLに分ける必要があります。例えば、FortranのGFOSUBとDIFSUBおよびCのCOUSUBがある場合、FortranおよびCサブルーチンをそれぞれ2つの異なるDLLにビルドします。
  • Type 1サブルーチンがすべて1つの言語で書かれている場合、2つのDLLは必要ありません。例えば、Type 2サブルーチンがすべてCで、Type 1サブルーチンがすべてFortranで書かれている場合、FortranのDLLをビルドする指示を使用し、Cソースは単にプロジェクトに挿入します。代わりに、コードをスタティックライブラリにビルドし、Fortranプロジェクトにそれをインクルードすることも可能です。
    注: Type 1サブルーチンがすべて1つの言語で書かれていても、それらを数多くのDLLにビルドできます。ただし、各DLLは別々のエンティティです。異なるDLLで別のサブルーチンを、コールする1つのDLL内に持つことができます。