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

[Arrowstar]

19 hours ago, awang said:

Shorter version of the logs here:https://www.dropbox.com/s/k9s1z2i6blzxcri/ksp_tot_relay_logs.txt?dl=0

This is the short version? LOL

Have you learned anything since yesterday that might help diagnose what's going on?

[awang]

Yeah... It's sort of a mess.

I found a few interesting areas, but nothing really concrete. I think the issue is that WINE just can't see what's going on in your code. I can see where I think the exception-handling code is first called (line 66131 of the full logs), but everything above that looks pretty normal (although it's definitely possible I missed something). Sorry.

I'm not exactly sure how to debug this "normally", either. The Matlab file is encrypted, so I can only debug it through Matlab itself, and I'm not entirely sure about Matlab's ability to run things through WINE first. It'd certainly be interesting: Matlab running gdb running WINE running KSP TOT. I'll take a second look once I get ahold of a copy of Matlab.

[Gordon Dry]

Do you use UPX or something?

Every new KSPTrajectoryOptimizationTool.exe is scanned by my AV as PUP.

Edit:

and btw I installed MATLAB last time but now it says on install that I didn't.

Edited May 21, 2016 by Gordon Dry

[Arrowstar]

4 minutes ago, Gordon Dry said:

Do you use UPX or something?

Every new KSPTrajectoryOptimizationTool.exe is scanned by my AV as PUP.

Not sure what you mean.  What are UPX and PUP?

[Gordon Dry]

Ultimate Packer for eXecutables - http://upx.sourceforge.net/

PUP = Potentially Unwanted Program - https://en.wikipedia.org/wiki/Malware#Grayware

[Arrowstar]

5 minutes ago, Gordon Dry said:

Ultimate Packer for eXecutables - http://upx.sourceforge.net/

PUP = Potentially Unwanted Program - https://en.wikipedia.org/wiki/Malware#Grayware

KSPTOT is based on MATLAB and uses the MATLAB Compiler to generate the executable.  I have no idea what UPX is but I don't use it.

The only way this software will be "unwanted" is if you decide you don't want the best mission design software for KSP around.

[Gordon Dry]

Okay, then why is this happening when I try to install?

I installed the MCR_R2014b_win64_installer.exe last time and had KSPTOT already working...

Edited May 21, 2016 by Gordon Dry

[Arrowstar]

Just now, Gordon Dry said:

Okay, then why is this happening when I try to install?

Did you install the MATLAB Compiler Runtime (MCR)?

[Gordon Dry]

Yes, 10 days ago, but actually a search for the dll didn't give a result, so it seems not to be a part of the whole partition C: at all ...

And as I mentioned in my edited post above I already had it running before ...

[Arrowstar]

Try re-installing it.  Make sure you have the R2014b version of MCR if you're using the v1.5.3 release of KSPTOT.

[Gordon Dry]

Of course I got R2014b, you linked it.
MCR_R2014b_win64_installer.exe SHA1 crc cae13fcbe2f8bc0cdd1bdd9798b76feb2f2bce83

[Arrowstar]

1 minute ago, Gordon Dry said:

Of course I got R2014b, you linked it.
MCR_R2014b_win64_installer.exe SHA1 crc cae13fcbe2f8bc0cdd1bdd9798b76feb2f2bce83

Have you tried uninstalling and reinstalling on your PC?  And you are running this on Windows, yes?

[Gordon Dry]

Actually I install again.
I don't like so called "runtimes" that don't survive a PC reboot.

The package also contains other runtimes as well (that I already got on a well trimmed Windows PC and are hopefully not force-downgraded by that MATLAB), so dependencies over dependencies.

So, after that it still doesn't work, there is a wrong reference in your build.

A search for everything that contains "mclmcrrt" in it AFTER a fresh install of MATLAB runtimes shows this:
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\appdata\files\mclmcrrt_win64 1407828315_manifest.bin
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\appdata\files\mclmcrrt_common 1410828026_manifest.bin
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\appdata\components\mclmcrrt_common 1410828026 3424161043731414870.xml
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\appdata\components\mclmcrrt_win64 1407828315 851371322785675806.xml
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\extern\include\mclmcrrt.h
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\extern\lib\win64\microsoft\mclmcrrt.lib
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\runtime\win64\mclmcrrt8_4.dll

[Arrowstar]

23 minutes ago, Gordon Dry said:

Actually I install again.
I don't like so called "runtimes" that don't survive a PC reboot.

The package also contains other runtimes as well (that I already got on a well trimmed Windows PC and are hopefully not force-downgraded by that MATLAB), so dependencies over dependencies.

So, after that it still doesn't work, there is a wrong reference in your build.

A search for everything that contains "mclmcrrt" in it AFTER a fresh install of MATLAB runtimes shows this:
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\appdata\files\mclmcrrt_win64 1407828315_manifest.bin
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\appdata\files\mclmcrrt_common 1410828026_manifest.bin
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\appdata\components\mclmcrrt_common 1410828026 3424161043731414870.xml
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\appdata\components\mclmcrrt_win64 1407828315 851371322785675806.xml
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\extern\include\mclmcrrt.h
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\extern\lib\win64\microsoft\mclmcrrt.lib
c:\Program Files\MATLAB\MATLAB Compiler Runtime\v84\runtime\win64\mclmcrrt8_4.dll

I apologize that you don't like the runtime.  Unfortunately unless you have MATLAB itself, you're stuck with using it.  It's the best I (and MathWorks) can do.

I suspect that whatever is going on is on your end.  Lots of people here have been using the MCR with KSPTOT successfully.  If you've already uninstalled and reinstalled the MCR and verified that you have the correct version, I'm not sure what else I can tell you.  Perhaps try on another clean Windows PC you have available?  I suspect that whatever it is, it's something simple.

Are you still getting the same "not found" error when you start KSPTOT?

[Arrowstar]

Hey everyone, good news!  I'm working on a new tutorial.

[Snoman314]

2 hours ago, Arrowstar said:

Hey everyone, good news!  I'm working on a new tutorial.

That's great news! As much as I use KSPTOT, I always feel like I'm only just scratching the surface of it. 

[PingTe]

Hi i have a problem with the numbers/trajectories in RSS/RO. it shows unrelistic orbits the whole time and high dV numbers like 14.5 Km dV for an Earth>Jupiter Transfer. With the normal kerbol system it works.

Any advice?

2 Examples

 

 

Edited May 24, 2016 by PingTe

[Arrowstar]

57 minutes ago, PingTe said:

Hi i have a problem with the numbers/trajectories in RSS/RO. it shows unrelistic orbits the whole time and high dV numbers like 14.5 Km dV for an Earth>Jupiter Transfer. With the normal kerbol system it works.

Any advice?

2 Examples

 

 

The pork chop plot probably just needs two things. First, cut down on the number of syodic periods you're searching. Second, move the earliest arrival date up until it's just below the first black tip.

On the flyby finder, you need to provide larger flight time windows. Make the max duration longer. Also look at increasing the launch window duration if need be. Finally, try running it a few times, the genetic algorithm has an element of randomness to it. 

[Arrowstar]

Hi everyone!

I'm ready to release a "preliminary" version of the tutorial I showed above.  I'm releasing this version in order to get feedback from the community before I publish it formally with the next KSPTOT release.  If you're interested in learning how to do a Kerbin -> Eve -> Jool -> Plock mission with powered flybys in Mission Architect, please take a look at the download link below.

I would really appreciate it if, after you are done going through the tutorial, you please leave me some notes here in this thread.  I would like feedback on the following items:

• Ease of use.  Is the tutorial easy to read?  Are the instructions clear, both in their intent (what we're doing) and purpose (why we're doing it)?
• Practicality.  Is the tutorial too long or too short?  Does anything else hinder your ability to learn from it?
• Completeness.  Do you feel as if you've learned the skills needed to perform your own complex mission plans after going through this tutorial?
• Functionality.  Does the tutorial work?  Are the intermediate results the same as what you get (assuming you accurately follow all instructions)?  Do you achieve the final result?
• Language.  Are spelling, grammar, and formatting okay?

Here's the download link.  It includes a PDF file with the tutorial contents and a bodies.ini file you'll need to load into KSPTOT before getting started.

https://dl.dropboxusercontent.com/u/29126891/Solar%20System%20Edge%20-%20MA%20Tutorial.zip

A few notes and known issues:

• There are some "lessons learned" sections which are not yet complete.  I'll get to these next chance I get!
• The comm network analysis part of the tutorial at the end may be buggy in the release version of KSPTOT (v1.5.3).  I fixed a bug in the network path algorithm while putting together the tutorial.

Thanks, guys!  I look forward to your comments, suggestions, and feedback.

[Drew Kerman]

You forgot the bodies.ini file in the package.

Also I'm a bit disappointed the MFMS was skipped over completely. I would very much like to know the process you went through to get that data, especially since that's something I would have to do to create my own missions that are similar to what you've put together for this tutorial.

I only read the first couple of pages before stopping - before I bother taking notes separately I'd like to ask for a Word file or something that I can put notes and stuff in as I go through it.

[russm]

3 hours ago, Arrowstar said:

Thanks, guys!  I look forward to your comments, suggestions, and feedback.

Initial thoughts, after reading only:

Page 9: I think both instances of "principle requirement" should be "principal requirement" (or perhaps "in-principle requirement", depending on what you mean).

Is there any particular reason other than "I have found it works better this way" that you prefer to use a coast to SOI transition before the following coast to periapsis? Does it make any significant difference if that coast to SOI change triggers on moving to an inferior instead of superior body? (eg: if event 4 "coast to sun SOI" is actually a Mun encounter, or event 7 "coast to sun SOI 2" is actually a Gilly encounter?) Not that either of those encounters are going to happen in this scenario, but as a general best practices thing.

[Arrowstar]

7 hours ago, Gaiiden said:

You forgot the bodies.ini file in the package.

Also I'm a bit disappointed the MFMS was skipped over completely. I would very much like to know the process you went through to get that data, especially since that's something I would have to do to create my own missions that are similar to what you've put together for this tutorial.

I only read the first couple of pages before stopping - before I bother taking notes separately I'd like to ask for a Word file or something that I can put notes and stuff in as I go through it.

Whoops!  I've added back in.  I meant to include the ini file, but looks like I grabbed the .mat file instead.  Good catch.

I've added a Word version for you to the package, as well.

I originally didn't want to do the MFMS part of the tutorial, because I need everyone to be on the same page when we start and MFMS uses that genetic algorithm which isn't really deterministic.  However, I could just hand-wave that part by teaching how to use it and then say "we're going to use my results" and point to what I have in there.  I'll think on this some today, thanks for the suggestion.

6 hours ago, russm said:

Initial thoughts, after reading only:

Page 9: I think both instances of "principle requirement" should be "principal requirement" (or perhaps "in-principle requirement", depending on what you mean).

Is there any particular reason other than "I have found it works better this way" that you prefer to use a coast to SOI transition before the following coast to periapsis? Does it make any significant difference if that coast to SOI change triggers on moving to an inferior instead of superior body? (eg: if event 4 "coast to sun SOI" is actually a Mun encounter, or event 7 "coast to sun SOI 2" is actually a Gilly encounter?) Not that either of those encounters are going to happen in this scenario, but as a general best practices thing.

Yes.  If you use try to "coast to periapsis" with a revolutions count of something other than 0, Mission Architect will yell at you because your eccentricity is greater than or equal to 1, which means you're hyperbolic, which means you can't go around that 1 or more times.  The coast to SoI puts you in the Sun SoI, where your eccentricity is less than one, meaning you can do the whole "go once around" thing that is so useful.

Based on this, yes, hitting a moon or something would be problematic, but that's fairly rare for interplanetary missions, so I'm not too worried about it at the moment, or at least not for this tutorial.

[mikeydz]

Greetings....

I'm new to using TOT, but it looks cool, so I figured I'd try it out.

As I mentioned before, I'm very new to TOT, so I'm wondering about the results I'm getting while trying to setup a Kerbin-Moho trip. I'm using new sandbox game, so I'm starting at year 1, day one.

 

Here's the initial porkchop plot for Kerbin-Moho. It shows a 97 day trip starting day 32, using 6.42k dV

Curious, and as a comparison to another tool I've used before, I fired up the Alexmoon page and put in Kerbin-Moho, and got this.

Hmm, it's showing a trip that's gonna save about 1.4k dV, with a 136 day trip starting day 269.

Since I'm not sure why TOT didn't find this trip, I reran TOT, manually setting the earliest departure date to 250 (and setting earliest arrival to 300). That got me this...

So it found roughly the same transfer, leaving a day earlier (268 vs 269), and arriving the same day (405), but still showing over 1k more dV. I went ahead and computed the burn...

From what I can tell, the dV of the ejection burns between the 2 tools are roughly the same (1.5k dV vs 1.49k dV), so I'm assuming the difference is in the insertion dV (alexmoon shows 3.5k dV, but not sure where to find that in TOT).

 

So 1st, why did my 1st porkchop plot not find the same trip as alexmoon's site?

2nd, once I forced it to look at a similar departure date, why did it seem to find a similar trajectory, timewise, but showing so much more dV requirement?

 

 

 

 

Edited May 25, 2016 by mikeydz

[Drew Kerman]

7 hours ago, Arrowstar said:

I've added a Word version for you to the package, as well.

Thanks, I will look it through entirely later today

7 hours ago, Arrowstar said:

I originally didn't want to do the MFMS part of the tutorial, because I need everyone to be on the same page when we start and MFMS uses that genetic algorithm which isn't really deterministic.  However, I could just hand-wave that part by teaching how to use it and then say "we're going to use my results" and point to what I have in there.  I'll think on this some today, thanks for the suggestion.

Ok, I agree with your reason for leaving out the MFMS part. If you decide to leave it out of this tutorial though, I still think there should be one covering the MFMS. But then, there's a lot about KSPTOT that needs to be properly documented still and yea that's always a pain to do I know Maybe you'll feel more towards working on features again after this extensive tutorial. All I'm saying is I'm not asking for an MFMS tutorial to come right after this one.

[Arrowstar]

4 hours ago, mikeydz said:

So 1st, why did my 1st porkchop plot not find the same trip as alexmoon's site?

2nd, once I forced it to look at a similar departure date, why did it seem to find a similar trajectory, timewise, but showing so much more dV requirement?

HI there,

1) You actually more or less answered your own question.  The porkchop plot search space is defined by three things: the earliest departure date, the earliest arrival date, and the number of synodic periods you're going to search, which you can find it Edit->Options.  By moving the date up as you did, you placed the solution you were looking for in the search space.

2) So the delta-v in the porkchop plot has two considerations you need to be aware of.  First, the DV shown is actually the hyperbolic excess velocity, which I use to estimate DV without having to perform more complex orbit calculations at each step.  Second, the DV shown is the sum of the arrival and departure DV (or, as I just said, the hyperbolic excess velocities).  I suspect that Alex Moon's tool gives the departure values only.

Do those answers help?  Let me know if I can answer any more questions!

4 hours ago, Gaiiden said:

Thanks, I will look it through entirely later today

Ok, I agree with your reason for leaving out the MFMS part. If you decide to leave it out of this tutorial though, I still think there should be one covering the MFMS. But then, there's a lot about KSPTOT that needs to be properly documented still and yea that's always a pain to do I know Maybe you'll feel more towards working on features again after this extensive tutorial. All I'm saying is I'm not asking for an MFMS tutorial to come right after this one.

Got it, thanks for letting me know.