Code combinations Generator – Eurocodes context

[Anonymous]

Hello,

I add this topic, at the edge between Eurocodes and the software itself, as it seems (to me) that the way RSA generates automatic combinations is partial/non-conservative. I am using the software mainly in the French context (Eurocode with French national appendices).

To be clearer, this situation appears when different live loads subnatures exist in one project, with different sets of psi0,1,2 factors, for this specific variable action. (If a single LL exists in one project, or LL with same psi, no problem then).

Evolution leads to multi-activities buildings, so we can find in a same project different categories (sub-natures) of Live Loads (by reference to XX EN 1990 : LLA,LLB, etc). Eg: basement floors with cat F or G (car park), first floors cat D and E1, or conference centre cat C, then offices cat B, ...

Variable actions (clear) are classified by nature: Live Loads, or Wind, or Snow, or Thermal effects ...

For better comprehension, let ‘s imagine the case of a building with variable actions LLF, LL D, LLB, + W (negliging S, E, T...). Psi factors (psi 0,1,2) are different, by reference to eurocode:

• LLB (0.7 / 0.5 / 0.3)
• LLD (0.7 / 0.7 / 0.6)
• LLF (0.7 / 0.7 / 0.6)

To me in a multi-activities building, (unclear but logical) LL, even if several sub natures, should be considered as a whole and unique variable action, existing or not (in the project situations, ie with correct psi factors). This means that the LL group can appear in combinations as leading action, or as accompanying action, in addition to other variable actions. All these actions are linked and that it is unsecure to envisage the LL D (leading), without (fully) the others ( and then LL F, LL B degraded with psi factors).

That’s my point of view: RSA doesn’t consider this in automatic combination rules and / or don’t set the right factors, due to the way of the code combination wizard/pondedit file is designed. For SLS CAR, SLS FRE, ULS (ie for combinations where variable actions are chosen one as leading action, the others as accompagnying actions).

I tried the 2 possibilities with the automatic combinations wizard:

• A/ each LL considered as a single group, and the relationship (“AND”)
• B/ all LL in one group (relationship “AND”)

(Note: the number of combinations generated are not the same in case A and B, A>>B so data...).

Case A: This leads to correct (combinations with) accompanying action, as each LL is taken separately when accompanying action with correct psi factor (eg wind leading...). But when it is time to look to LL as leading action, then problem as the software takes LLA leading , the others accompanying, (and then, permutations). Never the case of all LL present (eg: for ULS, never the case of all LL x1.5 ) .

Cas B: This leads to correct combinations when LL is leading action (and without psi factor), but false when it’s accompanying action (as, it seems, written in .rgl file, the software is unable to apply different psi 0 1 2 for each LL taken separately in one task, so it takes a psi factor false – the lowest ?- for all LL). (eg: for SLS CAR, never the case of Sigma (LLi xpsi0,i ), but sigma (LLI) x pso,1 ?).

Adding other consideration (seismic design, water uplift matter), this can induce to false results (or bad accuracy). Difficult to identify, due to the high number of combinations, but take a look.

So it’s a little bit disturbing, to me, not to cover the range of normal combinations. And not to have the ability to set parameters – by exception, copy/paste, with time consuming methods -). When an automatic combinations wizard is supposed to help designers (21th century).

If anybody has a feedback or point of view, on the subject: LL = 1 group of action...

To conclude on the code combinations wizard, beyond this topic, an improvement is asked, to deal with practical problems such as:

• Snow and cat H can’t exists together (solved in 2020 ? – look to combinations if other live loads with H),
• Relationships between different variable actions, which can’t occur together (eg : snow and thermal effect – summer case ! -)
• Other combinations group (factors different), for ULS/UPL (or EQU),
• Implementation of other cases (shrinkage, prestress, water...), that don’t have the same partial factors (ok possible to add in the .rgl file, but this is normally software development matter)

To solve all these, the approach of revision and development of the combinations software could be a table (matrix) allowing to set rules between actions (different natures), even if not from the same nature. With also economy of the combinations numbers... (data, time, ...). Allowing combinations of simple cases, leading to a new single case of load could be usefull too. Possible only for newmark combination at this time, so why not allowing it for static cases ?

Thanks