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

[Borv413]

Also as part of me troubleshooting KSPTOT, I installed the latest version of MATLAB runtime

[Arrowstar]

On 9/18/2020 at 8:14 PM, Borv413 said:

yes

could it be that since I am using a planet mod that re-parents Kerbin, it breaks it?

It could very well be, yes.  Can you try in stock KSP and see if your issue persists there?  If it works, then one of your mods is messing with it.  If you can figure out which one I can take a look.

[Mare Ingenii]

On 9/17/2020 at 8:12 PM, Arrowstar said:

Can I see the MAT file that you're seeing this in?

Added to the Git Repo Issue.

[Drew Kerman]

@Arrowstar I am getting an error for an "unknown task" when attempting to optimize this MAT file. It's all setup, just try to run the optimizer to trigger the error.

[Arrowstar]

3 hours ago, Drew Kerman said:

@Arrowstar I am getting an error for an "unknown task" when attempting to optimize this MAT file. It's all setup, just try to run the optimizer to trigger the error.

Can I correctly assume that this started after you changed the names of the propellants in the MAT file?

[Arrowstar]

21 hours ago, Mare Ingenii said:

Added to the Git Repo Issue.

As a quick guess at what might be going on, select the rotation tool in the main LVD GUI and right click on the display axes, then select something along the lines of "reset to original view", should be at the top of the context menu that comes up.  I noticed that part of your trajectory wasn't rendering beceause it was being cut off by z-limits.  If you want to avoid this in the future, go into the view settings and select "update view limits" or something to that effect.

I'm hoping that the issue is just that the trajectory looks wrong, when in reality it's fine and just the way things are rendering that is the issue.

[Drew Kerman]

4 hours ago, Arrowstar said:

Can I correctly assume that this started after you changed the names of the propellants in the MAT file?

not sure, did not try prior to changing the names

[vitorboschi]

On 9/8/2020 at 4:42 PM, vitorboschi said:

Hey @Arrowstar, got a new bug report.

I'm getting this error while the LVD script propagates:
 

Error using odezero (line 49)
odezero: an event disappeared (internal error)

Error in ode45 (line 353)


Error in ODE45Integrator/integrate (line 23)


Error in TwoBodyPropagator/propagate (line 35)


Error in LaunchVehicleSimulationDriver/integrateOneEvent (line 171)


Error in LaunchVehicleEvent/executeEvent (line 162)


Error in LaunchVehicleScript/executeScript (line 293)


Error in ma_LvdMainGUI>propagateScript (line 173)


Error in ma_LvdMainGUI>runScriptMenu_Callback (line 1614)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


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

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.

This is the .mat file. Just open and try run the script and you should get the error: https://www.dropbox.com/s/855rjnrkzt7vcmr/Main mission plan.mat?dl=0

@Arrowstar did you had the time to take a look at this one? ^

[Arrowstar]

On 9/22/2020 at 5:32 AM, vitorboschi said:

@Arrowstar did you had the time to take a look at this one? ^

Could not reproduce.  Are you just loading it up and tapping control-p to propagate?  That's what causes the error?

[Mare Ingenii]

On 9/21/2020 at 6:01 PM, Arrowstar said:

As a quick guess at what might be going on, select the rotation tool in the main LVD GUI and right click on the display axes, then select something along the lines of "reset to original view", should be at the top of the context menu that comes up.  I noticed that part of your trajectory wasn't rendering beceause it was being cut off by z-limits.  If you want to avoid this in the future, go into the view settings and select "update view limits" or something to that effect.

I'm hoping that the issue is just that the trajectory looks wrong, when in reality it's fine and just the way things are rendering that is the issue.

Well, the graphical part of that is embarrassing, and yes that is what was happening there.  However, the continuity constrains are still violated significantly and do not converge after rerunning the optimization with the same setup as in PR4.  Is that expected?

[vitorboschi]

8 hours ago, Arrowstar said:

Could not reproduce.  Are you just loading it up and tapping control-p to propagate?  That's what causes the error?

Yes, just that. Maybe it's a Linux specific issue? Is there anything I could do to help you pinpoint the problem?

[Arrowstar]

