CANDE stands for Culvert ANalysis and DEsign. It is a finite element program built specifically for buried structures: pipes, culverts, and arches with soil over and around them. It came out of work for the Federal Highway Administration, and it has been the standard tool for soil-structure interaction on buried structures for decades. Unlike general structural software, it is built around one idea: a buried structure and the soil around it act together, and you cannot understand one without the other.
The intuitive way to analyze a pipe is to treat it like a ring or a beam, push a load on top, and see what happens. For a buried structure that approach is either badly wrong or wildly conservative, because it ignores the soil.
When a flexible pipe deflects under load, it pushes outward against the soil at its sides, and that soil pushes back. That side support is often what holds the structure up. A rigid pipe does the opposite, attracting load to itself because it is stiffer than the soil around it. Either way, the soil is not just load sitting on top of the structure. It is part of the structural system. CANDE models the soil and the structure together, which is the entire point.
You need this kind of analysis when the soil-structure interaction genuinely drives the answer. In practice that means large-diameter culverts and pipes, deep fill heights, shallow cover under live load, unusual installation conditions, and any time the structure is flexible enough that side support matters. It applies across materials: corrugated metal, reinforced concrete, thermoplastic, and fiberglass, along with metal and concrete arches.
You probably do not need it for a small-diameter pipe under modest cover in standard conditions, where established tables and simpler methods are perfectly adequate and a full finite element model is overkill. Part of the value of asking is finding out you do not need to spend the money.
CANDE models construction in stages, building up the soil in layers the way it actually gets placed, because a buried structure sees load incrementally during installation, not all at once at the end. It uses soil models that capture how soil stiffness changes with stress and confinement. It will give you deflections, thrusts, and moments through the structure under realistic conditions.
What it does not do is make judgment calls for you. The soil properties, the installation assumptions, the interpretation of the results: those are engineering, and the program is only as good as the inputs and the person reading the output. A buried-structure analysis that does not interrogate its own soil assumptions is not worth much.
I do a fair amount of buried-structure work, and a lot of it comes from smaller outfits who have an occasional culvert or pipe problem and no reason to keep a soil-structure interaction specialist on staff. If that is you, this is exactly the kind of thing I am happy to take on, including the small jobs that larger firms tend to decline.
One last note, since it is relevant: the manual side of preparing these models, assigning materials and construction steps across a mesh, got tedious enough that I eventually built my own preprocessor to handle it. That is a story for another article.
]]>A real drawing is not a sketch. It is to scale, dimensioned, annotated, and readable by a fabricator or a plan reviewer who was not in the room when it was designed. I am building tooling that produces genuine DXF drawings from a description: scaled details, sections, framing plans, and the structural notation that goes with them, including weld and bolt symbols, member tags, schedules, general structural notes, and multi-sheet sets.
I will be straight about its status: this one is harder than the SAP2000 work, and it is still in development. A model can be subtly wrong and still produce a drawing that looks fine, which makes the verification problem genuinely difficult. It is producing real drawings today, but I am not going to call it finished, because a drawing that is almost right is worse than useless. It earns the same treatment as everything else here, which is that nothing leaves without an engineer checking it.
A calculation isn’t a deliverable until it is documented. The writeup, the assumptions, the code references, the limitations language, all of it has to keep pace with the analysis, and historically it is the part that lags, because it is tedious and it is the last thing standing between you and sending the package. I built a skill that assembles formatted engineering reports with consistent structure and language, so the documentation moves at the speed of the work instead of holding it up. This one is in regular use.
Load combinations are exactly the kind of bookkeeping that is mind-numbing by hand and easy to get wrong: the full set of strength and service combinations across the governing code, applied correctly and tracked through the analysis. I am building a skill to generate and check them across the codes I work in. It is not finished yet, and I would rather tell you that than oversell it. It is coming.
Every one of these is taught the same painstaking way the SAP2000 tool was, and every one of them keeps a licensed engineer in the loop. The tools handle production. They do not handle judgment, and they never get the last word. What they buy back is time: the assembly, the drafting, the documentation, and the bookkeeping that were never really engineering get compressed, so more of the project goes to the part that actually is.
That is the whole strategy. Not a gimmick, and not a promise that a machine will do your engineering. A deliberate, verified automation layer under the parts of the work that deserve to be automated, built and checked by someone who has to sign for the result. That is what the SAP2000 and analysis automation work is built around.
]]>Every structural engineer who uses SAP2000 knows the part of the job that isn’t really engineering. Before you can analyze anything, you have to build the model: nodes, frames, sections, supports, load patterns, load cases, combinations. On a routine job that setup can eat hours, and not one of those hours goes to judgment. They go to data entry.
A SAP2000 model is, underneath the interface, structured data. The geometry, the section properties, the loads, all of it can be expressed as a text file that the program reads back in. Which means the real bottleneck was never the analysis. It was translating engineering intent into the exact format the software expects. That is a translation problem, and translation is something modern AI is genuinely good at.
So I built a tool that does the translating. I describe a structure in plain language, and the AI assembles the corresponding SAP2000 input file. That sentence makes it sound easy. It was not.
A model like Claude is very good at producing structured text. But it does not know SAP2000’s input format. None of that format lives in its general knowledge, and the format itself is unforgiving: a dense text specification full of ordering rules, unit conventions, escaping behavior, and quirks that break silently when you get them slightly wrong. You cannot simply ask an AI to “write me a SAP2000 file” and trust what comes back. It will hand you something that looks correct and is wrong in ways that matter.
Getting it to work meant teaching the model the format from the ground up, through a long iterative process: build, test against real models, find exactly where it breaks, correct, and repeat, over and over, across a great deal of time and compute. What you end up with is called a skill, a hard-won body of encoded knowledge that lets the AI produce input the program will actually accept and that means what I intended it to mean. None of that knowledge came for free, and none of it is the sort of thing you knock out on a weekend.
What this really demands is fluency in two domains at the same time. You have to know the structural software deeply enough to catch when its output is subtly wrong, because the AI will confidently produce subtly wrong things, and you have to understand how these AI systems actually behave and fail well enough to corner them into reliability. There are plenty of structural engineers. There are plenty of people who can prompt an AI. The overlap, people who can do both well enough to build something a licensed engineer would put a seal on, is very thin. That isn’t a complaint. It is the whole point.
The sensible question any client asks is this: if an AI built it, why should I trust it? The answer is that the AI never gets the final word, and never touches the judgment. Every model is round-trip validated, generated, read back, and checked against what I actually intended, and then it goes through the same review any model of mine would. A licensed professional engineer verifies it and stamps it. The tool does the assembly. The engineering stays human. That division is not a compromise I put up with. It is the design.
Speed, without a quality penalty. Work that used to take days, parametric studies, design options, product calculators that need the same model rebuilt a hundred different ways, now turns around in hours. For repetitive and parametric problems especially, the difference is dramatic, and it shows up in both your schedule and your fee.
It does not do everything, and I would be wary of anyone who told you their version did. It does not do the conceptual design, the part where you decide what the structure should be. It does not replace an engineer’s read on whether an answer is even reasonable. There are problems where it offers no advantage at all, and on those I build the model by hand like everyone else. The tool is excellent at the tedious, well-defined assembly that used to waste my time, and it stays silent on the things that genuinely require an engineer. That boundary is exactly what makes the rest of it trustworthy.
If you have a project that fits, particularly something parametric or repetitive in SAP2000, that is precisely where this pays off. You can see more about this analysis automation work. And if it doesn’t fit, I will tell you that too.
]]>