In many fabrication shops, the drawing isn't where a job begins. It begins with a calculation report.
A design engineer sizes the vessel in a pressure-vessel design program such as PV Elite, checks it against ASME Section VIII, and produces a long PDF: design conditions, every shell course and head, flanges, the tube bundle, the tubesheet calculation, nozzles, saddles, pages and pages of numbers. The draughtsperson then sits with that report on one screen and CAD on the other, carrying values across by hand.
So a natural question came up: if RevE can read a drawing, can it read the calculation report and start the drawing from there?
We tried it on a publicly available sample report for a fixed-tubesheet (BEM-type) heat exchanger. What we learned was less about reading and more about honesty.
Reading: 413 values, each with its receipt
Calculation reports are far friendlier than drawings. The text is real, the layout is consistent from page to page, and the program always prints its sections in a known order. That meant this reader could be **pure code**, with no AI involved, which is exactly what the "Code, AI, or Both" table from Part 1 would recommend.
The parser pulled out 413 values: design conditions, the seven-element vessel stack, body flanges, tube bundle, tubesheet, five nozzles and two saddles. Every value carries a small receipt:
- the value exactly as printed, in its original imperial units
- the converted SI value
- the page number
- the exact line of the report it came from
When an engineer asks "where did this 0.625 come from?", the answer is one click away, not a search through forty pages.
Mapping: where the honesty begins
Reading the report is one job. Turning it into the inputs a drawing generator needs is another, and this is where it gets interesting. A calculation program and a drawing are interested in different things. The calculation cares about thicknesses, stresses and allowances. The drawing also needs things like how many baffles there are, where the tie rods go and which nozzle is the inlet.
So instead of quietly filling the gaps, the mapper gives every one of the 113 drawing-spec fields an honest label:
- Mapped (86): taken straight from the report, with the receipt attached.
- Derived (1): calculated from report values, with the formula written down.
- Needs input (15): genuinely not in the report. PV Elite models the tube bundle's support as an unsupported span, so it never gives a baffle count. It doesn't model tie rods at all. It gives a bolt size but not the bolt-hole size, and a nozzle's pipe material but not the flange material.
- Model limitation (7): the report describes something our drawing engine can't yet show. Examples are a shell expansion joint, a tubesheet extended as a flange, and nozzle reinforcement pads.
- Available, not mapped (4): in the report, and noted for later.
That middle group is the important one. Not one of those 15 gaps was filled with a "sensible default". A default looks exactly like a real value once it's printed on a drawing, and that's how a guess becomes a fabricated part.
When we wanted to see a complete drawing for demonstration purposes, we filled the gaps in a separate, clearly labelled demo-assumptions file, kept apart from the real data, so nobody could mistake an assumption for something the engineer had calculated.
The report that contradicted itself
Then came the finding I enjoy telling most.
While mapping the tube bundle, a simple geometric check flagged a problem. The report's outer tube limit was 17.01 inches. The shell inside diameter was 17.000 inches.
Read that again. The tube bundle, as stated, was larger than the shell it had to slide into. At the report's own dimensions, there would be no room for baffles at all.
Was it a rounding quirk? A value typed at one point in the design and not updated at another? We don't know, and that's exactly the point. It isn't our place to "fix" a design engineer's report quietly. It's our place to notice and to ask.
A human reading forty pages would very likely miss a 0.01-inch conflict between two numbers printed pages apart. A simple check in code, written once, never misses it.
Another quiet ambiguity
There was a gentler example too. The report lists three shell nozzles (S1, S2 and S3) but never says which is the inlet and which is the outlet. Our drawing engine places exactly two. Rather than pick the first two, the mapper marks the choice as needs input, explains why, and waits for a person.
Small things, but they add up to a tool an engineer can trust: it says "I don't know" when it doesn't know, and "this doesn't add up" when it doesn't.
From experiment to a step in the wizard
When I first wrote about this, the report reader was an experiment that sat outside the app. It's now a step in RevE's new-design wizard. When an engineer starts a new drawing from a template, they can add the design calculation PDF (often hundreds of pages), and RevE proposes values for the wizard's boxes. Nothing leaves the laptop, and no AI is involved.
Three design decisions made it trustworthy.
Check the exchanger type before filling anything. A calculation for a fixed-tubesheet exchanger must never fill a floating-head template. So RevE first reads the exchanger type from the report itself, with the pages as evidence: the tubesheet type, the front head and the shell courses. Our sample report reads as BEM, from pages 82, 4 and 6. Against a BEM template, 21 values filled exactly and 10 were left for the engineer to pick. Against a BES template, RevE filled nothing and said why: "rear end differs: fixed vs floating".
Show every candidate, not just the first. A long report prints the same kind of value many times. Shell pressure appears as the design pressure, the maximum allowable working pressure and the hydrotest pressure, on different pages. For every field, RevE lists every other value printed with the same wording, with all its pages, so the engineer chooses with the evidence in front of them. A value found only this way is never filled automatically.
The calculation governs, visibly. Where the calculation and the template disagree on something the calculation governs (a thickness, a pressure, a flange class), RevE proposes the calculation's value with a clear remark. Every filled box carries a small "from calc · page N" tag and can be put back to the template's value with one click. In "What changed", the change says where it came from: the page, the section and the printed text.
Nozzles needed special care. The report lists every nozzle with size, schedule, class and material, but the wizard's nozzle boxes follow the template's own nozzle schedule. RevE suggests a match only when one nozzle clearly fits best. On our sample, three shell nozzles fit equally well, so it suggests none and lets the engineer pick.
The honest gaps from earlier haven't gone away. Baffle count, tie rods and flange materials still aren't in a PV Elite report, and RevE still says so. But the report now does what it should: it fills what it really knows, with a receipt, and leaves the rest to a person.
What I'd tell any team turning documents into designs
1. Use code where the document is regular. Calculation reports are structured, so reading them is a parsing problem, not an AI problem.
2. Give every value a receipt: page, line, original units.
3. Label every gap honestly. "Needs input" and "model limitation" are features, not failures.
4. Keep assumptions in a separate, clearly labelled place. Never mix them with real data.
5. Write simple consistency checks. They'll catch what tired eyes miss, even in the source document.
In engineering, an honest blank beats a plausible wrong number every time. This time, the honest check also caught a conflict hiding inside the design report itself.
Next, in Part 6: from a flat drawing to a 3D model, and what the model taught us about the drawing.
#PressureVessels #PVElite #ASME #EngineeringDesign #HeatExchangers #IndustrialAI #DataQuality #Fabrication #MechanicalEngineering #SandurTech
Disclaimer
This series introduces SandurTech RevE, a product in development for AI-assisted engineering drawing analysis and generation. Examples reflect our current capabilities and ongoing validation. Outputs should be reviewed by qualified engineers and verified against approved drawings, standards, and project requirements before use.
