feat: add ACI 318-25 support (one-way slab flexure and shear)

[joreilly86]

Summary

Adds ACI 318-25 (Building Code Requirements for Structural Concrete) to the library, starting with one-way slab flexural and shear design. This builds on the discussion in #187 and complements (but is independent of) #343.

Architecture: "Thin Adapter, Thick Code Module" — minimal material classes plug into the existing geometry/section/integrator pipeline unchanged. ACI design intelligence lives in pure functions under codes/aci318_25/. No changes to existing base classes, geometry, sections, or integrators.

What's included

• Material property functions (Ch. 19, 20): Ec, fr, beta1, eps_cu, alpha1, fct, lambda_factor, Es, fy_design, grade lookup
• Strength reduction factors (Ch. 21): phi_flexure with strain-based transition zone (Table 21.2.2), phi_shear, phi_torsion, phi_bearing, section_classification
• Flexural strength (Ch. 22.2-22.3): Mn_singly_reinforced, Mn_doubly_reinforced, As_required, As_min_slab, As_min_beam, equilibrium helpers
• One-way shear strength (Ch. 22.5): Vc_detailed (Table 22.5.5.1 with size effect), Vc_simplified, Vs, Vn, spacing limits
• One-way slab rules (Ch. 7): min_thickness (Table 7.3.1.1), As_shrinkage_temperature, bar spacing limits
• Material classes: ConcreteACI318_25, ReinforcementACI318_25 (with from_grade())
• WhitneyBlock constitutive law: equivalent rectangular stress block for section integration, with Marin integration support
• Unit conversion utility: PSI_TO_MPA, IN_TO_MM, etc.

Two design paths

1. Closed-form ACI equations — Whitney stress block hand-calc functions for standard design
2. Section-integrator-driven analysis — existing Marin/Fiber integrators with ACI-appropriate constitutive laws

End-to-end validation confirms both paths agree within 5% for the one-way slab example (Whitney: 36.16 kN-m vs parabola-rectangle integrator: 34.52 kN-m).

ACI vs Eurocode safety philosophy

ACI 318 uses LRFD — material strengths are unreduced (gamma_c=1.0, gamma_s=1.0), and strength reduction factors (φ) are applied to member capacity. The phi logic is centralized in _strength_reduction.py. Design functions return nominal strengths; phi is applied externally by the caller. This is documented in the material class docstrings and follows the approach endorsed in #187.

Files changed

• 4 existing files modified (registration only — adding imports and dict entries to codes/__init__.py, materials/concrete/__init__.py, materials/reinforcement/__init__.py, materials/constitutive_laws/__init__.py)
• 22 new files created (implementation + tests)
• Zero changes to geometry, sections, integrators, or base classes

Future extensibility

The pattern supports adding more ACI member types (beams Ch. 9, columns Ch. 10, walls Ch. 11, two-way slabs Ch. 8) as thin member-rule modules that reference the shared flexure/shear/phi functions.

Test plan

• All new ACI 318-25 unit tests pass
• All existing tests pass (zero regressions)
• End-to-end: closed-form and integrator paths cross-checked
• ruff format and ruff check clean

Related

• Discussion: Plans for future code adoption? #187
• Complementary PR (ACI 318-19 materials): feat: add ACI 318-19 concrete and reinforcement material properties #343
• Design spec: docs/superpowers/specs/2026-04-15-aci318-25-integration-design.md

[joreilly86]

Hey all, sharing this as a draft to make the work visible and open for discussion. This represents my take on how ACI 318 could be structured within the existing architecture, building on the conversation in #187.

The core idea is a "thin adapter, thick code module" approach: minimal material classes that satisfy the existing Concrete/Reinforcement interfaces (with gamma_c=1.0 to neutralize the partial factor machinery), while the real ACI design intelligence lives as pure functions in the code module. The existing geometry, section integrators, and constitutive laws are reused unchanged.

I don't have a huge amount of bandwidth to continue active development on this, so please feel free to take over, adapt, or cherry-pick from this work as you see fit. I'm happy for someone else to run with it. The goal is just to share what I've done so far in the interest of collaboration rather than letting it sit on a local branch.

I will continue to chip away at this as time permits.

Open to feedback on the architecture, naming, or any of the design decisions. Happy to answer questions about the approach.