カスタムメソッドの作成

新しいメソッドを登録し、既存のライブラリを保存 / インポートします。次のチャプターMethod Managerでは、これらの手順を詳細に示します。

メソッドエンティティ構造

必要な手順を理解するには、メソッドとライブラリの構造に慣れる必要があります。

ライブラリは、メソッド定義と再利用できるユーザー属性定義の集合です。ライブラリは、*.xmlファイルとして保存 / インポートされ、以下の形式にする必要があります：


図 1. ユーザーメソッドファイルスキーマ

これには、<method>タグのリストを含むメインブロック<root>が必要です。

オプションで、<root>レベルで属性名=“ユーザーライブラリ名”を追加できます。ユーザー名がMethod Managerに表示されます。

これには、<method>タグのリストを含むメインブロック<root>が必要です。

メソッドは以下のとおりです：

  • 外部ファイル（Compose、Python、Tcl、DLL）で定義された、functionに対する参照（例： retval=myfunc(x,y,z)）
  • 入力引数のマッピングの並び替えリスト
  • 出力引数名の並び替えリスト
  • （オプション）評価後のソート（集約）
図 1をご参照ください。

メソッドの属性

メソッドタグ（xml）には、いくつかの必須属性があります。（図 1）

displayname=" "
名前がMethod Managerダイアログに表示されます。これはIDキーとして機能します。
designpointmethodエンティティがHyperMeshデータベースで作成されると、ID、名前（HyperMeshエンティティ名）、および属性Method（.xmlファイルのdisplaynameの値に設定されます）が付属します。


図 2. メソッドエンティティエディター
実行時に、メソッド定義は、displaynameキーによって登録された使用可能なライブラリから検索されます。
注: 名前は、登録されたすべてのメソッドで一意である必要があります。
type="DLL | PYTHON | COMPOSE | TCL"
メソッドの実行に使用されるエンジン。これは、データ名“Engine”としてHyperMesh designpointmethodエンティティ（図 2）に保存されます。
path=" "
関数が定義されるPython/Compose/Tclファイルのファイルパス。絶対パスまたはライブラリファイルパスからの相対パスとすることができます。
name=" "
Compose/Python/Tclファイルで定義した真の関数名。
category="Rivet | Spring | Panel_metallic | Panel_composite | Generic"
UIで使用可能なメソッドのリストのフィルタリングに使用されます。カテゴリ値はdesignpointsetコンフィグと同等です。
次の引数は、実行時に変更できる結果抽出のメソッドUIにオプションを追加するオプション引数です。
corner= ”true |false”（デフォルト： false）
resavg=”none |simple |min |max |ext | sum”（デフォルト： none）
hideoption=”true |false”
作成者はcornerおよびresavgのデフォルトを設定することはできますが、これらを変更することはできません。

入力パラメータとメソッド出力を指定するために、次の2つのタグが必要です。

InputArgList
メソッド入力と、エンジンから照会するmodel/result/userキーのマッピングを定義します。パラメータのリストは、メソッド引数と同じ順序になっている必要があります。
属性のリストはインストール時に事前定義されます。これらの属性は<name-value>のペアで、実行時に現在のソルバーに基づいて解決されます。これは、ソルバーキーワードに関連付けられないマッピングを定義することにより、再利用可能なメソッドを登録することを目的としています。
この属性のデフォルトのセットに照会する目的のキーがない場合、独自の属性をメソッドにより使用されるライブラリに追加することができます（ユーザー属性の登録を参照）。
属性にマップされたパラメータは自動的に照会されて、評価のためにメソッドに渡されます。これらの属性には編集できないものもありますが（結果の値が結果ファイルに属している）、一部はHyperMeshデータベースで編集可能です（材料の許容値、メソッド / 構造プロパティデータ名など）。場合によっては、メソッドで、HyperMesh内に既存のプレースホルダーがない他の入力が必要になります。
  • 材料の追加の許容値をソルバーデックで使用することはできません（面外せん断の制限と同様）。
  • メソッド固有の座屈係数を通常のエンティティデータ名として使用することはできません。
