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

[Arrowstar]

On 12/5/2017 at 6:58 PM, Drew Kerman said:

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?

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

Here are two versions of the same code base, one compiled for 2015b and one for 2017b.  Can you take a look and see if you spot a difference in how they behave?  Just to note, I have not tested the 2015b executable in any real way, so if something doesn't work, please let me know...

Thanks!

[Drew Kerman]

Just now, Arrowstar said:

Here are two versions of the same code base, one compiled for 2015b and one for 2017b.  Can you take a look and see if you spot a difference in how they behave?  Just to note, I have not tested the 2015b executable in any real way, so if something doesn't work, please let me know...

Thanks!

K, I'll have something for you if you check in tomorrow evening

[Drew Kerman]

alright I ran both executables without any obvious issues and got the same results for both after propagating the original orbit out two Mun encounters to its present state in the game:

Epoch: 37877638.8568547
SMA: 16115.4036362252
Ecc: 0.315899270667825
Inc: 130.799241992445
RAAN: 106.535659985894
Arg Peri: 91.732534984549
True Anom: 88.303484758255

Both mission files can be found here.

These are the values I get from importing the current orbit via the SFS file (available as an Other Spacecraft in the 2017 mission file):

Epoch: 37877597.156481
SMA: 16120.7076370317
Ecc: 0.316634850921572
Inc: 130.807237794599
RAAN: 106.53544658843
Arg Peri: 91.677156954846
True Anom: 88.394396339316

So close! Which is why I'm suspecting some kind of precision issue being compounded over time

Edited December 7, 2017 by Drew Kerman

[Arrowstar]

8 hours ago, Drew Kerman said:

alright I ran both executables without any obvious issues and got the same results for both after propagating the original orbit out two Mun encounters to its present state in the game:

Epoch: 37877638.8568547
SMA: 16115.4036362252
Ecc: 0.315899270667825
Inc: 130.799241992445
RAAN: 106.535659985894
Arg Peri: 91.732534984549
True Anom: 88.303484758255

Both mission files can be found here.

These are the values I get from importing the current orbit via the SFS file (available as an Other Spacecraft in the 2017 mission file):

Epoch: 37877597.156481
SMA: 16120.7076370317
Ecc: 0.316634850921572
Inc: 130.807237794599
RAAN: 106.53544658843
Arg Peri: 91.677156954846
True Anom: 88.394396339316

So close! Which is why I'm suspecting some kind of precision issue being compounded over time

Okay, so let me confirm, because I think I'm a bit confused: The issue you're reporting is between actual KSP and KSPTOT, right?  And it just appeared when I started using the R2017b MCR?

If this is the case, it could be precision, but it could also be differences in the integrator (the numerical subroutine that propagates the orbit).  In fact, KSPTOT exclusively uses two body propagation for all non-thrusting orbit arcs, and I think KSP numerically integrates the equations of motion (unless the spacecraft/body is "on-rails" which is KSP-speak for the two body analytical motion).  The latter will be less precise by definition.  If you propagate over long periods of time in KSP, it's reasonable to think you might slowly see a divergence between KSPTOT and KSP.  Is this what you're doing?

Finally, if you're importing from an SFS file, the numerical precision will be limited by the limited number of digits that show up in the SFS file.  The SFS file is a far less precise data source that using KSPTOTConnect.

If my initial assumptions are correct, does any of this sound like it could be the culprit?

[Drew Kerman]

6 hours ago, Arrowstar said:

The issue you're reporting is between actual KSP and KSPTOT, right? 

right

6 hours ago, Arrowstar said:

And it just appeared when I started using the R2017b MCR?

No, this has always been a thing. It's a separate issue from the R2015b vs, R2017b precision issue - I made a mistake in thinking it was related to this

6 hours ago, Arrowstar said:

Is this what you're doing?

Yup

6 hours ago, Arrowstar said:

if you're importing from an SFS file, the numerical precision will be limited by the limited number of digits that show up in the SFS file

