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

[Arrowstar]

15 hours ago, Drew Kerman said:

Very odd to see an asteroid enter, go to Ap then come crashing into Kerbin. It is supposed to crash into Kerbin the game shows this as well, but when I advanced to the asteroid entering Kerbin's SOI in the game it didn't show a trajectory like this. When I tried loading up 1.5.8 it loaded okay with the newer runtimes installed but when I went to do the same thing as in the screenshot it told me it couldn't even find an SOI to coast to. Here is the MAT file from 1.5.9 with the original asteroid orbit data. Note that this is with data imported from the save file. I found as I was working on this post that loading the orbit from the game produces the proper result. I've included the MAT file with the ingame orbit as well as the SFS file.

Okay, so there's funny business going on with the "bad" MAT file.  It looks like when the SoI transition occurs, the spacecraft is already well within Kerbin's SoI.  In fact, it looks like it starts out in a Sun-centric orbit that really should be Kerbin-centric, because the distance between Kerbin and the spacecraft is only a few thousand kilometers at that initial state.  I suspect this might be part of the issue... any idea why this might be?

[Drew Kerman]

6 minutes ago, Arrowstar said:

any idea why this might be?

not even the slightest. Could it be a data import issue given that the bad MAT is using values from the SFS file? Otherwise I couldn't begin to guess other than the orbit was generated by the game's asteroid spawner and so that may have some inherent minor flaw in the orbits it spits out sometimes. I did nothing that could have modified it before using it in MA

[Arrowstar]

11 minutes ago, Drew Kerman said:

not even the slightest. Could it be a data import issue given that the bad MAT is using values from the SFS file? Otherwise I couldn't begin to guess other than the orbit was generated by the game's asteroid spawner and so that may have some inherent minor flaw in the orbits it spits out sometimes. I did nothing that could have modified it before using it in MA

Okay, I believe the issue is that the asteroid is getting spawned funny.  I imported another asteroid from the scenario (generated later) and it works fine.  Additionally, I imported the same asteroid from the SFS file and via KSPTOTConnect and got the same result.  Looks like just a funky asteroid....

Except that it doesn't look funky in the tracking window.  There it's well outside Kerbin's SoI.  Boy, I'm not sure what's going on there, maybe some issue with Kerbin's location over an extended period of time.  Not sure...

[Drew Kerman]

3 minutes ago, Arrowstar said:

Okay, I believe the issue is that the asteroid is getting spawned funny.  I imported another asteroid from the scenario (generated later) and it works fine.  Additionally, I imported the same asteroid from the SFS file and via KSPTOTConnect and got the same result.  Looks like just a funky asteroid....

Except that it doesn't look funky in the tracking window.  There it's well outside Kerbin's SoI.  Boy, I'm not sure what's going on there, maybe some issue with Kerbin's location over an extended period of time.  Not sure...

quite wonky indeed! I'd say let this rest until I come across another similar instance

Edited November 25, 2017 by Drew Kerman

[Arrowstar]

5 minutes ago, Drew Kerman said:

quite wonky indeed! I'd say let this rest until I come across another similar instance

Okay I think I figured it out!  It's just a KSP quirk: In this case, KSP generates the asteroid orbit by starting at some future time that defines where the asteroid should be relative to Kerbin.  It then back propagates the orbit about 60-70 days or so to the current game time (look at the time stamp on the asteroid orbit you import from KSP as opposed to the timestamp actually in the game).  So the reason the asteroid starts out in Kerbin's SoI is because it was designed to do that... but not for a long while in the game time.

The "reference" orbit around the Sun that's getting imported is this future timestamp orbit, because that's what is stored in the game's memory and in the SFS file.

Does this make sense?

In other news!  The MATLAB developers finally made it so that 3D axes don't just explode into the window they're embedded into when you zoom or pan around in them, so I'm happy to announce that Mission Architect's main UI window will have this feature in the next release!

[Drew Kerman]

25 minutes ago, Arrowstar said:

Does this make sense?

it does, thanks - I will know now to keep an eye out for this in the future so I can just work around it by getting the ingame orbit data

[Drew Kerman]

no issues so far on the MFMS, it's cruising along fine. Question tho about this:

These are all my sub orbital arcs from launches this year, plotted as Other Spacecraft. Is there a way to get them to line up so they are all coming from the same point? I tried matching RAAN and ArgPE but that didn't quite do the trick... I also tried setting their Epoch all to the same time thinking that was what was causing them to pop up all over the place but that didn't do anything either