この場合、バインド先にプレースホルダーを動的に追加して、データベースを拡張することができます。パラメータはuserinput=”1”という形で宣言されます。この場合、entitytypeは、データが付加される“有効なHyperMeshエンティティタイプ”です。バインドの選択は、期待される粒度に応じて異なります。一般的なユースケースは次のとおりです：
designpointmethod
メソッドレベルパラメータ
  • メソッド固有パラメータ
  • 評価されるすべての構造要素で同じ
structuralproperty
構造プロパティレベルパラメータ
  • 引数は構造要素ごとに異なる可能性がある
property（prop）
FEプロパティに割り当てられる属性
material（mat）
材料許容値
  • 材料自体に固有
entitytypeがpropertyかmaterialの場合、エンジンはxml内でattribute name=””と同じ名前のエンティティで使用できるメタデータを検索します。メタデータのタイプは属性によって定義されます：
  • Name=””： 値のクエリに使用されるメタデータ名
  • Datatype=””： double |integer | string
  • Value=””： メタデータが自動作成されている場合に使用されるデフォルト値
entitytypeがdesignpointmethodかstructuralpropertyの場合、その他のオプションが使用可能です：
  • displayname =””： UIに表示される属性の名前（nameと異なる名前にできます）
  • allowables =””： 許容値のスペース区切りリストUIではコンボボックスとしてレンダリングされます。
  • differentiator=””：
    • fileopen |filesave：文字列をファイルのオープン / 保存ウィジェットとしてレンダリングします。
    • checkbox：整数をブーリアンチェックボックスとしてレンダリングします。
選択したコンフィグで指定されている通常のデータ名と共に、動的データ名がdesignpointmethod（またはstructuralproperty）に追加されます。これらはもはやメタデータではありません。次の例では、文字列条件（conditionと呼ばれる）がdesignpointmethodに追加されています。これは次の2つの値を受け入れます：
  • Condition1
  • Condition2


    図 3.
このテンプレートから作成した場合、メソッドは以下のように示されます：


図 4.
メタデータ値
ユーザー入力パラメータを使用する定義を持つメソッドがエンジンにより実行される場合、実行時にデータが存在することが期待されます。xml内で設定されている値に関係なく、エンジンでは常に、データベースでエンティティレベルで定義された値が使用されます。
メソッドが作成されると、designpointmethodの動的データ名が追加されます。その他のエンティティについては、実行するメソッドが（designpointsetに）割り当てられたとき、または選択されたときに、次のロジックが適用されます：
メソッドの実行時にエンティティをスキャンし、関連する動的データ名またはメタデータが存在しない場合にのみそれらを作成します。メタデータを割り当てる必要がある場合、structuralpropertyに割り当てられたプロパティと材料が要素プロパティより優先されます。
プロパティ（材料）に同じ名前のメタデータがある場合、それを変更せずに維持します。それ以外の場合、メタデータが見つからなければ、xmlからのデフォルト値（指定されている場合）で追加されます。
OutputArgList
メソッドは複数の（事前定義）結果を出力できます。
可変数の出力はサポートされていません。各メソッド出力に表示名を（順序立てて）割り当てることができます。この名前は、メソッドテーブル列のヘッダーになります（図 5）。
OuptuArgListで使用される<Parameter>タグの1つ（1つのみ）に属性marginofsafety="1"を割り当てることができます。
複数のメソッドが同じ場所に割り当てられる場合は常に、すべてのメソッドが1つの属性marginofsafety="1"を持つものとして、追加の集約テーブルが作成されます。その後、メトリックとしてmarginofsafetyとタグ付けされたパラメータを使用して、メソッドが互いに比較されます。
図 5. メソッドテーブル：入力および出力

ソート