6 hours ago, Arrowstar said:

I think KSP numerically integrates the equations of motion (unless the spacecraft/body is "on-rails"

So the ironic thing is that I'm using the SFS file because by refusing to ever load the vessel into the flight scene I am forcing it to stay on rails throughout all of its orbital activity and my hope was that this would keep things more consistent with what KSPTOT was calculating.

So here is a possible workaround - Load to a different vessel, and then use KSPTOTConnect to pull precise orbital data for Alaba from the list of vessels in the game (rather than using the Active Vessel option)? Problem here is that this seems to be bugged (I think it has been for a while). Even with the latest R2017b build you linked me to when I load a craft in flight and choose to select an orbit from KSP it pops up a load dialog then shows the Load from SFS window with no craft listed. Note I'm still on KSP v1.2.2

 

[Arrowstar]

On 12/8/2017 at 12:42 AM, Drew Kerman said:

So here is a possible workaround - Load to a different vessel, and then use KSPTOTConnect to pull precise orbital data for Alaba from the list of vessels in the game (rather than using the Active Vessel option)? Problem here is that this seems to be bugged (I think it has been for a while). Even with the latest R2017b build you linked me to when I load a craft in flight and choose to select an orbit from KSP it pops up a load dialog then shows the Load from SFS window with no craft listed. Note I'm still on KSP v1.2.2

 

I'll investigate the bug, thanks!

EDIT: Okay, @Drew Kerman, so I could not reproduce the issue.  I can pull in both asteroid orbits and normal spacecraft orbits using the Get Orbit From KSP option (not the Active vessel option, the one that presents the list).  Can I see the error message you get?  Are you on the latest version of KSPTOTConnect?  Or maybe the issue is that you're on KSP v1.2.2, which I technically don't support anymore...

Edited December 9, 2017 by Arrowstar

[Arrowstar]

Okay, here is KSPTOT v1.5.9 pre-release 4. It includes the following changes:

1. The Mission Architect optimization algorithm is now select-able from the Script -> Execution Options menu.
2. Mission Architect aerobraking events can now select a color to use for drawing on the UI.
3. I made an experimental update to the Kepler solver which seems to provide results more consistent with KSPTOT running under MATLAB 2015b.  This one could be touchy, so in particular if you see issues with the way orbits are being propagated, please let me know!
4. I added the MATLAB version the application is running on to various splash screens and informational texts.

Please let me know if you have any questions or have found any bugs.  Thanks!

 

[OverlordMorgoth]

Ok very stupid issue here: KSPTOT won't detect my celestial bodies...

Flight mode: yes
KSPTOTConnect in Gamedata: yes
Mods: GPP, OPM, KO, GPO etc.

The Logs:

Read doubles from KSPTOT Connect failed: SIZE must be greater than 0.
    file: 'S:\Matlab\v90\mcr\toolbox\shared\instrument\@icinterface\fread.m'
    name: 'fread'
    line: 163

    file: 'C:\Users\Hajdin\AppData\Local\Temp\Hajdin\mcrCache9.0\KSPTra0\h...'
    name: 'readDoublesFromKSPTOTConnect'
    line: 53

    file: 'C:\Users\Hajdin\AppData\Local\Temp\Hajdin\mcrCache9.0\KSPTra0\h...'
    name: 'getBodiesINIFileFromKSP'
    line: 8

    file: 'C:\Users\Hajdin\AppData\Local\Temp\Hajdin\mcrCache9.0\KSPTra0\K...'
    name: 'createNewBodiesFileFromKSP_Callback'
    line: 0

    file: 'S:\Matlab\v90\mcr\toolbox\matlab\guide\gui_mainfcn.m'
    name: 'gui_mainfcn'
    line: 95

    file: 'C:\Users\Hajdin\AppData\Local\Temp\Hajdin\mcrCache9.0\KSPTra0\K...'
    name: 'mainGUI'
    line: 42

    file: 'S:\Matlab\v90\mcr\toolbox\matlab\graphics\+matlab\+graphics\+in...'
    name: '@(hObject,eventdata)mainGUI('createNewBodiesFileFromKSP_Callbac...'
    line: 0

The error simply states that there was an error pulling and asks me if I was in flying mode (cruising over Kerbin in a homemade jet) and if KSPTOTConnect is loaded (its in Gamedata).

What am I doing wrong?

[Gilph]

4 hours ago, OverlordMorgoth said:

Ok very stupid issue here: KSPTOT won't detect my celestial bodies...

Flight mode: yes
KSPTOTConnect in Gamedata: yes
Mods: GPP, OPM, KO, GPO etc.

The Logs:

Read doubles from KSPTOT Connect failed: SIZE must be greater than 0.
    file: 'S:\Matlab\v90\mcr\toolbox\shared\instrument\@icinterface\fread.m'
    name: 'fread'
    line: 163

    file: 'C:\Users\Hajdin\AppData\Local\Temp\Hajdin\mcrCache9.0\KSPTra0\h...'
    name: 'readDoublesFromKSPTOTConnect'
    line: 53

    file: 'C:\Users\Hajdin\AppData\Local\Temp\Hajdin\mcrCache9.0\KSPTra0\h...'
    name: 'getBodiesINIFileFromKSP'
    line: 8

    file: 'C:\Users\Hajdin\AppData\Local\Temp\Hajdin\mcrCache9.0\KSPTra0\K...'
    name: 'createNewBodiesFileFromKSP_Callback'
    line: 0

    file: 'S:\Matlab\v90\mcr\toolbox\matlab\guide\gui_mainfcn.m'
    name: 'gui_mainfcn'
    line: 95

    file: 'C:\Users\Hajdin\AppData\Local\Temp\Hajdin\mcrCache9.0\KSPTra0\K...'
    name: 'mainGUI'
    line: 42

    file: 'S:\Matlab\v90\mcr\toolbox\matlab\graphics\+matlab\+graphics\+in...'
    name: '@(hObject,eventdata)mainGUI('createNewBodiesFileFromKSP_Callbac...'
    line: 0

The error simply states that there was an error pulling and asks me if I was in flying mode (cruising over Kerbin in a homemade jet) and if KSPTOTConnect is loaded (its in Gamedata).

What am I doing wrong?

If you are running GPP, you will need to create a bodies.ini file and then load it.

11 hours ago, Arrowstar said:

Okay, here is KSPTOT v1.5.9 pre-release 4. It includes the following changes:

1. The Mission Architect optimization algorithm is now select-able from the Script -> Execution Options menu.
2. Mission Architect aerobraking events can now select a color to use for drawing on the UI.
3. I made an experimental update to the Kepler solver which seems to provide results more consistent with KSPTOT running under MATLAB 2015b.  This one could be touchy, so in particular if you see issues with the way orbits are being propagated, please let me know!
4. I added the MATLAB version the application is running on to various splash screens and informational texts.

Please let me know if you have any questions or have found any bugs.  Thanks!

 

Hi, to be clear, this is the version that supports R2017b? If so, is that the preferred version for testing? Thanks.

[Arrowstar]

24 minutes ago, Gilph said:

If you are running GPP, you will need to create a bodies.ini file and then load it.

Hi, to be clear, this is the version that supports R2017b? If so, is that the preferred version for testing? Thanks.

Does KSPTOTConnect not work with that mod?

And yes, all versions from here on out will be on MCR R2017b, which I linked to previously. 

[OverlordMorgoth]

2 hours ago, Arrowstar said:

Does KSPTOTConnect not work with that mod?

Couldn't definitely answer that but to specify: this came up while trying to create a bodies.ini. It won't load any bodies except the stock ones. I am using GPP_Secondary.
 

[Drew Kerman]

On 12/8/2017 at 10:57 PM, Arrowstar said:

EDIT: Okay, @Drew Kerman, so I could not reproduce the issue.  I can pull in both asteroid orbits and normal spacecraft orbits using the Get Orbit From KSP option (not the Active vessel option, the one that presents the list).  Can I see the error message you get?  Are you on the latest version of KSPTOTConnect?  Or maybe the issue is that you're on KSP v1.2.2, which I technically don't support anymore...

I never noticed this edit until now. Forum doesn't notify me if you tag me on an edit it seems.

No error chime sounds, nothing shows up in the log - just loads the vessel selection window with an empty vessel list. Well, I will be updated to the latest KSP version by the end of the year so I will just wait until I get around to doing that.

[Arrowstar]

3 minutes ago, Drew Kerman said:

I never noticed this edit until now. Forum doesn't notify me if you tag me on an edit it seems.

No error chime sounds, nothing shows up in the log - just loads the vessel selection window with an empty vessel list. Well, I will be updated to the latest KSP version by the end of the year so I will just wait until I get around to doing that.

Sorry about that, I was hoping the tag would work. 

It could just be a KSPTOTConnect thing, but it should work with KSP v1.3.  Let me know if you have issues in the coming weeks after you upgrade.

[Gilph]

4 hours ago, Arrowstar said:

Does KSPTOTConnect not work with that mod?

Yes, I use it extensively. I don't have any issues with it.

@OverlordMorgoth, I don't use GPP Secondary or the other mods, just GPP. but there are some gotchas

First, there can only be one Sun, so all instances of Ciro need to be renamed in the bodies.ini file. I'm not sure how GPP_Secondary will affect the one sun rule. Next, I had some weirdness in some of my plots that were only fixed by deleting Grannus from the bodies file. You may wish to look into it.

[Arrowstar]

7 hours ago, Gilph said:

Yes, I use it extensively. I don't have any issues with it.

@OverlordMorgoth, I don't use GPP Secondary or the other mods, just GPP. but there are some gotchas

First, there can only be one Sun, so all instances of Ciro need to be renamed in the bodies.ini file. I'm not sure how GPP_Secondary will affect the one sun rule. Next, I had some weirdness in some of my plots that were only fixed by deleting Grannus from the bodies file. You may wish to look into it.

Yes, this is all correct.  Gilph, do you have a bodies.ini file for this mod you'd be willing to share here?  That might help @OverlordMorgoth out a lot.

----

In other news, I put together KSPTOT v1.5.9 pre-release 5 tonight.  The changes are as follows:

1. Mission Architect orbit display clipping parameter updated to "rectangle"; should help with some funny clipping issues that existed previously.
2. "Central Body ID" constraint should now be smooth instead of discrete.  This should help with using this constraint during optimization.
3. New "Eve Aerobraking" MA example will be included in next build.
4. Another experimental update to the Kepler solver (tightened tolerances after comparison to external solver).

[Drew Kerman]

Don't forget the MFMS time constraint. Just a reminder - no rush. For these 50-run sequences I'm still doing it's not a big deal but when I finish up and select the routes I really want to crunch on in a few weeks it will really help to have this additional constraint to clamp down on things for 500-run sequences

[Arrowstar]

Just now, Drew Kerman said:

Don't forget the MFMS time constraint. Just a reminder - no rush. For these 50-run sequences I'm still doing it's not a big deal but when I finish up and select the routes I really want to crunch on in a few weeks it will really help to have this additional constraint to clamp down on things for 500-run sequences

Oh right!  Yeah, I can add that in the next day or two.  Thanks for the reminder.

[Drew Kerman]

On 12/7/2017 at 6:59 PM, Arrowstar said:

Finally, if you're importing from an SFS file, the numerical precision will be limited by the limited number of digits that show up in the SFS file.  The SFS file is a far less precise data source that using KSPTOTConnect.

There may be a numerical maths thing here I don't quite understand but I just thought about the fact that the game is getting all its initial data from the SFS file... so it should stand to reason that importing data from the SFS file into KSPTOT should still yield the same results as the game shouldn't it?

[Gilph]

11 hours ago, Arrowstar said:

Yes, this is all correct.  Gilph, do you have a bodies.ini file for this mod you'd be willing to share here?  That might help @OverlordMorgoth out a lot.

Sure, but I'm not sure it will match his config. Mine only has GPP. I believe he is also running GPP_Secondary and OPM, and I do not have those.

[Drew Kerman]

also, I can do pretty much everything while the MFMS is running, except for some reason importing current UT into the main KSPTOT window and also trying to enter time manually through the dialog (pasting seconds in works fine).

I'm only asking for a fix for this because I pause the MFMS in order to do this and then sometimes I forgot to resume

[Arrowstar]

17 hours ago, Drew Kerman said:

also, I can do pretty much everything while the MFMS is running, except for some reason importing current UT into the main KSPTOT window and also trying to enter time manually through the dialog (pasting seconds in works fine).

I'm only asking for a fix for this because I pause the MFMS in order to do this and then sometimes I forgot to resume

I can take a look, but stuff like this is usually out of my hands because MATLAB does not really allow UI stuff to be run on anything but the main thread, and that means that conflicts like the one you're talking about tend to happen.  Still, I'll see.

In other news, KSPTOT v1.5.9 pre-release 6 is here.  This update includes:

1. Some graphical changes in Mission Architect; and
2. A total mission duration constraint in MFMS.

As usual, please let me know if you find any bugs.  Thanks!

[Drew Kerman]

55 minutes ago, Arrowstar said:

Still, I'll see.

Yup, I figured. I appreciate you taking a look but don't expect you to chase after it if it seems to be a difficult issue to work around

[Drew Kerman]

On 12/12/2017 at 8:17 AM, Drew Kerman said:

There may be a numerical maths thing here I don't quite understand but I just thought about the fact that the game is getting all its initial data from the SFS file... so it should stand to reason that importing data from the SFS file into KSPTOT should still yield the same results as the game shouldn't it?

so, more thinking on this subject I realize it may be that this is the root of all the problems. Even when I'm keeping track of my asteroid orbits, which I update once per orbit for each asteroid, I notice some drift over time. Very small, milliseconds of difference in the orbital period but there every single time I re-check the orbits. Maybe the KSPTOTConnect should be extended to store high-precision orbital data for save files and inject that into the game when the flight scene is loaded.

[Drew Kerman]

OK I found something new for my asteroid moonlet Alaba. Been keeping an eye on it in the Tracking Station and a Mun pass just popped up waaay earlier than MA predicted from my original propagation I talked about a while ago:

So there are the details. Now I loaded up the latest PR6 of KSPTOT linked just above and imported the SFS data to get this:

So it's still telling me the SOI entry should be a ways off still. So then I loaded the asteroid into the game and pulled from the active vessel, and that gave me a proper SOI entry:

Well, actually the entry time is still a few seconds off but at least its close. So then I thought about the SFS precision and decided to unpack the save file version from my backups (hooray versioning backups!) from the actual day of the SFS epoch time, because it's been a while since the SFS data has been updated. I loaded the asteroid into the game and pulled in the data:

I have boxed the time of the initial state to show that it's finding the proper SOI entry from several weeks back than the other instance in which I imported data from the game.

So in conclusion:

• Pulling SFS data with an epoch several weeks old gave me an incorrect result
• Pulling game data from just a few hours after that same epoch and propagating several weeks forward gave me a proper result

So yea, hopefully all my issues will be fixed when I upgrade to v1.3.1 and start pulling data from the game indirectly through the Select Vessel menu rather than from the SFS file

Hope that all made sense... it's late and this stuff is already confusing when we discuss this topic

[Arrowstar]

Sounds like everything you mentioned is related to that issue I found earlier where KSP generates orbits with an epoch in the future or the past and a position that places asteroid in the Kerbin SoI (even though the orbit definition is about the Sun).  That's most likely why you see the funny orbit you did when you read in from the SFS file.  Does that sound reasonable?

I can take a look at the MAT file and SFS file if you'd like me to confirm.