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

[KC_073]

 

File looks like it's 0 bytes... can you confirm there's data in there?

I re-uploaded it and it now shows as ~338KB. Hopefully that fixes it.  Link is the same as before.

[Drew Kerman]

 

Is anyone aware of anything show-stopping (bugs or otherwise) that would preclude doing so?

negatory.

Also been humming along well so far on the new build without any problems, have gone through at least 5-6 sequences so far. Of course, I probably just jinxed myself

[Drew Kerman]

maybe a bug? Mission file. Steps:

1. Add a Coast to Next SOI
2. Add a Coast to Periapsis
3. Change the Coast to Pe into a Coast to UT and change the hour to 21 and the minutes to 58
4. Delete the Coast to Next SOI event
5. Note that the trajectory view and Final State now return to a sun orbit

This also happens if you just add a Coast to Pe without first coasting to the next SOI and then change the UT the same way. Perhaps when coasting to UT, SOI transitions are not taken into account? Or is there some other consideration here that I'm missing to explain this behavior of apparently needing a distinct Coast to SOI event?

[Drew Kerman]

I just realized you can enter something like 14.232625496 into the Number of Synodic Periods to Plot option and you don't get an error, and the porkchop plot seems to compute fine. Is it in fact using a floating point number or is it rounding to the nearest integer? I would like to constrain the plotter to within a certain time period (in this case that number of periods should equal 1 Year of earth time for Moho) and this seems the only way to do it

[Gilph]

Not really a show stopper, but if you change the departure time in the Departure Burn calc window (Enter Transfer and Initial Orbit Info window), and right click the Arrival Time field to "Find Optimal Arrival Time for Input Departure Time", it throws an error:

Spoiler

Not enough input arguments.

Error in findOptimalDepartureArrivalObjFunc (line 13)

Error in computeDepartureGUI>@(arrivalTime)findOptimalDepartureArrivalObjFunc(arrivalTime,departUT,departBodyInfo,arrivalBodyInfo,gmu,options.quant2opt)

Error in fmincon (line 534)

Error in fmultistart

Error in MultiStart/run (line 257)

Error in multiStartCommonRun (line 18)

Error in computeDepartureGUI>findOptimalArrivalForInputDeparture_Callback (line 512)

Error in gui_mainfcn (line 95)