Edited November 27, 2017 by Drew Kerman

[Arrowstar]

12 hours ago, Drew Kerman said:

no issues so far on the MFMS, it's cruising along fine. Question tho about this:

These are all my sub orbital arcs from launches this year, plotted as Other Spacecraft. Is there a way to get them to line up so they are all coming from the same point? I tried matching RAAN and ArgPE but that didn't quite do the trick... I also tried setting their Epoch all to the same time thinking that was what was causing them to pop up all over the place but that didn't do anything either

Setting the same RAAN, Argument, and Epoch should do it... what happens when you try that?

[Drew Kerman]

4 hours ago, Arrowstar said:

Setting the same RAAN, Argument, and Epoch should do it... what happens when you try that?

They all just stack upon each other:

[Arrowstar]

7 hours ago, Drew Kerman said:

They all just stack upon each other:

Oh I get what you want. You'll have to adjust the RAAN of each manually to get them from the same point.  

[Drew Kerman]

1 hour ago, Arrowstar said:

Oh I get what you want. You'll have to adjust the RAAN of each manually to get them from the same point.  

is there a formula or something to this or am I just fiddling with numbers until they all line up? Also do you mean adjust the RAAN while keeping the ArgPe and Epoch all the same or adjust only the RAAN?

[Arrowstar]

1 hour ago, Drew Kerman said:

is there a formula or something to this or am I just fiddling with numbers until they all line up? Also do you mean adjust the RAAN while keeping the ArgPe and Epoch all the same or adjust only the RAAN?

Generally just fiddling with numbers. But you could also use the optimizer to target the ascending point at zero altitude to have the same longitude by strictly adjusting the RAAN of the orbit. That might be faster.

[Arrowstar]

On 11/13/2017 at 9:18 AM, Drew Kerman said:

Hrmm, already off to a rough start. So I had the first encounter ingame and was going to put the new orbital data into the mission file but first I had to advance events up to the point of the new orbit. After I did this though I ended up with a completely different result several events later and I'm not sure why. Repro steps:

1. Open mission file
2. Right-click on event 4 and select "Advance Script Up To Selected Event"
3. Wait a minute or so for it to churn
4. MA now tells me it will no longer take 100+ revs to get another encounter several events later

I don't get what's happening here, as I did not even put in the new orbital data yet, I just advanced the script which should keep everything else the same right? I checked the Initial State orbit properties after the script advance against the orbit that should be applied to event 4 in the original mission file and they match up exactly. Soooo where's the deviation?

So I have bad news about this one.  After investigating tonight, I believe I know what the issue is.

Between MATLAB R2015b and R2017b, it looks like the MATLAB developers figured out how to get MATLAB to carry more digits per number internally in memory.  This means that numbers in R2017b are more precise after digits around 1E-10 to 1E-14 or so.  I ran an experiment to be sure.  In both versions, I ran a coast propagation from UT=35860529.8244236 seconds to UT=1.00000000000372e+19 seconds (so a massive propagation, but done analytically, very quick).  The large numbers are needed to get the difference in memory storage to appear easily.

On MATLAB R2015b, the final result was:

Quote

rVectUT(:,end)

ans =

          5911.79459078336
          2274.41900643143
          7291.38549301709

In MATLAB R2017b, the final result was:

Quote

ans =

          6886.75452757461
         -6613.39910759879
          5449.31230243905

These are very different.

To illustrate further, here's what happens when I look at the initial state even further.  This is the first element of the position vector.

MATLAB R2015b:

Quote

sprintf('%32.64f',rVect(1))

ans =

-1786.0598619631464000000000000000000000000000000000000000000000000000

MATLAB R2017b:

Quote

sprintf('%32.64f',rVect(1))

ans =

    '-1786.0598619631464316626079380512237548828125000000000000000000000000'

And the difference between these:

Quote

0.0000000000000316626079380512237548828125

or

 3.16626079380512e-14

These little differences in position mean that over many propagations, or even just one long propagation, and many revolutions of propagation, the solution becomes more and more off.  The position and velocity differences start small, but after a long period of time in the MATLAB file you gave me, grow to centimeters of difference, then meters, then kilometers, etc.  And the numerical differences accelerate as the differences get larger, so the issue sort of compounds on itself.

I'm not sure what to tell you as there's not much I can do about this.  Have you noticed any other places where this has impacted things?

[Drew Kerman]

On 11/30/2017 at 8:25 PM, Arrowstar said:

These little differences in position mean that over many propagations, or even just one long propagation, and many revolutions of propagation, the solution becomes more and more off.  The position and velocity differences start small, but after a long period of time in the MATLAB file you gave me, grow to centimeters of difference, then meters, then kilometers, etc.  And the numerical differences accelerate as the differences get larger, so the issue sort of compounds on itself.

Hrrrmmmmmm.... I'm not entirely sure how the differences you're showing between the two Matlab versions have an affect on what is being seen in KSPTOT vs. KSP. I think what you are saying is what I suspected, which is that KSPTOT is so hyper-precise that it eventually deviates from the game's lower precision over time. Now, the previous Matlab versions took a bit more propagation for this to become apparent but with the more recent version carrying greater precision this deviation happens more quickly after fewer propagations. Is this what you're saying?

[Drew Kerman]

also tried to calculate an asteroid Cd and got an error. Here are the values I used:

Drag Model: FAR
Orbiting: Kerbin
Pre-Aerobrake Mass: 87890.797
Pre-Aerobrake Peri. Alt.: 16.93418
Pre-Aerobrake SMA: 37512.9371076654
Post-Aerobrake SMA: 2265.58365678296
Orbital Inclination: 47.455203501067

Maybe the mass is too large considering a spacecraft typically wouldn't weigh that much?

[Arrowstar]

52 minutes ago, Drew Kerman said:

also tried to calculate an asteroid Cd and got an error. Here are the values I used:

Drag Model: FAR
Orbiting: Kerbin
Pre-Aerobrake Mass: 87890.797
Pre-Aerobrake Peri. Alt.: 16.93418
Pre-Aerobrake SMA: 37512.9371076654
Post-Aerobrake SMA: 2265.58365678296
Orbital Inclination: 47.455203501067

Maybe the mass is too large considering a spacecraft typically wouldn't weigh that much?

I think I've got this resolved.  Here is KSPTOT v1.5.9 pre-release 2, please let me know if this takes care of the issue!  I successfully tested it on my end.  This build also includes the handful of other items I mentioned I resolved since the first pre-release.  Still requires the r2017b MCR, as with last time.

[Drew Kerman]

38 minutes ago, Arrowstar said:

I think I've got this resolved.  Here is KSPTOT v1.5.9 pre-release 2, please let me know if this takes care of the issue!  I successfully tested it on my end.  This build also includes the handful of other items I mentioned I resolved since the first pre-release.  Still requires the r2017b MCR, as with last time.

Ok tested and got a Cd of 919.996118 - that doesn't seem a bit much? I have this data from a previous event where an asteroid passed low through Kerbin's atmosphere several times. If I manually play around with the Cd to get a Post-Aerobrake SMA that matches these numbers I end up with 0.477

Also I'm still unclear if I understood your post explaining the precision problems. Please let me know if I'm on the right track with this response:

On 12/1/2017 at 9:39 PM, Drew Kerman said:

Hrrrmmmmmm.... I'm not entirely sure how the differences you're showing between the two Matlab versions have an affect on what is being seen in KSPTOT vs. KSP. I think what you are saying is what I suspected, which is that KSPTOT is so hyper-precise that it eventually deviates from the game's lower precision over time. Now, the previous Matlab versions took a bit more propagation for this to become apparent but with the more recent version carrying greater precision this deviation happens more quickly after fewer propagations. Is this what you're saying?

 

[Arrowstar]

On 12/3/2017 at 7:21 PM, Drew Kerman said:

Ok tested and got a Cd of 919.996118 - that doesn't seem a bit much? I have this data from a previous event where an asteroid passed low through Kerbin's atmosphere several times. If I manually play around with the Cd to get a Post-Aerobrake SMA that matches these numbers I end up with 0.477

So... a dig through the code actually suggests that number, the 919.977 we're seeing, is Cd*A, or the drag coefficient times the frontal surface area.  That would make 1) the units on the drag coefficient output make sense, and 2) make the actual number output make more sense.  This obviously isn't clear, though, so I can update the UI to reflect that.  Given this interpretation, does that help resolve the issue?

I agree that 0.477 actually makes far sense as a true blue drag coefficient.  Can you explain further where this number came from?

Quote

Also I'm still unclear if I understood your post explaining the precision problems. Please let me know if I'm on the right track with this response:

Not quite.  The difference is purely between how the two versions of MATLAB are storing and computing doubles.  KSP itself is not related to this.

Edited December 5, 2017 by Arrowstar

[Drew Kerman]

42 minutes ago, Arrowstar said:

This obviously isn't clear, though, so I can update the UI to reflect that.  Given this interpretation, does that help resolve the issue?

Well, I understand now what the number is but it doesn't really resolve the issue because that number is the number I have to be able to plug into the Aerobrake state You agree that a value of 0.477 is a proper Cd and that should be the result since the purpose of the calculator is to give a value that can be used not a value that I have to further derive the actual value from.

42 minutes ago, Arrowstar said:

Can you explain further where this number came from?

Yea so I imported the asteroid state parameters from before the aerobrake, added an Aerobrake coast and then a Coast to Ap. I already knew (since this happened in the past) what the SMA was after it had made the atmo pass, so I just manually incrementally increased the Cd in the Aerobrake state until the SMA in the final state was very close to the actual SMA I recorded for the asteroid after it made the pass in the game.

42 minutes ago, Arrowstar said:

KSP itself is not related to this.

Hrmmm ok so you are simply referring to the problem where the mission file can no longer do a coast. So essentially with the newer Matlab version I have to rebuild that entire thing from scratch? Or is it just the huge 100+ events length of the mission file itself that is the problem?

I'm actually starting to already see a deviation from the propagated orbit in the mission file to what is happening in the game:

So the green orbit is where I expected it to be after 2 Mun encounters, the red orbit is where it actually is. I will continue to keep an eye on it to see how much it grows over time. First Mun encounter was only 0.342 seconds late on the SOI exit, but the second encounter happened several seconds off before and after. This is just watching from the Tracking Station, not even loading the asteroid in the flight scene. So I was wondering if precision issues were throwing things off

ALSO...

Do you think a mission length constraint would be possible in the MFMS? I think a lot of my runs could have been cut shorter if I had been able to tell it I don't want to take 100 years to get through all the planets on my list  

Edited December 5, 2017 by Drew Kerman

[Arrowstar]

50 minutes ago, Drew Kerman said:

Well, I understand now what the number is but it doesn't really resolve the issue because that number is the number I have to be able to plug into the Aerobrake state You agree that a value of 0.477 is a proper Cd and that should be the result since the purpose of the calculator is to give a value that can be used not a value that I have to further derive the actual value from.

Yea so I imported the asteroid state parameters from before the aerobrake, added an Aerobrake coast and then a Coast to Ap. I already knew (since this happened in the past) what the SMA was after it had made the atmo pass, so I just manually incrementally increased the Cd in the Aerobrake state until the SMA in the final state was very close to the actual SMA I recorded for the asteroid after it made the pass in the game.

Okay, thanks for the clarification.  Can I get the MAT file that you did this in, by any chance?  It would help my investigation!  I'm still trying to understand what you're seeing with what I believe the correct result should be, and that would definitely help.

EDIT: Just to be clear, I agree that 0.477 is a proper value of Cd, but I also note that what Mission Architect uses as an input for aerobraking is not Cd, but instead CdA.  That's why I wasn't bothered by seeing 919 earlier, because, given that it's a huge asteroid, there's probably a massive amount of frontal surface area there.

Quote

Oh ok, I see now you are simply referring to the problem where the mission file can no longer do a coast. So essentially with the newer Matlab version I have to rebuild that entire thing from scratch. Wheeee

So I'm actually starting to already see a deviation from the propagated orbit in the mission file to what is happening in the game:

So the green orbit is where I expected it to be after 2 Mun encounters, the red orbit is where it actually is. I will continue to keep an eye on it to see how much it grows over time. First Mun encounter was only 0.342 seconds late on the SOI exit, but the second encounter happened several seconds off before and after. This is just watching from the Tracking Station, not even loading the asteroid in the flight scene. So I was wondering if precision issues were throwing things off

Well, that is certainly troubling!  Could I get this MAT file too?  Or some more details of how you were doing your comparison/prediction?  I'm not sure how I'll get to the bottom of this one, but I can try. 

Quote

ALSO...

Do you think a mission length constraint would be possible in the MFMS? I think a lot of my runs could have been cut shorter if I had been able to tell it I don't want to take 100 years to get through all the planets on my list  

Sure, I don't see why not.  You just want to be able to constrain the amount of time from the initial state epoch to the epoch of the final event's final state?

-------------------------------------------------

Also, some good news!  I actually got parallel optimization in Mission Architect working this evening (I found a number of bugs that were, weirdly, only kicking in under the parallel case).  This will be in the next pre-release build and the next stable build as well!

Edited December 5, 2017 by Arrowstar

[Drew Kerman]

7 minutes ago, Arrowstar said:

Can I get the MAT file that you did this in, by any chance? 

Yea I recreated it here. Using data I recorded back when this event happened, I have the Inital State being the asteroid's orbit right after a previous aerobrake pass, which is why it seems to go all the way around. I already know the SMA after its next aerobrake pass was 2265.58365678296 so I just worked up from the default 0.2 to a Cd that gave me close to that result

10 minutes ago, Arrowstar said:

Well, that is certainly troubling!  Could I get this MAT file too?  Or some more details of how you were doing your comparison/prediction? 

Here it is. The Initial State comes from selecting Event 5 in my Alaba propagation file and choosing Copy Orbit After Selected Event - this gives me the expected orbit after leaving Mun's SOI for the second time. The Other Spacecraft orbit is from importing the actual current orbit from the SFS file.

18 minutes ago, Arrowstar said:

You just want to be able to constrain the amount of time from the initial state epoch to the epoch of the final event's final state?

Yup that sounds right

[Drew Kerman]

Additional request - is it possible to detect the Genetic Algorithm window is open while the MFMS is running so if you choose to output a Graphical Analysis it opens in a separate window? Currently it tries to plot in the already-open GA window. I sometimes like to pause my current MFMS run to do something quick in MA. For now my workaround is just to have it generate a tabular text file - thankfully plotting in the open window doesn't seem to adversely affect the MFMS run

[Drew Kerman]

hey! I just noticed that the tooltip that pops up when you hover over the Drag Coefficient input box in the state editor that states the value is actually Cd * A for FAR/NEAR users. So you already have a note in there it could probably just be made more obvious? I'm progressing through an asteroid aerobrake on multiple passes now tho and getting good results from the Aerobrake state. Will share the details after the event is over.

Also I just noticed you can't set a line color for Aerobrake events

Edited December 5, 2017 by Drew Kerman

[Arrowstar]

21 hours ago, Drew Kerman said:

Yea I recreated it here. Using data I recorded back when this event happened, I have the Inital State being the asteroid's orbit right after a previous aerobrake pass, which is why it seems to go all the way around. I already know the SMA after its next aerobrake pass was 2265.58365678296 so I just worked up from the default 0.2 to a Cd that gave me close to that result

Here it is. The Initial State comes from selecting Event 5 in my Alaba propagation file and choosing Copy Orbit After Selected Event - this gives me the expected orbit after leaving Mun's SOI for the second time. The Other Spacecraft orbit is from importing the actual current orbit from the SFS file.

Yup that sounds right

Thanks for the MAT files!

Btw, does the Alaba offset issue show up if you use the last R2015b version of KSPTOT?

19 hours ago, Drew Kerman said:

Additional request - is it possible to detect the Genetic Algorithm window is open while the MFMS is running so if you choose to output a Graphical Analysis it opens in a separate window? Currently it tries to plot in the already-open GA window. I sometimes like to pause my current MFMS run to do something quick in MA. For now my workaround is just to have it generate a tabular text file - thankfully plotting in the open window doesn't seem to adversely affect the MFMS run

Done.  I increased the figure number offset so it should not be a problem in the future.  This will be in the next pre-release.

15 hours ago, Drew Kerman said:

hey! I just noticed that the tooltip that pops up when you hover over the Drag Coefficient input box in the state editor that states the value is actually Cd * A for FAR/NEAR users. So you already have a note in there it could probably just be made more obvious? I'm progressing through an asteroid aerobrake on multiple passes now tho and getting good results from the Aerobrake state. Will share the details after the event is over.

Also I just noticed you can't set a line color for Aerobrake events

I'll get a line color in for the aerobraking stuff, thanks for finding that.

So... where are we at with the drag coefficient stuff now?  I have made the labels more obvious (everything is "Area * Drag Coefficient" now).  Does anything else still need fixing?

Edited December 6, 2017 by Arrowstar

[Drew Kerman]

28 minutes ago, Arrowstar said:

Btw, does the Alaba offset issue show up if you use the last R2015b version of KSPTOT?

Can you link me to the KSPTOT version that is? I've completely lost track. Will it run okay with the new runtimes I downloaded for the latest pre-release or will I have to roll back those as well?

30 minutes ago, Arrowstar said:

So... where are we at with the drag coefficient stuff now?  I have made the labels more obvious (everything is "Area * Drag Coefficient" now).  Does anything else still need fixing?

I think I just have to see what you've changed in order to be sure I'm understanding the usage of Cd*A