example for Generic Concrete Ultimate Profile in materials.rst

[Agent6-6-6]

Hi @robbievanleeuwen

In going through implementing #80, I've noted the following doesn't seem consistent in the numbers utilised.

The example in material.rst implies a variable youngs modulus E for the strain calculations, and stresses provided max out at 40MPa but compressive strength is defined as only 32 MPa so inputs don't seem consistent with one another. Maybe I'm missing something here though, but it seems like this needs to be modified to a constant E consistent with the specified compressive strength and the maximum compressive strength and max stress aligned so they are the same value?

from concreteproperties.stress_strain_profile import ConcreteUltimateProfile

ConcreteUltimateProfile(
  strains=[-20 / 30e3, 0, 20 / 30e3, 30 / 25e3, 40 / 20e3, 0.003],
  stresses=[0, 0, 20, 30, 40, 40],
  compressive_strength=32,
).plot_stress_strain()

I think this is a case where ultimate_strain (don't think this is even initiated for this generic profile or parent class which would presumably cause some issues if it was used for a design_code check) and possibly compressive_strength should possibly just be populated from the user input at the end of the __post_init__ method and not initiate compressive_strength as an input:-

i.e. self.ultimate_strain = max(self.strains), and similar for the concrete_strength variable.

[robbievanleeuwen]

Hi @Agent6-6-6, this example is inconsistent, the compressive strength should be modified compressive_strength=40. I'll update this once this discussion is closed out.

As far as I'm aware, no other modules access the ultimate_strain or compressive_strength variables. Instead they use the get_ultimate_compressive_strain() and get_compressive_strength() methods.

I believe the get_ultimate_compressive_strain() method is consistent with the inputs.

The get_compressive_strength() allows for a different 'compressive strength' to that in a profile which may be useful in some cases (the only time I use it in AS3600 is to compute the squash load). This is a 'generic' profile so the user can really do what they want with it. The other abstracted profiles generate the stress-strain profile from the compressive strength so do not allow for inconsistency.

Does this answer the question?

[Agent6-6-6]

Hi @robbievanleeuwen, hopefully, the following makes sense!

In the NZS3101 class, I was directly accessing these ultimate_strain and compressive_strength variables when creating the different sections for the various types of analysis. The reason for doing this was the outcome of issue #47.

I guess what is required to populate these variables so they can be accessed is to simply run these get_xxxx methods at the end of the creation of the profiles if the user did not provide them (i..e don't initiate them but populate with the correct value anyway so it can be accessed directly if required):-

• do this before adding any horizontal portions of the curve required for interpolation (which would mean the max(strain) would not return the true specified or intended ultimate_strain value,
• and before applying any alpha factor reductions that might apply to get from the max strength being the characteristic value specified and the final design value for the compressive_strength. (similar to how ultimate_strain was initiated in the modified mander profile as an example).

As it stands for some of the profiles if I'm interpreting it correctly the ultimate_strain is equal to None as it is never initiated if not specifically required to generate the profile. But for completeness, I'm saying it probably should be initiated with the correct value so all profiles have valid values irrespectively if that makes sense. Some analyses may require it (as per NZS3101 class implementation as noted above, and other future codes may require it also). Sure you can get the value using the get_ultimate_compressive_strain but that value would include any extra bits added on for interpolation purposes. For example, in EC2 service profile you have a 1.01 x factor which could throw a max permissible strain returned out by 1% if used or others are following the same logic (note that I've yet to update this profile with the calculations for the ultimate_strain).

Also for the EC2 profiles that are being worked on in #80, they will have to work in a similar way populating the values at the end because there is no input ultimate_strain as that is calculated in accordance with the equations in table 3.1 of EC2 for example.

The idea is if I have not already done it would be to populate this value at the end of the generation of the profile so it can be returned and isn't equal to None as it has never been populated otherwise if I'm following how some profiles are working?

I have always been interpreting the compressive_strength for ultimate analyses as being the specified characteristic value, and for a design value to be returned which has been factored down by whatever equivalent alpha factor might apply based on the analysis code or analysis being undertaken.