Limitations and scope

What the Section Analyzer is, what it deliberately is not, the assumptions baked into the calculator, the geometry constraints the validator enforces, and where to go when you need a capability that lies outside its scope.

Why this page exists

Every analysis tool has a scope. Understanding where the Section Analyzer stops is as important as understanding what it computes — because relying on a tool outside its scope is one of the most reliable ways to produce wrong answers. This page is the canonical scope statement. The driving principle is the platform-wide rule from #874: returning incorrect data is worse than returning no data. Where a capability sits outside the tool’s scope, the tool refuses rather than approximating.

Scope

The Section Analyzer is a 2D geometric and stiffness-weighted property calculator for arbitrary cross-sections. It produces:

Geometric section properties (area, centroid, second moments, elastic/plastic moduli, radii of gyration, principal moments, polar moment, shape factor) for single-material sections
Stiffness-weighted (transformed) properties via the modular-ratio method for composite multi-material sections
A finite-element mesh overlay for visual inspection of the section

It does not produce:

Design-code capacity checks (no $M_n$ , $V_n$ , $N_n$ , no utilisation ratios)
Buckling loads or buckling-mode shapes
Stress fields under applied loads
Fire / thermal response
Time-dependent behaviour (creep, shrinkage, relaxation)
3D geometry, twisted sections, or warping-aware properties

Assumptions baked into the calculator

The geometric property calculator makes the following assumptions. Stepping outside them does not generate a runtime error — the numbers will still come out — but they will not correspond to anything physical.

Planar 2D sections only

Every region is a 2D polygon in the $xy$ -plane. The tool has no concept of section depth in the third direction, taper, or twist along a member’s length. Use external solvers for prismatic-with-taper or non-prismatic members.

Arc-aware exact integration

Properties are computed by closed-form integration of the polygon boundary (Green’s theorem), with analytic circular-segment correction terms for arc edges. For sections drawn entirely with straight edges the integrals are the classical polygon shoelace / Green’s theorem result. For sections that include arc edges (drawn with the arc tool — 3-point or radius mode), the exactRingProperties algorithm combines the chord-polygon integrals with closed-form circular-segment corrections to deliver zero discretisation error for area, centroid, second moments, extreme fibres, and perimeter, regardless of arc sweep angle or radius.

Sutherland-Hodgman clipping for plastic modulus

The plastic neutral axis is solved by binary search, and the resulting half-area is clipped from each region with Sutherland-Hodgman. The clipping is robust for convex and non-convex polygons but degrades for highly degenerate inputs (vertices coincident within floating-point tolerance, edges almost collinear with the neutral axis). If you see a plastic modulus that is wildly off from a hand-check, simplify the offending vertex layout.

Modular ratio assumes linear elasticity

Transformed properties are valid only while every material is in its linear-elastic regime. The method is an axial-strain compatibility argument under plane-sections-remain-plane; it does not capture concrete cracking, rebar yielding, or any post-elastic redistribution. For sections where the engineering question is post-elastic capacity, use a material-specific designer.

Plastic modulus is null for composite sections

Already covered in Materials — Plastic modulus is null for composite sections, but worth re-stating here as a scope decision. The calculator does not return a “transformed plastic modulus” because no such quantity has physical meaning — plastic capacity depends on per-material yield, not modular ratio. This is a deliberate refusal in the #874 sense.

Geometry validation rules

Before any properties are computed, every submitted region set is validated server-side. The following invariants are enforced. Each rule corresponds to a code value returned in the 400 ProblemDetails response — wire-compatible for frontend branching.

