In the most recent update to the load combination generator, we have simplified the inner workings of the module and added the following functionality:

• Load combination generation is defined by a single .json file (Schema) for each standard.
• Load groups and combinations can be created without having to assign loads first in the S3D modelling space.
• Modelli, which are based on old the “Expand Wind Loads” casella di controllo, now work with any load cases.

Nomenclatura

Nell'ultima versione del generatore di combinazioni di carico, il nome del caso di carico utilizzato per molte cose:

• Agire come un ID univoco.
• Distinguere tra carico caso eccezionale e caso di carico, e richiedono sempre un valore in ciascuno (portando a quelli bizzarri come Morto: morto).
• Resta leggibile dall'uomo, pur rimanendo abbastanza piccolo per i menu a discesa contraendo le parole (Vivere: Q-dist-pavimento-tetto).

Nell'aggiornamento più recente, we have divided load case names into simboli, che sarà piccolo per essere utilizzato per la codifica e quando lo spazio è limitato (when naming the load combinations for example: 1.25D1 + 1.5Il + 1.5Ld + 0.5Sl + 0.5T), e labels, which will aim to be very descriptive. Tutti e due simboli e labels will have to be unique within a given standard. We will also allow casi di carico to be named the same as the load caso eccezionale, usually for the default load case (most commonly used). The two examples used above would be split like this:

{“D”: “Dead”}
{“Ldr”: “Live - Concentrated, Roofs, Floor”}

La symbol must be composed minimally of one uppercase letter, which defines the super case. La caso eccezionale is a new concept, used to group similar load cases that usually act together. La caso eccezionale label is given at the start of the load case label (before the dash). In the example above (Eurocodice) the load case Ldr would be part of the L super case (named Live in the label), alongside other load cases like Ldd and Ldo. Dietro le quinte, il caso eccezionale is mainly used to enforce the filtering rules, that is to determine which schema rows need to be kept and which need to be removed.

The first part of the label (before the dash) is the name of the caso eccezionale. The second part is a description, using commas to separate categories from sub-categories. The second part is optional, but only one load case can take the default caso eccezionale spot.

Standard Schemas rows

Each standard has a schema which completely defines all of the possible load combinations for this standard. La Schema.json file is quite straightforward, but it can become quite long, especially in standards (like Eurocode) that require a multitude of permutations. To take a simple example, take the following example requirement.

1.2*D + 1.5*L + (0.5*S or 0.5*W or 0.5*T)

To convert this into our schema, we need to break it down into each possible permutation:

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

Once every load combination is listed out in this manner, you can build the schema by following these steps:

1. Use each load case key and coefficient to create a schema row object.
2. Name each row with a unique identifier (since this is going to be an object). The convention is to use dashes to separate different elements of the name.
3. One level up, group the rows into criteria (forza, manutenibilità, accidental, ecc.)

The end result should look something like this:

"righe": {
  "forza":{
    "A-1-u": {"D": 1.40},
    "A-2a-u":{"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},
    "A-3a-u":{"D": 1.25, "S": 1.50}
  }
}

Load Combination generation algorithm

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

• La schema 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 casi di carico di pattern. Per esempio, 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 modelli di caso di carico will give the following object, which will be passed to the main load combination generation function.

input_by_case = 
  {
    "D": {"unire": [2, 2], "individuale": []},
    "W": {"unire": [], "individuale": [4]},
    "S": {"unire": [], "individuale": [1]}
  }

• The last two arguments are filtering objects, che consentono il filtraggio in base a criteri o tramite chiave schema.
• Una volta che ha tutti gli argomenti richiesti, viene richiamata la funzione di generazione della combinazione di carico principale. Questa funzione passa attraverso più cicli nidificati per generare ogni combinazione richiesta, che sono spiegati nei seguenti punti elenco, ed illustrato nella figura successiva.
  • Al massimo livello, scorre attraverso le righe dello schema. Ogni riga viene controllata per vedere se deve essere mantenuta o saltata in questo passaggio, using the filtering objects and specific logic that is described in the section below.
  • Nested into the first loop is a second one, which loops through each requested caso di carico in the schema row. If the requested caso di carico also exists the schema row (requests are summarized in the input_by_case object), then we proceed to the next level.
  • Nested into the second loop is a third one, which loops through each possible pattern to see if there are load groups to generate within them, and runs the function to name and generate them when they do.
  • Una volta che tutti i casi di carico nella riga dello schema sono stati generati e denominati, sono ricombinati (insieme ai loro coefficienti) in una o più combinazioni di carico.

• Questo processo viene ripetuto per ogni riga dello schema, spingendo tutte le combinazioni di carico generate nell'oggetto della combinazione di carico finale.

It is worth nothing that all of the logic related to patterns is happening while inside a single schema row. Sapere questo è importante per comprendere il comportamento dei modelli. Il modello di fusione, per esempio, does not allow merging anything other than the load case it is assigned to. Ciò significa che non puoi:

• Unisci insieme diversi casi di carico, come provare a unire i gruppi di carico D1 e L1.
• Unisci casi di carico identici su righe diverse della tabella di input. Per esempio, nell'esempio riportato al punto #2 sopra, ci viene chiesto di generare 2 carichi morti utilizzando il modello di unione su due righe separate. Le combinazioni del risultato finale assomiglierebbero quindi a qualcosa di simile:

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

Filtraggio automatico delle combinazioni di carico non necessarie

While the above algorithm is functional without any filtering, it can lead to redundant load combinations, which leads to extra computing time and redundant results. Take the following load combinations:

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

If we have a single dead load case, these four load combinations will result in identical load combinations:

1.2*D
1.2*D
1.2*D
1.2*D

To avoid this situation, four rules are used which each contain some slight exceptions. Primo, let’s have a look at the rules. Lo stato predefinito prevede che la combinazione venga mantenuta e le regole vengono utilizzate per determinare quale escludere.

Filtraggio per criteri

This case is pretty self-explanatory. Se la criteri non è richiesto, tutte le righe dello schema ad esso associate criteri vengono scartati.

Filtraggio in base ai caratteri nella chiave dello schema

Le chiavi dello schema sono generalmente puntatori separati da virgole al riferimento originale. Per esempio, nell'esempio NBCC riportato di seguito, la chiave ha tre componenti:

• A: Il primo termine è solitamente il riferimento principale, fare riferimento alla tabella in cui viene presa questa parte dei carichi.
• 2b: Il secondo termine è solitamente un identificatore univoco per la combinazione di carico all'interno della tabella.
• u: Il terzo termine è solitamente riservato per indicare quando un gran numero di combinazioni di carico vengono permutate con una leggera modifica. Per esempio, può indicare se i carichi permanenti nella combinazione di carico sono favorevoli ( f ) o sfavorevole ( u ).

{
  "forza":{
    "A-2b-u":{"D": 1.25, "L": 1.50, "Ls": 1.50, "S": 1.00},
  }
}

È possibile filtrare la chiave dello schema per uno qualsiasi di questi termini. Per esempio, if we want to filter by the third term, possiamo aggiungere il seguente filtro, che creerà un menu a discesa di filtro per questo termine:

"nome_filtri": {
  "Forza": {
    "Carico morto": {
      "posizione": 2,
      "descrizione comando": "",
      "elementi": {
        "Favorable": "f",
        "Unfavorable": "u"
      },
      "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. In questo passaggio, viene risolto il problema della ridondanza dell'esempio precedente. Per fare questo, dobbiamo guardare due oggetti contemporaneamente, riga dello schema e l'oggetto input_by_case ordinato (vedere la descrizione sopra), che descrive quali casi di carico sono stati richiesti. Se la riga dello schema contiene un super caso che l'oggetto input_by_case non contiene, la combinazione di carico viene rimossa. Prendere, per esempio, la seguente riga dello schema:

"A-2a-u":{"D": 1.25, "L": 1.50, "S": 1.50}

e il seguente oggetto input_by_case:

input_by_case = 
{
  "D": {"unire": [], "individuale": [1]},
  "L": {"unire": [], "individuale": [4]}
}

In questo esempio, the schema row contains a caso eccezionale 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, quindi viene rimosso.

"A-1a-u":{"D": 1.25, "L": 1.50}

Eccezioni

Mentre questo comportamento è solitamente desiderabile, ci sono casi in cui NON eliminare una riga quando il caso di carico è assente porta a uno schema molto più semplice. Per esempio, se abbiamo carichi di terra orizzontali che dovrebbero essere aggiunti a ogni combinazione di schema, ma non sono sempre presenti, 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. In alternativa, 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. In questo passaggio, 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. Prendere, per esempio, la seguente riga dello schema:

"A-2a-u":{"D": 1.25, "Sl": 1.50}

and the following input_by_case:

input_by_case = 
{
  "D": {"unire": [], "individuale": [1]},
  "Sh": {"unire": [], "individuale": [1]}
}

In questo esempio, both the schema row and the request have matching super cases. Tuttavia, the request requires a combination with Sh, which the schema row does not provide. così, the schema row is not kept.

Eccezioni

Ancora una volta, 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. Per esempio, in 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 caso eccezionale before the code runs in the meta data. Dietro le quinte, the symbol following the “->” characters will be attributed to the load case, which will simulate the load cases acting in that caso eccezionale. The result looks something like this in the schema’s meta property:

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

In the case above, il caso eccezionale “W” will be swapped to “X” before the code runs. This feature can also be used to send group load cases that have unique caso eccezionale symbols together.