在负载组合生成器的最新更新中, 我们简化了模块的内部工作并添加了以下功能:

• Load combination generation is defined by a single .json file (模式) 对于每个标准.
• 无需先在 S3D 建模空间中分配载荷即可创建载荷组和组合.
• 图案, 这是基于旧的 “扩大风荷载” 复选框, 现在可以处理任何负载情况.

命名法

在负载组合生成器的最新版本中, 用于多种用途的荷载工况名称:

• 充当唯一ID.
• 区分负载 超级案例 和 是屋檐到屋脊的水平距离, 并且总是需要每个值一个值 (导致像这样奇怪的事情 死: 死).
• 保持人类可读, 同时通过收缩单词来保持下拉菜单足够小 (生活: Q-分布-屋顶-地板).

在最近的更新中, we have divided load case names into 符号, 当空间有限时，它会很小，可用于编码 (例如，在命名荷载组合时: 1.25D1 + 1.5这 + 1.5LD + 0.5SL + 0.5Ť), 和 标签, which will aim to be very descriptive. 两个都 符号 和 标签 在给定标准内必须是唯一的. 我们也将允许 负载情况 与负载同名 超级案例, 通常用于默认负载情况 (最常用的). The two examples used above would be split like this:

{“D”: “死的”}
{“先生”: “居住 - 集中, 屋顶, 地面”}

的 象征 必须至少由一个大写字母组成, 它定义了超级情况. 的 超级案例 是一个新概念, 用于对通常一起作用的类似载荷工况进行分组. 的 超级案例 标签在荷载工况标签的开头给出 (在破折号之前). 在上面的例子中 (EUROCODE) 载荷工况 Ldr 将是 L 超级工况的一部分 (标签中名为“Live”), 与 Ldd 和 Ldo 等其他负载情况一起. 幕后花絮, 的 超级案例 主要用于强制执行过滤规则, 即确定哪些模式行需要保留，哪些需要删除.

标签的第一部分 (在破折号之前) 是的名字 超级案例. 第二部分是描述, 使用逗号将类别与子类别分开. 第二部分是可选的, 但只有一种荷载工况可以采用默认值 超级案例 点.

标准模式行

每个标准都有一个 图式 它完全定义了该标准的所有可能的载荷组合. 的 架构.json 文件非常简单, 但它可能会变得很长, 尤其是在标准方面 (像欧洲规范) 需要大量的排列. 举个简单的例子, 采取以下示例要求.

1.2*d + 1.5*大号 + (0.5*S 或 0.5*W 或 0.5*T)

要将其转换为我们的 图式, 我们需要将其分解为每种可能的排列:

1.2*d + 1.5*L
1.2*深 + 1.5*大号 + 0.5*S
1.2*深 + 1.5*大号 + 0.5*瓦
1.2*深 + 1.5*大号 + 0.5*时间
1.2*深 + 1.5*大号 + 0.5*小号 + 0.5*瓦
1.2*深 + 1.5*大号 + 0.5*w ^ + 0.5*时间
1.2*深 + 1.5*大号 + 0.5*Ť + 0.5*S
1.2*深 + 1.5*大号 + 0.5*小号 + 0.5*w ^ + 0.5*Ť

一旦以这种方式列出每个荷载组合, 您可以按照以下步骤构建架构:

1. 使用每个载荷工况键和系数创建架构行对象.
2. 使用唯一标识符命名每一行 (因为这将是一个对象). 约定是使用破折号来分隔名称的不同元素.
3. 升一级, 将行按条件分组 (强度, 适用性, 偶然, 等等)

最终结果应该是这样的:

"行": {
  "强度":{
    "A-1-u": {"d": 1.40},
    "A-2a-u":{"d": 1.25, "大号": 1.50, "LS": 1.50},
    "A-2b-u":{"d": 1.25, "大号": 1.50, "LS": 1.50, "小号": 1.00},
    "A-2c-u":{"d": 1.25, "小号": 1.50, "w ^": 0.40},
    "A-3a-u":{"d": 1.25, "小号": 1.50}
  }
}

荷载组合生成算法

