Plans for future code adoption?

[joreilly86]

Great work on this project.

Are there any plans for incorporating other international codes? US, Canada, Australia?

[mortenengen]

For the moment we do not have any concrete plans for incorporating other codes, but we are happy to have contributions related to this 😃 Is there a specific code you are looking for?

[joreilly86]

ACI 318 is probably the most useful in terms of the number of people using it.
I will consider this moving forward, if I can add something, I will submit for review. 👍

[gabe-kafka]

I'd like to take this on — starting with ACI 318-19 concrete and reinforcement material properties (Chapters 19, 20, 22). Planning to follow the existing EC2/MC2010 patterns: standalone equation functions in codes/aci318/, material classes inheriting from Concrete/Reinforcement, registered in the factory dicts.

One architectural question: the library's safety factor approach is built around the Eurocode partial factor method (γc, γs applied to material strength). ACI 318 uses LRFD — material strengths are unreduced, and strength reduction factors (φ) are applied to member capacity instead. For material properties this is straightforward (default γc=1.0, γs=1.0), but it will matter when member design functions (shear, flexure) are added later. Is the current architecture something you'd want to evolve to accommodate both philosophies, or should ACI contributions stay scoped to material properties for now?

Will target the dev branch.

[gabe-kafka]

I'd like to take this on, starting with ACI 318-19 concrete and reinforcement material properties (Chapters 19, 20, 22). Planning to follow the existing EC2/MC2010 patterns: standalone equation functions in codes/aci318/, material classes inheriting from Concrete/Reinforcement, registered in the factory dicts.

One architectural question: the library's safety factor approach is built around the Eurocode partial factor method (γc, γs applied to material strength). ACI 318 uses LRFD material strengths, which are unreduced, and strength reduction factors (φ) are applied to member capacity instead. For material properties this is straightforward (default γc=1.0, γs=1.0), but it will matter when member design functions (shear, flexure) are added later. Is the current architecture something you'd want to evolve to accommodate both philosophies, or should ACI contributions stay scoped to material properties for now?

Will target the dev branch.

[mortenengen]

Thanks for taking on this task, @gabe-kafka! Your first step makes total sense. Implementing material classes for concrete and reinforcement like you propose in #343 already makes it possible to start using the library for calculating e.g. interaction domains for axial force and biaxial bending according to ACI-318.

You address an important topic in your question, the safety factor approach. And you are correct that so far, all we have implemented in the library follow the partial factor method which is common in the Eurocodes and in the fib Model Code.

However, in the material classes for concrete and reinforcement, we let it be the user's responsibility to assign constitutive laws with parameters that are suitable for the problem at hand. For example, if you are estimating the cracked stiffness of a geometry, you are advised to use the Sargin law with mean properties for concrete, but if you are estimating the interaction domain between bending moment and axial force in the ultimate limit state, you should use the parabola-rectangle law with design properties. And, of course, consistent material properties for the reinforcement material.

According to ACI-318, and if I interpret your message correctly, for the case of the interaction domain, one should rather use the parabola-rectangle law with LRFD properties, and furthermore apply strength reduction factors on axial force and bending moment. As long as this is transparent, and the user is given clear guidance, I think this is a good approach for the implementation.

What is your take on this topic @talledodiego?

[gabe-kafka]

@mortenengen all makes sense. I've added clarity to the docstrings on ConcreteACI318 and ReinforcementACI318 to make the LRFD philosophy explicit. This PR just introduces ACI at the material properties level, users pair it with your existing constitutive laws. Down the line, in the member design space, it might make sense to add a Whitney stress block as a dedicated law since it's used for most simple ACI cases and is highly recognizable.

Also rebased onto latest main (picked up #344). @talledodiego, would love your take when you have a moment.

[joreilly86]

Glad to see somebody is taking this on @gabe-kafka! I started down this path a while ago and took a similar approach:

1. Introduced ACI as a distinct code module.
2. Started with material properties.
3. Tried to reuse as much of the existing constitutive-law / section-analysis framework as I could, but eventually ran into problems I could not easily solve. It works reasonably well for interaction diagrams and more generic section checks, but a lot of the ACI 318-19 / 318-25 nuances become hard to represent cleanly within the current abstractions.

For example, I think there is a useful distinction between:

• generic, mechanically meaningful constitutive/material laws that can remain shared across codes, and
• ACI-specific design idealizations or analysis procedures (e.g. a Whitney stress block, LRFD-oriented section assumptions, etc.), which are probably better treated as isolated code-specific implementations that satisfy a common interface.

While many other codes use similar equivalent rectangular compression blocks, the specific formulations (stress factors, depth factors, strain assumptions, and how safety is applied) differ by code. These are therefore better viewed as code-calibrated design models rather than fundamental stress–strain relationships, even though they share a common conceptual basis.

This is where I got stuck - I couldn’t come up with a clean, extensible architecture that would map well to other codes.

Moving forward, my sense is that the most effective path would be to complete the ACI material layer first, and then use that work to define a more repeatable architecture for adding other national codes as well. That likely means keeping constitutive laws and core section-analysis routines code-independent (which is already how the library works), while capturing code-specific section/design models (e.g. Whitney-type stress blocks, LRFD or other safety-format handling, strain-domain assumptions, etc.) as modular components within each code namespace that conform to common interfaces.

That would make it easier not only to support ACI cleanly, but also to extend the library later for other jurisdictions that are likely to run into many of the same architectural speed bumps.

Keep us updated on your progress! 👍

[gabe-kafka]

@joreilly86 thanks for the architectural context. The distinction you're drawing, generic, mechanically-meaningful constitutive laws vs. code-specific design idealizations, clears things up.

Quick walk-back on my earlier comment: I said Whitney might make sense "as a dedicated law" which was off. Rectangular stress blocks don't meet the definition of constitutive law and are generally at odds with the structure of the library.

More importantly, I'm realizing the library's approach of integrating the real parabola-rectangle curve is already ACI 318 compliant via §22.2.2.3, which permits any stress-strain relationship that produces strength predictions in substantial agreement with tests. Skipping Whitney entirely makes sense.

Happy to complete the material layer as scoped in #343 and circle back for member design once this lands. When I do, I'll follow the "code-specific modular components with common interfaces" pattern you described rather than reaching for a generic stress-block abstraction.