Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reliability issues (and Tech Transfer) #2505

Open
9 tasks
NathanKell opened this issue Aug 19, 2021 · 14 comments
Open
9 tasks

Reliability issues (and Tech Transfer) #2505

NathanKell opened this issue Aug 19, 2021 · 14 comments

Comments

@NathanKell
Copy link
Member

NathanKell commented Aug 19, 2021 •
edited
Loading

Think we probably need to police reliability data. Issues I'm skeptical of / worried about:

  • Are we double-dipping on failure chance? 80% cycle reliability and 80% ignition chance is 64% actual success chance, e.g. (It's actually slightly lower due to the 5s of increased failure chance)

  • If possible we should tweak the configger to take the increased failure chance in the first 5s into account. Right now it's a uniform (but inversely proportional to burn time) increase in failure chance.

  • Some configs just don't make sense. The Altair starts at like 99.8% reliability but the Antares starts very low, e.g.

  • The LR79 has a serious problem where S-3D is cheaper but has better specs, and better reliability than the config that unlocks one node later (LR79-NA-9).

  • In general, IMO we should not simply have exactly the same values for cycle reliability and ignition chance. Pressure-fed hypergolics, e.g., should have rather higher ignition chance and lower cycle reliability, and the reverse for pump-fed engines I think.

  • Another issue with ignitions: subsequent relights should probably have a higher success chance. That might need a TF change however.

  • We might want to include some level of tech transfer between branches. E.g. XLR41 data -> XLR43 -> LR79/89/105, but also LR87 tree should probably inherit from XLR43 since it does for the ECM. Antares should inherit a bit from Altair and GCRC (and probably Sergeant too). Not much, like 5% rather than 50%, but some. With TF's branch support, it will work fine, e.g. LR79-NA-13 gets 50% of previous LR79 data or 10% of LR87 data, or 20% of XLR43 data, etc.

  • Engines with tech transfer: while the reliability of a given config is calculated based on flown models of that config, that is implicitly including tech transfer in real life but not ingame: Example: Castor 1 vs XM20 config. The XM20 is quite unreliable, the Castor 1 ludicrously so even at the start (99+% reliability). But the reason few production Castor 1s failed was precisely because of the XM20 test program--which we should model by tech transfer rather than starting reliability. This is true for any engine with tech transfer. AJ10-37 to AJ10-42 is another example: AJ10-42 had a great track record in part because of all the AJ10-37 failures that gave data.

  • Tech Transfer: we should make better use of multiple branches for tech transfer. In particular, you shouldn't get the full 50% going from, say, the XLR43-NA-3 all the way up to the LR89-NA-7.1; you should get the full transfer only from the immediately prior config (maybe 2 back if they're close?), and lower values for earlier configs. We also can use this system for limited transfer across lines, i.e. some transfer between LR79, 89, and 105.

Anything else?
@leudaimon
Copy link
Contributor

We could define a consistent way to deal with engines that have too few data for a good estimation of reliabilities, I have the impression this is all over the place

@jwvanderbeck
Copy link
Contributor

