In de meest recente update van de belastingcombinatiegenerator, we hebben de interne werking van de module vereenvoudigd en de volgende functionaliteit toegevoegd:

• Load combination generation is defined by a single .json file (Schema) voor elke standaard.
• Belastingsgroepen en -combinaties kunnen worden gemaakt zonder dat u eerst belastingen hoeft toe te wijzen in de S3D-modelleringsruimte.
• Patronen, die zijn gebaseerd op de oude “Vouw windbelastingen uit” selectievakje, werk nu met alle belastingsgevallen.

Nomenclatuur

In de laatste versie van de belastingcombinatiegenerator, de naam van het belastinggeval die voor veel dingen werd gebruikt:

• Fungeren als een unieke ID.
• Maak onderscheid tussen belasting super geval en de obstructie onder het dakoppervlak, en vereisen altijd één waarde in elk (leidend tot bizarre zoals Dood: dood).
• Blijf leesbaar voor mensen, terwijl het toch klein genoeg blijft voor vervolgkeuzemenu's door woorden samen te trekken (Leven: Q-dist-dakvloer).

In de meest recente update, we have divided load case names into symbolen, die klein zal zijn om te worden gebruikt om te coderen en wanneer de ruimte beperkt is (bijvoorbeeld bij het benoemen van de belastingscombinaties: 1.25D1 + 1.5De + 1.5Ld + 0.5Sl + 0.5T), en etiketten, which will aim to be very descriptive. Beide symbolen en etiketten zal uniek moeten zijn binnen een bepaalde standaard. Wij zullen het ook toestaan belastingsgevallen dezelfde naam krijgen als de belasting super geval, meestal voor het standaardbelastingsgeval (het meest gebruikt). The two examples used above would be split like this:

{"D": "Dood"}
{“Ldr”: "Live - Geconcentreerd, Daken, Vloer"}

De symbool moet minimaal uit één hoofdletter bestaan, die het supergeval definieert. De super geval is een nieuw concept, gebruikt om vergelijkbare belastinggevallen te groeperen die gewoonlijk samen optreden. De super geval label wordt gegeven aan het begin van het belastinggevallabel (vóór het streepje). In het bovenstaande voorbeeld (Eurocode) het belastingsgeval Ldr zou deel uitmaken van het L-supergeval (genaamd Live in het label), naast andere belastinggevallen zoals Ldd en Ldo. Achter de schermen, de super geval wordt voornamelijk gebruikt om de filterregels af te dwingen, dat wil zeggen om te bepalen welke schemarijen moeten worden behouden en welke moeten worden verwijderd.

Het eerste deel van het etiket (vóór het streepje) is de naam van de super geval. Het tweede deel is een beschrijving, gebruik komma's om categorieën van subcategorieën te scheiden. Het tweede deel is optioneel, maar slechts één belastinggeval kan de standaardwaarde aannemen super geval plek.

Standaardschemarijen

Elke standaard heeft een schema die alle mogelijke belastingscombinaties voor deze standaard volledig definieert. De Schema.json bestand is vrij eenvoudig, maar het kan behoorlijk lang worden, vooral op het gebied van standaarden (zoals Eurocode) waarvoor een groot aantal permutaties nodig is. Om een ​​eenvoudig voorbeeld te nemen, neem de volgende voorbeeldvereiste.

1.2*D + 1.5*L + (0.5*S of 0,5*W of 0,5*T)

Om dit om te zetten in onze schema, we moeten het opsplitsen in elke mogelijke permutatie:

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

Zodra elke belastingscombinatie op deze manier wordt vermeld, u kunt het schema bouwen door deze stappen te volgen:

1. Gebruik elke belastinggevalsleutel en coëfficiënt om een ​​schemarijobject te maken.
2. Geef elke rij een unieke ID (aangezien dit een object gaat worden). De conventie is om streepjes te gebruiken om verschillende elementen van de naam van elkaar te scheiden.
3. Eén niveau hoger, groepeer de rijen in criteria (kracht, bruikbaarheid, toevallig, enz.)

Het eindresultaat zou er ongeveer zo uit moeten zien:

"rijen": {
  "kracht":{
    "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}
  }
}

Algoritme voor het genereren van laadcombinaties

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

• De 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 belastingsgevallen door pattern. Bijvoorbeeld, 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 patronen door de obstructie onder het dakoppervlak will give the following object, which will be passed to the main load combination generation function.

input_by_case = 
  {
    "D": {"samenvoegen": [2, 2], "individueel": []},
    "W": {"samenvoegen": [], "individueel": [4]},
    "S": {"samenvoegen": [], "individueel": [1]}
  }

