荷重組み合わせジェネレーターの最新のアップデートでは, モジュールの内部動作を簡素化し、次の機能を追加しました。:
- 負荷の組み合わせの生成は単一の .json ファイルによって定義されます (スキーマ) 規格ごとに.
- S3D モデリング空間で最初に荷重を割り当てることなく、荷重グループと荷重の組み合わせを作成できます。.
- パターン, 古いものに基づいています “風荷重の拡大” チェックボックス, あらゆる荷重ケースに対応できるようになりました.
命名法
荷重組み合わせジェネレーターの最新バージョンでは, さまざまな用途に使用された荷重ケース名:
- 一意のIDとして機能する.
- 負荷を区別する スーパーケース そして 荷重ケース, それぞれに常に 1 つの値が必要です (のような奇妙なものにつながります デッド: デッド).
- 人間が読める形式を維持する, その間、単語を短縮することでドロップダウン メニューに十分な大きさを維持します (住む: Q-dist-屋上-床).
最新のアップデートでは, 荷重ケース名を次のように分割しました。 シンボル, コンパクトでスペースが限られている場合に使用されます (たとえば、荷重の組み合わせに名前を付ける場合: 1.25D1 + 1.5の + 1.5Ld + 0.5Sl + 0.5T), そして ラベル, 説明的なものになります (たとえばドロップダウンで使用されます). 両方 シンボル そして ラベル 特定の標準内で一意である必要があります. も許可させていただきます 荷重ケース ロードと同じ名前が付けられます スーパーケース, 通常はデフォルトの荷重ケースの場合 (最も一般的に使用される). 上で使用した 2 つの例は次のように分割されます。:
{「D」: "死んだ"}
{「LDR」: "ライブ - 濃縮, 屋根, 床"}
の シンボル 少なくとも 1 つの大文字で構成する必要があります, スーパーケースを定義するもの. の スーパーケース 新しい概念です, 通常一緒に作用する同様の荷重ケースをグループ化するために使用されます. の スーパーケース ラベルは荷重ケースのラベルの先頭に与えられます (ダッシュの前に). 上の例では (ユーロコード) 荷重ケース Ldr は L スーパーケースの一部になります (レーベルのLiveという名前), Ldd や Ldo などの他の荷重ケースと並行して. 舞台裏, の スーパーケース 主にフィルタリング ルールを適用するために使用されます, つまり、どのスキーマ行を保持する必要があり、どの行を削除する必要があるかを決定します。.
ラベルの最初の部分 (ダッシュの前に) の名前です スーパーケース. 後半部分は説明です, カンマを使用してカテゴリとサブカテゴリを区切る. 2 番目の部分はオプションです, ただし、デフォルトを適用できるのは 1 つの荷重ケースだけです スーパーケース スポット.
標準スキーマ行
各規格には、 スキーマ これにより、この規格で可能なすべての荷重の組み合わせが完全に定義されます。. の スキーマ.json ファイルは非常に簡単です, しかし、かなり長くなる可能性があります, 特に規格においては (ユーロコードのような) 多数の順列を必要とする. 簡単な例を挙げると, 次の要件の例を考えてみましょう.
1.2*D + 1.5*L + (0.5*S または 0.5*W または 0.5*T)
これを私たちのものに変換するには、 スキーマ, それを考えられるそれぞれの順列に分解する必要があります:
1.2*D + 1.5*L 1.2*D + 1.5*L + 0.5*S 1.2*D + 1.5*L + 0.5*W 1.2*D + 1.5*L + 0.5*T 1.2*D + 1.5*L + 0.5*S + 0.5*W 1.2*D + 1.5*L + 0.5*W + 0.5*T 1.2*D + 1.5*L + 0.5*T + 0.5*S 1.2*D + 1.5*L + 0.5*S + 0.5*W + 0.5*T
この方法ですべての荷重の組み合わせがリスト化されると、, 次の手順に従ってスキーマを構築できます:
- 各荷重ケースのキーと係数を使用してスキーマ行オブジェクトを作成します.
- 各行に一意の識別子を付けて名前を付ける (これはオブジェクトになるので). 慣例として、名前のさまざまな要素を区切るにはダッシュを使用します。.
- 一つレベルアップ, 行を基準にグループ化する (力, 保守性, 偶然の, 等)
最終結果は次のようになります。:
"行": {
"力":{
"あ-1-う": {"D": 1.40},
"あ-2あ-う":{"D": 1.25, "L": 1.50, "Ls": 1.50},
"A-2b-u":{"D": 1.25, "L": 1.50, "Ls": 1.50, "S": 1.00},
"A-2c-u":{"D": 1.25, "S": 1.50, "W": 0.40},
"あ-3あ-う":{"D": 1.25, "S": 1.50}
}
}
荷重組み合わせ生成アルゴリズム
アルゴリズムはいくつかのステップを経て、最終的な荷重組み合わせオブジェクトを生成します。:
- の スキーマ 上で定義したように必要です. メインの荷重組み合わせ生成関数に渡されます。.
- オブジェクトの数をグループ化するために作成されます。 荷重ケース 沿って パターン. 例えば, 以下の荷重ケースのリクエストを見てみましょう:
2 死荷重ケース, マージパターンあり 4 風荷重ケース, 個性的なパターンで 1 積雪荷重ケース, 個性的なパターンで 2 死荷重のケース, マージパターンあり
グループ化 パターン 沿って 荷重ケース 次のオブジェクトが得られます, これはメインの荷重組み合わせ生成関数に渡されます。.
ケース別入力 =
{
"D": {"マージ": [2, 2], "個人": []},
"W": {"マージ": [], "個人": [4]},
"S": {"マージ": [], "個人": [1]}
}
- 最後の 2 つの引数はフィルタリング オブジェクトです, これによりフィルタリングが可能になります 基準 またはスキーマキーによって.
- 必要な引数をすべて指定したら, メインの荷重組み合わせ生成関数が呼び出されます. この関数は、複数のネストされたループを通過して、必要なすべての組み合わせを生成します。, 以下の箇条書きで説明します, 次の図に示されています.
- 最高レベルで, スキーマ行をループします. このステップで各行を保持するかスキップするかを確認します。, 以下のセクションで説明するフィルタリング オブジェクトと特定のロジックを使用します。.
- 最初のループに 2 番目のループがネストされています, リクエストされたそれぞれをループします 荷重ケース スキーマ行内. リクエストされた場合 荷重ケース スキーマ行も存在します (リクエストは input_by_case オブジェクトに要約されます), それから次のレベルに進みます.
- 2 番目のループに 3 番目のループがネストされています, 可能なすべてをループします パターン その中に生成する荷重グループがあるかどうかを確認します, そして、実行時に名前を付けて生成する関数を実行します。.
- スキーマ行内のすべての荷重ケースが生成され、名前が付けられたら、, それらは再結合されます (係数と一緒に) 1 つまたは複数の荷重の組み合わせに分割.
- このプロセスはスキーマの行ごとに繰り返されます, 生成されたすべての荷重組み合わせを最終的な荷重組み合わせオブジェクトにプッシュします。.
パターンに関連するすべてのロジックが単一のスキーマ行内で発生することには何の価値もありません. これを知ることはパターンの動作を理解する上で重要です. マージパターン, 例えば, 割り当てられている荷重ケース以外のものをマージすることはできません. これは、できないことを意味します:
- 異なる荷重ケースを結合する, D1 と L1 の荷重グループをマージしようとするようなもの.
- 入力テーブルの異なる行の同一の荷重ケースを結合します。. 例えば, ポイントで示した例では #2 上, 生成するように求められています 2 2 つの別々の行でマージ パターンを使用したデッド ロード. 最終的な結果の組み合わせは次のようになります。:
1.2*D1 + 1.2*D2 + 1.5*L 1.2*D3 + 1.2*D4 + 1.5*L 1.2*D1 + 1.2*D2 + 1.5*L + 0.5*S 1.2*D3 + 1.2*D4 + 1.5*L + 0.5*S 1.2*D1 + 1.2*D2 + 1.5*L + 0.5*W 1.2*D3 + 1.2*D4 + 1.5*L + 0.5*T
不要な負荷の組み合わせを自動フィルタリング
上記のアルゴリズムはフィルタリングなしでも機能しますが、, 冗長な負荷の組み合わせが発生する可能性があります, これにより、余分な計算時間と冗長な結果が発生します。. 次の荷重の組み合わせを考えます:
1.2*D + 1.5*L 1.2*D + 1.5*L + 0.5*S 1.2*D + 1.5*L + 0.5*W 1.2*D + 1.5*L + 0.5*T
単一の死荷重ケースがある場合, これら 4 つの荷重の組み合わせは、同じ荷重の組み合わせになります。:
1.2*D
1.2*D
1.2*D
1.2*D
この状況を避けるために, 4 つのルールが使用されますが、それぞれに若干の例外が含まれます。. 最初, ルールを見てみましょう. デフォルトの状態では組み合わせが保持され、ルールを使用してどれを除外するかが決定されます。.
条件によるフィルタリング
このケースは一目瞭然です. 非線形解析にはP-Deltaが含まれます 基準 要求されていない, それに関連付けられたすべてのスキーマ行 基準 捨てられる.
スキーマキーの文字によるフィルタリング
スキーマ キーは通常、元の参照へのカンマ区切りのポインタです。. 例えば, 以下の NBCC の例では, キーには 3 つのコンポーネントがあります:
- あ: 通常、最初の用語が主な参照になります, 負荷のこの部分が取られるテーブルを参照してください.
- 2b: 2 番目の項は通常、テーブル内の荷重の組み合わせの一意の識別子です。.
- あなた: 3 番目の項は通常、多数の荷重の組み合わせがわずかな変更を加えて並べ替えられる場合を示すために予約されています。. 例えば, 荷重の組み合わせにおける死荷重が適切かどうかを示すことができます ( f ) または不利な ( あなた ).
{
"力":{
"A-2b-u":{"D": 1.25, "L": 1.50, "Ls": 1.50, "S": 1.00},
}
}
スキーマ キーでのフィルタリングは、これらの用語のいずれに対しても実行できます。. 例えば, 3番目の項でフィルタリングしたい場合, 次のフィルターを追加できます, これにより、この用語のフィルタリング ドロップダウンが作成されます:
"名前フィルター": {
"力": {
"デッドロード": {
"位置": 2,
"ツールチップ": "",
"アイテム": {
"有利": "f",
"不利": "あなた"
},
"デフォルト": ["有利", "不利"]
}
}
}
考えられるドロップダウン名と関連用語はすべて「項目」の下にリストする必要があります。. 一致するシンボルを持つスキーマ行のみが保持されます. フィルターに入力された内容とは関係なくスキーマ行を保持する必要がある場合, 用語は空白のままにすることができます. 一致するドロップダウン用語がすべて含まれていないスキーマ キーは破棄されます。.
冗長な組み合わせ
最初の 2 つの手順でスキーマ行が除外されない場合, ステップ 3 に進みます. このステップでは, 上記の例の冗長性の問題は解決されています. これをする, 2 つのオブジェクトを同時に見る必要がある, スキーマ行とソートされた input_by_case オブジェクト (上の説明を参照してください), どの荷重ケースが要求されたかを説明します. スキーマ行に、input_by_case オブジェクトに含まれないスーパー ケースが含まれている場合, 荷重の組み合わせが削除される. 取った, 例えば, 次のスキーマ行:
"あ-2あ-う":{"D": 1.25, "L": 1.50, "S": 1.50}
および次の input_by_case オブジェクト:
ケース別入力 =
{
"D": {"マージ": [], "個人": [1]},
"L": {"マージ": [], "個人": [4]}
}
この例では, スキーマ行には スーパーケース リクエストされていないS. この行を保持すると、以下のスキーマ行に関連付けられた負荷の組み合わせと同一の負荷の組み合わせが生成されます。, それでそれは削除されます.
"あ-1あ-う":{"D": 1.25, "L": 1.50}
例外
通常、この動作は望ましいものですが、, ロードケースが存在しないときに行を削除しないと、スキーマがはるかに単純になる場合があります。. 例えば, スキーマのすべての組み合わせに追加する必要がある水平方向の土荷重がある場合, しかし常に存在するわけではありません, すべての荷重の組み合わせをコピーして貼り付け、水平土荷重の「h」などの接尾辞を付けて新しい行のスキーマ キーを変更できます。. あるいは, すべてのケースに水平地球荷重を追加し、メタデータ内の荷重ケースに保持例外を追加するだけです。. そうやって, 荷重ケースが要求されていない場合, それは表示されません, ただし、行は引き続き保持されます. 結果はスキーマのメタ プロパティで次のようになります。:
"H": {
"ラベル": "ラテラルアース - 不利",
"ランク": 1,
"例外": ["保つ"],
"古いラベル": []
},
余計な組み合わせ
最初の 3 つの手順でスキーマ行が除外されない場合, ステップ 4 に進みます. このステップでは, スキーマと要求されたものの間で特定の荷重ケースを一致させる問題. スキーマ行とリクエストに一致するスーパーケースがある場合, しかし、要求された特定の荷重ケースはスキーマにありません, 行は保持されません. 取った, 例えば, 次のスキーマ行:
"あ-2あ-う":{"D": 1.25, "Sl": 1.50}
および次の input_by_case:
ケース別入力 =
{
"D": {"マージ": [], "個人": [1]},
"シュ": {"マージ": [], "個人": [1]}
}
この例では, スキーマ行とリクエストの両方に一致するスーパーケースがあります. しかしながら, リクエストには Sh との組み合わせが必要です, スキーマ行では提供されないもの. したがって, スキーマ行は保持されません.
例外
もう一度, 通常、この動作は望ましいものです, しかし問題を引き起こす可能性があります. そのような問題の 1 つは、標準にスーパー ケースを共有する荷重ケースがある場合です。, ただし同時に行動しないでください. 例えば, ASCEで, 風荷重 W と竜巻荷重 Wt は同時に作用しません, 同じスーパーケース W を共有していますが、. この問題に遭遇したとき, 例外を追加して別の例外に切り替えることができます スーパーケース コードがメタデータで実行される前に. 舞台裏, に続く記号 “->” 文字は荷重ケースに起因します, これは、その中で作用する荷重ケースをシミュレートします。 スーパーケース. 結果はスキーマのメタ プロパティで次のようになります。:
"Wt" : {
"ラベル": "風 - 竜巻",
"ランク": 8,
"例外": ["スーパーケース->バツ"],
"古いラベル": []
},
上記の場合, の スーパーケース “W” に交換されます “バツ” コードが実行される前に. この機能は、固有の荷重ケースをグループに送信するために使用することもできます。 スーパーケース シンボルを一緒に.