Error in computeDepartureGUI (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)computeDepartureGUI('findOptimalArrivalForInputDeparture_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied objective function evaluation. FMINCON cannot continue.
    Failure in evaluation call to the local solver with user-supplied problem structure.

Error while evaluating Menu Callback

Thanks

[Drew Kerman]

can confirm the above behavior

[Arrowstar]

20 hours ago, Drew Kerman said:

negatory.

Also been humming along well so far on the new build without any problems, have gone through at least 5-6 sequences so far. Of course, I probably just jinxed myself

Copy.

17 hours ago, Drew Kerman said:

maybe a bug? Mission file. Steps:

1. Add a Coast to Next SOI
2. Add a Coast to Periapsis
3. Change the Coast to Pe into a Coast to UT and change the hour to 21 and the minutes to 58
4. Delete the Coast to Next SOI event
5. Note that the trajectory view and Final State now return to a sun orbit

This also happens if you just add a Coast to Pe without first coasting to the next SOI and then change the UT the same way. Perhaps when coasting to UT, SOI transitions are not taken into account? Or is there some other consideration here that I'm missing to explain this behavior of apparently needing a distinct Coast to SOI event?

Fixed in next build.  Thanks for the find!

8 hours ago, Drew Kerman said:

I just realized you can enter something like 14.232625496 into the Number of Synodic Periods to Plot option and you don't get an error, and the porkchop plot seems to compute fine. Is it in fact using a floating point number or is it rounding to the nearest integer? I would like to constrain the plotter to within a certain time period (in this case that number of periods should equal 1 Year of earth time for Moho) and this seems the only way to do it

This is permissible.  The synodic period is merely a length of time that is convenient for drawing the plots.  If you want to allow for 2.5 synodic periods of plots (or pi periods), there's no reason you shouldn't be able to do that. The code will use the floating point number directly.

4 hours ago, Gilph said:

Not really a show stopper, but if you change the departure time in the Departure Burn calc window (Enter Transfer and Initial Orbit Info window), and right click the Arrival Time field to "Find Optimal Arrival Time for Input Departure Time", it throws an error:

  Reveal hidden contents

Not enough input arguments.

Error in findOptimalDepartureArrivalObjFunc (line 13)

Error in computeDepartureGUI>@(arrivalTime)findOptimalDepartureArrivalObjFunc(arrivalTime,departUT,departBodyInfo,arrivalBodyInfo,gmu,options.quant2opt)

Error in fmincon (line 534)

Error in fmultistart

Error in MultiStart/run (line 257)

Error in multiStartCommonRun (line 18)

Error in computeDepartureGUI>findOptimalArrivalForInputDeparture_Callback (line 512)

Error in gui_mainfcn (line 95)

Error in computeDepartureGUI (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)computeDepartureGUI('findOptimalArrivalForInputDeparture_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied objective function evaluation. FMINCON cannot continue.
    Failure in evaluation call to the local solver with user-supplied problem structure.

Error while evaluating Menu Callback

Thanks

Fixed.  Thanks for the find!

21 hours ago, KC_073 said:

I re-uploaded it and it now shows as ~338KB. Hopefully that fixes it.  Link is the same as before.

So this is an issue with the code interacting with the parallel computing tool box in a funny way.  I think I'll leave it for now and then try to fix it in the same 1.6.0 build that I move over the MATLAB R2017[a|b], since the new MATLAB version might help things.  In the mean time, just avoid using it.

Speaking of new builds, here we go!  This should correct all the issues noted above.

[Gilph]

2 hours ago, Arrowstar said:

Speaking of new builds, here we go!  This should correct all the issues noted above.

HI...This build may have some issues.  I was not able to get an intercept from a MAT file that worked in the previous version. So, I tried to recreate all the steps and it still did not work.  When I reverted to the prior versions, it all worked again. I'll try and work through it more carefully over the weekend and post some logs. Thanks

[Arrowstar]

36 minutes ago, Gilph said:

HI...This build may have some issues.  I was not able to get an intercept from a MAT file that worked in the previous version. So, I tried to recreate all the steps and it still did not work.  When I reverted to the prior versions, it all worked again. I'll try and work through it more carefully over the weekend and post some logs. Thanks

Thanks for letting me know. Since all my test cases passed, can I see the mission file you're working on that demonstrates the issue? Please include a description of how to reproduce the problem. I should be able to look tomorrow. Thanks!

[Gilph]

Was able to work a bit on it today. here are the steps:

1. I open a flight scene for a vessel on orbit around the sun heading to Gael.  I have a small maneuver in 36 days to fine tune (14m/s), encounter at about 116 days (Thalia->Gael in GPP)
2. Open TOT and start MA
3. Import the maneuver, which creates a set state, coast to UT, and dv_maneuver node.
4. Import the orbit info into Set State
5. Add a fourth step to coast to Pe of Gael.

Final spacecraft state should show orbiting around Gael. Instead, I'm orbiting around the Sun and an error that I cannot go to True Anomoly because there is no SOI for Gael. I had done that exact sequence a few times in the past days and it always worked. I have not tried to optimize yet because I can't get the actual state correct. The imported data looks correct. The log was pretty empty:

Spoiler

____________________________________________________________
   Diagnostic Information

Number of variables: 3

Functions 
Objective:                            @(x)ma_optimObjWrapper(x,maData.script,vars,objFunc,maData,celBodyData,partialExec)
Gradient:                             finite-differencing
Hessian:                              finite-differencing (or Quasi-Newton)

Constraints
Nonlinear constraints:                do not exist
 
Number of linear inequality constraints:    0
Number of linear equality constraints:      0
Number of lower bound constraints:          3
Number of upper bound constraints:          3

Algorithm selected
   interior-point

____________________________________________________________
   End diagnostic information
                                            First-order      Norm of
 Iter F-count            f(x)  Feasibility   optimality         step
    0       4    1.000000e+00    0.000e+00    0.000e+00

Optimization completed: The final point is the initial point.
The first-order optimality measure, 0.000000e+00, is less than
options.TolFun = 1.000000e-10, and the maximum constraint
violation, 0.000000e+00, is less than options.TolCon = 1.000000e-10.

Optimization Metric                                         Options
first-order optimality =   0.00e+00                TolFun =   1e-10 (selected)
max(constraint violation) =   0.00e+00             TolCon =   1e-10 (selected)

Let me know if you need anything else? Thanks

[Arrowstar]

5 minutes ago, Gilph said:

Was able to work a bit on it today. here are the steps:

1. I open a flight scene for a vessel on orbit around the sun heading to Gael.  I have a small maneuver in 36 days to fine tune (14m/s), encounter at about 116 days (Thalia->Gael in GPP)
2. Open TOT and start MA
3. Import the maneuver, which creates a set state, coast to UT, and dv_maneuver node.
4. Import the orbit info into Set State
5. Add a fourth step to coast to Pe of Gael.

Final spacecraft state should show orbiting around Gael. Instead, I'm orbiting around the Sun and an error that I cannot go to True Anomoly because there is no SOI for Gael. I had done that exact sequence a few times in the past days and it always worked. I have not tried to optimize yet because I can't get the actual state correct. The imported data looks correct. The log was pretty empty:

  Reveal hidden contents

____________________________________________________________
   Diagnostic Information

Number of variables: 3

Functions 
Objective:                            @(x)ma_optimObjWrapper(x,maData.script,vars,objFunc,maData,celBodyData,partialExec)
Gradient:                             finite-differencing
Hessian:                              finite-differencing (or Quasi-Newton)

Constraints
Nonlinear constraints:                do not exist
 
Number of linear inequality constraints:    0
Number of linear equality constraints:      0
Number of lower bound constraints:          3
Number of upper bound constraints:          3

Algorithm selected
   interior-point

____________________________________________________________
   End diagnostic information
                                            First-order      Norm of
 Iter F-count            f(x)  Feasibility   optimality         step
    0       4    1.000000e+00    0.000e+00    0.000e+00

Optimization completed: The final point is the initial point.
The first-order optimality measure, 0.000000e+00, is less than
options.TolFun = 1.000000e-10, and the maximum constraint
violation, 0.000000e+00, is less than options.TolCon = 1.000000e-10.

Optimization Metric                                         Options
first-order optimality =   0.00e+00                TolFun =   1e-10 (selected)
max(constraint violation) =   0.00e+00             TolCon =   1e-10 (selected)

Let me know if you need anything else? Thanks

Thanks!  Can I get the mat file you're using too?

[Gilph]

Sure, here is the link

found some other things.

I deleted my appoptions.ini file to allow the program to recreate from scratch. I restarted and changed the time from Earth to Kerbin, but changing to Kerbin does not save in the file.

I use the GPP pack, so I deleted the default bodies.ini file and load a GPP file with another name.  If I delete the options file, it will start with the stock system parameters, even though I dont have a stock bodies file.  Is there a set of stock data embedded in the app?

[Arrowstar]

3 hours ago, Gilph said:

Sure, here is the link

So... are you absolutely sure there's an SoI transition in there?  I did some poking around and could not find anything.  It doesn't look like the spacecraft gets anywhere near the target planet.  I did some checking with previous 1.5.8 pre-release versions and I didn't see any SoI transitions either, so it's definitely not something I did just yesterday. 

I'm going to need some more information about when and where the SoI transition occurs.  Do you have a screenshot of it happening in-game?  Maybe a UT I can propagate to in the mission file you gave me?

Quote

I deleted my appoptions.ini file to allow the program to recreate from scratch. I restarted and changed the time from Earth to Kerbin, but changing to Kerbin does not save in the file.

Found the bug, fixed for next version.  Thanks!

Quote

I use the GPP pack, so I deleted the default bodies.ini file and load a GPP file with another name.  If I delete the options file, it will start with the stock system parameters, even though I dont have a stock bodies file.  Is there a set of stock data embedded in the app?

There is a set of stock data embedded in the application, yes.  The software needs to load something, so this is hidden away as a default or fall-back if the specified bodies file does not exist.  If the options file doesn't exist, the default options specify to use this file as well.

[Gilph]

1 hour ago, Arrowstar said:

So... are you absolutely sure there's an SoI transition in there?  I did some poking around and could not find anything.  It doesn't look like the spacecraft gets anywhere near the target planet.  I did some checking with previous 1.5.8 pre-release versions and I didn't see any SoI transitions either, so it's definitely not something I did just yesterday. 

I'm going to need some more information about when and where the SoI transition occurs.  Do you have a screenshot of it happening in-game?  Maybe a UT I can propagate to in the mission file you gave me?

*sigh* OK. Hoping it was something easy.  I can look to try to make a youtube video. I made one once to show a USI MKS bug, I just need to remember how to do it again.

I am very sure.  In fact, I don't need that maneuver node to get an SOI. I was just moving the Pe  a little closer. Here is a screenshot to give you an idea. It's the station icon in the center and the SOI is upper left.  I am on an intercept with the body connected by the green line:

 

Edit1: Executed the burn and encounter and Pe are good. Created a MA where I just set initial state and a coast to Gael Pe. This is the MA screen still showing a total miss:

 

 

Edited October 6, 2017 by Gilph
update

[Arrowstar]

Okay, thanks.  So do this for me:

1. Set up a scenario in KSP that has you intercepting the target body (Gael?) without any maneuvers.
2. Import that state into KSPTOT Mission Architect.
3. Send me the MAT file and a screenshot showing the intercept.

Is Gael the super far out one?  I wouldn't be surprised if that was the cause, though I don't know why it would be yet.

Thanks!

[Gilph]

10 hours ago, Arrowstar said:

Okay, thanks.  So do this for me:

1. Set up a scenario in KSP that has you intercepting the target body (Gael?) without any maneuvers.
2. Import that state into KSPTOT Mission Architect.
3. Send me the MAT file and a screenshot showing the intercept.

Is Gael the super far out one?  I wouldn't be surprised if that was the cause, though I don't know why it would be yet.

Thanks!

OK, the file is problem2.mat in the same shared link as above.

The MA screenshot above is that exact scenario you requested. The screenshot here is the station intercepting Gael in 45 days. Gael is the pale blue dot (to coin a phrase). You can see the Commnet green line linking the vessel to Gael. I also copied a recent persist file for your reference.  Thanks

Edited October 7, 2017 by Gilph
add persist file

[Gilph]

FYI, to give perspective, Gael is a kerbin replacement at roughly the same SMA as Kerbin. The inner planets are not that far and the purple body is about a Duna distance away, so nothing in the screenshot is that far.

I have two other vessels in flight with a valid SOI and no maneuvers going to Gauss and Nero, which are far and very far. Doing the process you asked, I made two MAT files:

• GaussRelayGood.mat: correctly shows the SOI at 2y141d away
• NeroRelayBad.mat: does not show the SOI at 15y273d away.

Thanks

[Gilph]

@Arrowstar, It looks like it's working again:

• Reinstalled 1.3.0 and every flippin mod in a new directory. TOT did not work.
• Deleted and Reinstalled TOT back to the main 1.5.7 release in the same TOT directory (e:\ksptot). Still did not work.
• Created a new TOT directory (e:\ksptot2) and reinstalled the 1.5.7 release. It worked.

Not sure why creating a new directory worked. A quick look at the security settings shows no difference. Same drive and a simple directory off the root.

Thanks very much for your help.  I will stay at this version for a while. 

 

[Drew Kerman]

Have been running MFMS virtually non-stop on all kinds of sequence variations all last week and since the last pre-release I haven't gotten a single error, even that other issue that wasn't the atan2 problem hasn't reared its head since. I'm posting this to see if I jinx myself

Also not sure why but I'm able to write this as MFMS churns away in the background. Been like that since the latest build too tho I did restart my PC so maybe that had something to do with it. If it locks me out again I think I may know what the problem is, possibly involving the multi-monitor app I use to place a taskbar on each screen

Anyways, just posting to not report an issue for once!

Aaaaannnd never mind LOL, but it's nothing related to what I posted earlier. I noticed that if I have the Mission Animator window open when I try to plot an analysis graph I get an error ding, even though the graph window shows up but without any labels identifying the axis. If it's a multi-plot without sub-plotting then only one window opens with the ding. If I click for a tabular text output the file is not created (wait no yes it is the dialog notification just doesn't show up). Not sure how best to handle this but I think maybe the easiest would be a warning dialog if ppl try to select the graphical analysis tool when the mission animator is open asking them if they'd like to close it & telling them if they don't the GA won't open. Or just fix it so both can be open at the same time? Whatever's easier I'd say.

Also FWIW I didn't notice any immediate issues if I worked things the other way and plotted out two graph windows then opened the mission animator

Edited October 8, 2017 by Drew Kerman

[Drew Kerman]

Holy crap I just by accident realized you can enter something like 25/6 into a text box asking for a number and it will do the calculation for you. I mean, I guess that makes sense given what the thing is built on but still! Cool!

[Arrowstar]

14 hours ago, Gilph said:

@Arrowstar, It looks like it's working again:

• Reinstalled 1.3.0 and every flippin mod in a new directory. TOT did not work.
• Deleted and Reinstalled TOT back to the main 1.5.7 release in the same TOT directory (e:\ksptot). Still did not work.
• Created a new TOT directory (e:\ksptot2) and reinstalled the 1.5.7 release. It worked.

Not sure why creating a new directory worked. A quick look at the security settings shows no difference. Same drive and a simple directory off the root.

Thanks very much for your help.  I will stay at this version for a while. 

 

So... does the issue persist still in 1.5.8?

[Gilph]

18 hours ago, Arrowstar said:

So... does the issue persist still in 1.5.8?

SIgh...sort of. V1.5.7 was not working perfect. it seems like some vessels always work in doing the two step MA of set state/coast to Pe, and it looks like it's the same vessels in 1.5.7 and 1.5.8. Also, the SOI after maneuver did not work after the first test on either version.

I wiped the MCR runtime and installed it on a different drive, and did the same with the TOT app directory. Did not help.

I think I won't take any more of your time on this. I'll do some work with stock saves I have archived to see if it's a Kopernicus issue. If there is any command line debug or log modes I can capture, please let me know.

Thanks very much for your help

Edit1: Found the problem.  In the GPP bodies file, I deleted Grannus, the outermost body that is also a sun (it's not marked as a sun in the bodies file, but it may have some parameters that was confusing TOT). Every vessel now has the correct intercepts and all of the ones with maneuvers are correct also. Now I can get some sleep. Thanks again.

Edit2: this was with 1.5.8

Edited October 9, 2017 by Gilph
found it

[Arrowstar]

6 hours ago, Gilph said:

 

Edit1: Found the problem.  In the GPP bodies file, I deleted Grannus, the outermost body that is also a sun (it's not marked as a sun in the bodies file, but it may have some parameters that was confusing TOT). Every vessel now has the correct intercepts and all of the ones with maneuvers are correct also. Now I can get some sleep. Thanks again.

Edit2: this was with 1.5.8

Any idea why this causes a problem?

[Drew Kerman]

hrm, calculating some porkchop plots In noticed it was only searching for a optimal departure burn 20 times, despite what I had set in the options. Didn't this departure burn search count depend on that option? I honestly can't remember but I thought I had it set once to 50 and that's how many it did for the porkchop plotter. Maybe something got messed up when the update came to allow the MFMS to use this option value as well?

[Gilph]

6 hours ago, Arrowstar said:

Any idea why this causes a problem?

Not really, but I have a few ideas. I know that Kopernicus sometimes gets confused on what the dominant star is, like  pointing solar panels to Grannus when you are very close to Ciro. Also, even though I change Ciro to Sun in the bodies file, I don't edit Grannus. Maybe some sun-like parameters are being set for Grannus in TOT even though it should be just a body and throwing off the calculations.

What gave me the idea was that I was working on a trajectory to Thalia (similar to Kerbin->Eve), and it was totally off.  It was burning prograde (like it wanted to go to an outer planet like Grannus). I moved the burn 180 deg and had a trajectory with a Pe that looked close, but was not lined up to intercept Thalia at all (Thalia was in the wrong place). When I put that maneuver in, it calculated a final spacecraft state as orbiting Grannus (which is like setting up a Kerbin->Eve burn and seeing it intercepted Eeloo). If TOT thought Sun (Ciro) was Grannus, then that was correct. So I thought to just delete Grannus in the bodies file to make sure only one sun (called Sun) was included.  When I reimported the file, it's been perfect ever since. fingers crossed.