Moment Interaction Diagram Usability Enhancements

[robbievanleeuwen]

Fixes #39.

Introduces/redefines the following parameters to moment_interaction_diagram():

• limits - defines the limits of the moment interaction diagram (note there are some cases e.g. AS3600 where I don't want to generate max compression to max tension)
• n_points - now defines the number of points between the limits
• n_spacing - Optional axial force spacing for the moment interaction diagram

Other features:

• Sorting of control_points no longer required, only requirement is that limits be in order from larger N to lower N (error message when not the case) - this is due to how kappa0 is implemented which effectively implements a neutral axis depth of infinity. EDIT: no longer required.

[robbievanleeuwen]

@Agent6-6-6 this is still a WIP. Outstanding tasks:

• Update all examples and other methods that call moment_interaction_diagram()
• Update max_comp with fix as suggested in Moment Interaction Diagram Usability Enhancements #39
• Resolve n_points spacing issue
• Fix tests

[robbievanleeuwen]

n_points Spacing Issue:

Either have a user supplied variable to break this range up evenly by a certain number of evenly spaced control points (like n_points = 48)...

This creates the following issue:

Points are focussed towards higher axial loads as setting kappa0 as a limit point equates to a neutral axis depth of 2 * D.

Wondering if you have any thoughts as to how this should behave? Haven't thought too much about it myself yet.

[robbievanleeuwen]

Axial Force Spaing:

On the other hand, this seems to be working well!

[robbievanleeuwen]

@Agent6-6-6 I've changed the default arguments to get better behaviour for default calls of moment_interaction_diagram().

The limits now go from decompression ("D", 0) to full tension ("d_n", 1e-6) with a control point added at full compression ("kappa0", 0) as well as balanced and pure bending. This causes the neutral axes to be spaced between the decompression and tension point which has a better distributed default curve.

If the user wants more points towards the full compression they can easily change their limits and/or use n_spacing (of course this will take much longer to generate but is prettier). There are no longer any requirements to put things in a particular order. I think this is better behaviour.

[robbievanleeuwen]

@Agent6-6-6, this one is ready for review. Would love to get your thoughts on whether this makes moment interaction diagrams more usable!

Docs for this PR here.

[Agent6-6-6]

@robbievanleeuwen one comment so far before taking it for a spin, you're referring to the limits with the decompression limit point being based on the ratio of neutral axis depth to section depth = "D".

But I think the actual point at which the concrete section starts to not be fully in compression (edit -- at the maximum concrete strength) is actually when the neutral axis depth is h/gamma if h = section depth and gamma is the factor by which you're relating the neutral axis depth to compression block depth in your code nomenclature. Maybe I'm misinterpreting though.

But obviously, this would depend on the stress-strain relationship, but it seems like you're potentially missing the true decompression point as implemented if you're solving for a neutral axis depth equal to section depth as the uppermost limit?

To demonstrate for example if gamma = 0.85, and h = 500mm, then the decompression point is really when the neutral axis depth = 500/0.85 = 588 mm. This came up in #26 when you reworked the interaction diagrams before.

If I'm correct here you'd need to somehow determine where the stress-strain profile transitions to the constant plateau (for rectangular, bilinear and parabolic stress-strain curves) and work out the upper bound limit based on that to achieve the full section in compression?

[Agent6-6-6]

One other observation @robbievanleeuwen, with the n_spacing parameter related to axial load step, since you don't know the total extent between limits you kind of have to run a few times to tune the value of n_spacing to get the desired result. Underestimate it and you might be in for a longer analysis than expected.

I kind of wonder if the n_spacing parameter should really be defined as a number of equally spaced axial loads (irrespective of the section and range of axial load between the limits), which hopefully keeps the number of iterations similar irrespective of the section being analysed. As opposed to a hard-coded axial load value like 200kN which will give a different accuracy of the interaction curve for sections with 10000kN axial range vs 500kN axial range along with quite significant differences in run time.

Or alternatively, consider adding this as a third option for controlling the resulting output for the curve on top of n_points and n_spacing?

[Agent6-6-6]

@robbievanleeuwen added a few suggestions/corrections regarding docs and some other queries/suggestions. Let me know if anything isn't clear!

[Agent6-6-6]

Rather than interpolating here, why not just calculate neutral axis depth d_n at max_comp and then work out actual moment capacity at this control point.

I wonder if max_comp used, maybe easier to add another artificial control point at this axial load so you calculate the moment capacity value in above code iterations when going through all the points, then you're just cutting off the unused values above max_comp here?

This would be more accurate.

[robbievanleeuwen]

This is a far more sensible approach, thanks. I was approaching this as a (bad) programmer not an engineer 🤣

Before I implement this, just wanting to get clarification on something - should the first point in the diagram be at zero moment or have the same moment as the pretrimmed diagram, i.e. point 1 or 2 in the below? Current implementation is point 2.

[Agent6-6-6]

@robbievanleeuwen, I'd say zero moment (point 2), simply because if you plotted the negative side of the diagram it all meets up as a horizontal line anyway to complete the full interaction surface slice. So the actual value isn't that important as at that axial load you know you can have a moment between whatever the capacity is at -M_max_comp or +M_max_comp.

I'll have a look at what SPColumn does though to see if there is another precedent.

I was thinking that this additional point just gets appended to the evenly spaced points, rather than a control point so as not to mess up the labels?

I wonder if max_comp is specified if that should then substitute in for the upper limit so as not to waste computation time working out points above this axial load (don't recall maybe you already did this, been a week since I did the review!?). I'm thinking here for wall design in NZ at least, the max compression load is like 0.3f'cAg which is usually way below the balance point, so there is no point working out data points above this only to then truncate the results and throw a large percentage of them away

[robbievanleeuwen]

Ok thanks for that, some good points, will implement!

[Agent6-6-6]

Hi @robbievanleeuwen

I'll have a look at what SPColumn does though to see if there is another precedent.

I had a look at this but forgot to post back, what SPColumn does if you look at the positive or negative branches of the diagram is just cut it off at zero moment at the axes, but has the part of the negative curve generated at max compression or max tension, for example +ve and -ve views below:-

So you get the full half of the diagram, not a skewed result for a non-symmetric section or reinforcement with different moment capacities top and bottom like concreteproperties returns. That could lead to not quite knowing for example if in your last diagram you're at an N*=-350kN and M*=25kNm that you're above or below the curve even though you're in the positive half of the interaction curve.

As a thought I wonder how hard would it be to generate the remaining missing points back to zero moment in the tension region in your last example and to have the option of truncating the curve at zero moment to implement something similar to SPColumn for a consistent approach to a positive and negative portion of the curve. This would also make it easier to test if inside the curve or not if you added a closing line at zero moment and then used some shapely stuff to check if a point lies within a polygon or similar.

[robbievanleeuwen]

Thanks for exploring this. I'm going to turn this into a new issue as it raises a few items and it would be nice to get this PR merged for now.

[robbievanleeuwen]

@Agent6-6-6

@robbievanleeuwen one comment so far before taking it for a spin, you're referring to the limits with the decompression limit point being based on the ratio of neutral axis depth to section depth = "D".

I think my approach here will be to change the docs such that it is clear that it is the strain profile that is in decompression, not necessarily the stress (as you say, depends on your stress-strain profile). Given that there are many possible stress-strain profiles (not just the rectangular stress block), compounded with the possibly of sections with differing grades of concrete, I'm not going to try to work out when the stress "decompresses", but rather work with strain.

Design codes and/or users can then modify this value to their needs if they require.

EDIT: Because the rectangular stress block attempts to simplify the "real" concrete stress profile I feel like decompression should still be based on the strain profile and not the stress profile. This way if you are comparing decompression of a rectangular stress block with a parabolic stress block you should get similar results. Pushing down the rectangular stress block by D/gamma wouldn't make sense in this case as your strain profile no longer corresponds to decompression and comparison with a parabolic profile at decompression would be way off.

[robbievanleeuwen]

@Agent6-6-6

One other observation @robbievanleeuwen, with the n_spacing parameter related to axial load step, since you don't know the total extent between limits you kind of have to run a few times to tune the value of n_spacing to get the desired result.

This is a fair comment, I will add an additional parameter modify n_spacing to allow for n evenly spaced axial loads .

[robbievanleeuwen]

@Agent6-6-6 another off-topic one if you don't mind 😄 Wondering what hardware you use to run pfSense (had a quick little read of this!)

[Agent6-6-6]

@Agent6-6-6 another off-topic one if you don't mind 😄 Wondering what hardware you use to run pfSense (had a quick little read of this!)

@robbievanleeuwen - I run it on a little fanless Qotom PC similar to this but from back in 2017... just have it screwed to the underside of a shelf where my fibre connection terminates inside the house. Took a few weeks to arrive from China form memory

4Gb of memory, 32Gb mSSD.

It does gets a bit toasty in Summer on hot days. But it is more than capable of maxing out my 300/100Mbit fibre connection if required. Took a while to get my head around how all the rules work for the firewall and setting up other features. But once over that hump, I'd never go back to using a consumer router.

You can get it all set up for a lot less cost than a half-decent high-end router that would offer you a lot less control over tinkering with it! Plus pfSense is regularly updated form a feature and security standpoint since it's mostly open source.

[Agent6-6-6]

I think my approach here will be to change the docs such that it is clear that it is the strain profile that is in decompression, not necessarily the stress (as you say, depends on your stress-strain profile). Given that there are many possible stress-strain profiles (not just the rectangular stress block), compounded with the possibility of sections with differing grades of concrete, I'm not going to try to work out when the stress "decompresses", but rather work with strain.

Design codes and/or users can then modify this value to their needs if they require.

EDIT: Because the rectangular stress block attempts to simplify the "real" concrete stress profile I feel like decompression should still be based on the strain profile and not the stress profile. This way if you are comparing decompression of a rectangular stress block with a parabolic stress block you should get similar results. Pushing down the rectangular stress block by D/gamma wouldn't make sense in this case as your strain profile no longer corresponds to decompression and comparison with a parabolic profile at decompression would be way off.

I've always thought the decompression point was where the concrete in the section started to not be fully in compression at the design compression stress. Independent of the stress-strain profile this is still the same physical phenomenon in terms of cross-section stresses. i.e. for a rectangular stress block when the neutral axis is D/gamma, for a parabolic stress block when D/(ratio of distance on strain diagram where it transitions to the horizontal to the maximum strain), similar for a bilinear approach. For all of the ultimate stress-strain profiles, I think you already have these values probably as they are used to generate the stress-strain profile in the first place.

Can follow that it would be a bit of a dog with multiple different concrete sections with different strengths and hence different parameters like gamma (still have not wrapped my head around how this is even done for the ULS analysis yet!)

Anyway, I'll see what you say in the docs as probably not fully understanding exactly what has been done, just seemed like you're missing out on a bit of the curve between the max point and this first calculated data point where you take the neutral axis depth at D, but granted nothing interesting usually happens at the top of the curve anyway and in my use case that part of the curve usually seems to be truncated by max_comp!!!

I'm not so sure we are talking about the same thing, as not really envisaging how the strain comes into it when it is a stress based thing, i.e. the point at which the stress starts to reduce below a constant concrete stress (for the concrete only) across the entire section? Past this point obviously only the bar forces can vary to take more load in compression.

[robbievanleeuwen]

Thanks for the heads up on the aliexpress special, everything else I was looking at seemed very expensive! Yep the open source nature and features pfSense offer are very appealing!

Yeah maybe we are thinking of two different things, decompression for me is when one extreme fibre of the concrete has a stress of zero (and thus a corresponding strain of zero for most stress-strain profiles).

The below picture is by no means definitive, just one of the first results on google, but kind of explains what I probably haven't put into words very eloquently. Zero concrete strain at the bottom, and for a rectangular stress block some portion of the cross-section with zero stress.

Setting ("D", 1.0) as a control point puts the neutral axis at a depth D and thus gives you this "decompression point". Agreed you lose a bit of fidelity between this point and pure compression, but the user can easily change the limits if they desire. See the very first image in this thread if you change the top limit to ("D", 2.0) and use n_points, not very nicely spaced, hence why I went with ("D", 1.0).

[Agent6-6-6]

OK got it now. Zero strain at extreme fibre = decompression point.

Yeah plenty of options to tweak if people want to refine the curve above the decompression point if there is any markedly different behaviour going on, so all good!

Its kind of got me thinking if there should also be a control point behaviour based on defining strain at the extreme tension (concrete) fibre. You have one for stell with the ʼf_yʼ for example. Though not sure how much use it is but I guess it is just a different way of specifying the ʼDʼ ratio that might seem a bit more logical with respect to the analysis actually being strain based. I mean would basing the step on equally spaced strains vs equally spaced neutral axis depths just be a same same but different thing?