• The last two arguments are filtering objects, waarmee gefilterd kan worden criteria of via schemasleutel.
• Zodra het alle vereiste argumenten heeft, de functie voor het genereren van hoofdbelastingcombinaties wordt aangeroepen. Deze functie doorloopt meerdere geneste lussen om elke vereiste combinatie te genereren, die in de volgende punten worden toegelicht, en geïllustreerd in de volgende figuur.
  • Op het hoogste niveau, het loopt door de schemarijen. Elke rij wordt bij deze stap gecontroleerd om te zien of deze moet worden behouden of overgeslagen, met behulp van de filterobjecten en specifieke logica die in de onderstaande sectie worden beschreven.
  • Genest in de eerste lus is een tweede, die door elke gevraagde lus loopt de obstructie onder het dakoppervlak in de schemarij. Indien gevraagd de obstructie onder het dakoppervlak bestaat ook de schemarij (verzoeken worden samengevat in het input_by_case object), dan gaan we naar het volgende niveau.
  • Genest in de tweede lus is een derde, die door elk mogelijk loopt pattern om te zien of er belastingsgroepen zijn die daarin kunnen worden gegenereerd, en voert de functie uit om ze een naam te geven en te genereren wanneer ze dat doen.
  • Zodra alle belastinggevallen in de schemarij zijn gegenereerd en benoemd, ze worden opnieuw gecombineerd (naast hun coëfficiënten) in één of meerdere belastingscombinaties.

• Dit proces wordt herhaald voor elke rij van het schema, alle gegenereerde belastingscombinaties naar het uiteindelijke belastingscombinatieobject duwen.

It is worth nothing that all of the logic related to patterns is happening while inside a single schema row. Dit weten is belangrijk om het gedrag van patronen te begrijpen. Het samenvoegpatroon, bijvoorbeeld, does not allow merging anything other than the load case it is assigned to. Dit betekent dat u dat niet kunt:

• Voeg verschillende belastinggevallen samen, zoals het proberen om D1- en L1-belastingsgroepen samen te voegen.
• Voeg identieke belastinggevallen op verschillende rijen van de invoertabel samen. Bijvoorbeeld, in het voorbeeld gegeven in punt #2 bovenstaande, ons wordt gevraagd te genereren 2 dode lasten met behulp van het samenvoegpatroon op twee afzonderlijke rijen. De eindresultaatcombinaties zouden er dan ongeveer zo uit kunnen zien:

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

Automatisch filteren van onnodige belastingscombinaties

Terwijl het bovenstaande algoritme functioneel is zonder enige filtering, het kan leiden tot redundante belastingscombinaties, wat leidt tot extra rekentijd en redundante resultaten. Neem de volgende belastingscombinaties:

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

Als we één enkel geval van dode belasting hebben, deze vier belastingscombinaties resulteren in identieke belastingscombinaties:

1.2*D
1,2*D
1,2*D
1,2*D

Om deze situatie te voorkomen, Er worden vier regels gebruikt, die elk enkele kleine uitzonderingen bevatten. Eerste, laten we eens kijken naar de regels. De standaardstatus is dat de combinatie behouden blijft en de regels worden gebruikt om te bepalen welke moeten worden uitgesloten.

Filteren op criteria

This case is pretty self-explanatory. Als het criteria wordt niet gevraagd, alle schemarijen die daaraan zijn gekoppeld criteria worden weggegooid.

Filteren op tekens in de schemasleutel

Schemasleutels zijn doorgaans door komma's gescheiden verwijzingen naar de oorspronkelijke verwijzing. Bijvoorbeeld, in het onderstaande NBCC-voorbeeld, de sleutel bestaat uit drie componenten:

• A: Meestal is de eerste term de belangrijkste referentie, raadpleeg de tabel waarin dit deel van de belastingen is opgenomen.
• 2b: The second term is usually a unique identifier for the load combination inside the table.
• u: The third term is usually reserved to indicate when a large number of load combinations are permuted with a slight modification. Bijvoorbeeld, it can indicate if the dead loads in the load combination are favorable ( f ) or unfavorable ( u ).

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

Filtering in the schema key can be done for any of these terms. Bijvoorbeeld, 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": {
  "Kracht": {
    "Dode lading": {
      "Negatieven gebruiken om de negatieve Z-richting te specificeren": 2,
      "tooltip": "",
      "items": {
        "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 deze stap, the redundancy issue from the above example is addressed. Om dit te doen, 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, bijvoorbeeld, the following schema row:

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

and the following input_by_case object:

input_by_case = 
{
  "D": {"samenvoegen": [], "individueel": [1]},
  "L": {"samenvoegen": [], "individueel": [4]}
}

In dit voorbeeld, the schema row contains a super geval 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, "L": 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. Bijvoorbeeld, 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. Alternatief, 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 deze stap, 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, bijvoorbeeld, the following schema row:

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

and the following input_by_case:

input_by_case = 
{
  "D": {"samenvoegen": [], "individueel": [1]},
  "Sh": {"samenvoegen": [], "individueel": [1]}
}

In dit voorbeeld, both the schema row and the request have matching super cases. Echter, the request requires a combination with Sh, which the schema row does not provide. Dus, the schema row is not kept.

Exceptions

Nogmaals, 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. Bijvoorbeeld, 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 super geval before the code runs in the meta data. Achter de schermen, the symbol following the “->” characters will be attributed to the load case, which will simulate the load cases acting in that super geval. The result looks something like this in the schema’s meta property:

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

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