[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[Drew Kerman]

1 hour ago, Arrowstar said:

I would first check that the gravitational parameter of Kerbin is the same in LVD and KSP

the bodies.ini file I'm using has GM defined as 3531.600000000. When I calculate it in kOS I get 3531473003619.97. I know this is an accurate number since I use it to lock my throttle to TWR and in my ascent videos I have a TWR readout displayed and it is spot-on to what I'm supposed to be locked to.

Could you update this value in the case file I linked in my last post?

1 hour ago, Arrowstar said:

Next thing I would look at is making sure that the pitch profile is being executed as closely as possible to what's in LVD

I could clean this up a bit tomorrow, but I think the offset is mostly due to either the GM or atmospheric density, since I have the rocket hitting pitch targets at certain altitudes so if the rocket is traveling faster due to thinner air or less gravity it's hitting the proper angles at the proper altitudes but sooner than the actual flight

[Arrowstar]

8 minutes ago, Drew Kerman said:

the bodies.ini file I'm using has GM defined as 3531.600000000. When I calculate it in kOS I get 3531473003619.97. I know this is an accurate number since I use it to lock my throttle to TWR and in my ascent videos I have a TWR readout displayed and it is spot-on to what I'm supposed to be locked to.

Could you update this value in the case file I linked in my last post?

Done.

[Drew Kerman]

No difference. I'll see what tweaking the pitch profile does tomorrow. Annoyingly, for some reason I can't get the optimizer to work down to an objective function of 0 despite being able to do that with the LVD file simulating the atmosphere. Vac sim results:

atmo sim results:

 

[Arrowstar]

1 hour ago, Drew Kerman said:

No difference. I'll see what tweaking the pitch profile does tomorrow. Annoyingly, for some reason I can't get the optimizer to work down to an objective function of 0 despite being able to do that with the LVD file simulating the atmosphere. Vac sim results:

atmo sim results:

 

Hmm, yeah, that is a bit annoying.  Try playing with the scale factors on the constraints.  If you set the scale factor to the desired value, that can help with convergence (maybe).

[Drew Kerman]

argh we were barking up the wrong tree. Not your fault tho because you wouldn't have known without looking closely or me telling you that I was using a TWR throttle model for my ascent. Here is a no atmosphere ascent from Kerbin at full throttle from launch holding 45° heading 98° pitch (altitude over time):

We can attribute the slight discrepancy to the fact that in KSP the engine has throttle lag and also to minor steering losses since the rocket did wobble a few thousands of a degree off pitch either way during the ascent. But here's using 1.65 TWR until 40km and then full throttle (altitude over time again):

And here is a look at thrust over time:

to validate my kOS code is calculating properly I have a Kerbal Engineer readout open during flight and the TWR value is a steady 1.65 all the way up to 40km. Checking the GA output from LVD shows it too thinks its holding 1.65. I've uploaded both LVD files so you can double-check I have things set up properly. I also included the analysis Excel sheet I've built up so far

[Arrowstar]

46 minutes ago, Drew Kerman said:

argh we were barking up the wrong tree. Not your fault tho because you wouldn't have known without looking closely or me telling you that I was using a TWR throttle model for my ascent. Here is a no atmosphere ascent from Kerbin at full throttle from launch holding 45° heading 98° pitch (altitude over time):

<snip>

We can attribute the slight discrepancy to the fact that in KSP the engine has throttle lag and also to minor steering losses since the rocket did wobble a few thousands of a degree off pitch either way during the ascent. But here's using 1.65 TWR until 40km and then full throttle (altitude over time again):

<snip>

And here is a look at thrust over time:

<snip>

to validate my kOS code is calculating properly I have a Kerbal Engineer readout open during flight and the TWR value is a steady 1.65 all the way up to 40km. Checking the GA output from LVD shows it too thinks its holding 1.65. I've uploaded both LVD files so you can double-check I have things set up properly. I also included the analysis Excel sheet I've built up so far

Okay, so there's possibly an issue with the way that LVD is computing thrust to weight, it looks like?

[Drew Kerman]

14 minutes ago, Arrowstar said:

Okay, so there's possibly an issue with the way that LVD is computing thrust to weight, it looks like?

Confirmed. I just put the atmosphere back in and did a full-throttle ascent:

I find that acceptable and would expect more steering losses due to extra drag since I'm using control surfaces instead of an engine gimbal. In addition here is the thrust plot over altitude

The very slight discrepancy may mean we could still use a fix for the atmospheric density curve as well

[Arrowstar]

4 minutes ago, Drew Kerman said:

Confirmed. I just put the atmosphere back in and did a full-throttle ascent:

I find that acceptable and would expect more steering losses due to extra drag since I'm using control surfaces instead of an engine gimbal. In addition here is the thrust plot over altitude

The very slight discrepancy may mean we could still use a fix for the atmospheric density curve as well

Okay thanks.  Can you confirm that the mass of the vehicle is correct and the engine mass flow rate and ISP is correct?

[Drew Kerman]

51 minutes ago, Arrowstar said:

Okay thanks.  Can you confirm that the mass of the vehicle is correct and the engine mass flow rate and ISP is correct?

I can confirm mass and ISP. I got the mass directly from kOS ship:mass call and ISP is properly set in the Engine properties. I can't output ISP via the GA so no way to check if it's scaling the same as in the game. Mass flow is interesting though:

LVD is showing it changing if you start the plot at +1s. If you start the plot at 0s the 0 thrust value enlarges the vertical axis and makes this look like a constant value in a straight line - which is why no one probably noticed this before if it's an issue. KSP does not do this curve however. The blue line is the approximate position of the value that KSP gives me for the constant mass consumption as per this display figure in the part access window of the engine (actual flight value shown):

12.50595*.005 gives 0.062529764mT/s (rounded to 0.06253 in the GA marker line tool it can't be displayed which is why I had to draw it myself )

It makes sense that fuel flow would be constant no? ISP changes and thrust changes but that is based on the atmosphere not the fuel flow. I wouldn't have expected to see a curve here and it's only because I plotted it in Excel that I noticed it because I left out the 0 thrust value.

Edited October 1, 2019 by Drew Kerman

[Arrowstar]

43 minutes ago, Drew Kerman said:

I can confirm mass and ISP. I got the mass directly from kOS ship:mass call and ISP is properly set in the Engine properties. I can't output ISP via the GA so no way to check if it's scaling the same as in the game. Mass flow is interesting though:

LVD is showing it changing if you start the plot at +1s. If you start the plot at 0s the 0 thrust value enlarges the vertical axis and makes this look like a constant value in a straight line - which is why no one probably noticed this before if it's an issue. KSP does not do this curve however. The blue line is the approximate position of the value that KSP gives me for the constant mass consumption as per this display figure in the part access window of the engine (actual flight value shown):

12.50595*.005 gives 0.062529764mT/s (rounded to 0.06253 in the GA marker line tool it can't be displayed which is why I had to draw it myself )

It makes sense that fuel flow would be constant no? ISP changes and thrust changes but that is based on the atmosphere not the fuel flow. I wouldn't have expected to see a curve here and it's only because I plotted it in Excel that I noticed it because I left out the 0 thrust value.

You're right that it is changing, but it's in the hundreds of thousandths of kilograms per section, which is negligible.  Mass flow rate is basically constant.  Can you plot total mass of the vehicle over time in both KSP and LVD?

[Drew Kerman]

23 minutes ago, Arrowstar said:

Can you plot total mass of the vehicle over time in both KSP and LVD?

Yup. You're right, looks good:

teeny little imperfection likely due to the throttle lag, which takes 3 seconds to reach full fuel flow

Also just to be clear this is still the data from the test launching at full thrust, in atmosphere, 45° heading 89° pitch the whole way up

Edited October 1, 2019 by Drew Kerman

[Arrowstar]

27 minutes ago, Drew Kerman said:

Yup. You're right, looks good:

teeny little imperfection likely due to the throttle lag, which takes 3 seconds to reach full fuel flow

Also just to be clear this is still the data from the test launching at full thrust, in atmosphere, 45° heading 89° pitch the whole way up

Right.  So it looks like the issue is with the TtW throttle law.  Would you agree?  Ugh lol.

Can you provide me a time history of thrust, throttle, total vehicle mass, and altitude?  For the case with the throttling in there, of course.  With no atmosphere would make it easier to analyze. 

EDIT: I suspect I know what the issue is.  The code I'm using fixes the thrust to weight relative to planetary sea level (altitude = 0 km).  However, gravitational force drops off as you get farther from the body, and so less throttle is needed.  Now, I don't know if it's really enough to be the full cause here, but if the "thrust to weight" you're seeing in kOS or KER or whatever is the true thrust to weight computed at the given altitude, then that would be a discrepancy.

Edited October 1, 2019 by Arrowstar

[Drew Kerman]

1 hour ago, Arrowstar said:

EDIT: I suspect I know what the issue is.  The code I'm using fixes the thrust to weight relative to planetary sea level (altitude = 0 km).  However, gravitational force drops off as you get farther from the body, and so less throttle is needed.  Now, I don't know if it's really enough to be the full cause here, but if the "thrust to weight" you're seeing in kOS or KER or whatever is the true thrust to weight computed at the given altitude, then that would be a discrepancy.

Oh, yea that would have been obvious if I had plotted out the throttle setting. Before ramping up to full, actual flight is down to 45.30% while LVD is only 51.07%. My TWR code is accounting for gravity falloff, which as I said matches up with KER's readout. Looking at the previous post of the difference in altitude and the difference in thrust - they both seem pretty equal so it could indeed be the majority of cause

[Arrowstar]

5 minutes ago, Drew Kerman said:

Oh, yea that would have been obvious if I had plotted out the throttle setting. Before ramping up to full, actual flight is down to 45.30% while LVD is only 51.07%. My TWR code is accounting for gravity falloff, which as I said matches up with KER's readout. Looking at the previous post of the difference in altitude and the difference in thrust - they both seem pretty equal so it could indeed be the majority of cause

I'll push out this change tonight and you can tell me if it helps any.

[Arrowstar]

@Drew Kerman: Here's pre-release 7 with the update to the T2W throttle model in LVD that uses the true T2W, not the sea-level T2W.  Please let me know if this helps any.  This is the only change from pre-release 6.

[Drew Kerman]

4 hours ago, Arrowstar said:

@Drew Kerman: Here's pre-release 7 with the update to the T2W throttle model in LVD that uses the true T2W, not the sea-level T2W.  Please let me know if this helps any.  This is the only change from pre-release 6.

Didn't have a lot of time tonight. Going back to the case file I designed for my ascent, data from PR6 with the smoothed atmosphere said the rocket would burn out at 66.194km ASL. PR7 says the rocket will burn out at 65.483km ASL (I remembered to re-optimize the pitch profile since the thrust change would affect when the rocket arrives at a given altitude). The actual altitude of MECO was 63.408km ASL. So, getting closer and besides modeling changes I still also have room to tweak the LVD ascent into a better fit with the actual one. I have everything setup to take a deep dive into the data tomorrow for some new plots. I'll have something in the morning

[Drew Kerman]

Ooof this all took longer than I thought. Alright nevermind about my actual mission profile, I just did another test ascent with atmosphere, TWR throttle lock, 45° heading, 89° pitch to keep things simple. Here's the result:

Now lets compare to full throttle with everything else the same:

That's pretty tight yea? I also tested without throttle lag in KSP and didn't see any serious deviation. Do you think the atmospheric density curve should still be fixed?

Also it looks like MA is still not finding encounters properly. Here is the MAT file. if you do a distance check, you'll find this:

I can confirm this is the proper time for an in-game encounter. But at default settings the SOI search still finds an encounter days later. if I switch to stricter SOI search it finds an encounter waaay later than even the default settings. If I set the minimum SOI search tolerance it too finds an encounter later than the default, but not as many days beyond what the stricter SOI search option gets. If I turn on stricter SOI search and also have the tolerance set to minimum it doesn't find any SOI intercept (which is set to search the max 100 revs ahead)

[Arrowstar]

23 minutes ago, Drew Kerman said:

Ooof this all took longer than I thought. Alright nevermind about my actual mission profile, I just did another test ascent with atmosphere, TWR throttle lock, 45° heading, 89° pitch to keep things simple. Here's the result:

<snip>

Now lets compare to full throttle with everything else the same:

<snip>

That's pretty tight yea? I also tested without throttle lag in KSP and didn't see any serious deviation. Do you think the atmospheric density curve should still be fixed?

Also it looks like MA is still not finding encounters properly. Here is the MAT file. if you do a distance check, you'll find this:

<snip>

I can confirm this is the proper time for an in-game encounter. But at default settings the SOI search still finds an encounter days later. if I switch to stricter SOI search it finds an encounter waaay later than even the default settings. If I set the minimum SOI search tolerance it too finds an encounter later than the default, but not as many days beyond what the stricter SOI search option gets. If I turn on stricter SOI search and also have the tolerance set to minimum it doesn't find any SOI intercept (which is set to search the max 100 revs ahead)

1. Looks much better!  What do your thrust vs time plots look like now?  How does the mission do with no atmosphere?  If it's spot on, then we can conclude that the remaining difference is the density.  By the way, that can be fixed, but there is a performance hit to doing so, mostly because it means I have to compute the latitude of the spacecraft to get the temperature model in there.  Hopefully it won't be too bad.  I'll look at this next week when I have some time then.
2. Thanks for the note about the SoI search issue still.  I'm a bit annoyed it's still there but I'll look into it.  Thanks!

[Drew Kerman]

1 hour ago, Arrowstar said:

What do your thrust vs time plots look like now?  How does the mission do with no atmosphere?  If it's spot on, then we can conclude that the remaining difference is the density.  By the way, that can be fixed, but there is a performance hit to doing so, mostly because it means I have to compute the latitude of the spacecraft to get the temperature model in there.  Hopefully it won't be too bad.  I'll look at this next week when I have some time then.

Thrust over time for no atmosphere, using 1.65 TWR until 40km then full throttle (you can see the throttle lag, but like I said I found its effect to be negligible):

Thrust over time with atmosphere using 1.4 TWR until 40km then full throttle - the difference is so MECO happened inside the atmosphere (at 68km) because otherwise it would not be able to maintain guidance with its fin control surfaces (no atmo was using engine gimbal):

Again a slight discrepancy similar to what was seen for the TWO (throttle wide open) scenario.

[Arrowstar]

On 10/2/2019 at 11:19 AM, Drew Kerman said:

Also it looks like MA is still not finding encounters properly. Here is the MAT file. if you do a distance check, you'll find this:

<snip>

I can confirm this is the proper time for an in-game encounter. But at default settings the SOI search still finds an encounter days later. if I switch to stricter SOI search it finds an encounter waaay later than even the default settings. If I set the minimum SOI search tolerance it too finds an encounter later than the default, but not as many days beyond what the stricter SOI search option gets. If I turn on stricter SOI search and also have the tolerance set to minimum it doesn't find any SOI intercept (which is set to search the max 100 revs ahead)

If you set the SoI search tolerance to 1E-10 and the number of SoI search attempts to 100, it should find the SoI transition you're talking about.  In general, for tough SoI transitions, keep strict search off, set the number of attempts to a higher number, and set the tolerance to a small number, as I've done here.

[Drew Kerman]

1 hour ago, Arrowstar said:

If you set the SoI search tolerance to 1E-10 and the number of SoI search attempts to 100, it should find the SoI transition you're talking about.  In general, for tough SoI transitions, keep strict search off, set the number of attempts to a higher number, and set the tolerance to a small number, as I've done here.

when I open the file I sent you, I have a Mun encounter at Y4 D95. When I set the search tolerance to 1E-10 (attempts is already at 100) I get a Mun encounter at Y4 D114. The encounter I'm looking for, and the one shown in the plot I made, is at Y4 D65

[Arrowstar]

8 hours ago, Drew Kerman said:

when I open the file I sent you, I have a Mun encounter at Y4 D95. When I set the search tolerance to 1E-10 (attempts is already at 100) I get a Mun encounter at Y4 D114. The encounter I'm looking for, and the one shown in the plot I made, is at Y4 D65

Did you set the number of SoI Transitions Search Attempts to 100?  When I do this, I get the transition you're looking for.

[Drew Kerman]

31 minutes ago, Arrowstar said:

Did you set the number of SoI Transitions Search Attempts to 100?

Auuuughhhghhhhghghg

I did not pay enough attention to what you were saying and confused the "search attempts" option with "search revs" You're right, that works. Will keep that in mind thx

[Drew Kerman]

managed to find some more weird behavior with the SOI search. Take this MAT file for example.

1. Note end time of Y4 D45, which is an actual future in-game encounter
2. Change SOI search tolerance to 1E-9
3. Note end time goes a few million years into the future
4. Change SOI search tolerance to 1E-10
5. Note end time is now a more reasonable at Y4 D74 however I have already advanced the game past this and can confirm there is no such future encounter
6. Change SOI search attempts to 3
7. Note end time is now a few hundred billion years into the future! Damn I'm good at breaking things
8. Change SOI search tolerance down up to 1E-14
9. Note end time is now Y4 D71 - still no actual encounter there either
10. Change SOI search tolerance down to 1E-8
11. Back to proper Y4 D45

So all this came about when I hoped to just set search revs to 100, search attempts to 100 and tolerance to 1E-14 and have a nice catch-all. I guess I shouldn't be surprised to find it's a bit more complicated than that I'll just make a habit of doing a manual check via distance graph output and if I see anything being missed I'll narrow down to just that one encounter and tweak around with the search options until I find it

[Arrowstar]

22 hours ago, Drew Kerman said:

managed to find some more weird behavior with the SOI search. Take this MAT file for example.

1. Note end time of Y4 D45, which is an actual future in-game encounter
2. Change SOI search tolerance to 1E-9
3. Note end time goes a few million years into the future
4. Change SOI search tolerance to 1E-10
5. Note end time is now a more reasonable at Y4 D74 however I have already advanced the game past this and can confirm there is no such future encounter
6. Change SOI search attempts to 3
7. Note end time is now a few hundred billion years into the future! Damn I'm good at breaking things
8. Change SOI search tolerance down up to 1E-14
9. Note end time is now Y4 D71 - still no actual encounter there either
10. Change SOI search tolerance down to 1E-8
11. Back to proper Y4 D45

So all this came about when I hoped to just set search revs to 100, search attempts to 100 and tolerance to 1E-14 and have a nice catch-all. I guess I shouldn't be surprised to find it's a bit more complicated than that I'll just make a habit of doing a manual check via distance graph output and if I see anything being missed I'll narrow down to just that one encounter and tweak around with the search options until I find it

Alright, so it might not surprise you to find out that I've gotten sick of finding out that my algorithm for finding SoI transitions continually doesn't find SoI transitions. I've basically decided to rewrite the thing from scratch tonight, hopefully I'll have a prototype for you to test out this weekend.  It's based on the algorithm used for LVD, so it should be more stable, at the expense of a bit of CPU time.  I've got the new algorithm roughed out tonight, and I'll polish it this week, adding new SoI transition options and removing those that are no longer applicable.  You can prototype it on all those edge cases you are so good at finding lol.