The algorithm goes through several steps to generate the final load combination object:

• 的 图式 as defined above is needed. It will be passed to the main load combination generation function.
• An object is created to group the number of 负载情况 通过 pattern. 例如, let’s look into a request for the load cases below:

2 Dead load case, with a merge pattern
4 Wind load cases, with an individual pattern
1 Snow load cases, with an individual pattern
2 Dead load cases, with a merge pattern

Grouping the 图案 通过 是屋檐到屋脊的水平距离 will give the following object, which will be passed to the main load combination generation function.

按情况输入= 
  {
    "d": {"合并": [2, 2], "个人": []},
    "w ^": {"合并": [], "个人": [4]},
    "小号": {"合并": [], "个人": [1]}
  }

• The last two arguments are filtering objects, 允许过滤 标准 或通过架构键.
• 一旦它拥有所有必需的参数, 主要荷载组合生成函数称为. 该函数通过多个嵌套循环来生成每个所需的组合, 以下要点对此进行了解释, 并如下图所示.
  • 在最高级别, 它循环遍历架构行. 在此步骤中检查每一行以确定是否应保留或跳过它, 使用下一节中描述的过滤对象和特定逻辑.
  • 第二个循环嵌套在第一个循环中, 循环遍历每个请求 是屋檐到屋脊的水平距离 在架构行中. 如果要求 是屋檐到屋脊的水平距离 还存在架构行 (请求汇总在 input_by_case 对象中), 然后我们进入下一个级别.
  • 第三个循环嵌套在第二个循环中, 循环遍历每个可能的 pattern 查看其中是否有要生成的荷载组, 并运行函数来命名并生成它们.
  • 生成并命名架构行中的所有载荷工况后, 他们重新组合 (以及它们的系数) 分为一种或多种荷载组合.

• 对架构的每一行重复此过程, 将所有生成的荷载组合推入最终的荷载组合对象.

It is worth nothing that all of the logic related to patterns is happening while inside a single schema row. 了解这一点对于理解模式的行为很重要. 合并模式, 例如, does not allow merging anything other than the load case it is assigned to. 这意味着您不能:

• 将不同的载荷工况合并在一起, 就像尝试合并 D1 和 L1 负载组.
• 合并输入表不同行上的相同载荷工况. 例如, 在点给出的例子中 #2 以上, 我们被要求生成 2 在两个单独的行上使用合并模式进行静载. 最终结果组合看起来像这样:

1.2*D1 + 1.2*D2 + 1.5*大号
1.2*D3 + 1.2*D4 + 1.5*大号
1.2*D1 + 1.2*D2 + 1.5*大号 + 0.5*小号
1.2*D3 + 1.2*D4 + 1.5*大号 + 0.5*小号
1.2*D1 + 1.2*D2 + 1.5*大号 + 0.5*w ^
1.2*D3 + 1.2*D4 + 1.5*大号 + 0.5*Ť

自动过滤不必要的荷载组合

虽然上述算法无需任何过滤即可运行, 它可能导致冗余负载组合, 这会导致额外的计算时间和冗余结果. 采取以下荷载组合:

1.2*d + 1.5*L
1.2*深 + 1.5*大号 + 0.5*S
1.2*深 + 1.5*大号 + 0.5*瓦
1.2*深 + 1.5*大号 + 0.5*Ť

如果我们有一个静载情况, 这四种荷载组合将产生相同的荷载组合:

1.2*D
1.2*深
1.2*深
1.2*深

为了避免这种情况, 使用了四个规则，每个规则都包含一些轻微的例外情况. 第一, 我们来看看规则. The default state is for the combination to be kept and the rules are used to determine which to exclude.

Filtering by criteria

This case is pretty self-explanatory. 如果 标准 is not requested, all schema rows associated with that 标准 are discarded.

Filtering by characters in the schema key

Schema keys are usually comma separated pointers to the original reference. 例如, in the NBCC example below, the key has three components:

