Predicted vs actual movement, from a mountain of data
A huge analysis model and the surveyor's data, combined into predicted-versus-actual tracking graphs.
The problem
ETABS gives you a lot back. On a construction-stage analysis of a large tower, that was gigabytes of results across two models, holding the predicted deflection at every level, for every stage of the build. The team wanted to track that prediction against what the building was actually doing as it went up, comparing the analysis to the surveyor's measurements. Pulling that together by hand, out of spreadsheets that size, every reporting cycle, is not realistic.
What I built
I took the ETABS results and the surveyor’s data and put them in the same space, so predicted and measured deflections lined up by level and by construction stage. Then I wrote a set of Python scripts to bring it all together and produce the comparison graphs and tables directly.
Simple pieces doing an unglamorous job well: read both sources, align them, plot them, ready to report from.
What makes this work
The scripts match the analysis prediction to the real survey measurement, stage by stage and level by level, and turn the two into a single clear picture. The alignment is the point, not the export. It comes out client-ready, which is why the team could send the graphs straight on to their own client as a progress update each cycle.
What changed
The team gets a clear predicted-versus-actual view they can hand to builders and clients to report on progress, regenerated from the data each cycle instead of reassembled by hand. The specific job was deflection tracking, but the pattern holds for any large dataset you are trying to wrangle into something usable.
Notes on maintainability
The same approach applies to any large dataset you are trying to make sense of. The specifics change, the pattern does not.