EC2 stress/strain profile inconsistencies

[Agent6-6-6]

Hi @robbievanleeuwen,

I've literally just started working my way through creating some of the 'pretty' plots for other stress-strain profiles (like what was done for the ModifiedMander class). But I've got some questions about the current implementation of the Eurocode curves:-

Because these generic profiles are sort of code independent, and the EC2 equations have not been provided for the inputs. Was the intent these factors such as n and compressive strain would come later in an EC2 design code class? Or should they really be within the EurocodeParabolicUltimate class like for the other stress-strain profiles, as typically the input is a 28-day compressive strength for all of the ultimate profiles and then this is factored down within the stress-strain profile class?

But the EC2 one seems to rely on the user factoring the concrete strength down prior and working out all the inputs which could simply be calculated by the class, I think this is not really consistent and makes for user errors if someone does not factor down the 28-day compressive strength first. None of the doc examples factors it down first which seems to be an error in how it is intended to be implemented.

Eurocode 2 provides equations for example for the $n$ exponent, the $\varepsilon_{c2}$ (equivalent to your compressive_strain variable) so I think these should really be implemented within the class as not really required as inputs as they are derived from the equations given in EC2 (though could be Optional to allow for specific National Annexes to modify/override if required from the default EC2 eqns.

Along the same lines, the partial safety factors $\gamma_{c}$ and $\alpha_{cc}$ modification factor as inputs to modify the concrete strength from a 28-day strength $f_{ck}$ to a design value $f_{cd}$ should be included in the class. Other classes such as the RectangularStressBlock have these similar modification factors to the strength included (gamma & alpha factors for comparison), but equivalent factors are not included in the EC2 parabolic class for comparison which is inconsistent.

Happy to review and update to correct these stress-strain profiles if you're in agreement with including all the relevant factors utilising the defaults out of EC2 using optional variables to allow for a specific design code override if a given national annex happens to utilise a different value.

Also if I'm updating this to correct, any issue with renaming the n to n_exp for 'exponent' to differentiate it from axial loads which have typically adopted the n variable throughout?

[robbievanleeuwen]

Hi @Agent6-6-6 yes I see your point. I would like to keep the option of having these generic because sometimes they are used in non-typical code applications.

I think your idea of computing the relevant factors within the class (with the option of overriding with Optional arguments) is a neat solution.

Also agree n_exp is better nomenclature.

If you have time to make these changes they would be appreciated!

[Agent6-6-6]

@robbievanleeuwen, do you recall if the BilinearStressStrain class was actually intended to be the EC2 bilinear stress-strain relationship as the inputs are set up similarly to the existing EurocodeParabolicUltimate class, or was the intent that it was just a generic Bilinear curve?

... and as such, I can add the EC2 bilinear curve as a new class EurocodeBilinearUltimate rather than modify the generic one?

[robbievanleeuwen]

At the moment it's acting as a generic curve. Yep sounds like a good idea, happy to have a EurocodeBilinearUltimate class.

[Agent6-6-6]

@robbievanleeuwen, one other thing I've sort of noted in working through these stress strain profiles creating the pretty plots is that the naming isn't to consistent for the stress-strain profile classes.

There are some called 'stress block' , some with 'ultimate' and 'service' descriptions included, some without. Some ending in 'profile' , some not.... Etc.

Wonder if there should be some consistency in the naming convention for these. Like design code ref or generic, followed by shape if applicable followed by ultimate/service followed by the word 'profile'

So consider updating to for example (not all shown, but hopefully you get the idea):-
GenericServiceProfile
ModifiedManderServiceProfile
RectangularUltimateProfile
GenericUltimateProfile
EC2ParabolicUltimateProfile
GenericBilinearUltimateProfile
etc.

So it's very clear on the purpose, shape, etc with a consistent naming nomenclature? Thoughts?

[robbievanleeuwen]

@Agent6-6-6, yes this is great! I obviously didn't spend too much time on coming up with these names! Happy to have these breaking changes in a future release as we're still technically in beta.

[Agent6-6-6]

@Agent6-6-6, yes this is great! I obviously didn't spend too much time on coming up with these names! Happy to have these breaking changes in a future release as we're still technically in beta.

Sounds good. I think best done after #80 is finished as added additional profile(s) and those nicer plots to the docs. Makes sense to do this in a separate pull request.