• 一个: The first term is usually the main reference, reference the table in which this part of the loads are taken.
• 2b: The second term is usually a unique identifier for the load combination inside the table.
• ü: The third term is usually reserved to indicate when a large number of load combinations are permuted with a slight modification. 例如, it can indicate if the dead loads in the load combination are favorable ( F ) or unfavorable ( ü ).

{
  "强度":{
    "A-2b-u":{"d": 1.25, "大号": 1.50, "LS": 1.50, "小号": 1.00},
  }
}

Filtering in the schema key can be done for any of these terms. 例如, if we want to filter by the third term, we can add the following filter, which will create a filtering dropdown for this term:

"name_filters": {
  "强度": {
    "静载": {
      "位置": 2,
      "tooltip": "",
      "items": {
        "Favorable": "F",
        "Unfavorable": "ü"
      },
      "defaults": ["Favorable", "Unfavorable"]
    }
  }
}

All of the possible dropdown names and associated terms must be listed under “items”. Only the schema rows with matching symbols will be kept. If it is required to keep a schema row independently of what is entered in the filter, the term can be left blank. Any schema key that does not contain all of the matching dropdown terms will be discarded.

Redundant combinations

If a schema row is not filtered out by the first two steps, it moves on to step number three. 在这一步中, the redundancy issue from the above example is addressed. 去做这个, we need to look at two objects simultaneously, schema row and the sorted input_by_case object (see description above), which describes which load cases have been requested. If the schema row contains any super case which the input_by_case object does not, the load combination is removed. Take, 例如, the following schema row:

"A-2a-u":{"d": 1.25, "大号": 1.50, "小号": 1.50}

and the following input_by_case object:

按情况输入= 
{
  "d": {"合并": [], "个人": [1]},
  "大号": {"合并": [], "个人": [4]}
}

在这个例子中, the schema row contains a 超级案例 S which has not been requested. Keeping this row would lead to a load combination that would be identical to the load combination associated with the schema row below, so it is removed.

"A-1a-u":{"d": 1.25, "大号": 1.50}

Exceptions

While this behavior is usually desirable, there are cases where NOT deleting a row when the load case is absent leads to a much simpler schema. 例如, if we have horizontal earth loads that should be added to every combination of schema, but are not always present, we could copy and paste all of the load combinations and modify the schema key for the new rows with a suffix like “h” for horizontal earth loads. 或者, we can simply add the horizontal earth load to all of the cases and add a keep exception to the load case in the meta data. That way, if the load case is not requested, it will not show up, but the row will still be kept. The result looks something like this in the schema’s meta property:

"H": {
  "label": "Lateral earth - Unfavorable",
  "rank": 1,
  "exceptions": ["keep"],
  "old_labels": []
},

Superfluous combinations

If a schema row is not filtered out by the first three steps, it moves on to step number four. 在这一步中, the issue of matching specific load cases between the schema and what is requested. If a schema row and a request have matching super cases, but the specific load case requested is not in the schema, the row will not be kept. Take, 例如, the following schema row:

"A-2a-u":{"d": 1.25, "SL": 1.50}

and the following input_by_case:

按情况输入= 
{
  "d": {"合并": [], "个人": [1]},
  "Sh": {"合并": [], "个人": [1]}
}

在这个例子中, both the schema row and the request have matching super cases. 然而, the request requires a combination with Sh, which the schema row does not provide. 从而, the schema row is not kept.

Exceptions

再次, this behavior is usually desirable, but can lead to problems. One such problem is when standards have load cases that share a super case, but do not act simultaneously. 例如, 在 ASCE, the wind loads W and tornado loads Wt do not act simultaneously, though they share the same super case W. When we run into this problem, we can add an exception to switch to another 超级案例 before the code runs in the meta data. 幕后花絮, the symbol following the “->” characters will be attributed to the load case, which will simulate the load cases acting in that 超级案例. The result looks something like this in the schema’s meta property:

"Wt" : {
  "label": "风 - Tornado",
  "rank": 8,
  "exceptions": ["supercase->X"],
  "old_labels": []
},

In the case above, 的 超级案例 “w ^” will be swapped to “X” before the code runs. This feature can also be used to send group load cases that have unique 超级案例 symbols together.