RustCore
Release notes
What was added to RustCore in each version, newest first.
The current release is 0.24.0, for Windows. RustCore is beta software. Installed copies from 0.3.0 on update themselves: RustCore offers the new version in the sidebar when it starts.
Version 0.24.0
Current
The Export page starts with a Rocket Salvo apps card.
- Rocket Salvo apps first on the Export page
- The Export page now starts with a Rocket Salvo apps card: save to the design library, save a prediction or test plans for RustStand, and send results to RustPEP. On the Burn page, **Save for RustStand** is now a coloured button.
Version 0.23.6
Moon cores can sit anywhere from centred out to touching the casing.
- Moon cores out to the casing
- A moon core’s offset no longer has to be less than its radius: the offset plus the core radius can be anything up to the grain radius, so the core can clear the axis and touch the casing exactly, where before every core stopped a little short of it. The offset slider runs that far, and the side view shows the propellant between the axis and the core.
- Burning area for off-axis moon cores
- The 3D burnback now measures the distance to a moon core exactly, and keeps the propellant on the far side of a core that clears the axis, which it had been leaving out. Designs whose core covers the axis are unaffected.
Version 0.23.4
No change you can see: a test now checks that the design library’s shared index stays up to date.
- The shared index is tested
- A design saved to the library now provably appears in the shared index with its id, class, peak pressure, grains and core profile, and drops out of it once deleted.
Version 0.23.3
The design library keeps a shared index that the other Rocket Salvo programs can read.
- A shared index of your designs
- Whenever you save a design, delete one or open the library, RustCore writes `Documents\Rocket Salvo\Motors\index.json`. Each entry gives the design’s id and revision, its propellant and linked case, and, as last simulated, its class, impulse, burn time and peak pressure, with the grain count, widest grain, stack length, nozzle and a short core profile. It lets RustCase and RustStand show a list of your motors without opening each one. Neither of those programs is released yet, so for now nothing you can install reads it.
- Saved designs record more of their result
- A saved design’s summary now also records the burn time, average thrust, peak pressure, peak mass flux and throat as simulated.
Version 0.23.2
The case-loads file tells RustCase the grain diameter and the length of the stack.
- Grain diameter and stack length for RustCase
- The case-loads file RustCore writes for RustCase now gives the widest grain’s diameter and the grains’ length end to end, so RustCase can size a liner and tube to fit. RustCore models no gaps between grains, so spacers and gap allowances are for RustCase to add.
Version 0.23.1
The case-loads file shrinks from several megabytes to under one.
- A leaner case-loads file
- The file RustCore writes for RustCase was 3.6 to 7.7 MB. It now keeps six significant figures, thins each profile to 100 moments through the burn and drops the indentation, coming to under 1 MB.
- Filament-wound cases
- The Case card shows a filament-wound case as such.
Version 0.23.0
A side view of the motor shows the core opening up and when the liner is first exposed, and a design can be linked to a case from RustCase.
- A side view of the burn
- The Burn page draws the motor cut along its length at the slider’s moment: the ordinary simulation above the axis and the erosive prediction below it, so you can see the nozzle end opening faster. The erosive half is the same research-only prediction as before; confirm it by static test. The case wall turns red where the flame has reached the liner, and a strip beneath says how long each point of the liner sits in hot chamber gas before burnout, naming the worst point. For a round core that is where it burns through; for a star or finocyl, its thinnest web.
- Link a design to a RustCase case
- The Design page’s **Case** card links a design to a case saved by RustCase, the case and closure designer. It checks that the grains fit the bore, the stack fits between the closures, the throat fits the nozzle carrier and the peak pressure stays under the case’s rating, offers that rating as the design’s pressure limit, and tells you when RustCase has saved a newer revision of the case. Suggestions from RustCase — a bore, a length, a rating — appear on the card to accept or decline, and nothing changes until you accept. In return, saving a design and running an erosive prediction write a case-loads file for RustCase: the pressure through the burn and, along the motor, liner exposure, mass flux and port size. RustCase is not released yet, so until it is, the card has no cases to offer.
Version 0.22.6
Edit a stack of identical grains as one, Undo and Redo get buttons, and a first run offers a place to start.
- Edit every grain together
- When every grain is the same, as in a BATES stack, the Grains card offers **Edit every grain together**: one grain and a number of grains, with each change applied to the whole stack. Untick it to change one grain on its own; it is offered again whenever the grains match. A stack of identical grains opens this way.
- Undo and Redo buttons
- Undo and Redo are now buttons in the top bar as well as Ctrl+Z and Ctrl+Y, greyed out when there is nothing to undo or redo.
- A first-run card
- The first time you open RustCore, the Design page shows three steps to start from, with a link to Help, until you dismiss it.
Version 0.22.5
The erosive-burning guide shows its figures and describes calibration as it now works.
- Figures in the guide
- The erosive-burning guide now draws its figures in place: a reference BATES motor in the base-rate step, a high-erosion reference motor in the erosive step, and the mass flux and erosive ratio along the port in “Read the along-the-core view”.
- Up to date
- Step 4 describes calibrating as it now works: choosing firings by campaign, each firing on its own motor as measured, the minimum of 1000 samples a second, the throat before and after, and **Send to RustPEP**, which RustPEP declines if the law has changed since. Throat erosion is no longer listed as not modelled.
Version 0.22.4
A newcomer’s first screens are clearer, and RustCore opens on a design whose erosive prediction works straight away.
- Opens on a BATES stack with Wimpy Red
- RustCore now opens on the BATES stack with Wimpy Red, so the erosive prediction and the reference test motors work from the first screen. The double taper keeps its constant-rate propellant and is one click away, and the New dialog says which propellant each template uses.
- Quieter and tidier
- “Not in RustPEP’s library” was a red box on every new design, for a propellant that simply came with RustCore; it is now a quiet line that says how to change Wimpy Red, and it follows a change of propellant instead of describing the previous one. On the Erosive inputs panel, symbols no longer run into their labels, values read to four significant figures, and a row that is already met offers “About this” instead of “How do I get this?”. The Reference test motors card follows your chosen units throughout. The greyed-out “Save test plans for RustStand” says why it is unavailable, and plain numbers on the Propellant page show four significant figures. Help’s opening workflow starts from Wimpy Red and covers erosion, the reference motors and calibrating from firings.
Version 0.22.3
Grain temperature in °F or °C, and erosive calibration warns about firings recorded too slowly to fit.
- A minimum sample rate for erosive firings
- When you pick a firing for an erosive calibration or a validation, RustCore warns if its pressure was sampled slower than 1000 samples a second, saying the rate and the minimum: the early, most erosive part of a small motor’s burn holds too few samples to fit at less. Base-rate firings have no minimum. The firing picker marks a slow firing and leaves it unticked. RustStand will warn against the same minimum when it arms.
- Grain temperature in your units
- The grain temperature at firing is entered in °F or °C, following your chosen units, instead of kelvin. A value that cannot be a grain temperature is refused, with what it was read as.
- Wimpy Red’s description corrected
- The app now describes Wimpy Red’s burn-rate law as fitted from four BATES motor firings at 400 to 1000 psi. 0.22.1 and 0.22.2 had called them strand-burner firings, which nothing recorded.
Version 0.22.2
The throat can open as the motor burns, and a calibration or validation can be sent to RustPEP instead of copied by hand.
- Throat erosion
- Under **Nozzle settings**, choose how the throat opens during the burn: not at all, at a steady rate, by openMotor’s pressure model, or from the throat diameter you measured after a firing. Both the ordinary simulation and the erosive prediction follow the choice, so the two stay comparable. An openMotor `.ric` motor keeps its erosion coefficient when imported and carries it back out on export.
- Send to RustPEP
- Calibrate and Validate can now send their result straight to RustPEP with **Send to RustPEP**, rather than leaving you to copy constants across by hand. RustPEP decides what to do with it: each arrives under **Suggestions** to accept or decline on its own. It needs RustPEP 0.66.0 or later, installed and started at least once — RustPEP advertises that it takes these only after it has run — and the same `DocumentsRocket Salvo` folder, so the same machine or a synced Documents. RustPEP need not be running when you send: the suggestion waits and is picked up when RustPEP next starts or comes to the front. To accept it, the recipe it belongs to has to be open, and RustPEP offers to open it if it is not.
- A search that did not settle is never shown as confirmed
- A calibration whose search ran out before it converged is not presented as a confirmed result, in RustCore or in RustPEP. It is the best the search reached, not the best there is, and both programs now say so in the same way.
- Ready for RustStand, and waiting
- Two things are built and have nothing to act on yet. Calibrate and Validate can list RustStand’s published firings by campaign, but no released RustStand publishes any, so the picker says there are none yet and **Choose files instead…** works as before. And where a firing names the batch it was mixed from, RustCore reads that batch and uses its measured density in place of the recipe’s, refusing a set of firings that spans two batches — which can only come into play once RustStand publishes firings that name one.
- Fixes
- The Design page could list the *previous* propellant’s missing inputs after you switched propellant. A throat diameter recorded from a firing now overrides a design that sizes its own throat, rather than being ignored. The reference-motor card explains a constant-rate propellant instead of logging an error. The help gains new sections with diagrams.
Version 0.22.1
A new design starts from a real propellant instead of a rough example.
- New designs start with Wimpy Red
- A new design now starts with **Wimpy Red**, a real AP composite with a burn-rate law fitted from four BATES motor firings at 400 to 1000 psi, in place of the rough KNSB example it used before. RustPEP 0.67.0 and later carry the same propellant under the same identity, so a design begun in RustCore links to that recipe once you add it to RustCore’s library from RustPEP’s Export page. Templates size their throat for 600 psi, which sits inside the range Wimpy Red’s law was fitted over rather than outside it.
- Two things it stopped saying wrongly
- A propellant brought from RustPEP no longer has its thermochemistry treated as unrecorded, since RustPEP recorded it. And “Not in RustPEP’s library” no longer claims the recipe was replaced, which it had not been.
Version 0.22.0
A saved design keeps an identity of its own, so a test can say which design and which revision it was fired on.
- A design knows which design it is
- A saved design now carries a permanent id and a revision that rises only when the motor itself changes — not when you rename it or move it. **Save As** makes a copy with a new id of its own, so a copy is a copy rather than a second claimant to the same identity. The Open dialog shows each design’s revision and points out copies. A test plan records the design and propellant revisions it was made against.
- A firing belongs to the design it was fired on
- Calibrate refuses a firing recorded on one of your designs unless that design is the one open. Before, it used whichever design happened to be open, which quietly fitted constants against the wrong motor.
- Saves that survive being interrupted
- A design is written to a temporary file and renamed into place, so a save interrupted part way leaves the previous file intact rather than a half-written one.
Version 0.21.8
The fictitious-data banner stops appearing over your own propellant.
- A missing source is not made-up data
- A prediction no longer carries **FICTITIOUS TEST DATA** over your own propellant merely because one input has no recorded source. It names the unrecorded input in a plain caution instead, and the banner is kept for what it is for: data that was made up. Validate also no longer describes a firing with no test record as “synthetic”. The distinction matters — a value you measured but did not note the source of is not the same as a value nobody measured, and treating them alike taught people to ignore the banner.
Version 0.21.7
Repository documents only. Nothing a user sees changed.
- Housekeeping only
- The contract documents no longer describe the prediction export as unwritten, since it is written. Nothing in the program changed. It is listed because every version is listed.
Version 0.21.6
An internal document caught up with RustPEP. Nothing a user sees changed.
- Housekeeping only
- The handoff document that tracks the link between RustCore and RustPEP still said the deep link had not shipped. RustPEP 0.64.0 shipped it. Nothing in the program changed.
Version 0.21.5
Important: on a firing that peaked below about 2 MPa, the burn window began before ignition, so every calibration and validation made from it was out of step with the trace.
- Redo a calibration or validation made on a low-pressure firing
- If you calibrated or validated using a firing that peaked below about **2 MPa (290 psi)**, redo it in this version or later. Any value that came out of such a calibration — a fitted beta, G_th, k_G or any other constant — and any validation pass or fail should be treated as untrustworthy until it has been run again. If you saved such a value to a propellant, or sent it to RustPEP as a suggestion, re-fit it there too.
- What went wrong
- The burn window was cut at 5 percent of the absolute peak pressure. A quiet record sits near 101 kPa, which is 5 percent of 2 MPa, so on any firing peaking below that the cut fell *below atmospheric* and every sample recorded before ignition passed it. The window’s first sample is also where RustCore lines the prediction up with the measurement — t = 0 of the prediction sits on it — so the prediction was laid against the trace shifted by the whole quiet stretch. Calibrate then fitted its parameters to that misaligned comparison, and Validate measured its peak and integral errors on it. The cut is now 5 percent of the rise above ambient, which is what NFPA 1125 means on an absolute trace.
- How far it reached
- Calibrate and Validate in every build before this one: fitting from traces arrived in 0.17.0 and the Burn page button in 0.19.0. It needed a firing loaded from your own `samples.csv` in absolute pascals, peaking under about 2 MPa, with quiet samples before ignition. A record that starts at ignition lined up correctly, firings well above 2 MPa were never affected, and neither were RustCore’s own synthetic tests — which is why none of them showed it. In practice it took a CSV written by hand with RustCore’s exact column names, so it may have reached nobody; that cannot be confirmed, which is why the warning is here rather than left out. RustStand found it in its own export code and reported it.
Version 0.21.4
The help says how to lay out a firing so Calibrate can find the motor it belongs to.
- How to hand Calibrate a firing
- A paragraph under **How to get a calibration**: keep each firing in its own folder beside its test record, so each trace is predicted on its own motor. A trace with no record beside it is predicted on the design open on screen. This describes what works today — RustCore’s own test files, or a bare CSV.
Version 0.21.3
Groundwork for pairing each firing with its own motor, for when RustStand can export them.
- Reading a test record written by RustStand
- RustCore’s trace loader only ever read its own synthetic test files, so a real firing exported by RustStand could not be paired with the motor it was fired on — and scored against the wrong motor, a two-design calibration puts beta near 90 instead of 70. Now a `rocketsalvo.erosive` test record sitting beside a `samples.csv` supplies the design, throat diameter, ambient pressure, test type, name and provenance. It is refused if its sample rate disagrees with the CSV, or if a folder holds several records and none is named after the CSV. Beside RustCore’s own test file it fills in only what that file left unsaid.
- Preparation, not something new to use
- RustStand is building the export that produces these folders, and RustStand is not yet available, so nothing changes for anyone today. What you can do now, and could before this version, is calibrate a single real firing from a `samples.csv`, which RustCore predicts on the design open on screen — which is the right motor for a one-design calibration. The gain arrives with a two-design calibration, where each firing has to be matched to the motor it came from.
Version 0.21.2
A peak pressure that falls once erosion is included is no longer presented as good news.
- A lower eroded peak, explained where you see it
- When erosion lowered the peak pressure, the Design page tile read “with erosion: … −8%” in a neutral colour, which reads as an improvement. It is not one: erosion is worst near the nozzle, so that end burns through first and the late pressure rise never happens. The note under the verdict now says so, which is what the Burn page already explained and the Design page did not.
Version 0.21.1
A provisional method no longer leaves the Design page predicting for ever, and the two apps are linked end to end.
- King no longer re-enables Predict
- Fixed: with a prediction live, switching to King — which computes nothing — re-ran the prediction, and its failure re-enabled the Predict button and left the Design page reading “Predicting…” for good. A provisional method is now never re-predicted, the checklist decides the button’s state, and the Design page says plainly that the method computes nothing. This was found by the full screenshot run of 0.21.0, which was built and deliberately never published.
- Push to RustPEP works end to end
- With this version and RustPEP 0.63.0 or later, a value entered in the Erosive inputs panel goes to RustPEP as a suggestion to accept or decline, rather than being text telling you what to type. When RustPEP’s library carries the value, RustCore clears its own copy — whatever the revision, since RustPEP keeps the revision number for unchanged content. RustCore also says when RustPEP’s library holds a newer revision of the propellant a design uses, lists what changed, and updates in one click.
- Smaller things
- The reference-motor card explains that a propellant burning at a constant rate — the starting template’s — cannot be sized, rather than failing without saying why. Every control on the Erosive inputs panel and the reference-motor card now has a tooltip.
Version 0.21.0
The Design page shows every number with and without erosive burning, and shaped cores get a cross-section drawn to scale. Built but never published.
- Both answers, never one
- The Design page’s numbers — designation, peak pressure, burn time — came from the standard simulation, which leaves erosive burning out, and nothing said so. A line under the verdict now says whether the numbers include erosion, says it more firmly as the flux nears the limit, and offers **Predict with erosion** there and then — or, if the method still needs inputs, “2 inputs needed — show me”, which goes to the first one. Once predicted, each affected tile gains a second line, such as “with erosion: 559 psi +15%”, red where it got worse. Both are shown rather than a switch, because a switch hides one answer and makes you remember which you are looking at.
- The limit check judges both
- A pressure over the case limit with erosion is a problem even when the standard simulation comes in under it. The prediction also stays live, re-running as the design changes rather than being quietly dropped, until you press Stop.
- Cross-sections for moon and D-grain cores
- Drawn to scale, with a slider that moves the shape live and the web thicknesses given in words.
- Why it was not published
- The full screenshot run of this build found the King bug fixed in 0.21.1, so 0.21.0 was never put on the site. Everything above reached users in 0.21.1.
Version 0.20.6
A review of the Burn page found ten bugs, most of them buttons that did nothing or worked from the wrong numbers. Built but never published.
- Predict and the checklist now read the same inputs
- Fixed: Predict built its own inputs from the propellant, so it ignored every value entered in the Erosive inputs panel, and Lenoir-Robillard and Ma refused any propellant without a stored grain temperature — the normal case since RustPEP 0.59, which correctly treats grain temperature as belonging to a firing rather than to a propellant. The checklist meanwhile showed it as defaulted. So the checklist said ready and Predict said not recorded, about the same propellant. Every command now goes through one resolver, which the checklist also reads.
- The Erosive inputs panel rendered nothing
- Fixed: the command flattened the readiness answer while the panel, the drawer and the matrix all read its rows, so since 0.20.0 the panel threw on every render and the drawer showed a headline over an empty checklist. The shape is now pinned by a test.
- Alpha, when it has to be supplied
- Fixed: Lenoir-Robillard with alpha set to be supplied, and none supplied, read “Can predict” with alpha itself marked met and computed. Readiness now decides the mode first, and the registry publishes the condition on the constant so that no reader has to infer it.
- Why it was not published
- This build was superseded by 0.21.0 and 0.21.1 before it could go out. All of it reached users in 0.21.1.
Version 0.20.5
One answer to “what is missing?” instead of three. Built but never published.
- Three implementations, two of them deleted
- RustCore shipped three implementations of readiness. The Erosive inputs panel called the shared function the three apps agree on; the guide drawer still called an older one with no notion of a run condition, which counted grain temperature as missing — three missing inputs where the panel said two; and the test harness carried a copy of that same older command, so its screenshots would have shown the wrong answer looking perfectly right. The second and third are deleted rather than reconciled: the drawer now renders the shared rows read-only and points at the panel for the actions, and the harness calls the shared function.
- How it was found
- By a question rather than a review: the website session asked whether the guide drawer was the dead-end panel under a new name. It was not — but checking the question found this.
Version 0.20.4
The two pressure curves in an exported prediction never shared a time base, and the file said they did.
- A claim that was technically true and substantively false
- Fixed: an exported prediction said its eroding and non-eroding pressure curves were decimated the same way, with the same stride, and so could be compared point by point. On the published worked example one curve holds 291 points from 1.873 ms and the other 256 from 4.749 ms, and not one index-aligned pair shares a time. With fewer points than the target the stride is one on both, so neither is decimated at all — and the two marches step at different times regardless, because each step is one web increment of the fastest-burning station and the eroding motor burns faster. Same stride, different grids. RustStand had built a reader on that claim before checking it.
- The baseline is deliberately not resampled
- The fix is not to interpolate the baseline onto the eroding times. That field should hold what the baseline simulation actually produced, and filling it with interpolated values under the same name is how a third program comes to treat them as simulation output. Instead the document now states the fact: a field naming each curve’s time base, and a note telling a reader to interpolate, and not to subtract index-wise or extrapolate past the point where the baseline motor has stopped.
- A test that was checking each curve against itself
- The test that should have caught this compared each curve’s span against its own burn time, which passes whatever the times are. It now pins the honest claim instead. RustStand’s own check reporting that the curves do not share a time base, on all four files, was it working rather than being strict.
Version 0.20.3
Two defects in the first shared fixture set are recorded rather than quietly corrected.
- A note, not an edit
- The five synthetic erosive tests of the first shared fixture set came from the same generator as the second, so they carry the same two defects: a declared burn time that can outrun its own trace, and negative absolute pressures in the dead tail. The fix is deliberately switched off for the older set, because its checksum is pinned in all three apps and in each of their status files — correcting the bytes would break an agreement in order to fix a file that nothing currently depends on being right in that particular way. The note also records what the defects do not affect: no golden value, no pressure-and-rate point, no fit.
- A trap worth knowing
- Related, and a property of the criterion rather than of these files: a burn-time window taken at five per cent of peak pressure is unsafe once five per cent of the peak falls inside the baseline noise.
Version 0.20.1
A caution printed on every prediction since the start was measurably false, and is corrected.
- Nothing is absorbed, and nothing is counted twice
- Every prediction used to carry the warning that a burn-rate law fitted from eroding firings already holds some of the effect, so an erosive model on top counts it twice. RustStand measured it and it does not hold. Burn time tracks the slowest part of the grain, and erosion spends the aft web first, so the aft end burns through while the head end runs on at very nearly its unaffected rate — on a strongly erosive firing the measured rate comes back at 0.993 of the non-erosive law, slightly low rather than high. The advice to fit the burn law from low-flux firings and the erosive parameters from high-flux ones stands, for a better reason: a burn law is meant to describe the propellant with nothing flowing over it, and a firing with crossflow is not a measurement of that. What the erosion does inflate is the measured pressure, which shifts each point on the log-log plot and biases the law slightly downward. Corrected in the prediction cautions and in the app’s help.
- The demo runs as a test
- Every step of the shared worked example that is RustCore’s now runs as a test with the example’s own numbers, so “the demo passes” is something you can check rather than something somebody said.
- A method’s class note, when it is informative
- Fixed: a method that applies to one class of propellant — ammonium perchlorate composites, say — said so only when refusing. Saying it when the propellant *is* one is the case that tells you what the method stands on, and that is now when it appears.
Version 0.20.0
The erosive-burning dead end is gone: every missing input now leads somewhere, Ma (2020) computes, and King is registered as provisional.
- A checklist instead of a dead end
- The old panel named four problems and offered no way to fix any of them. It is now a checklist where every missing row leads somewhere, and a test asserts that no message anywhere tells you an input has no place to enter it. Where a value is RustCore’s to hold rather than RustPEP’s, there is somewhere to enter it, badged as not in RustPEP, with a way to push it back.
- Four things that were wrong about what a model needs
- Grain temperature was treated as a propellant property; it is a run condition, because the same propellant fired warm and cold has two values. One hardcoded flag answered four different questions about a model’s constants and answered no to all of them, so Mukunda-Paul, which needs nothing calibrated, and Ma, which has no constants at all, were both refused — each constant now follows a declared policy. And each app worked out what was missing on its own; one shared function now does it, with the three apps checking a canonical file against its hash rather than agreeing in prose.
- Re-add your propellants after updating
- Earlier builds kept only the propellant fields they already knew about, so adding a propellant to the RustCore library — or saving one — could quietly drop the newer erosive records it carried, with nothing to say it had happened. This build keeps everything a file holds, named or not, pinned by a test that adds field shapes no build has seen and checks each one survives. No download from this site was ever affected, because the RustPEP published here never reached the versions that write those records. If you built RustPEP yourself or ran a CI build, re-add your propellants from RustPEP once you are on this version and the full records come back.
- A stale answer that outlasted the feature
- Fixed: the question “can this model compute?” was hardcoded to no, with a comment saying no model had a RustCore calculation. The coupled march had landed in 0.16.0 and a test had pinned the stale answer, so for three releases the Burn page drew predictions while the programming interface reported that none was possible.
- Ma computes; King is registered and computes nothing
- Ma et al. (2020) is implemented and all twenty of its reference points match to one part in a million, including the Reynolds number, the heat-transfer coefficient and the regime named at each. King is registered as provisional and computes nothing at all: nobody has read the papers, so there are no equations to implement. It carries its requirement list so you can see what it would need, and that it is not ready, rather than finding it missing. Everything here remains research only — no method’s citation has been checked against its source paper, nothing has been validated against real firings, and fitting a method to your own data does not establish that the method describes a motor.
Version 0.19.1
Erosive prediction works on star, finocyl and moon grains, which it had refused outright.
- Shaped grains can be predicted
- Two of the methods refused to predict a star, finocyl or moon grain at all: a little before burnout they reported that the port hydraulic diameter must be above zero, and the whole run was lost. A shaped slice takes its wetted perimeter from its burning area, and once that slice has burnt through to the casing there is no propellant left to draw a wall — so the perimeter went to zero while the port was in fact at its widest. The perimeter is now floored at the circle of equal area, which is the least any shape can have and the exact answer for a slice burnt through to a round casing. Live slices are untouched: a star at ignition has well over twice the circle’s perimeter.
- If you hit that error, your design was fine
- There was no way to read the old message as RustCore’s fault. It looked like a problem with your motor or with the method, and anyone who changed a core diameter or a parameter set to make it go away was chasing a fault that was not theirs. Install 0.19.1 and run the prediction again; nothing else is needed, and your design and propellant did not need changing.
- Round cores are unchanged, bit for bit
- The floor only raises a perimeter that is below the circle of equal area, and a round port’s perimeter is exactly that circle, so the arithmetic for a round core is unchanged rather than merely close. All 64 values of the shared fixture set pass unmoved and the synthetic test firings regenerate to the same bytes. No prediction you have already run comes out differently.
- Why no test caught it, and what covers it now
- Every motor in the 64 golden values and the five synthetic firings is a round core, so the verification was strong exactly where it was built and silent everywhere else — worth knowing when you judge how much to trust the along-the-core view on a shaped grain. Three tests now close that gap, the firmest being a bound rather than a case: the wetted perimeter can never fall below the equal-area circle, at any web, on any shape. The others check that a burnt-through slice keeps the casing bore, and that a star and a finocyl predict end to end with all four methods.
- A clearer message when a prediction cannot settle
- The coupled march can run away instead of settling — each pass raises the ratio, which raises the flux, which raises the ratio. The first thing to meet an impossible pressure was the burn law, so you were told the propellant’s own burn rate must be above zero, which says nothing about what happened. It now stops at a pressure no chamber holds and says that the design and these parameters together have no steady state, giving the pressure the motor would reach without erosion for comparison. Both messages are in the methods’ troubleshooting tables.
Version 0.19.0
Fit a method’s erosive parameters to your own static-test traces, from the Burn page.
- Fit from tests
- “Fit from tests…” on the Burn page takes one or more samples.csv traces from your static firings and fits the selected method’s parameters against the whole pressure curve, not a summary figure. It shows the parameters with their units, the residual as a percentage of peak pressure with the sample count behind it, and the flux and pressure range the fit actually covered, so the quality of the fit is visible rather than asserted. “Predict with these” then runs the prediction on the fitted values, and the card says it is using them rather than the propellant’s own.
- It refuses what it cannot judge
- A base-rate firing is turned away by name: a low-flux firing carries no information about erosion and would pull the fit toward nothing. A method whose constants are published has nothing to fit, and a trace with uneven sample spacing is refused rather than quietly fitted against a stretched time axis. A fitted value is shown to the precision that carries the answer, so you can see whether the fit found 2.5e-4 or 2.4987e-4.
- Where fitted parameters live
- The parameters are not written into the propellant. RustPEP owns what a formulation carries, so the card says so and tells you to enter them there to keep them.
- No erosion is a result, not a blank
- The Along the core view used to look the same whether you had not predicted at all or had predicted and the method found no erosion. It now says, for example, that the method predicts no erosive burning in this motor, and explains that this is a result rather than a failure.
- Still research only
- Fitting a method to your traces does not establish that the method describes a motor. No method’s citation has been checked against its source paper, and nothing has been validated against real firings. Confirm by static test.
Version 0.18.0
An Erosive Burning guide, with a checklist that tells you what your propellant is missing and where to supply it.
- The Erosive Burning guide
- A “?” beside the method picker and another beside the results open the guide in a side drawer, which leaves the page behind it usable. It holds a page for each method saying plainly what it is for and what it cannot do, an end-to-end walkthrough, and a glossary shared with RustPEP and RustStand.
- The checklist
- The live tab lists every input the method you picked needs, whether this propellant has it, the value with its unit, where that value came from, and for anything missing, where to go and supply it. It is built from the method registry rather than a hand-written list, so a method added later needs no change to the program. A parameter that does not apply under your current settings says so, rather than being reported as missing.
- What the walkthrough leads with
- The burn-rate coefficient and exponent must come from low-flux firings and the erosive parameters from high-flux ones. Mixing the two campaigns makes the burn law absorb the erosion, and every model then counts it twice.
Version 0.17.0
Groundwork for fitting erosive parameters from static-test traces. Not yet reachable from the program.
- Fitting from measured traces, under the hood
- RustCore can now fit a method’s parameters from static-test traces, against the whole pressure curve rather than against summary numbers. There is no way to run this from the program yet: the calculation exists and is tested, but nothing in the app calls it, so a method needing fitted parameters still depends on values you supply. Two parameters fitted to two tests would be exactly determined: it would always succeed, report no quality, and could not be seen to be wrong. Against the traces the same two parameters are over-determined thousands of times over, so the residual means something.
- A residual that can be judged
- On reference data the fit recovers the parameters to within 0.04%, and the residual that remains is exactly the noise the traces carry — as good as the data allows and no better. Fitted against the wrong motor the residual rises about fiftyfold, so a mislabelled test shows up instead of returning a confident wrong answer. A fit to synthetic traces is recorded as synthetic however small the residual: fit quality is not provenance.
Version 0.16.0
RustCore predicts erosive burning, and draws the prediction beside the standard simulation.
- Predict on the Burn page
- Pick a method on the Erosive burning card and press Predict. The coupled march runs: each station along the core burns at its own rate, and the chamber pressure follows the burning area weighted by erosion rather than the plain Kn. The result is drawn beside the standard simulation and never in place of it — a dashed curve in its own colour on the thrust and pressure charts, with the burn-rate ratio along the motor in the Along the core view and the port drawn as the prediction has it, since an eroding motor’s port is wider toward the nozzle.
- A prediction is not the baseline with bigger numbers
- Where the predicted peak pressure comes out below the no-erosion figure, the card says why. Erosion is worst where the flux is highest, near the nozzle, so that end of the grain burns through first and the late rise in burning area never happens. The motor is in worse shape, not better. Peak pressure, flux, burn time and impulse are each shown against the no-erosion figure, with the method’s cautions beneath. A method that predicts no erosion at all says so and draws no second curve.
- Research only
- No method’s citation has yet been checked against its source paper, so every method is marked unverified. A prediction carries the provenance of the inputs its own method needed, and shows a banner when any of them is fictitious or synthetic. Do not design a motor from these numbers; confirm by static test. A prediction is never saved with the design and is dropped as soon as the design changes under it, so it can never be shown against a motor it was not computed for.
Version 0.13.0
Reads the properties, burn-rate laws and erosive parameters of RustPEP 0.46.0 and later.
- Lenoir-Robillard runs from a propellant file
- The solid-phase properties a model like Lenoir-Robillard needs had nowhere to live in a propellant file, so it could only ever run from a fixture. RustPEP 0.46.0 gives them a home and RustCore now reads it, so the model runs end to end from a propellant you published. A pinned value is preferred over the plain field, because only the pin carries its origin, and a pinned value that disagrees with its plain field is reported rather than silently chosen.
- Several burn-rate laws, and erosive parameter sets
- A propellant can carry several burn-rate laws with one active, each with its reference pressure, valid range, conditioning temperature, R² and origin, and it can carry a method’s fitted parameters. A parameter set for a method this version of RustCore does not have is kept rather than refused.
- Older files keep working
- All of it is optional and stays inside file version 3, so a propellant written before RustPEP 0.46.0 reads exactly as it did, and no RustPEP release can lock you out of RustCore.
Version 0.12.1
The method registry is written where the other apps can actually find it.
- Published where apps can read it
- RustCore now writes the erosive-burning method registry to the RocketSalvo folder under Documents on startup, beside the Propellants folder, and only when it has changed. Until now the file existed only in RustCore’s own source, so on a real machine RustPEP saw no registry at all. RustPEP 0.48.0 and later read it from there.
- Parameters carry their type
- A parameter is now declared as a number or as a choice with its allowed values, and prose has a field of its own rather than sitting where a machine-readable origin belongs. A reader can also tell that a parameter matters only under a particular setting, instead of having to read that in a note.
Version 0.12.0
A correction to the aft-end mass flux on grain stacks with uninhibited ends.
- Aft-end mass flux corrected
- On a grain stack with uninhibited ends the aft station’s mass flux read about 4% high — on the shared test motor, 513 kg/(m²·s) where the right answer is 492. If you reopen a saved design of that kind you will see a slightly lower peak flux than before. The old figure was the conservative one, so nothing you designed under it becomes less safe. Two faults were behind it: the last grain’s aft face burns into the plenum ahead of the nozzle rather than through the core, so it is not upstream of the aft station; and the flow area there counted the annulus the receding face has vacated as port when it is plenum. The hydraulic diameter at that station had the same fault and is corrected with it. An end burner is deliberately not treated this way, since its aft face is the whole cross-section.
- Checked at every station
- All 40 station values of the shared fixture set now match an independent reference to one part in a million, and a second test ties them to the real solver: simulated Kn within 0.5%, chamber pressure within 1%, and the aft mass flux and hydraulic diameter within 1.5% and 1%.
Version 0.11.2
The erosive-burning method registry the other apps read.
- A registry the other apps can read
- RustCore publishes a registry listing each erosive-burning method, the inputs it needs and whether an estimate will do. RustPEP 0.48.0 and later read it to show what a method still needs from a formulation, so neither app hard-codes the other’s list and a method added here appears there without a new release of either.
Version 0.11.1
The true hydraulic diameter for star, finocyl, moon and D grain cores.
- Hydraulic diameter from the real perimeter
- The erosive-burning models take the hydraulic diameter, four times the port area over its wetted perimeter. RustCore had only the equivalent round diameter, which is the same thing for a round core but not for a shaped one: a star’s hydraulic diameter is about 32% below its equivalent round diameter at ignition. A D grain’s port is now handled exactly, as a circular segment, and a star, finocyl or offset moon takes its perimeter from the burning area, within about 1.1% of the analytic outline. No round motor’s numbers change.
Version 0.11.0
The erosive-burning method library, checked against the shared fixtures. Nothing is predicted yet.
- Four methods, none of them running yet
- RustCore can work out the erosive burn-rate ratio at a station for four methods: a control that applies no erosion, Lenoir-Robillard, Mukunda-Paul and a threshold-linear empirical fit. In this version nothing calls them — no simulation, no design and no prediction — and the Burn page is still the baseline alone. Each method refuses with the exact list of what it is missing rather than guessing.
- Checked against the shared fixtures
- All 24 point values of the shared fixture set match an independent reference to one part in a million. No method claims a citation anybody has checked, and none publishes a validity range anybody has read from a paper.
Version 0.10.2
The Mukunda-Paul erosive burning model needs no constants of its own.
- Mukunda-Paul inputs
- The erosive burning card had listed Mukunda-Paul as needing constants fitted to your propellant. Its constants come from a single fit across many propellants in the original paper, so it needs only the burn law, density and chamber gas viscosity, all of which a propellant from RustPEP 0.42.0 or later carries. It now shows its inputs as all present. RustCore still does not calculate erosive burning.
Version 0.10.1
Fuller tooltips throughout.
- Tooltips
- Every tooltip now says what the control does, its units and what it affects, across the nozzle, propellant and burn-rate fields, export buttons, study settings, core shapes, grain controls and the save menu. Each “?” link names the Help section it opens. Result tiles, Burn page chart titles and the Propellant card explain what each number is.
Version 0.10.0
Opens propellants from RustPEP 0.43.0, with their composition.
- RustPEP 0.43.0 propellants
- RustPEP 0.43.0 saves propellants in a newer file version that RustCore 0.9.0 and earlier refused. RustCore now opens them and keeps what they carry: the ingredients, particle size grades, binder and bonding agent, each test firing’s peak mass flux, and where the burn-rate data came from. The Propellant page shows the composition, read-only.
- Erosive burning checks use the real composition
- The erosive burning card now checks the propellant’s actual composition against what each model needs. For example, AP grades must add to 100% with sizes you entered or nominal sizes, the binder must be confirmed, and the bonding agent must be recorded (“none” counts). It also states the test firings’ mass flux range, whether their pressures were measured, and this design’s peak flux.
Version 0.9.0
Groundwork for erosive burning research. RustCore does not calculate erosive burning yet.
- Erosive burning models, documented only
- The Burn page has a new Erosive burning card listing four published models: Lenoir-Robillard, King, Mukunda-Paul and Ma et al. (2020). Each shows its references, what it needs and its limits, and whether your propellant has the data it needs. None of them is calculated yet, and the simulation results are unchanged.
- Research results
- Modeled or measured erosive burning results produced elsewhere can be added to a design as .rcresult files, with their source, assumptions and uncertainty. They are drawn beside the normal curves, dashed for modeled and dotted for measured, and labelled Research only, Validated within stated scope or Measured. Demonstration data is always labelled as such.
- Double-counting caution
- Every model shows a caution that a burn rate fitted from your own firings may already include erosive burning.
Version 0.8.1
Opens propellants from RustPEP 0.42.0.
- RustPEP 0.42.0 propellants
- RustPEP 0.42.0 saves propellants in a newer file version that RustCore 0.8.0 and earlier refused. RustCore now opens them and keeps the extra details they carry: the propellant’s identity, its revision and the exhaust gas properties at the chamber, throat and exit. The gas properties are stored for later use and do not change any results yet.
- Revision shown
- The Propellant card and the Propellant page show the propellant’s revision.
Version 0.8.0
A Studies goal that aims the peak mass flux at a number you choose.
- Peak mass flux closest to a target
- A new Studies goal finds the core whose worst mass flux comes as close as it can to your target without going over it. Lowest peak flux opens the core as far as the ranges allow and gives up impulse. Aiming at a flux you can live with keeps that impulse. When several designs land within half a percent of the target, the one with the most total impulse wins.
- Target checks
- The result says whether it reached the target, and the page warns when the target is above the flux limit.
Version 0.7.0
The Design page shows the propellant you are working with.
- Propellant card
- A Propellant card now heads the results on the Design page. It shows the propellant’s name, burn rate, density, delivered c* and where it came from, and marks it Example when it is a template’s stand-in.
- Edit or change it in place
- Click the name to edit the propellant, or press Change… to pick another from the library or open one from a file. Ctrl+Z undoes the change.
Version 0.6.0
End burners, and a warning for a nozzle exit too large for its throat.
- End burners
- A new Solid section shape and an End burner template. The grain burns from its nozzle end only, and that end can be flat or have a cone or drilled hole for more thrust at ignition. openMotor export writes it as an End Burner grain.
- Nozzle exit check
- A nozzle exit too large for its throat now says so and suggests an exit size.
- Mandrel units
- The mandrel note uses the chosen units.
Version 0.5.0
Longest-burn studies for sustainers, and a grey and tan 3D model.
- Two new Studies goals
- Longest burn and Burn time closest to a target, for sustainers such as D grains and moons.
- Average pressure
- The result table shows the average pressure and warns when it falls below the pressures the burn rate was fitted from.
- 3D model
- Burning propellant is now grey, and inhibited surfaces, the outside and any inhibited end, are tan.
Version 0.4.0
A design library.
- Design library
- Open lists your designs in Documents\Rocket Salvo\Motors, newest first, with each motor’s class, size, propellant and impulse; Browse opens a file from anywhere else. New designs save to that folder unless you choose another.
- Propellant warnings
- Results now warn when a design still uses a template’s example propellant, and the motor tile names the propellant in use.
Version 0.3.0
RustCore updates itself.
- Automatic updates
- RustCore now updates itself from rocketsalvo.com, as RustPEP does. When a new version is out, the sidebar offers to install it and restart, with a note of what is new, and Help › About has Check for updates. Unsaved work is offered a save first.
- Code signing
- The installers are code-signed.
Version 0.2.0
The D grain.
- D grain
- A flat slot down the grain, where only the flat burns. It can taper so the flat moves along the grain. It has its own 3D model, mandrel and pulling plan, exports to openMotor as a D Grain (and imports from it) and to BurnSim, and works in studies.
- Studies
- Range fields no longer show rounding noise such as 118.9999.
Version 0.1.0
First alpha.
- Core design
- Round, star, finocyl, moon and tapered core sections, full burnback, and mass flux along the core.
- Studies
- Find the best core within the flux limit.
- Models and exports
- The 3D model and mandrel, and exports to openMotor, BurnSim, .eng, STL, STEP and CSV.
- Propellants
- The propellant library shared with RustPEP.
Get the current version.
Version 0.24.0 for Windows.