メソッド登録内で、Sortブロックを追加できます。これにより、designpoint内のそれぞれのエンティティ（要素 | レイヤー）について、およびそれぞれの荷重ケースについて、メソッドが引き続き評価されます。

ただし、メソッドの実行後、集約はメトリックとエンベロープタイプを使用して、Domain上で実行されます。この集約の結果として、メソッドによって出力されるテーブルには、集約された値のみが保持されるようになります。エンベロープタイプは空間的にすることも、領域に応じて荷重ケース上とすることもできます（図 6）。

Type（エンベロープの）
有効なタイプは以下のとおりです：
  • Min
  • Max
  • AbsMin
  • AbsMax
Value
値は、InputArgListまたはOutputArgListのどちらの浮動小数点パラメータであってもかまいません。これは、比較メトリックとして使用されます。
Domain
領域は次のリストにある複数のキーの組み合わせにすることができます：
  • DDP
  • entityid
  • elementid
  • nodeids
  • layerindex
  • か荷重ケース
これらのキーのいずれかが欠落すると、この次元で集約が行われます。例として、以下の連続する呼び出しで構成される領域を挙げます：
  • DDP |entityid |elementid|layerindex |nodeids：荷重ケースエンベロープを実行します。コーナーまたは節点データが考慮される場合、これらはソート後に保持されます。
  • DDP |entityid |elementid|layerindex：荷重ケースエンベロープを実行します。コーナーまたは節点データが考慮される場合、これらは集約されます。
  • DDP |entityid |elementid|nodeids|loadcase：要素のレイヤーで集約を実行します。荷重ケースごとに結果を保持します。
  • DDP |entityid |elementid：荷重ケースエンベロープを実行します。要素ごとに重要な値を保持する空間的な集約。
  • DDP | entityid：荷重ケースエンベロープを実行します。重要なエンティティ（パネルまたはフリーボディ）を保持する空間的な集約。
  • DDP |nodeids |loadcase：指定のDDPの節点上の値を集約します（DDP境界は維持します）。荷重ケースごと。


図 6. 評価後のソート
制約事項: ソートが行われると、出力テーブルは、重要なメトリック値に対応する行全体をそのすべての値（入力 / 出力）と共に維持します。次元全体にわたってソートを実行することで、次元が失われ、その結果として、ソートされた次元での完全なコンター表示ができなくなる可能性があります。
  • 複数の荷重ケースにまたがる重要な値がある場合は常に、エンベロープの荷重ケースについてのみコンターを表示できます。
  • 複数の層にまたがる結果が集約される場合は常に、要素レベルでのみコンターを表示できます。
  • （designpoint上の）複数の要素にまたがって集約が実行される場合は常に、テーブルには、DDP | elementid | loadcase | ..inputs | ..outputs | metricが含まれます（metricでは重要な値が使用されます）。その結果として、テーブルでdesignpointごとに1つの要素IDのみが保持されます。ただし、コンターメソッド機能は、DDPをエンティティとして選択する機能を備えています。これにより、構造要素内のすべての要素上で一定値がコンター表示されます。

入力の集約

評価後のソートに加えて、属性を評価のためにメソッドに送信する前に、それらの属性をソートできます。これにより、メソッドの評価においてある程度の柔軟性が得られます。例えば、メソッドの入力パラメータを次のように宣言できます：
<Parameter name = "Composite Stress XX"
                perlayer="0"
                sort=”min|max|minmax|sum|avg|absmin|absmax” (optional)
/>

こうして、メソッドを呼び出す前に、Sxxについてすべてのレイヤーが照会され、minまたはmaxのみが保持されてメソッドに送信されます。minmaxの場合は、minとmaxの両方の値がベクトルとしてメソッドに送信されます。sortキーはオプションです。ソートが要求されない場合は、Sxxのすべてのレイヤーの値が（ベクトルとして）同時にメソッドに送信されます。

