Micro modular reactor pressure boundary

Four failure mechanisms, one piece of geometry

A reactor pressure boundary at high temperature and multi-MPa is not a structural problem with a thermal complication attached. It is four different physics problems sharing a single wall thickness, and each of them wants a different answer.

Pressure wants thick section. Thermal gradients want thin section, because through-wall gradient stress scales with thickness. Creep wants low sustained stress at temperature, which pushes back toward thick. Fatigue wants low stress range, which cares about how quickly the plant cycles rather than where it sits. And then manufacturability and inspection access want something a shop can actually produce and a technician can actually put a probe on.

None of these can be optimised in sequence. Fix the wall for pressure and you have already lost the thermal argument. The work is holding all of them open long enough to find the region where every one of them is satisfied, and being honest when that region turns out to be empty.

Develop the loads, do not inherit them

On a first-of-a-kind system there is nothing to inherit. There is no previous unit whose loads you can scale, and a load set copied from an adjacent programme carries assumptions you cannot see and cannot defend.

So loads get developed from function: what this component is for, what it is attached to, what the plant does to it across the full set of interacting conditions. That is slower at the start and very much faster later, because when a reviewer asks where a number came from there is an answer, and when a requirement changes you can see exactly what it invalidates.

Interfaces are where first-of-a-kind systems fail

Individual components are rarely the problem. The problem is the boundary between them: mechanical interfaces, tolerance chains that cross responsibility lines, load paths that hand off between two analyses owned by two different people, and thermal growth that nobody has reconciled because each side assumed the other was holding it.

Interface control, applied early and written down, is the highest-leverage work on a programme like this. It is also the least visible, which is why it is usually done too late.

Reduce it to something decidable

Most of what I do sits between thermal-hydraulics, structural analysis, safety, materials, manufacturing and procurement. Every one of those groups is correct within its own frame, and their conclusions still conflict.

The deliverable is not a compromise. It is a defensible engineering resolution: a decision, the basis for it, the alternatives that were rejected and why, in a form that survives review and can be found again in two years when somebody asks.

Write the basis as you go

Design-basis content assembled after the fact is a reconstruction, and it always shows. Written alongside the design it is simply a record of decisions already made, and it keeps the analysis, the requirement and the part in the shop from quietly drifting apart — which, over a multi-year programme, is the failure mode that actually gets you.