The errors that survive code review are the ones where the code is correct and the number is wrong. A diff will not catch a capacity in MW that should have been GW, a price in $/tonne read as $/kg, or a discount rate entered as 7 instead of 0.07. The model runs, converges, reports a clean objective, and the answer is off by a thousand.
These survive because nobody looked at the number and asked whether it was plausible. That asking is a skill, it is fast, and almost nobody is taught it.
None worth assigning as a course. The reference values are in your own field: ERCOT’s grid reports for demand and capacity, the EIA’s Annual Energy Outlook for costs and generation, USGS Mineral Commodity Summaries for production volumes and prices. Learn where your field keeps its true numbers; that is most of the skill.
None.
Three checks, on one of your own results.
1. Predict before you run. Write the answer you expect and its order of magnitude, in advance, in writing. Not precisely — within a factor of ten is the whole point. If you cannot predict it to a factor of ten, you do not yet understand the model well enough to interpret what it returns, and that is worth discovering now rather than in a committee meeting.
2. Check the units, everywhere. Every input, every output, every axis. MW or MWh. $/MWh or $/kW-yr. Tonnes or kilotonnes. Nominal or real dollars, and in which year’s dollars. Most order-of-magnitude errors are unit errors wearing a disguise.
3. Anchor to a published number. Find one external reference value your result should be near — a reported ERCOT peak, a published LCOE range, a USGS production figure — and compare. State the source. If you are off by more than a factor of two, you have either found something or broken something, and you must say which.
4. If you ran a solver, read the log rather than the status word.
OPTIMAL is printed by a solver that stopped for any reason it considers acceptable, including
hitting a gap tolerance you set and forgot. Three things to look at every time:
If you do not run solvers, skip this one and say so.
Then check one extreme: what does the model do at zero, or at a very large value? Models that behave absurdly at the boundary are often subtly wrong in the middle.
Text entry: the prediction, the actual, the unit audit, the published anchor with its source, and the extreme-case result.
This replaces your arithmetic entry for the week you do it. Submit it to that week’s WA assignment in Canvas — the same one you would have submitted anyway. It is not an extra piece of work on top of the log.
You do not submit anything to the milestone yet. When all five skills in M1 are done, submit the M1 — The Workbench assignment, which is just an index saying which week each one went in.