Pourcast

Inspiration

Concrete doesn't get strong on a schedule. It gets strong from heat.

A slab that's ready to strip in two days in July can need a week in January. The crew standing on it has no way to tell which one they've got, so they go by a calendar, because that's what the last job did.

That fails in both directions. In a cold week you pull the forms off something that isn't ready and get cracking, sagging, or worse. Concrete that freezes before it reaches about 500 psi is damaged for good, and waiting longer doesn't fix it. In a warm week the opposite happens. The concrete was ready on day three and the forms sat there until day seven anyway, which on a multi-storey job is four days lost on every floor.

The fix has been around since the 1970s. It's called the maturity method, ASTM C1074. Large contractors run it with sensors buried in the pour. Almost nobody else does, because doing it by hand means a spreadsheet and a copy of a standard you have to buy. But a weather forecast is free, and a forecast is really just a temperature history for the next sixteen days. That was the whole idea.

How I built it

One self-contained HTML file. No dependencies, no framework. You can open it off a USB stick in a site trailer with no internet and it still works.

The engine runs ASTM C1074 maturity, both Nurse-Saul and Arrhenius equivalent age, to turn a temperature history into a strength. Underneath that is a one-dimensional finite difference solve of heat conduction through the section, seven nodes from the core out to the surface, with hydration heat released at each one.

That part mattered more than I expected. Cement gives off heat as it sets, so a pour runs warmer than the air around it for its first two days. Predict from air temperature alone and cold weather comes out badly wrong. The placement checks come from ACI 305 for evaporation and ACI 306 for freezing and protection.

When the answer is bad, it searches 1,740 combinations of blankets, enclosures, concrete temperature and pour hour, then hands back the cheapest set of changes that makes the pour work. 95 unit tests and a 38-check browser harness.

Challenges I ran into

Getting protection right. I first treated insulation as nothing more than slower heat loss, which made a heated enclosure look almost useless in hard frost. An enclosure does two other things. It sets the air temperature the concrete is losing heat to, and it takes the wind off, and wind is the biggest term in the evaporation equation. With all three of those in, my Chicago test week went from "never reaches strength" to "strip at 42 hours".

Speed. Scoring a week means 169 full simulations. My first version rebuilt a lookup table on every row, which made it quadratic and laggy on every keystroke. Caching on object identity took it from 99 ms to under 3 ms.

Time zones. Every time this prints is an instruction to someone standing on a jobsite, so it has to be their local time, and a pour that spans a daylight saving change can't quietly shift by an hour.

What I learned

A test is only worth something if it checks against something outside your own code. My evaporation rates came out eight times too small because I'd used the imperial version of Menzel's equation with Celsius inputs. Nothing about the output looked wrong. One test caught it, the one I'd pinned to a published nomograph point. Every test that checked the function against itself passed happily.

Being right isn't the same as being useful. An early version of the recommender told a crew in a 30 °C heatwave to heat the mixing water to 16 °C. The arithmetic was correct. As an instruction to a human being, it was ridiculous.

Built With

• aci-305
• aci-306
• astm-c1074
• css3
• es-modules
• html5
• javascript
• node.js
• open-meteo
• rest
• svg