Erosive Burning

Erosive burning is the increase in propellant burn rate caused by high-velocity gas flow across the burning surface, on top of the normal pressure-driven rate. It's strongest near the aft end of a grain, where mass flux is highest, and shows up as an ignition pressure spike and/or the aft end of a grain burning through before the forward end. BurnSim 4 can model this; BurnSim 3 could not.

This is opt-in and off by default - a motor with the feature off behaves exactly as before.

Turning it on

Under Settings:

• Simulate Erosive Burning (Use Axial Grain Slices) - the master switch. When on, each grain is divided into axial slices and burn rate is augmented per-slice by the selected model; when off (default), BurnSim uses a single lumped burn rate per grain as it always has.
• Set Slice Count... - how many axial slices each grain is divided into. More slices resolve a tapered port or a burnthrough more precisely, at the cost of simulation speed. 100 is a reasonable default, depending on available processing power.
• Erosive Burning Model - a submenu to pick which correlation the sliced simulation uses: Lenoir-Robillard or Mukunda-Paul. This is a global setting, not a per-motor one - a saved .bsx file doesn't record which model produced its numbers. Switching models re-simulates immediately if slicing is on, since the two can produce visibly different traces.

This all lives in the Settings menu alongside the other simulation-accuracy toggles.

The two models

Both models estimate an augmentation factor on top of the normal Saint-Robert rate (r = a*P^n), evaluated per slice from that slice's local mass flux. They differ in what they assume and what they need from you.

Lenoir-Robillard (default)

The model most motor designers actually use. It's an empirical, "data-fitting" correlation, not a first-principles prediction - the literature is explicit that it requires experimental data for each propellant formulation to be exact. BurnSim's default numbers are a reasonable starting point, not a guarantee.

• Needs a propellant with valid C*, Specific heat ratio and Molar mass set (see the Propellant panel) - these feed a derived flame temperature, which the model needs. A propellant missing these is refused with a warning rather than silently simulated wrong; all three are ordinary ProPep/CEA outputs, so this is rarely a real blocker.
• Its erosive sensitivity constant, beta, has a sensible derived default (based on the propellant's own a/n - slower propellants are inherently more crossflow-sensitive) but can be overridden if you've characterized your own propellant against crossflow.
• Its length scale is distance along the grain port from the head end, not a hydraulic diameter - not something you need to enter, but worth knowing if you're comparing against a value from another source.

Mukunda-Paul

A newer correlation whose selling point is being universal - not fitted per propellant. It's threshold-based: below a certain non-dimensional mass flux there is no augmentation at all, and above it augmentation follows a fixed exponent that doesn't vary by formulation.

• Needs only ordinary a/n/density data, plus (optionally) the combustion-gas viscosity override below - no C*/specific heat ratio/molar mass required, so it will run on propellants Lenoir-Robillard can't.
• No propellant-specific constant to supply or tune - the model's two constants are treated as universal and are not exposed as overrides.
• Because it has a hard threshold, a motor that shows a taper under Lenoir-Robillard can legitimately show none at all under Mukunda-Paul at the same conditions - that's a real difference between the two correlations, not a bug.

Neither model is "more correct" in general - they're offered so you can pick or compare, not because one is a fallback for missing data.

Erosive burning overrides

On the Propellant panel's dedicated Erosive Burning tab (split out from the main Properties tab, since these only matter once slicing is on) is a section of six advanced tri-state fields: Beta, Viscosity (mu), Prandtl, Surface temp, Solid heat capacity (cs), and Combustion temp. Each works the same way:

• Blank - BurnSim derives a value automatically (from the propellant's own a/n, C*, specific heat ratio and molar mass, or from a nominal composite-propellant constant, depending on the field). This is correct for most users and most fields.
• A number - use exactly that value instead. Useful once you have test data or a thermochemistry report (ProPep, CEA) with a directly measured or reported number you'd rather pin exactly.

The small grey text under each box always shows what value is actually in effect, whether derived or overridden. These overrides travel with the propellant in a saved .bsx file and in the shared propellant database, the same way C* and molar mass do. They only matter once axial slicing is turned on - Mukunda-Paul only actually uses the Viscosity override; the other five feed Lenoir-Robillard.

Reading the results

• A Kn Eff checkbox appears next to the ordinary Kn checkbox above the graph, plotting the erosive-burning-effective Kn as its own series. It reads a flat zero unless slicing is on - BurnSim always reports geometric Kn separately rather than silently redefining it.
• The grain cross-section/axial view draws a taper once slicing is on and a simulation has run, showing the port opening up faster toward the aft end where erosive burning is strongest - the visible signature of the effect.
• The Results tab's usual summary (total impulse, peak thrust, Isp, etc.) reflects the augmented burn automatically, and also adds a dedicated line reporting whether erosive burning actually had any effect on this run - off, on with a peak augmentation percentage, or on but never triggered (the port/throat crossflow never got restrictive enough) - so you're not left guessing whether the option did anything.

Things worth knowing

• This is a calibrated correlation, not predictive physics - both models are fits to test data, and published literature notes real gaps (for example, Lenoir-Robillard predicts a temperature dependence that measurements don't actually show). Treat results as informative, not exact, especially with default/derived constants rather than your own measured ones.
• The master switch and model choice are both global settings, not saved per motor - if you need to know how a particular .bsx's numbers were produced, that's state you have to track yourself.
• Turning slicing on costs simulation speed (more work per timestep, times the slice count) - most motors aren't anywhere near the flux regime where it changes the answer, which is why it's off by default.