Upper limit on interaction curves?

[Agent6-6-6]

@robbievanleeuwen, many codes ACI318 and NZS3101 have a hard upper cutoff for the axial load a section can take, which seems a little different to the squash load definition in AS3600 which is the axial capacity at zero moment. Basically the interaction curve is cutoff horizontally at this level of load as per below image. This is probably something that would need to be introduced into the interaction curve code generate as an upper limit cutoff and then return the curve at the same axial load to zero moment?

Addtionally it may be useful to also report the control points and have an option to plot these points on the interaction curves?
For example points as follows are useful for interpretation of the results:-

A = ZERO M* AT MAX COMP
B = MAX M* AT MAX COMP
C = ZERO STRAIN POINT
D = 50% STRAIN POINT
E = BALANCED STRAIN POINT
F = ZERO AXIAL LOAD POINT
G = MAX TENSION POINT

I'm intending on taking a stab at a NZS3101 design code implementation.

[robbievanleeuwen]

Hi @Agent6-6-6,

Thanks for the heads up on this, I've only ever practised in Australia so may appear to have a narrow-minded view/implementation of a few things!

This is probably something that would need to be introduced into the interaction curve code generate as an upper limit cutoff and then return the curve at the same axial load to zero moment?

Yes this could be added to the moment_interaction_diagram() method, something like max_comp: float = None, then if provided cuts off the top of the diagram.

Addtionally it may be useful to also report the control points and have an option to plot these points on the interaction curves?

Also yes, do you think it would be a good idea to add these points on top of the n_points provided to moment_interaction_diagram()? E.g. calculate 24 points between decompression and pure bending plus points C, D and E. I currently have to calculate the balanced point for AS 3600 so I could take this out of design_codes and put it into the main API along with the other two points.

The way I've calculated the balanced point for AS 3600, get_n_ub(), is to find the bar furthest away from the extreme compression fibre, calculate its yield strain and then work out the neutral axis depth based on this. Does this logic sound reasonable to you?

Let me know your thoughts, if so I can look at implementing the above two items.

[robbievanleeuwen]

Yeah I think the max_comp method will work fine and is probably very easy to implement

Thinking a bit more about this, you will also need to handle this in ultimate_bending_capacity() separately. A user may just want to calculate the bending capacity at a high axial load and not implementing the cut off here would give an unconservative result.

a cp_res variable? should there be a means of simply feeding some additional axial load 'control points' so they are injected into the range of axial loads being solved for when generating the interaction curve?

I like the idea of this. I will add this feature.

I kind of wonder if Reinf be a more appropriate name for this

What do we think about a Bar class? Future class that would be prestressed would a Strand class? Thinking about this if we change Steel to Bar, there's no need for anything to change if you use a stainless steel or FRP bar, you just provide a different density and stress-strain profile and everything still works.

But I appreciate how you've got to build it up independently now if you want to do something 'non-default' to the AS3600 design method.

I think this is how I want it to work. Make it simple and default for the typical use case, and if a user wants to throw in a different stress-strain profile, they can do by calling another function like set_stress_strain_profile(). I'd rather do this than complicate the setting up of the design code object. This also keeps a nice generic structure that can be similar to other design code implementations.

So could I do a design using say an ACI analysis method using ACI318 class when someone implemented it, but use AS3600 concrete stress block factors (not a constant but variable values based on the values in AS3600 class)?

I'm not sure I entirely understand this one? Are you asking if you can generate an AS3600 stress block automatically based off an ACI318 material? At the moment not really, easiest would be to calculate the parameters yourself. Although you could maybe do something like this (pseudo-code) assuming you use consistent units:

fc = 40

aci = ACI318()
aci_conc = aci.create_concrete_material(compressive_strength=fc)

as = AS3600()
as_conc = as.create_concrete_material(compressive_strength=fc)

# set aci profile to as3600 profile
aci_conc.ultimate_stress_strain_profile = as.ultimate_stress_strain_profile

Is this what you're getting at or have I completely missed the point?

you should really be injecting an additional axial load point to capture exact point of change on the interaction curve.

This should be doable, I'll look into it.

I think I covered everything there, let me know if I missed anything!

[connorferster]

What do we think about a Bar class? Future class that would be prestressed would a Strand class? Thinking about this if we change Steel to Bar, there's no need for anything to change if you use a stainless steel or FRP bar, you just provide a different density and stress-strain profile and everything still works.

One of the special things about concreteproperties is that it can handle sections reinforced with, say, a large I-section. This steel section would still be defined with the Steel material. I think that, during the process of defining materials, it does not matter what the geometry of the material is, be it a reinforcing bar or other kind of section, but only the material is defining the behaviours of the material. Would a Bar be a special kind of geometry? Is Strand a special kind of geometry? My question: what are the essential differences between these things that needs to be captured?

I think whether a reinforcing element is a bar or any other section is irrelevant in relation to the material defining it. By keeping these separation of concerns (geometry vs. material), it is more consistent with sectionproperties where we define a geometry and assign a material to it. I think that some kind Material class would be appropriate to define the interface required for any new materials beyond Steel however, the Material class is used by sectionproperties and concreteproperties defines/requires some different attributes than sectionproperties. Perhaps there could be advantages in harmonizing the two classes?

Thoughts?

[robbievanleeuwen]

@connorferster @Agent6-6-6 I'm going to move the discussion on the material module naming & functionality to #17 to try to keep this thread focussed on interaction curves.

[Agent6-6-6]

Thinking a bit more about this, you will also need to handle this in ultimate_bending_capacity() separately. A user may just want to calculate the bending capacity at a high axial load and not implementing the cut off here would give an unconservative result.

Yeah agree. In NZ at least, checking for a higher load than the horizontal portion of the curve would be a failure. That result would be of no interest to me as a designer and should ideally generate a valueerror and some warning that the axial load you're checking for is greater than the maximum allowable (and ideally include the maximum calculated value so user can revise section size or reinforcement or lower axial load until it works).

[robbievanleeuwen]

I've created a few issues based off this discussion, please have a look at these and make sure I've covered everything. I'll be looking to implement these changes shortly!

1. Interaction Diagram Features #20
2. AS 3600 extra design point at transition in phi #21

Material module issue is referred to in #17.