Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EC2 parabolic stress-strain profile #80

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

Agent6-6-6
Copy link
Contributor

Hi @robbievanleeuwen

Pull request addressing points noted in #79.

Note I decided at this stage against being able to specify the ultimate strain and transition strain as optional parameters pending your thoughts on the following. I think instead it is maybe better to add a further generic parabolic class (like you have for the Bilinear ssp) utilising the EC2 derivation for want of anything better, where you can specify these directly (basically almost like the older EurocodeParabolicUltimate class but renamed as a generic one?

So you'd have the specific EC2 one with all the calculated factors, and then a generic one that takes a concrete strength that the user has already reduced to a design value as opposed to a characteristic value and a user-specified transition strain, ultimate strain and n_exp value.
(with this in mind potentially a warning is required in the generic ones to apply the equivalent of the alpha factor to reduce concrete_strength to a design value, this would be true of all the generic cases. Maybe the generic profiles should have another alpha factor reduction variable that is equal to 1.0 by default that the user can feed in a specific reduction factor if required by their use case).

Note for the AS3600 example changes, given I'm not too familiar with AS3600. Should the final design strength of the concrete be the alpha factor in AS3600 class multiplied by the concrete strength multiplied by the 0.9 factor?

So effectively you're comparing the stress-strain profile all with the same maximum design concrete strength? As it previously was arranged, this did not appear to be the case, bilinear and parabolic utilised 0.9*40 MPa, and the rectangular stress block utilised alpha*0.9*40 which are not really consistent for comparing apples with apples which the plot is intended to do?

I'll do a similar approach for the EC2 bilinear class as for the parabolic class. I'll keep it draft until that is incorporated.

@robbievanleeuwen
Copy link
Owner

robbievanleeuwen commented Dec 31, 2022

I like the idea of having the two stress strain profiles as you describe.

I believe the alpha 0.9 factor is 'built-in' to the alpha factor in the rectangular stress block parameters in AS3600 but I'll double check this and let you know.

EDIT: Fixed above sentence.

@Agent6-6-6
Copy link
Contributor Author

Agent6-6-6 commented Dec 31, 2022

  • add bilinear EC2
  • add generic parabolic curve (essentially the same as the original EurocodeParabolicUltimate class), revise docstring as required.
  • add tests to cover revised/new code
  • In AS3600 notebook example @robbievanleeuwen to confirm if alpha factor should be applied to bilinear and parabolic example concrete strength (on top of the 0.9 factor already included on specified concrete strength). Believe it should be included for consistency.
  • possibly refactor alpha and gamma factors into separate methods in AS3600 to achieve above?
  • Confirm if an additional alpha factor should be included in all generic profiles to ensure the user thinks about reducing characteristic concrete strengths to design concrete strengths (otherwise results potentially unconservative)
  • Update readme.md file to reflect changes

@robbievanleeuwen
Copy link
Owner

As far as I understand the 0.9 factor is built into the alpha factor in AS3600 (sorry I miswrote my previous comment).

Here are the relevant code extracts (Note 1 is relevant):

Screenshot 2022-12-31 at 8 16 46 pm

Screenshot 2022-12-31 at 8 16 23 pm

As a result, I think the comparison plot in the AS3600 example should be consistent, let me know your thoughts.

@Agent6-6-6
Copy link
Contributor Author

Agent6-6-6 commented Dec 31, 2022

As a result, I think the comparison plot in the AS3600 example should be consistent, let me know your thoughts.

Yeah agree, appears to be correct in that case. The commentary does seem to suggest the 0.9 factor is only to be applied when the strength is determined based on testing as per point (b). Which in turn implies it is not a generic factor to be utilised by other forms of stress-strain curves?
image

I think a user specified factor equivalent to an alpha factor should be included on the generic profiles so not reliant on the user making the modification beforehand (can be equal to 1.0 by default) if you agree?

It would make all the ultimate ssp's consistent in that they return a factored design strength. The 'pretty' plots can all then show the nominal curve and the design curve as follows for example to show all the parameters in a logical manner (for the generic ones the design curve would simply be $\alpha f'_c$:-

ec2_parabolic_ultimate_plot hires
ec2_bilinear_ultimate_plot hires

What doesn't quite sit right with me though in the example is that just adopting the 0.9 factor results in the interaction curve being quite a bit higher than the rectangular stress block AS3600 one. The $\alpha_2$ factor for rectangular stress block can be significantly lower, so just taking 0.9 reduction seems too high when $\alpha_2$ could be as low as 0.67 based on your screenshot. Which lends some support to the point above regarding that it is intended when test results from test cylinders are used directly for design.

In the past, since most codes do not explicitly give you a reduction factor to apply to other ssp's such as a parabolic curve, I've just made the assumption or engineering judgement that the same factor as equivalent to $\alpha_2$ should be applied when working to NZS3101 code. We don't have anything equivalent to the 0.9 factor.

@robbievanleeuwen
Copy link
Owner

Sorry coming back to this after a bit of a holiday and might have lost the train of thought slightly.

I think a user specified factor equivalent to an alpha factor should be included on the generic profiles so not reliant on the user making the modification beforehand (can be equal to 1.0 by default) if you agree?

Could you very quickly show me what this would look like?

What doesn't quite sit right with me though in the example is that just adopting the 0.9 factor results in the interaction curve being quite a bit higher than the rectangular stress block AS3600 one.

Agreed there is something not quite right here. I'll do some digging to try to make the comparison more consistent, but you're right - the comparison isn't really fair or valid given the differences in the ultimate profiles.

@Agent6-6-6
Copy link
Contributor Author

Agent6-6-6 commented Jan 9, 2023

Hi @robbievanleeuwen
For the first point, all I meant was for example taking the current generic bilinear profile and modify as follows to accept a characteristic compressive_strength as input, and return reduced design profile based on a generic alpha factor reduction being applied to the compressive_strength to return a profile with an appropriate reduction applied for actual design:-

@dataclass
class BilinearStressStrain(ConcreteUltimateProfile):
    """Class for a bilinear stress-strain relationship.
    :param compressive_strength: Concrete compressive strength
    :param compressive_strain: Strain at which the concrete stress equals the
        compressive strength
    :param ultimate_strain: Concrete strain at failure
    :param alpha: Factor that modifies the concrete compressive strength
    """

    strains: List[float] = field(init=False)
    stresses: List[float] = field(init=False)
    compressive_strength: float
    compressive_strain: float
    ultimate_strain: float
    alpha:float = field(default=1.0)

    def __post_init__(
        self,
    ):
        self.strains = [
            -self.compressive_strain,
            0,
            self.compressive_strain,
            self.ultimate_strain,
        ]
        self.stresses = [
            0,
            0,
            self.compressive_strength*alpha,
            self.compressive_strength*alpha,
        ]

Kind of feel like default=1.0 value should not be provided to make sure the user actually thinks about the value provided even if it is ultimately 1.0 or 0.9 or whatever might apply based on their analysis code.

This alpha factor reduction is applied to the RectangularStressBlock class already for example, but none of the others. Rather than expecting the user to reduce the value prior to using one of the other classes, make any appropriate reduction part of defining the profile so all profiles are used in a similar manner. Characteristic strength in, design strength out.... if that makes sense.

@Agent6-6-6
Copy link
Contributor Author

Agreed there is something not quite right here. I'll do some digging to try to make the comparison more consistent, but you're right - the comparison isn't really fair or valid given the differences in the ultimate profiles.

Yeah EC2 does the analysis with reduced steel and concrete strengths (equivalent to applying phi to the material properties before doing the analysis) vs how AS and NZS codes work by applying the phi factor right at the end to the calculated strength.

So if using with a code that uses phi applied at end of an analysis with a EC2 parabolic profile I feel it is appropriate to reduce the concrete strength in the profile by some factor that is likely equivalent to the alpha factor.

So if using a rectangular stress block and a parabolic one for example, the maximum design compressive strength is similar or the same to compare apple with apples if that makes sense. Only modifying the shape to be more realistic, but still having the same maximum strength effectively. Refer to the description I added in the docs for the updated parabolic EC2 curve, I left it fairly generic given the lack of advice around this (really up to the user to apply some engineering judgement here).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants