Comparison with other software

[connorferster]

Hi @robbievanleeuwen!

I have been playing with concreteproperties and just created this gist:
https://gist.github.com/connorferster/7fe8c1687dab86d0d84be4ee0287515a

The comparison with the geometric solver used in spColumn is quite good!

The interesting thing I noticed is that, as the axial load increases, the divergence between the two solvers also increases. Do you have any thoughts on why this might be?

The differences are so small (and modelling a concrete section is inherently without high accuracy) so I do not think this is a big deal at all. I was very happy I was able to match the results of this commercial solver!

I have said it before and imma keep saying it: concreteproperties is just awesome.

[robbievanleeuwen]

Gday @connorferster!

Thanks for performing the comparison! Glad to hear the results are looking good!

Not too sure on the small differences? Can't say I'm totally on top of how spColumn works, but in the Australian code the capacity factor phi varies depending on the axial load, could it be related to this? Or perhaps you've controlled this in spColumn so it's a like for like comparison. Other thoughts - does spColumn deduct steel area from concrete area, concreteproperties does so maybe it's this? This could explain the slightly deeper neutral axis under higher axial load? For this simple geometry, a hand calc could verify what the correct neutral axis is for this axial load. I can have a look at this tomorrow :)

[Agent6-6-6]

@connorferster, I also chucked in your Canadian section from your gist into my spreadsheet just to confirm it wasn't my spreadsheet and I get agreement with the concreteproperties results to within fractions of a percent for both 1500kN and 3000kN (and agreement with stresses etc that @robbievanleeuwen showed in the example calculation). So overall I have no idea, maybe SPColumn is the issue in your comparison as you guys concluded.

However I get near perfect agreement in some instances, and in others out by some amount that are beyond normal variance due to rounding and precision. It gets weirder I guess, and needs more investigation when I have further time!

[Agent6-6-6]

@connorferster, @robbievanleeuwen, I've gotten partly to the bottom of these differences (I think at least):-

• SPColumn makes the assumption that irrespective of the reinforcement layout that the axial load is applied at the location of the gross concrete section centroid (i.e. ignoring reinforcement). This is the same assumption (rightly or wrongly) I've made in developing an independent hand check.
• concreteproperties does not appear to do this. I think looking at the code it assumes the elastic centroid which is inclusive of any offset from the gross concrete sections centroid due to the presence of reinforcement, though finding it a little hard to interpret?

Obviously with a symmetrical rectangular section, but with unsymmetrical reinforcement this leads to differences in any outputs.

To demonstrate what seems like an error in the concreteproperties approach, if we look at for example when the entire section is in tension and there is no compression at all in the concrete to determine the moment capacity at this point:-

• Consider the following example:-
  • 800x500 section,
  • 50 cover to main bars,
  • 5 x 500MPa 20 and 25 diameter bars in unsymmetrical arrangement at the pure tension control point.
  • Only the bars are therefore carrying force (c=0), and bars are at yield at the max tension capacity of the section.
• To maintain force and moment equilibrium, a moment of 147.1 kNm must be applied.
• However concreteproperties calculates at the max tension load point a 139.1 kNm moment being applied to maintain equilibrium (force and moment), so something is not correct in the concreteproperties calculation regarding the assumption of where the forces are being applied??
  

I guess it must be remembered if we are comparing an analysis value taken from a centreline bar type element, that the forces we are comparing to are on the geometric centroid of the concrete section.

[robbievanleeuwen]

@Agent6-6-6 @connorferster some good discussion here. Hopefully I'll cover everything that hasn't already been solved...

• Holes in concrete - I don't see this making a significant difference but happy to be otherwise proven wrong. concreteproperties only includes concrete where there is concrete and even with the neutral axis within the bar depth should give correct results. For example, if the neutral axis coincides with the bar's centre, the bar will return zero force (force above in compression = force below in tension). If the neutral axis is slightly above the bar's centre, the bar will return a tension force, again even though evaluated at a point, this net force is consistent with summing the compressive areas and tensile areas of the bar so no material is lost or not considered. All materials are modelled consistently and I believe this is more consistant than the approach you describe, but perhaps I've missed something.
• n_points - I don't think the difference described is appreciable, probably more attributable to numerical differences e.g. neutral axis convergence slightly different between both cases etc.
• Where to take moments about? - I believe this is the difference and have come around to taking moments about the centroid of the concrete only. Technically this is arbitrary, but as you say, most users will be getting their moment results from a frame program where they have most likely entered a concrete cross-section and no reinforcement. These moments will be computed about this unreinforced centroid. Hence, for consistency, I agree that the point about which moments should be calculated is the unreinforced cross-section, it is currently the reinforced cross-section in concreteproperties. There's some good discussion on this here by @buddyd16 (I think?)
• But this begs the question - what to do for composite steel-concrete sections which would probably be modelled in the frame program? Should the approach be to ignore unmeshed areas (likely bars) in the centroid calculation, but include meshed areas (likely larger sections)? Either way, what is agreed on should also be communicated in the docs.

Once we agree on the above I will convert this to an issue and get it changed.

[Agent6-6-6]

But this begs the question - what to do for composite steel-composite sections which would probably be modelled in the frame program? Should the approach be to ignore unmeshed areas (likely bars) in the centroid calculation, but include meshed areas (likely larger sections)? Either way, what is agreed on should also be communicated in the docs.

I guess if an analysis dictates anything different to the gross concrete centroid, then the design actions would need to be transformed to this location by the user for direct comparison to the concretesection analysis results? So at least you're comparing apples with apples?

Maybe though the composite cross sections needs a bit more thought though. But fundamentally I wonder if it is really any different than an unsymmetrical reinforcement layout. I guess if modelling in a frame analysis there is a possibility of the centroid of the composite section being offset from the concrete centroid, but provided the user understands that the frame analysis output actions can be or need to be transformed in those types of cases to the gross concrete section centroid to allow for direct comparison of analysis actions vs concretesection capacities?

Potentially you might have the option of by default consider analysis about centroid of the concrete, but have option of specifying the location of the analysis centreline for other more exotic arrangements which would directly address any difference between a frame analysis composite centroid based action and a cross section analysis capacity being resolved to the exact same location?

Maybe returning a warning if meshed reinforcement + concrete centroid is not within some tolerance of the gross concrete centroid, to ensure user takes note and transforms actions appropriately is a good starting point?

I kind of think to go along with this conversation maybe the docs also need a section/page on the analysis assumptions so user is fully informed on any assumptions and possible pitfalls. Most of this is assumed in any analysis, but no harm in explicitly stating it for clarity. You know the usual stuff like for example:-

• Plane sections remain plane (Bernoulli), i.e. sections perpendicular to the axis of bending that are plane before bending remain plane after bending

• The strains in both the concrete and the reinforcement varies linearly through the depth of the member, i.e. cross section strains are proportional to the distance from the neutral axis

• The strain in the reinforcement is equal to the strain in the concrete at the same level/position, i.e. a perfect bond exists between the reinforcement and the concrete

• Any reinforcement is considered as being characterised by a single strain value at the centre of the reinforcement, i.e. for the analysis the strain gradient across the bar diameter is not considered

• The maximum strain at the extreme concrete compression fibre is assumed to reach a maximum limiting compressive strain

• The stresses in the concrete and reinforcement can be determined from the strains using stress-strain curves for both concrete and steel

• The tensile strength of concrete is neglected in strength calculations

• The member does not buckle before the ultimate strength of the cross section is attained

• The compressive stress-strain relationship for concrete may be assumed to be rectangular, trapezoidal, bilinear, parabolic, or any other arbitrary shape that results in prediction of strength in substantial agreement with the results of comprehensive tests

• Other???

I was planning on looking at what occurs in the two methods when the concrete is a hole vs considering the effective net stress in the bar as the compression block traversed the bar depth to see if there was any differences or blips in the section capacity achieved. Yet to find time/motivation to do it though!

[robbievanleeuwen]

I think I'll go with defaulting to using the gross section centroid (no material properties applied), with the option to use a user defined centroid if desired.

Fully on board with the assumpotions page, will create a new issue! #52

[Agent6-6-6]

@connorferster I know spColumn simply considers the reinforcement area as being lumped only at the defined centre of the bar. It does account for the reduced concrete area due to the bar, but the bar itself and forces/stresses are only accounted for based on the setout to the centre. In the past I've compared circular sections using the compression area as a true circular segment and got the exact same answers.

So if concreteproperties actually considers the real size and shape of the bar (as it appears to do with the mesh plots, I'm sure @robbievanleeuwen can confirm) then it will probably lead to some subtle differences like you've indicated.

I'd imagine then as well that considering the bars as being square as per your example @connorferster will also lead to further subtle differences. I've not looked into exactly how concreteproperties analysis is working but from the plots I'm just making an educated guess here that it's leveraging a finite element formulation and not working from a first principles section analysis considering the bars as occurring at just the centre of the bar.

[robbievanleeuwen]

@Agent6-6-6, concreteproperties does the same in it's calculation. The strains/stresses are evaulated at the centre of the bar and the force is just the area of the bar multiplied by the stress. Because the area of the square bars is equal to the provided area (700 mm^2 in this case) this should not change the results of the calculation, unless the neutral axis passes directly through a bar in which you would expect miniscule differences.

concreteproperties uses a very basic finite element formulation to evalute the concrete force based on the provided stress strain profile. Because all stress-strain profiles are piecewise linear this method gives an exact result and is mesh independent (the backend generates a very coarse mesh). In this example a rectangular stress block is used so the stress is constant over the applied area and all the finite element formulation is doing is summing the area of the concrete and multiplying by the concrete stress.

See above thread for a hand calc verifying the concreteproperties result.