On 9/23/2020 at 4:59 PM, Mare Ingenii said:

Well, the graphical part of that is embarrassing, and yes that is what was happening there.  However, the continuity constrains are still violated significantly and do not converge after rerunning the optimization with the same setup as in PR4.  Is that expected?

I noticed that myself when looking at your MAT file.  Maybe try running the NOMAD solver on it first and see if that helps.  It does a little better on hard problems, but usually takes longer to run.

On 9/23/2020 at 5:19 PM, vitorboschi said:

Yes, just that. Maybe it's a Linux specific issue? Is there anything I could do to help you pinpoint the problem?

It could be a Linux specific thing, but it shouldn't be.  I'll try to look into it tomorrow, but I have to apologize to everyone, my workload at work has exploded and along with some other things going on, I haven't had as much time to dedicate to this over the past few weeks as I might normally.  Sorry about that.

[vitorboschi]

7 hours ago, Arrowstar said:

I noticed that myself when looking at your MAT file.  Maybe try running the NOMAD solver on it first and see if that helps.  It does a little better on hard problems, but usually takes longer to run.

It could be a Linux specific thing, but it shouldn't be.  I'll try to look into it tomorrow, but I have to apologize to everyone, my workload at work has exploded and along with some other things going on, I haven't had as much time to dedicate to this over the past few weeks as I might normally.  Sorry about that.

No need to apologize, life happens and must always come first. Just take all the time you need.

[Drew Kerman]

