Erosive burning

What the page is for

From version 0.54.0, a top-level Erosive Burning page answers one question: can erosive burning be predicted for this propellant, and if not, what exactly do you still need? Every answer leads somewhere — no row tells you something is missing without telling you what to do about it.

The models themselves live in RustCore, not in RustPEP. RustPEP supplies the propellant and says what each model still needs from it; RustCore is what predicts. This page tells you whether a propellant is ready, and is not a prediction in itself. Everything about those predictions remains research only: see RustCore’s overview.

The page decides nothing

Pick a model from the pulldown and you get a checklist grouped as the shared contract groups it: the base values, the properties that model needs, the model’s own constants, and the values RustCore supplies when you predict.

None of that is RustPEP’s opinion. The model list is RustCore’s registry; every row’s label, symbol, unit, limits and owner path come from the shared field registry; and the rules are the one readiness function all three programs use. A model RustCore adds appears here with no new version of RustPEP.

Model settings

Above the checklist, Model settings appears only for a model that has a choice to make. Today that is Lenoir-Robillard’s alpha: computed works it out from the gas properties, and specified asks you to enter it.

The choice changes what the checklist asks for, which is why it sits above rather than among the rows. Set alpha to specified and the seven gas and solid property rows drop out, leaving alpha itself as the one input needed.

The five row states

Each row shows its state as a word as well as an icon.

State	What it means
Met	The value is there and good enough for this model.
Caveat	Usable, but something about it is worth knowing — an estimate rather than a measurement, say.
Missing	Something to go and get.
Info	Context rather than a requirement.
Blocked	Computed from other values, and one of those is absent.

Blocked is the one worth reading twice. A blocked row is not counted as something to supply, because you cannot supply it directly — fill in what it is computed from and it resolves itself. That is why a count of “2 inputs needed” always means two things to go and get, and never includes a row you could not act on.

What a row offers

Every row carries where its value came from and what to do about it: Enter value or Replace, an Estimate where one honestly exists, Change and Remove on a row holding a value you entered, Why?, and How do I get this?. A value entered here is the same stored value the Properties tab holds — one place to keep it, two places to type it.

From version 0.62.0, replacing or removing a value you entered does not lose it. The old value is kept in that property’s history and can be put back with Restore, and Remove goes back to RustPEP’s own figure where it has one. The Enter value box carries the unit in its label and starts from the current value’s own provenance.

The ? on every row opens a page about that field: what it is, why the selected model needs it, how to determine it with the routes ranked best first, the valid values, where it is entered, and what the common mistakes cost. The “why this model needs it” text changes with the model, and says plainly when the selected model does not use the field at all. Esc closes the popover, and it never covers the row it is explaining.

Those pages are shared with RustCore and RustStand, so the three programs answer “what is this and where do I get it?” with the same words. Where a range is still only guidance, the page says it has not been checked against a source — shown so a typing error is caught, not offered as published fact. Every worked example says its numbers are fictitious.

All models

All models swaps the checklist for a matrix across the methods. It is the fastest way to see which model you could run today and what each of the others is short of.

Guide me

Guide me, from version 0.56.0, is a guided layer over the same checklist rather than a flow of its own: seven steps, from choosing a model through to a review. Characterizing a propellant takes days or weeks of casting and firing across three programs, so it is built to be left and come back to. It stores nothing of its own — every step edits the same values the rows edit — and closing it loses nothing but the place you were at.

A step is ticked when the work it stands for is actually done, read off the checklist, not when a button was pressed. Choosing a model is the one exception, because it is a decision rather than a value, and that choice is remembered per formulation so you can resume. Where part of a step is not built yet, it says so, and says what to do in the meantime. From version 0.68.0 the two steps that wait on firings — the burn-rate step and the model-constant step — show the test campaigns RustStand has published for the recipe you have open: how many firings each campaign planned and how many could be used, the state of every firing, RustStand’s own sentence for anything standing in the way, and what the campaign produced. RustStand writes those campaign files and has no installers yet, so there is nothing to show today and the step says that rather than drawing an empty list.