Why does PEGAS implement UPFG instead of simply integrating the relevant equations?

[nbelakovski]

I hope this question isn't too naive, but I've been studying optimal control and I've come to understand that PEG and UPFG are approximations of certain thrust integrals. This raises the question, why not simply do the integrals, i.e. numerically via some kind of quadrature? I would think that the resulting code, while perhaps more compute intensive, would be simpler and more accurate. It's obvious why PEG/UPFG didn't do this, they simply didn't have the compute power. But I think we have enough compute power to do this sort of thing today, particularly if a certain amount of care is taken to optimize the quadrature in a way that's computationally efficient, even if some accuracy is sacrificed, and also if we take the approach that PEG once took of doing the computer intensive calculations once every ~2 seconds and using intermediate values between calculations.

What do you think?

[Noiredd]

PEG and UPFG are approximations of certain thrust integrals.

Not exactly. UPFG is a predictor-corrector type of solver for a specific problem that uses thrust integrals at one step of the calculation. (Note that we calculate those integrals explicitly.)

why not simply do the integrals, i.e. numerically via some kind of quadrature?

Good question nonetheless. I can think of the following reasons:

1. When I started to work on this, my knowledge on control theory was very elementary (I passed a 101-level course in college lol). I wouldn't even know where to start writing a numerical solver, honestly. By contrast, equations for PEG were really easy to follow and implement, and by the time I got to UPFG I was invested in this thing, enough to crawl through those arcane texts from NTRS.
2. UPFG accuracy is just good. From the POV of someone who simply wants to play KSP/RO and e.g. go to the ISS or Moon or Venus - you don't really need a perfect 180x180km parking orbit, 177x181 will do just fine. "If it works, don't fix it."
3. kOS does not have all the compute speed of your physical CPU. It runs at some number of steps per the in-game physics tick, emulating the compute speed limitations of early guidance computers. Even if you try to crank it up to some large value, you'll run into limitations because it's a CPU emulator written in C# running within Unity running on your physical CPU, which is a lot of abstraction layers that limit performance.
4. Doing it the classic way is sexy ;)

we have enough compute power to do this sort of thing today, particularly if a certain amount of care is taken to optimize the quadrature in a way that's computationally efficient, even if some accuracy is sacrificed

I'm a bit confused with this statement. Yes we have the compute to numerically brute-force it (not in kOS per se, but if you e.g. hooked it via RPC to some C++ program that does the math). Why "optimize the quadrature" though? I don't see the point in that - just throw all the cores and GHz at it instead of the extra work on your part. If you care about being computationally efficient while sacrificing accuracy, UPFG does that :)

[nbelakovski]

Thanks for the detailed answer.

Not exactly. UPFG is a predictor-corrector type of solver for a specific problem that uses thrust integrals at one step of the calculation. (Note that we calculate those integrals explicitly.)

I'm a little confused here, in a couple of parts so let me try to break it up into a couple questions

1. Predictor-corrector

I think we're talking about the same thing but I'm not sure if maybe you mean something other than what I have in mind. Partly this is on me, I should clarify that when I talk about PEG/UPFG approximating integrals, what I really mean is that you have a system of equations and some unknown values, and those equations include integrals. So you have to use some sort of iterative algorithm like Newton's method to solve that system of equations to get your unknown values. If you really squint you could call your initial guess for the root finder the "prediction" and the update from the root finder and the "correction" but I get the sense that I'm trying to abuse terms in order to fit this model, and perhaps what UPFG does is something else, does this make sense, could you clarify?

2. "Note that we calculate those integrals explicitly"

What does this mean? At first I thought you meant that you are doing the numerical calculation of the integral, but then as I continue reading your response it's clear that's not what you meant. Are you talking about how on page 6 (of the pdf) of Teren's paper he provides closed form solutions to the integrals?

kOS ... [is] a CPU emulator written in C# running within Unity ...

Ah, did not know that. I can see how that might make the computation challenging.

Why "optimize the quadrature" though? I don't see the point in that - just throw all the cores and GHz at it instead of the extra work on your part. If you care about being computationally efficient while sacrificing accuracy, UPFG does that :)

I meant optimizing it for computational efficiency, and by that I mean things like tuning the error-correction of a quadrature so that it computes an integral of acceleration to a tolerance of 0.1m/s as opposed to 1e-8, because why spend the extra computation power to compute something that not even the Shuttle would care about? Or instead of using an error correcting quadrature, using a fixed-order quadrature. In my experiments with scipy's quad and fixed_quad, the fixed one is significantly faster, even when using very high order polynomials.

If you care about being computationally efficient while sacrificing accuracy, UPFG does that :)

That's a good point, if you're going to sacrifice accuracy, what difference does it make if you do it via approximations to the integrals or approximations to the quadrature? Well, perhaps it's a matter of taste, but I find the quadrature solution to be both more elegant and more approachable. I salute anyone who has managed to create working implementation of PEG/UPFG, but they are so hard to follow! And I just get this uneasy feeling when I'm using someone else's equations without understanding the derivation.

All that said I totally agree with your comment, if it ain't broke, don't fix it! I don't have any illusions that quadratures would improve the accuracy of PEGAS in a meaningful way, I just wanted to pick your brain on the subject, thank you for letting me do that :)

[Noiredd]

Sorry I let your reply gather dust here for a while 🙏 I realized I failed to understand what you meant by "PEG and UPFG are approximations of certain thrust integrals", I left to ponder on it and then forgot.

Anyway I now think that the root of our miscommunication is that for me "thrust integrals" are those very precisely defined parameters (ones describe the physical capability of the vehicle), while you seemed to use the term in a broader context, like "equations of motion". In this sense yes PEG/UPFG are just methods of solving some very specific set of equations. The predictor-corrector scheme is just a computational method being used. Now when I think of it, maybe you could indeed replace the whole thing with a simpler solver - assuming you can rewrite the equations in the right way (whatever your solver of choice can ingest).

Hope I understood you correctly this time and this message is helpful :)