属性の集約タイプは次のとおりです（択一）：
  • perlayer="0|1"
    • 0はすべてのレイヤーのリストを意味します（メソッドは要素ごとにのみ呼び出されます）。
    • 1（デフォルト）は現在のレイヤーのみを意味します（メソッドはレイヤーごとに呼び出されます）。
  • perelement="0|1"
    • 0はすべての要素のリストを意味します（メソッドはdesignpointごとにのみ呼び出されます）。
    • 1（デフォルト）は現在の要素のみを意味します（メソッドは要素ごとに呼び出されます）。
  • perloadcase="0|1"
    • 0はすべての荷重ケースのリストを意味します（メソッドはすべての荷重ケースに対して一度呼び出されます）。
    • 1（デフォルト）はメソッドが荷重ケースごとに呼び出されることを意味します。

ユーザー属性の登録

登録される属性は、HyperMeshデータベースから照会されたモデル情報か、結果ファイルから照会された結果情報です。結果データタイプは結果ファイル内の名前と一致する必要があります。ほとんどの場合は、集約されたベクトルデータタイプまたはテンソルデータタイプが結果リーダーによって提供されます。

例：
  • 1DForcesと1DMoments
  • 2DForcesと2DMoments
  • Stress
  • Composite Stress
メソッド登録の移植性を高めるために、可能であれば、直接生のスカラーを使用するのではなく、このような集約されたデータタイプを使用することをお勧めします。生のスカラーは、同じソルバーであっても、要素の定式化（cbar力とcbush力など）や使用するファイルフォーマットに応じて変化することがあります（*.xdbと*.op2のスカラー表記は異なります）。使用できる事前定義の属性のリストがあります（図 3を参照）。ユーザー固有の属性のみを定義する必要があります。
制約事項: この操作は、現在、ライブラリの.xmlファイルを編集することによってのみ実行できます。GUIはありません。
すべての結果属性は、HMDb結果で始まるdesignpoint（キー“value=”）からの完全修飾パスで定義されます（図 7）。
注: HMDbは、照会される現在のdesignpointです。
designpointが複数の要素で構成されている場合は常に、このフレームワークによってdesignpointの内容がループ処理されます。例えば、panel_composite designpointで使用される“Composite Stress XX”は、要素ごと、およびレイヤーごとにSxxを照会します。属性は、完全修飾パスを使用して柔軟に定義できます。デフォルトでは、プロパティや材料に基づいた属性は、structuralpropertyのプロパティエンティティから照会されます。使用可能なプロパティエンティティがない場合、クエリは要素のプロパティレベルで実行されます。
構造プロパティの内容に関係なく、パスを通じて要素を照会したい場合は、その要素を含むようにパスを完全修飾できます：
  1. HMDb.property.PCOMP_MID.MAT8_Xtでは、上述の優先順位に基づいてプライの材料Xt（Nastranソルバー属性）が照会されます。
  2. HMDb.element.property.PCOMP_MID.MAT8_Xtでは、どのプロパティが構造プロパティに割り当てられているのか（または割り当てられていないのか）に関係なく、常にローカル要素のプロパティが使用されます。
場合によっては、このフレームワークでは優先順位を解決できない場合があります（panel_metallicの“Thickness”など）：
  1. HMDb.element.thicknessでは、パネル（金属&複合材）内の要素板厚が取得されます。
  2. HMDb.structuralproperty.thicknessでは、Panel_metallic構造プロパティのthickness属性を使用することが強制されます。

要素上で1つの属性が複数の値を取ることができる場合（プライあたりの材料の許容数と同様）、エンジンではクエリループ時にレイヤーごとに管理を行います。

キーname=" "はライブラリ内（同じ.xmlファイル）のすべての属性で一意である必要があります。
  • インストールと同じ名前で属性を再定義すると、同じライブラリのメソッド内で優先されます。
  • 複数のライブラリにわたって同じ名前の属性はローカルに解決されます。


図 7. ユーザー属性定義例