Are we double-dipping on failure chance? 80% cycle reliability and 80% ignition chance is 64% actual success chance, e.g. (It's actually slightly lower due to the 5s of increased failure chance)

You have a 20% chance to fail one check and a 20% chance to fail the other. They aren't cumulative because one isn't dependent on the other. (one doesn't influence the other)

@StonesmileGit
Copy link
Member

StonesmileGit commented Aug 19, 2021 •
edited
Loading

If the probabilities are completely independent, that means you can multiply them, P(igniting) x P(burn for t seconds)

@StonesmileGit
Copy link
Member

StonesmileGit commented Aug 20, 2021 •
edited by Capkirk123
Loading

Two more things:

  • Solids shouldn't get their ingition chance changed by dynamic pressure.
  • The starting reliability of the Castor 1 is too high, it should get transfer from the first config.

@NathanKell
Copy link
Member Author

Are we double-dipping on failure chance? 80% cycle reliability and 80% ignition chance is 64% actual success chance, e.g. (It's actually slightly lower due to the 5s of increased failure chance)

You have a 20% chance to fail one check and a 20% chance to fail the other. They aren't cumulative because one isn't dependent on the other. (one doesn't influence the other)

To put this another way: say an engine is classed as "98% success chance". If you naively set both cycle reliability and ignition reliability to 98%, the actual success chance becomes (probability of ignition, 98%) x (probability of making it through the burn, 98%) = 96%. You've just doubled the failure chance. If in fact the engine is usually involved in a two-burn flight it's worse, 94.1%.

@marsh1832
Copy link

To add, they are cumulative in the sense where the ignition chance must pass before the burn chance can be checked. So the failure rate is cumulative. And as NK showed in an example of a second ignition, then that’s a third check in a row which must pass, so the mission failure rate is all three cumulative.

I love the idea of the failure rates being tuned to where the pump fed engines have a higher ignition failure but lower burn failure, and the inverse for pressure fed. Adds more character to the engine feed choice.

@NathanKell NathanKell changed the title Reliability issues Reliability issues (and Tech Transfer) Oct 1, 2021
@NathanKell
Copy link
Member Author

I have updated this issue to mention tech transfer and branches.

@NathanKell NathanKell mentioned this issue Oct 1, 2021
Merged
@Capkirk123
Copy link
Member

#2539 addresses most of these issues.
For the reliability of pump fed vs pressure fed engines, that depends a lot on the engine itself. For example, Soviet pump-fed uppers almost never failed to ignite, but had their turbopumps fail during or shortly after their burn pretty frequently. The exception being the RD-58, which explodes on ignition to this day, but is usually fine once it starts. Even solids aren't immune, some had a propensity to explode, while other would just fail to ignite.

@ec429
Copy link
Contributor

ec429 commented Dec 9, 2021

If possible we should tweak the configger to take the increased failure chance in the first 5s into account.

FWIW TestLite already accounts for this internally: if an engine has a failure chance of (say) 10% across its 120-second rated burn time, then there will be a 1.5% chance of failure in the first 5s and an 8.5% chance in the next 120s, for 10% total over the 125s.

you should get the full transfer only from the immediately prior config

Doesn't techTransferGenerationPenalty already cover that (to some extent)? (As long as the configs are listed in the right order…)

@NathanKell
Copy link
Member Author

NathanKell commented Dec 10, 2021 via email

@ec429
Copy link
Contributor

ec429 commented Dec 10, 2021

Ah fair point, you're thinking of the max transfer. But branches don't fix that either; they, like techTransferGenerationPenalty, only set the transfer coefficient. The cap (techTransferMax) is the same no matter which config the transfer is coming from.

Maybe we need to add a techTransferSourceMax, that caps the du before the branch modifier is applied, so that weaker links can't supply as much even if you have 10k on the old part.

(Either that or you're just referring to the fact that RO sets techTransferGenerationPenalty stupidly low, at 0.05. Why isn't that higher?)

@NathanKell
Copy link
Member Author

NathanKell commented Dec 10, 2021 via email

@ec429
Copy link
Contributor

ec429 commented Dec 10, 2021

Generation penalty is nothing to do with indirect transfers. Generations are the comma-separated items within a techTransfer branch. (In TL, indirect transfers don't happen at all.)

The breakage in your example only happens because the config is written backwards (#1968). LR89-NA-7.1 has:

techTransfer = XLR43-NA-1,A-6,A-6H,A-7:20&XLR43-NA-3,LR43-NA-3,LR89-NA-3,LR89-NA-5,LR89-NA-6:50

which means it gets 50% transfer from XLR43-NA-3 but only 40% (0.50 * (1 - (4 * 0.05))) from LR89-NA-6. (Under TestLite it's 30% instead (0.50 - 4 * 0.05) because I did things Differently for some reason.)

If it were written correctly as

techTransfer = A-7,A-6H,A-6,XLR43-NA-1:20&LR89-NA-6,LR89-NA-5,LR89-NA-3,LR43-NA-3,XLR43-NA-3:50

then the percentages would be the other way round and XLR43-NA-3 would be four generations away.

@NathanKell
Copy link
Member Author

NathanKell commented Dec 10, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@jwvanderbeck @ec429 @NathanKell @leudaimon @Capkirk123 @StonesmileGit @marsh1832