@Arrowstar no rush on this because I actually got really close on my first try and then was able to do some manual tweakage through the Adjust Variables dialog to put it close enough to where I want. So it's all set to go but for future reference I'd like to know why this LVD case file was so unwilling to optimize. I plugged in a set of Lat/Lng coordinate constraints I was hoping it would move closer towards (wasn't expecting to nail it) but the first try it lasted 400s and ran through 1 iteration before quitting then I adjusted the scale to reduce the jacobian heat map <1 and it quit after 4s with no iterations.

[taio]

There's an issue in the multi-flyby maneuver sequencer's initial elliptical orbit info widget. The context menu "get orbit from KSP (active vessel)" option, and presumably the other options also, pull in the true anomaly value into the mean anomaly field.

And feature request. Add burn UT (at least for the first departure) to the maneuver information, at least if the MA/epoch are nonzero.

Edited October 24, 2020 by taio

[taio]

Hm. Even after converting TA to mean anomaly (which actually shouldn't affect this, but still), I'm just not able to reproduce the MFMS's results in MA. MA converges on significantly different burn TA (~20 deg!!) and delta V components (~1% off), and for my target inbound orbit, I can't reproduce the eccentricity to within 1%. Even after jumping 1 or 2 orbits back or forward for the departure. For MA I'm following the PDF tutorials quite closely.

Also, it's an Eve flyby, and I'm confused why the periapsis MFMS came up with is so high, 27 km above atmo. I guess there might be exceptions, but most of the time I figure a powered flyby will be more efficient with a lower periapsis.

My initial state is very close to circular (0.000031), but that shouldn't be close enough to cause trouble with things like TA.

[Snoman314]

I'm consistently getting an error message that's stopping me from optimising in the Mission Architect:

It seems to only be happening when I try and use the 'Distance to Ref. Spacecraft' constraint. I've double checked for something dumb, like setting the reference spacecraft to the wrong one etc, but can't figure out how to get around this.

Mission file:

https://drive.google.com/file/d/1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy/view?usp=sharing

This is me trying to insert Commsats into exactly even arrangements. I've always done this before by optimising in part with the expected distance from existing sats in the constellation. Is there some other orbital property I could use, set 120 degrees different and use to optimise instead?

Edited November 14, 2020 by Snoman314

[Snoman314]

So, my attempt at eyeballing it pretty much went as expected:

If anyone knows how to get around this error, or if there's some other orbital parameter I can use to space satellites out evenly, instead of using distance to each other, it'd be very appreciated if you could let me know.

[Arrowstar]

Hey everyone, sorry for disappearing for awhile.  Life got busy and I needed a creative break as well.  Hopefully I can look at some bug fixes in the next days and weeks and resolve everyone's recently-ish reported issues.

On 10/24/2020 at 4:13 AM, taio said:

There's an issue in the multi-flyby maneuver sequencer's initial elliptical orbit info widget. The context menu "get orbit from KSP (active vessel)" option, and presumably the other options also, pull in the true anomaly value into the mean anomaly field.

And feature request. Add burn UT (at least for the first departure) to the maneuver information, at least if the MA/epoch are nonzero.

1. I couldn't reproduce your mean anomaly / true anomaly issue.  I checked and it does look like I'm pulling mean anomaly directly.  Are you sure this is what you were seeing?
2. I'll look into this.  Thanks for the request!

On 10/24/2020 at 6:56 AM, taio said:

Hm. Even after converting TA to mean anomaly (which actually shouldn't affect this, but still), I'm just not able to reproduce the MFMS's results in MA. MA converges on significantly different burn TA (~20 deg!!) and delta V components (~1% off), and for my target inbound orbit, I can't reproduce the eccentricity to within 1%. Even after jumping 1 or 2 orbits back or forward for the departure. For MA I'm following the PDF tutorials quite closely.

Also, it's an Eve flyby, and I'm confused why the periapsis MFMS came up with is so high, 27 km above atmo. I guess there might be exceptions, but most of the time I figure a powered flyby will be more efficient with a lower periapsis.

My initial state is very close to circular (0.000031), but that shouldn't be close enough to cause trouble with things like TA.

A few things here:

1. You're probably not going to be able to reproduce the results from MFMS in MA, honestly.  Most people discount it, but the infinitesimal local gravity field assumption in use in MFMS is actually not super great with a solar system the scale of KSP's system.  I mean, it gets you close, but you should never expect to be able to hit exactly what MFMS shows you.  It's just a guide for more high fidelity analysis.
2. Because of this, I'm not super surprised that your burn true anomaly and delta-v components are a bit different. 
3. Finally, remember that MA is a numerically optimized propagated trajectory and MFMS uses Lambert arcs.  It could very well be that your differences are just optimizer noise or that the optimizer either doesn't have a fully optimized solution (regardless of what it reports out) or is in a different solution family due to SoI differences.

Finally, for working with gravity assist maneuvers and interplanetary tours like you're talking about, I would use Launch Vehicle Designer actually.  Look at some of the gravity assist example files I've included.  These will work out to be much, much easier to optimizer and to duplicate (or improve upon!) what MFMS gives you.

The big take away here should be that MFMS is only a low fidelity guide and your solutions in higher fidelity tools like MA and LVD will be different because of that difference in fidelity.

On 11/13/2020 at 8:16 PM, Snoman314 said:

I'm consistently getting an error message that's stopping me from optimising in the Mission Architect:

It seems to only be happening when I try and use the 'Distance to Ref. Spacecraft' constraint. I've double checked for something dumb, like setting the reference spacecraft to the wrong one etc, but can't figure out how to get around this.

Mission file:

https://drive.google.com/file/d/1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy/view?usp=sharing

This is me trying to insert Commsats into exactly even arrangements. I've always done this before by optimising in part with the expected distance from existing sats in the constellation. Is there some other orbital property I could use, set 120 degrees different and use to optimise instead?

Resolved for next release, I'll put up a new build whenever it finishes building tonight.  Sorry for the delay in getting back to you.

[Snoman314]

3 hours ago, Arrowstar said:

Hey everyone, sorry for disappearing for awhile.  Life got busy and I needed a creative break as well.  Hopefully I can look at some bug fixes in the next days and weeks and resolve everyone's recently-ish reported issues.

Hey it happens. I'm honestly thankful that you're still maintaining this. This tool has become so intrinsically linked to my experience of KSP, I don't know what I'd do without it!

3 hours ago, Arrowstar said:

Resolved for next release, I'll put up a new build whenever it finishes building tonight.  Sorry for the delay in getting back to you.

Woohoo! That's awesome, thanks .

I've been having some success using the Rendezvous Manoeuvre Sequencer, by manually changing the target craft's mean anomaly by 120 degrees. Fine for LKO, but I'm used to being able to plan the arrival of commsats at periapsis for their capture/insertion burn, already at the correct offset and in phase with other satellites around bodies I'm constellations around. I look forward to returning to my overly planned missions soon  

[Arrowstar]

15 hours ago, Snoman314 said:

Hey it happens. I'm honestly thankful that you're still maintaining this. This tool has become so intrinsically linked to my experience of KSP, I don't know what I'd do without it!

Woohoo! That's awesome, thanks .

You're welcome!  It's my pleasure.

KSPTOT v1.6.7 pre-release 5b with fix in MA for bug in computing position of spacecraft wrt to Sun.

[Snoman314]

1 hour ago, Arrowstar said:

KSPTOT v1.6.7 pre-release 5b with fix in MA for bug in computing position of spacecraft wrt to Sun.

Seems to be working great now, thanks again!

[Arrowstar]

On 10/16/2020 at 5:35 AM, Drew Kerman said:

@Arrowstar no rush on this because I actually got really close on my first try and then was able to do some manual tweakage through the Adjust Variables dialog to put it close enough to where I want. So it's all set to go but for future reference I'd like to know why this LVD case file was so unwilling to optimize. I plugged in a set of Lat/Lng coordinate constraints I was hoping it would move closer towards (wasn't expecting to nail it) but the first try it lasted 400s and ran through 1 iteration before quitting then I adjusted the scale to reduce the jacobian heat map <1 and it quit after 4s with no iterations.

I see two issues:

1. Events 3-5 are taking forever to propagate.  Consider moving to ODE5 as an integrator to seriously speed this up.
2. Your constraints are -40 but the indicator in the bottom right shows that the constraint value is +320.  You need to add 360 to your constraint values.

That's all I've seen for now.

[Drew Kerman]

On 11/17/2020 at 4:04 PM, Arrowstar said:

Events 3-5 are taking forever to propagate.  Consider moving to ODE5 as an integrator to seriously speed this up.

How did you know it was these events holding things up?

Switching to ODE5 did indeed bring down the execution time from 6s to 2s, but it also gave me a slightly different result. ODE5 has me coming down 3km from where ODE45 says the rocket will - which isn't really a huge difference so I'm not concerned about that. I'm just wondering though if the speed has sacrificed accuracy or improved it - could potentially make a difference on problems requiring more precision

Also is this speeding up just the script execution or the optimizer execution as well?

For my understanding in choosing between integrator options in the future, what would be considered a "stiff problem"?

On 11/17/2020 at 4:04 PM, Arrowstar said:

Your constraints are -40 but the indicator in the bottom right shows that the constraint value is +320.  You need to add 360 to your constraint values.

Ah, okay. So this is a bit of an inconsistency then since the Initial State coordinates seem to be okay with accepting -180/180 values for longitude. I thought then that was valid input for anything longitude in LVD (I know MA doesn't like it and I have to convert to 0-360). Actually this has always annoyed me a little bit since everything in KSP is done -180/180. A related minor annoyance is how input fields and stuff like the popup tooltips report lng/lat instead of lat/lng ;P

Anyways yea adding 360 to make the conversion seems to have worked. At least, the optimizer has been running along now without issue for over an hour crunching on the problem and the constraint violation is trending downwards

Also, this popped up on the kOS reddit yesterday. Not sure if it will be applicable to LVD's own work with drag calculation tho

 

Edited November 19, 2020 by Drew Kerman

[The Aziz]

On 1/3/2017 at 8:55 PM, bcote689 said:

It seems like I keep getting a MS-Windows sound (indicating an error) everytime I try to launch the program. Still the first time I tried it, it did work somewhat initially and I was able to see the user interface.

 

The log file shows “Undefined function or variable 'matlabrc'.” This log file is updated with this message every attempt.

So I keep getting the same thing (and the quoted problem happened to the guy over 3 years ago)
And basically same situation, I updated both the runtime and the tool to versions linked in first post (as I had very outdated versions), got it working once, and suddenly when I tried today I kept getting that "ping" sound. In task manager the exe seems to appear for a moment and then disappears, but no window shows up. Log is identical as in the quote. Using the prerelease solution linked few posts below won't make sense as it's even more outdated.