Rule	`code`	Why
Polygons do not self-intersect	`self_intersection`	The polygon integrals assume a simple boundary. Self-intersecting polygons produce signed areas that double-count the figure-eight crossing region.
Voids lie strictly inside an outline	`void_outside_outline`	A void escaping its outline is geometrically meaningless — you cannot subtract material from a region that has no material.
Outlines do not overlap each other	`overlapping_regions`	Two outlines must be adjacent (share at most a boundary, not interior area). Stacking outlines on top of each other has no physical meaning — the two regions would each claim the same area as their own material.
Inclusions are fully outside every outline (adjacent)	`overlapping_regions`	An inclusion today must be adjacent to outlines (composite-beam case — shares at most a boundary, never interior area). The strictly-contained layout (embedded composite — rebar inside concrete, plates inside a host shape) is planned under #1748; until it lands, any outline+inclusion overlap (including strict containment) is rejected.
Inclusions do not overlap each other	`overlapping_regions`	Two inclusions sharing interior area would be double-counted by the additive integration.
Inclusions do not overlap voids	`overlapping_regions`	An inclusion and a void overlapping have no physical meaning — there is no material at the void’s location for the inclusion to neighbour or (in the future embedded-inclusion model under #1748) displace.
Voids do not overlap each other	`overlapping_regions`	Overlapping holes would be double-counted by the subtractive integration.
Voids and inclusions require an enclosing outline	`no_outline`	A void or inclusion with no host outline has no material it is modifying.
Every region has at least 3 vertices	`insufficient_vertices`	The polygon integrals are undefined for fewer than 3 vertices.
Every coordinate is finite	`non_finite_coordinate`	NaN or Infinity in a vertex breaks every downstream computation.

The validator returns the first error in the detail field, along with the full list under extensions.errors so the frontend can highlight every problem region. The fix is always to repair the geometry — the calculator does not have a “best-effort” mode.

What lives in other tools instead

When the answer you need is outside the Section Analyzer’s scope, the platform usually has a specialist tool that does it correctly:

You want	Use
Warping constant $I_w$ , St. Venant torsion constant $J$ , shear centre, Wagner $\beta$ for open thin-walled sections	Light Gauge Steel Designer (coming soon) — its Vlasov beam-theory implementation reports the full warping-aware property set
Elastic buckling loads / signature curve	LGS (coming soon) — FSM buckling analysis
Cold-formed steel design-code capacity (DSM, shear, web crippling)	LGS (coming soon) — covers AS/NZS 4600, AISI S100, EN 1993-1-3
Reinforced concrete moment-curvature, $M$ - $N$ interaction, biaxial bending	Advanced Concrete Section
Fire-resistance analysis of concrete sections	ACS — heat transfer + post-fire capacity
Prestressed / post-tensioned concrete section analysis	ACS

If your question fits none of the above and is also not a question about section properties, the answer is probably “this is not yet built”. The development roadmap sketches what is coming next.

Numerical accuracy

Property family	Typical accuracy
Area, centroid, second moments — straight-edge polygons	Exact (modulo floating-point round-off at ~14 significant digits)
Area, centroid, second moments — sections with arc edges	Exact to floating-point precision — `exactRingProperties` carries zero discretisation error regardless of arc sweep angle or radius
Plastic modulus — any section	~10⁻⁶ relative for straight-edge sections, set by the binary-search tolerance; sub-0.1 % for arc-edge sections (arc edges are discretised to a fine polygon before clipping)
Transformed properties (composite)	Same as the underlying geometric properties, modulo the modular-ratio assumption

For verification, the test suite includes textbook values for rectangles, circles, I-sections, hollow squares, and a small set of composite scenarios. If you suspect a result, hand-check the area and centroid first — they are the cheapest invariants and almost every wrong result traces back to a mis-drawn polygon rather than a bug in the integrator.

Known constraints (not bugs)

Vertex tolerance is engineering-scale, not physics-scale. Two vertices within ~10⁻⁶ mm of each other are treated as distinct. Drawing two coincident vertices on purpose is not supported.
Material density is not part of the property output. The analyser reports geometry and stiffness; it does not multiply by $\rho$ to give mass per length. The Project workspace shows section mass separately if a density is set on the material.
No section taper. The analyser is a cross-section calculator, not a member calculator.
No automatic mesh refinement for irregular sections. The mesh overlay is for inspection; it does not adapt to feature scale today.

Reporting issues

If you find a wrong number — i.e., the analyser disagrees with a hand calculation against a published textbook section — open an issue with:

A screenshot of the geometry (with Vertex No. and Dimensions toggles on)
The reported value and the expected value, with the textbook reference for the expected value
The full JSON response (the Report button’s PDF includes it, or copy from the network panel)

Geometry-validation errors (the rules listed above) are intentional — they are how the tool says “this is not a valid section”. Those are not bugs.