[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]

[jakkarth]

30 minutes ago, Arrowstar said:

Only change is bug fix noted above. 

And lo, the bug was squashed, and the optimizer hummed happily along to itself having forgotten the words. Perhaps a once-only issue, but starting KSPTOT pre5 took over 2 minutes before the logo showed up on the screen. I had to verify it was running in the task manager. I don't mind the waiting, and I suspect there's not much you could do about it, just thought you might want to know.

[Arrowstar]

8 minutes ago, jakkarth said:

And lo, the bug was squashed, and the optimizer hummed happily along to itself having forgotten the words. Perhaps a once-only issue, but starting KSPTOT pre5 took over 2 minutes before the logo showed up on the screen. I had to verify it was running in the task manager. I don't mind the waiting, and I suspect there's not much you could do about it, just thought you might want to know.

Yeah, this is actually something with the MCR.  The executable you download has to unpack a bunch of files to a temporary directory somewhere on the first run, which is why the first time is always slower.  Subsequent runs should be quicker to start.

[jakkarth]

Alright, while this Jool flyby correction burn for Sarnus is calculating, here are the top four things I wish were different/available in KSPTOT. Please forgive me if these already exist, don't exist for a reason already discussed, or are sheer lunacy. Maybe they wouldn't even be helpful and I just don't realize it. Anyway, here they are in no particular order.

• MFMS warning. Somewhere around page 15 I think, there was a discussion about infinitesimal SoI sizes in KSPTOT tools other than MA. I don't know if this is still the case or not. It was cited as a reason that MFMS results shouldn't be used directly, because you might hit other intermediate SoIs or encounter other problems, and that the results should be used as initial guesses in MA instead. If it is still the case that MFMS results shouldn't be used directly, having some kind of warning on that tool's view might be helpful to people unaware of that. (This would have saved me about 30 minutes when I first got started)
• MA Optimizer persistence setting. Sometimes it doesn't even get 1 iteration done before it gives up. Sometimes it stops at a severely suboptimal solution when a better one might exist. Sometimes it just goes on and on and on with no apparent significant change in results. Sometimes you're going to let it run overnight and you don't care how long it takes. It would be nice to have a setting where you could set how aggressively it tries to continue the search, including a "keep looking until I tell you to stop" option. Paired with this, there have been times when the optimizer has found a good solution, then found steadily worsening solutions. When it stops working and asks you to accept, hitting yes currently accepts the last solution developed, rather than a better one several iterations ago. In my view, it would be better to store the best solution found so far, and when it concludes, Yes should select the best, rather than the most recent. Without this change to the acceptance behavior, running longer isn't likely to be very useful.
• Modify the display of celestial body lists. This applies for example to the list of bodies to consider in SoI transition coasts. It's hard for me to remember whether Hale is a moon of Sarnus or Urlum. Since we already have a heirarchy of planet SoIs, I propose that the hierarchy be displayed when the user is prompted for a list of celestial bodies to choose from. This could be accomplished by a pre-order traversal of the body hierarchy, with prepending of spaces or dashs to each body name equal to its distance from the root of the heirarchy. For example, Sun would have nothing prepended, Kerbin would be indented one space or dash, and Mun would get two. Entities with a common parent would be sorted in order of smallest SMA to largest SMA. The indentation coupled with the pre-order traversal of the tree would result in a logical grouping of planets and moons for the user to choose from.
• Post-optimization scorecard. Sometimes when I'm optimizing in MA, the objective function has improved while the constraints have worsened, or vice versa. It can also be unclear which variables have been changed to result in this new outcome. Proposal: in addition to having a Yes/No dialog to choose whether to accept the new solution, provide an explanation of what changed as well. This would include an explanation of which variables were being tweaked by the optimizer, what their initial and final values were (with delta). Same for the constraints: which constraint was met or unmet, and by how much. This would make it easier for people to identify sticky wickets, like RAAN in our previous discussion, and help identify how much dV is being expended for course corrections etc. Also include the final orbit data, as is currently visible while the optimizer is running. Having all this information available would make it much easier to determine whether the new solution is superior to the original, in the eyes of the orbit analyst. This item would also include a "keep working on it" button, re the persistence setting discussed above.

If I can finish planning this mission, I'd have a couple of suggestions for tweaks to the included tutorials. I'd be happy to provide pull requests for those, though I only see one of them in the source tree on github. I also have an idea or two for additional tutorial PDFs that I might be able to write if someone's willing to verify their technical accuracy.

Anyway, take these or leave them. The tool is already awesome as it is. Much thanks as always!

Edit: also, it would be nice if the optimizer window didn't keep popping to the foreground every time it repainted. Makes it hard to multitask.

Edited July 3, 2016 by jakkarth

[jakkarth]

Alright, giving up for the day. I spent a solid 11 hours today working on this mission and I still haven't gotten to Sarnus, let alone Urlum. It went from exciting to challenging and now frustrating. Here's my current attempt. Note that somehow the optimizer got event 3's radial component outside of the optimizer bounds, which I believe is a bug. You can see I added coasts to Sarnus, but the inbound hyperbolic to Jool was so screwed up that my correction burn at Jool was in excess of 1500m/s when I was planning for 0. My attempts to get the Jool inbound back on track have been unsuccessful. At this point I have no idea why it can't find a workable solution or what to do about it, and I'm too frustrated to keep beating my head against the problem for now. I may look at it again in a couple of days. Thanks for all your help today, have a fun holiday

Edit: event 6 is way out of bounds on all three components as well.

Edited July 3, 2016 by jakkarth

[rasta013]

11 hours ago, Arrowstar said:

I've never used Real Atmospheres before, but by all means give it a whirl and report back with your results.  Thanks!

I am very happy and pleased to report that this is a beautiful tool and believe this should be re-iterated as many times as possible.  It picked up all the atmosphere changes perfectly with absolutely no issues whatsoever for all bodies.  So, chalk up another body changing mod that KSPTOT just shrugs off and chugs along working like a charm!

As always, thank you so much for this utterly amazing and fun tool!

[jakkarth]

I had a breakthrough this morning when I was looking over my notes. It turns out that the initial radius of periapse for the Jool flyby isn't 6200km after all. I had this idea that I had to skim the top of the atmosphere almost in order to make the best use of a gravity assist, but that seems to not by the case in my example. I guess it would have added too much dV? Anyway, adjusting the radius of periapse constraint to match MFMS's suggestion made everything work significantly better. My Jool correction burn is now under 30m/s, and I have had no trouble following the same steps to achieve my Sarnus and Urlum flybys. Thanks for your patience Arrowstar, as we had surmised it was a user error problem, not an issue with the tool. I do occasionally end up with variables outside of their assigned limits though (not constraints, but input variables), but it's manageable.

[Arrowstar]

8 hours ago, rasta013 said:

I am very happy and pleased to report that this is a beautiful tool and believe this should be re-iterated as many times as possible.  It picked up all the atmosphere changes perfectly with absolutely no issues whatsoever for all bodies.  So, chalk up another body changing mod that KSPTOT just shrugs off and chugs along working like a charm!

As always, thank you so much for this utterly amazing and fun tool!

Hurrah!  Glad to hear it.  Thanks for testing it out, and do feel free to ask any other questions you have in the future.  Happy orbiting.

1 hour ago, jakkarth said:

I had a breakthrough this morning when I was looking over my notes. It turns out that the initial radius of periapse for the Jool flyby isn't 6200km after all. I had this idea that I had to skim the top of the atmosphere almost in order to make the best use of a gravity assist, but that seems to not by the case in my example. I guess it would have added too much dV? Anyway, adjusting the radius of periapse constraint to match MFMS's suggestion made everything work significantly better. My Jool correction burn is now under 30m/s, and I have had no trouble following the same steps to achieve my Sarnus and Urlum flybys. Thanks for your patience Arrowstar, as we had surmised it was a user error problem, not an issue with the tool. I do occasionally end up with variables outside of their assigned limits though (not constraints, but input variables), but it's manageable.

Ah, yes, that will do it.  When you fly by major body like Jool, you may not need all of the gravity assist it can provide.  What you're after is not the largest speed increase after the flyby, but the most fuel efficient trajectory from A to B.  Too much gravity assist will be just as problematic in this case as too little.

Anyway, glad you got it figured out! 

Anyway, regarding your suggestions above: I generally like them.  Here are my comments.

Quote

     MFMS warning. Somewhere around page 15 I think, there was a discussion about infinitesimal SoI sizes in KSPTOT tools other than MA. I don't know if this is still the case or not. It was cited as a reason that MFMS results shouldn't be used directly, because you might hit other intermediate SoIs or encounter other problems, and that the results should be used as initial guesses in MA instead. If it is still the case that MFMS results shouldn't be used directly, having some kind of warning on that tool's view might be helpful to people unaware of that. (This would have saved me about 30 minutes when I first got started)

This is an interesting point and I'll take it under consideration.

Quote

    MA Optimizer persistence setting. Sometimes it doesn't even get 1 iteration done before it gives up. Sometimes it stops at a severely suboptimal solution when a better one might exist. Sometimes it just goes on and on and on with no apparent significant change in results. Sometimes you're going to let it run overnight and you don't care how long it takes. It would be nice to have a setting where you could set how aggressively it tries to continue the search, including a "keep looking until I tell you to stop" option. Paired with this, there have been times when the optimizer has found a good solution, then found steadily worsening solutions. When it stops working and asks you to accept, hitting yes currently accepts the last solution developed, rather than a better one several iterations ago. In my view, it would be better to store the best solution found so far, and when it concludes, Yes should select the best, rather than the most recent. Without this change to the acceptance behavior, running longer isn't likely to be very useful.

Unfortunately this one I don't have a ton of control over.  Mission Architect calls an internal MATLAB function called "fmincon" (function minimize constrained) and that code does the actual optimization, only calling bits of MA code to evaluate constraints and the objective function.  The reason the optimizer sometimes takes forever to stop after it looks like it's found a solution is because it has not quite yet met the tolerances for minimum change on either the objective function, the constraint values, or (usually) the variables.  I could make these user definable, but as they have a huge impact on the way the optimizer runs (stops too soon, stops too late, etc) and because they don't correspond to anything physical (they're just an abstract tolerance), I'm more inclined to leave them hidden so people don't get confused.  The current values seem to work well enough most of the time.

Finally, with an optimizer like this there really is no "leave it overnight" functionality possible.  The mathematical algorithm will stop when it is designed to stop, regardless of how long or short it takes.  What you're thinking of is more of a brute-force, "search the whole trade space" kind of approach.  That usually doesn't work well for these sorts of problems, though, as it's impossible to know how coarse or fine the search grid would need to be in order to perform the search.  Not to mention the amount of RAM that would be required to store the results lol.

Quote

    Modify the display of celestial body lists. This applies for example to the list of bodies to consider in SoI transition coasts. It's hard for me to remember whether Hale is a moon of Sarnus or Urlum. Since we already have a heirarchy of planet SoIs, I propose that the hierarchy be displayed when the user is prompted for a list of celestial bodies to choose from. This could be accomplished by a pre-order traversal of the body hierarchy, with prepending of spaces or dashs to each body name equal to its distance from the root of the heirarchy. For example, Sun would have nothing prepended, Kerbin would be indented one space or dash, and Mun would get two. Entities with a common parent would be sorted in order of smallest SMA to largest SMA. The indentation coupled with the pre-order traversal of the tree would result in a logical grouping of planets and moons for the user to choose from.

This one isn't a bad idea and something I'll look into.

Quote

    Post-optimization scorecard. Sometimes when I'm optimizing in MA, the objective function has improved while the constraints have worsened, or vice versa. It can also be unclear which variables have been changed to result in this new outcome. Proposal: in addition to having a Yes/No dialog to choose whether to accept the new solution, provide an explanation of what changed as well. This would include an explanation of which variables were being tweaked by the optimizer, what their initial and final values were (with delta). Same for the constraints: which constraint was met or unmet, and by how much. This would make it easier for people to identify sticky wickets, like RAAN in our previous discussion, and help identify how much dV is being expended for course corrections etc. Also include the final orbit data, as is currently visible while the optimizer is running. Having all this information available would make it much easier to determine whether the new solution is superior to the original, in the eyes of the orbit analyst. This item would also include a "keep working on it" button, re the persistence setting discussed above.

Now this is something I've wanted to do for a while but kept forgetting about.  Anyway, luckily for you, me, and everyone else the actual implementation was very straight-forward, so I just went ahead and did it.  Here's what will come up now after optimization finishes instead of the yes/no prompt that I had before.

The code now lets you select from one of three results: the final optimization iteration (basically this is what you were always getting up until now), the iteration with the best functional value, and the iteration with the best constraint violation value.  The best functional and constraint violation values are highlighted in green to make them obvious.  If multiple iterations have the same value, all iterations with that functional/constraint value get highlighted.

If you want to discard the results of the optimization, you push the button at the button.  This is equivalent to pushing "No" when previously asked if you wanted to keep the optimization results before.

You will notice that I don't have anything on here describing the optimization variables.  There are three reasons for this:

1. When deciding whether to keep an optimization result, decision-making primarily revolves around how well the optimizer did at minimizing the objective function or avoiding constraint violations, not what variable values it had to use to do so.
2. The variable values actually get scaled and normalized and the like before going into the optimizer algorithm, so their actual values are a bit useless.  I could transform them back to their "real" values earlier for something like this, but not without some effort.
3. There really isn't a good way of displaying variable-sized UI elements in MATLAB.  The GUI editor just isn't that sophisticated.

The first point there is the main reason, the others are just support.

Anyway, I'd be happy to hear about your feedback on this!  @Gaiiden, if you have any suggestions or comments, I would appreciate them too!

Oh, finally, you mentioned something about tutorials.

Quote

If I can finish planning this mission, I'd have a couple of suggestions for tweaks to the included tutorials. I'd be happy to provide pull requests for those, though I only see one of them in the source tree on github. I also have an idea or two for additional tutorial PDFs that I might be able to write if someone's willing to verify their technical accuracy.

Please do feel free to provide me with feedback/comments/suggestions on the tutorials!  Ignore the github for now, it hasn't been updated in a long time because I ran into an issue with using the git software on my PC and things got very out of sync. And if you want to write up other tutorials, please by all means do so!  I will check them for technical accuracy and the like.  Thanks!

[jakkarth]

12 minutes ago, Arrowstar said:

Ah, yes, that will do it.  When you fly by major body like Jool, you may not need all of the gravity assist it can provide.  What you're after is not the largest speed increase after the flyby, but the most fuel efficient trajectory from A to B.  Too much gravity assist will be just as problematic in this case as too little.

As far as I can tell in the two PDF tutorials included, both of them push as close to the assisting body as possible (calculations shown for equatorial radius plus height of atmosphere plus fudge room). If it would be easy to do so, finding an example (such as the one I'm working through) to use that shows that scraping the atmosphere isn't always optimal might be beneficial. Otherwise, mentioning it the first time you add the radius of periapsis constraint would be sufficient. In the Solar System Edge tutorial, it might make sense to include it on page 23, where you talk a bit about why you're using radius instead of SMA. Since the mission I'm planning now includes an example of this, basing a tutorial on it might be fun.

 

12 minutes ago, Arrowstar said:

This is an interesting point and I'll take it under consideration.

I'm less convinced this is the case now, as actually using the data it provided turned out to be quite helpful once I realized what I was missing. Instead, I'd like to drop this suggestion and replace it with another.

After using the MFMS to find some flybys, it would be convenient if there was a single-click way to import the results into MA. This would be as simple as coast to true anomaly + (burn + coast to peri) * remaining bodies. Probably also set the initial state. Could optionally include adding constraints for inbound hyperbolic orbital parameters with reasonable bounds. Then one could proceed in adjusting with the optimizer to ensure all bodies are reached correctly, and from there refine the maneuvers for specific mission goals. Saves a little setup time.

12 minutes ago, Arrowstar said:

Unfortunately this one I don't have a ton of control over.  Mission Architect calls an internal MATLAB function called "fmincon" (function minimize constrained) and that code does the actual optimization, only calling bits of MA code to evaluate constraints and the objective function.  The reason the optimizer sometimes takes forever to stop after it looks like it's found a solution is because it has not quite yet met the tolerances for minimum change on either the objective function, the constraint values, or (usually) the variables.  I could make these user definable, but as they have a huge impact on the way the optimizer runs (stops too soon, stops too late, etc) and because they don't correspond to anything physical (they're just an abstract tolerance), I'm more inclined to leave them hidden so people don't get confused.  The current values seem to work well enough most of the time.

Finally, with an optimizer like this there really is no "leave it overnight" functionality possible.  The mathematical algorithm will stop when it is designed to stop, regardless of how long or short it takes.  What you're thinking of is more of a brute-force, "search the whole trade space" kind of approach.  That usually doesn't work well for these sorts of problems, though, as it's impossible to know how coarse or fine the search grid would need to be in order to perform the search.  Not to mention the amount of RAM that would be required to store the results lol.

Disappointing, but an excellent explanation. The machine I'm running KSPTOT on is an 8-core with 32gb ram. Obviously being a 32bit application it can't use all of that memory. How does KSPTOT do with using available cpu cores? I see a lot of mention of vectorization in this thread, but parallelization a bit less often. Perhaps I'll open up the task manager and monitor my next few runs and report my observations.

12 minutes ago, Arrowstar said:

This one isn't a bad idea and something I'll look into.

I hope this makes it in. My current method involves either googling for OPM wiki pages or using the Celestial Body Catalog and brute forcing it by hand.

12 minutes ago, Arrowstar said:

Now this is something I've wanted to do for a while but kept forgetting about.  Anyway, luckily for you, me, and everyone else the actual implementation was very straight-forward, so I just went ahead and did it.  Here's what will come up now after optimization finishes instead of the yes/no prompt that I had before.

The code now lets you select from one of three results: the final optimization iteration (basically this is what you were always getting up until now), the iteration with the best functional value, and the iteration with the best constraint violation value.  The best functional and constraint violation values are highlighted in green to make them obvious.  If multiple iterations have the same value, all iterations with that functional/constraint value get highlighted.

If you want to discard the results of the optimization, you push the button at the button.  This is equivalent to pushing "No" when previously asked if you wanted to keep the optimization results before.

This is absolutely fantastic! The method of selecting which results to use (or discarding) is exactly what I was hoping for, and the display of which values were optimized in which case is great.

12 minutes ago, Arrowstar said:

You will notice that I don't have anything on here describing the optimization variables.  There are three reasons for this:

1. When deciding whether to keep an optimization result, decision-making primarily revolves around how well the optimizer did at minimizing the objective function or avoiding constraint violations, not what variable values it had to use to do so.
2. The variable values actually get scaled and normalized and the like before going into the optimizer algorithm, so their actual values are a bit useless.  I could transform them back to their "real" values earlier for something like this, but not without some effort.
3. There really isn't a good way of displaying variable-sized UI elements in MATLAB.  The GUI editor just isn't that sophisticated.

The first point there is the main reason, the others are just support.

This is somewhat less ideal. I had two thoughts behind asking for the variables to be included, which I should have mentioned originally. First, sometimes I forget which variables I selected when I opened the optimizer, and I've realized at the end of a run that I was tweaking something I didn't intend to. User error to be sure, but labelling the variables with a name (jool flyby burn - prograde) would be a nice safety measure. The other reason is that sometimes I'm not very good at picking my bounds for the variables, and it would be nice to know (possibly even during the optimization run in addition to the end) how close the variables are to their bounds. I don't particularly care about the real values, just how likely it was that the optimal solution was outside of them, without having to look inside each event to see.

On a side note for that last point, I see the yellow warning listing the events close to boundary, but I have to hover over it to see the actual event numbers; they're off the right edge of that list item, and there's no horizontal scrolling.

Any luck with the bug about optimizer pushing the variables out of their bounds?

12 minutes ago, Arrowstar said:

Please do feel free to provide me with feedback/comments/suggestions on the tutorials!  Ignore the github for now, it hasn't been updated in a long time because I ran into an issue with using the git software on my PC and things got very out of sync. And if you want to write up other tutorials, please by all means do so!  I will check them for technical accuracy and the like.  Thanks!

Excellent. Assuming I can get this mission planned, I'd like to do a three-part series. The first would be getting to Urlum by way of Jool and Sarnus, and the second part would be doing flybys of the moons there. The first part would focus more on the gravity assist aspects of it and how to tune the optimizer to get where you want to go, while the second would focus more on timing, dV efficiency and doing rendezvous with planets and moons in a system not centered on Sun. Part three would be about getting all the science back to Kerbin. Basically it would be a MFMS plan kerbin->jool->sarnus->urlum->kerbin, with some stuff mixed in at ulrum in the middle of the circuit.

Assuming I can actually figure out how to do all that, and the tutorial document I provide for your review meets with your approval, I'd be open to suggestions for further ideas to cover. I know I've barely scratched the surface of what KSPTOT is able to accomplish.

Many thanks for your work, and even on a holiday! Any chance I can get a dev build of the optimizer scorecard?

[Stract]

21 hours ago, Arrowstar said:

It does appear that something funny is going on.  Can you check the bodies.ini file you're using to make sure that everything contained in it (that is relevant to your mission design work) looks right?  I'm at a bit of a loss I'm afraid.

Hi again Arrowstar!

Yes, it seems something is wrong with my bodies.ini file. The physical and orbital parameters seems to match with game data (and wikipedia:)). But when I played a bit with my first example (with the Mars), I've noticed that distance between probe and Mars is different in game and in TOT. One hour before entering Mars SOI this difference was about 1000 km. Also the moment of entering the Mars SOI in game happend 6 minutes earlier than TOT expected.  Not much but probably enough to create this error in orbit prediction. So I supposed that position of Mars on its orbit in bodies.ini is slightly shifted from the in-game position. I tweaked the Mars mean anomaly in bodies.ini to fit the Mars fly-by orbit and finally succeded. When I changed the Mars mean anomaly by 0.00029 degrees, all data was matched with a good presision. Confidend that I've found the solution, I decided to do the same for Jupiter fly-by (the second example I've posted earlier). But here this method didn't work for some reason. My ingame Jupiter periapsis is 4.11 Gm, but I wasn't able to get it by tweaking Jupiter mean anomaly in bodies.ini. The tendency was good, the orbit parameters became closer and closer to correct ones while I've increased the mean anomaly step by step. The closest value was 4.05 Gm and about 1 degree difference in inclination, but when I changed the mean anomaly value just a bit more, TOT lose the Jupiter SOI completely. I've tried to play with epoch instead, but the result was the same.

I've checked this in fresh game installation with RSS mod only, but the problem remains there. Still maybe it is just my game version (1.1.2), or something else.

[Drew Kerman]

Loving all of it, great work as always Arrowstar and good job on the suggestions, Jakkarth. Reading your troubles reminded me of when I first started using this tool. Don't worry it just gets easier and more complex at the same time  

[jakkarth]

58 minutes ago, Arrowstar said:

Mission Architect calls an internal MATLAB function called "fmincon"

As I continue to learn new things today, I came across an option in MFMS titled "Number of Runs". It appears to simply run the MFMS calculations over and over. Perhaps such an option could be appropriate for MA's optimizer? I understand the rationale behind not letting users directly tweak the optimizer's stop conditions, but perhaps this would be a reasonable compromise? The Stop button would need to terminate not only the current run, but skip any subsequent runs as well, and then the scorecard could be shown using the best data from each run completed plus the last iteration of the last run.

1 minute ago, Gaiiden said:

Reading your troubles reminded me of when I first started using this tool.

I am glad to find myself in such good company

[jakkarth]

1 hour ago, jakkarth said:

Perhaps I'll open up the task manager and monitor my next few runs and report my observations.

It seems that, at least when calculating flybys with MFMS, only a single core is utilized effectively.

https://imgur.com/u1CiZtR

[Arrowstar]

1 hour ago, jakkarth said:

After using the MFMS to find some flybys, it would be convenient if there was a single-click way to import the results into MA. This would be as simple as coast to true anomaly + (burn + coast to peri) * remaining bodies. Probably also set the initial state. Could optionally include adding constraints for inbound hyperbolic orbital parameters with reasonable bounds. Then one could proceed in adjusting with the optimizer to ensure all bodies are reached correctly, and from there refine the maneuvers for specific mission goals. Saves a little setup time.

So I know this sounds appealing, but trust me when I say it'll just cause more headaches than it will solve.   The big hang up is that the optimizer just can't handle doing more than one or (MAYBE) two legs of the journey at once.  The problem is just too non-linear and small changes in variables can result in very large changes down the road.  Volatile is the word I think I'm looking for.  In any event, if you tried to achieve all the constraints at once while optimizing the mission goals, you would basically just fail spectacularly.  Trust me, I've tried it.   (You're welcome to give it a try and see what I mean!)  There are also some potential usability issues:

New users will assume that the resulting Mission Architect plan will exactly match the plan in MFMS (but it won't because of the infinitesimal sphere of influence as we discussed earlier).  Experienced users will probably end up deleting all but the initial portion of it so they can set up maneuvers and coasts and whatnot as they see fit. 

It's a great suggestion and one I've toyed with in my head since Mission Architect got off the ground.  I just don't see it saving anyone much time once the hassle is factored in.

Quote

Disappointing, but an excellent explanation. The machine I'm running KSPTOT on is an 8-core with 32gb ram. Obviously being a 32bit application it can't use all of that memory. How does KSPTOT do with using available cpu cores? I see a lot of mention of vectorization in this thread, but parallelization a bit less often. Perhaps I'll open up the task manager and monitor my next few runs and report my observations.

So the application should actually be 64-bit.  I'm building everything with the x64 version of MATLAB R2015b.  Does it only show up as a 32-bit application to you?

As far as CPU cores: MATLAB is inherently single-core limited except in two cases:

1) Where MathWorks has optimized the underlying FORTRAN numerical libraries to be multi-threaded; and

2) Where I decide to explicitly make use of multi-threading for calculations.  Most of the time this is not as efficient as writing vectorized code, so I have only done it in one or two places.

Starting the thread pool in MATLAB actually takes like 30 seconds for some weird reason so I don't like using the Parallel Computing Toolbox library unless I really need to.

Quote

This is somewhat less ideal. I had two thoughts behind asking for the variables to be included, which I should have mentioned originally. First, sometimes I forget which variables I selected when I opened the optimizer, and I've realized at the end of a run that I was tweaking something I didn't intend to. User error to be sure, but labelling the variables with a name (jool flyby burn - prograde) would be a nice safety measure. The other reason is that sometimes I'm not very good at picking my bounds for the variables, and it would be nice to know (possibly even during the optimization run in addition to the end) how close the variables are to their bounds. I don't particularly care about the real values, just how likely it was that the optimal solution was outside of them, without having to look inside each event to see.

I can definitely understand wanting this information.  But my confusion comes in when I think about how it would help you choose what to do with the optimizer output.  Are you making the decision in part based on the values of the variables?  If not, why not just accept the optimizer result based on the objective function value and/or constraint value and then look up the variables information in the main UI afterwards?

Keep in mind that you can undo optimization (Edit -> Undo) so if you do something you didn't want to do (like having the wrong variables selected), fixing it is a few clicks away.

Quote

On a side note for that last point, I see the yellow warning listing the events close to boundary, but I have to hover over it to see the actual event numbers; they're off the right edge of that list item, and there's no horizontal scrolling.

Yeah, that whole scroll area is a bit of a hack unfortunately lol.  MATLAB doesn't really have scroll panes in it, so I was able to fake the vertical scrolling with a bit of a trick.  Horizontal scrolling, I'm not sure how that would work.  For now, just use the mouse-over text to read the whole message while I think about improving that.

Quote

Any luck with the bug about optimizer pushing the variables out of their bounds?

This is actually an issue with FMINCON.  It doesn't necessarily respect bounds at every iteration, despite my insistence that it do so.  I've looked into it before without much luck, sadly.  Probably won't be able to do much here.

Quote

Excellent. Assuming I can get this mission planned, I'd like to do a three-part series. The first would be getting to Urlum by way of Jool and Sarnus, and the second part would be doing flybys of the moons there. The first part would focus more on the gravity assist aspects of it and how to tune the optimizer to get where you want to go, while the second would focus more on timing, dV efficiency and doing rendezvous with planets and moons in a system not centered on Sun. Part three would be about getting all the science back to Kerbin. Basically it would be a MFMS plan kerbin->jool->sarnus->urlum->kerbin, with some stuff mixed in at ulrum in the middle of the circuit.

This all sounds great!  Let me know when you have something you want to share.

Quote

Many thanks for your work, and even on a holiday! Any chance I can get a dev build of the optimizer scorecard?

Enjoy!  Please provide feedback on what you think along with any new suggestions to improve the scorecard that you come up with while using it.

1 hour ago, Gaiiden said:

Loving all of it, great work as always Arrowstar

Thanks!

1 hour ago, jakkarth said:

As I continue to learn new things today, I came across an option in MFMS titled "Number of Runs". It appears to simply run the MFMS calculations over and over. Perhaps such an option could be appropriate for MA's optimizer? I understand the rationale behind not letting users directly tweak the optimizer's stop conditions, but perhaps this would be a reasonable compromise? The Stop button would need to terminate not only the current run, but skip any subsequent runs as well, and then the scorecard could be shown using the best data from each run completed plus the last iteration of the last run.

This works for MFMS because I use a genetic algorithm that, by definition, starts at a different point (or really, 1000 different points) within the trade space at each run.  And each starting point is completely random, which is why the results of the MFMS are also somewhat random.  The ability to do this, by the way, is a unique feature of genetic algorithms.

This is not the case for MA.  FMINCON is a deterministic optimization algorithm, which means that it returns the same results for the same inputs.  The optimization also always starts with a known starting point: the mission plan as it currently exists.  So we have "same inputs" + "deterministic algorithm" = "same result each time."  This means that it doesn't matter how many times you run the MA optimizer, you'll get the same result back each time.  And because of this, it doesn't make sense to implement that kind of feature that MFMS has in MA.

45 minutes ago, jakkarth said:

It seems that, at least when calculating flybys with MFMS, only a single core is utilized effectively.

https://imgur.com/u1CiZtR

Correct, see my notes above.  MFMS is highly vectorized but this has the disadvantage of primarily sitting on one CPU.  Note that going to a parallel solution would be an order of magnitude slower than what I have now because vectorized code in MATLAB is insanely fast, so this is probably as good as it's going to get.  And no, parallelizing the vectorization across more than one CPU is not supported by MATLAB at the moment.  

1 hour ago, Stract said:

Hi again Arrowstar!

Yes, it seems something is wrong with my bodies.ini file. The physical and orbital parameters seems to match with game data (and wikipedia:)). But when I played a bit with my first example (with the Mars), I've noticed that distance between probe and Mars is different in game and in TOT. One hour before entering Mars SOI this difference was about 1000 km. Also the moment of entering the Mars SOI in game happend 6 minutes earlier than TOT expected.  Not much but probably enough to create this error in orbit prediction. So I supposed that position of Mars on its orbit in bodies.ini is slightly shifted from the in-game position. I tweaked the Mars mean anomaly in bodies.ini to fit the Mars fly-by orbit and finally succeded. When I changed the Mars mean anomaly by 0.00029 degrees, all data was matched with a good presision. Confidend that I've found the solution, I decided to do the same for Jupiter fly-by (the second example I've posted earlier). But here this method didn't work for some reason. My ingame Jupiter periapsis is 4.11 Gm, but I wasn't able to get it by tweaking Jupiter mean anomaly in bodies.ini. The tendency was good, the orbit parameters became closer and closer to correct ones while I've increased the mean anomaly step by step. The closest value was 4.05 Gm and about 1 degree difference in inclination, but when I changed the mean anomaly value just a bit more, TOT lose the Jupiter SOI completely. I've tried to play with epoch instead, but the result was the same.

I've checked this in fresh game installation with RSS mod only, but the problem remains there. Still maybe it is just my game version (1.1.2), or something else.

Well that's strange.  Could it be a numerical truncation issue with the values in the bodies.ini file maybe?

[jakkarth]

57 minutes ago, Arrowstar said:

So I know this sounds appealing, but trust me when I say it'll just cause more headaches than it will solve.   The big hang up is that the optimizer just can't handle doing more than one or (MAYBE) two legs of the journey at once.  The problem is just too non-linear and small changes in variables can result in very large changes down the road.  Volatile is the word I think I'm looking for.  In any event, if you tried to achieve all the constraints at once while optimizing the mission goals, you would basically just fail spectacularly. 

My intention wasn't to optimize the entire path at once, but rather to check the opt? flags on the initial departure burn and run, then turn them off and turn on the ones for arrival at jool and run, etc. What I've been doing so far today has been to take the values from MFMS and plug them into each coast/burn as I go along, using MFMS values as initial guesses, and it's working out surprisingly well. I can understand the concern of someone not understanding that doing it in steps is required though. Perhaps a better approach would be to be able to copy-paste burns similar to how we can sometimes copy-paste orbits now. Or maybe it really won't save any trouble after all. You may have talked me out of this one.

57 minutes ago, Arrowstar said:

Starting the thread pool in MATLAB actually takes like 30 seconds for some weird reason so I don't like using the Parallel Computing Toolbox library unless I really need to.

57 minutes ago, Arrowstar said:

This is not the case for MA.  FMINCON is a deterministic optimization algorithm, which means that it returns the same results for the same inputs.  The optimization also always starts with a known starting point: the mission plan as it currently exists.  So we have "same inputs" + "deterministic algorithm" = "same result each time."  This means that it doesn't matter how many times you run the MA optimizer, you'll get the same result back each time.  And because of this, it doesn't make sense to implement that kind of feature that MFMS has in MA.

57 minutes ago, Arrowstar said:

And no, parallelizing the vectorization across more than one CPU is not supported by MATLAB at the moment.  

Well that's strange.  Could it be a numerical truncation issue with the values in the bodies.ini file maybe?

Is that 30 seconds per operation, or 30 seconds at application start? Even in the second case that sounds absurd. I've written multithreaded applications, including ones that use prebuilt pool libraries and ones where I've built my own, that don't have that kind of start-up penalty. I guess you've got to work with what you've got though. Not a criticism, just surprising to me. My goal in suggesting it was that perhaps you could have the vectorized code running different passes at the same time, but you've shot that down as well.

I was under the impression that MA's optimizer had some element of randomness to it as it adjusted the input variables. If it is deterministic, then running multiple of them in parallel will not provide any benefit, I agree. I don't know whether it makes sense to suggest adding some randomness or not; it seems like a genetic algorithm approach wouldn't be out of the question here, would it? Or perhaps we could use some GPU/CUDA/OpenCL horsepower?

57 minutes ago, Arrowstar said:

I can definitely understand wanting this information.  But my confusion comes in when I think about how it would help you choose what to do with the optimizer output.  Are you making the decision in part based on the values of the variables?  If not, why not just accept the optimizer result based on the objective function value and/or constraint value and then look up the variables information in the main UI afterwards?

This is likely just naivety on my part. If I hit the boundaries, that would seem to indicate that I'm asking the optimizer the wrong questions. If I max out my prograde on the jool assist burn, maybe that means I should be decreasing my periapsis instead, for example. The problem I'm facing at the moment is that I'm not familiar enough with what's going on to understand intuitively which variables hitting the boundaries would indicate what I should try next, and my default mode of operation is to try to collect more data on which to base my decisions. I agree that the information you've already included in the scorecard is more valuable than the input variable values, and if you don't think it's worth including I'm inclined to trust your judgement. I already have enough ways to shoot myself in the foot

57 minutes ago, Arrowstar said:

Yeah, that whole scroll area is a bit of a hack unfortunately lol.  MATLAB doesn't really have scroll panes in it, so I was able to fake the vertical scrolling with a bit of a trick.  Horizontal scrolling, I'm not sure how that would work.  For now, just use the mouse-over text to read the whole message while I think about improving that.

It might be as simple as making the text shorter, or putting the event numbers at the beginning of the string instead of the end.

57 minutes ago, Arrowstar said:

This is actually an issue with FMINCON.  It doesn't necessarily respect bounds at every iteration, despite my insistence that it do so.  I've looked into it before without much luck, sadly.  Probably won't be able to do much here.

Hopefully I won't be bumping into the boundaries in the first place, but if I do, perhaps you could display a note in the warnings and errors pane that some input variables are now outside of their designated tolerances? There's already a warning for being near them, it seems simple enough to update the verbiage if they're actually outside. While not a perfect fix, it could possibly avoid some confusion.

Enough writing, time to try out the new build!

 

 

[Arrowstar]

2 hours ago, jakkarth said:

Is that 30 seconds per operation, or 30 seconds at application start? Even in the second case that sounds absurd. I've written multithreaded applications, including ones that use prebuilt pool libraries and ones where I've built my own, that don't have that kind of start-up penalty. I guess you've got to work with what you've got though. Not a criticism, just surprising to me. My goal in suggesting it was that perhaps you could have the vectorized code running different passes at the same time, but you've shot that down as well.

It's one roughly 30 second hit at application start (or, more correctly, whenever you call the parallelpool() function).  I have no idea why it takes so long for the thread pool to finish initializing, but it's definitely a non-trivial amount of time.  I've also done multi-threaded work in Java directly and that was fine, as you've hinted at.  It's something on the MATLAB side that causes the issue, but I just don't know what it is.

Quote

I was under the impression that MA's optimizer had some element of randomness to it as it adjusted the input variables. If it is deterministic, then running multiple of them in parallel will not provide any benefit, I agree. I don't know whether it makes sense to suggest adding some randomness or not; it seems like a genetic algorithm approach wouldn't be out of the question here, would it? Or perhaps we could use some GPU/CUDA/OpenCL horsepower?

MA's optimizer is completely deterministic.  It uses an algorithm called "interior point" if you're interested in looking more into it.  It's the best compromise between performance and robustness that MATLAB offers at the moment within the context of FMINCON.  There's alsono real way to add randomness to it besides perturbing the initial inputs, and that just sounds problematic.

Quote

Hopefully I won't be bumping into the boundaries in the first place, but if I do, perhaps you could display a note in the warnings and errors pane that some input variables are now outside of their designated tolerances? There's already a warning for being near them, it seems simple enough to update the verbiage if they're actually outside. While not a perfect fix, it could possibly avoid some confusion.

I could do that, might be worth a look there.

Quote

Enough writing, time to try out the new build!

Enjoy!  Let me know what you think.

[jakkarth]

22 minutes ago, Arrowstar said:

MA's optimizer is completely deterministic.  It uses an algorithm called "interior point" if you're interested in looking more into it.  It's the best compromise between performance and robustness that MATLAB offers at the moment within the context of FMINCON.  There's alsono real way to add randomness to it besides perturbing the initial inputs, and that just sounds problematic.

There's no way to add some random jitter to the weights of the constraints or optimizing function perhaps?

Quote

I could do that, might be worth a look there.

While you're tweaking labels and such, in the MFMS I noticed that changing the root celetisal body doesn't correctly update the window labels directly below the target list. It tends to say kerbin->eve when I select Urlum. Obviously trivial but I figured I'd mention it. https://imgur.com/4Gbfb5N

Quote

Enjoy!  Let me know what you think.

Loving it so far! I tried running it on a different machine so I could ksp simultaneously, but the other machine's performance was suboptimal.

I recall something earlier in the thread about printable report sheets for maneuvers, that had diagrams and burn details etc. Is there something like that I could use to make pretty pictures for tutorial purposes?

Edited July 4, 2016 by jakkarth

[jakkarth]

Ok, I'm sure there's an obvious solution for this, and I feel silly for asking, but here goes anyway. So I've made it to Urlum, I've done my insertion burn and I've got a nice circular orbit. Now I just need to wait a little while for the moons to align, and I can set off on a cheap flyby of the moons. I set MFMS to open the window after several orbits are completed around Urlum, and it finds me a nice set of maneuvers. This is where I get stuck. In the tutorials, I was going from Kerbin to Eve or similar; they're both children. Now I'm going from orbit of a parent body to orbit of a child body. This means I can't use the initial orbit in MFMS to calculate my burn to start the flybys, and I can't use the main porkchop plot because the start and end have different parents. This leaves me with the Rendezvous Maneuver Sequencer, which gives me some information about the burn, but I can't specify an arrival time and orbit to optimize for. My plan was to take the burn parameters and transit duration, subtract the duration from my desired arrival time and use the parameters as initial guesses, and let MA's optimizer find me a burn that will send me off to Polta with the right values to be on track for the start of the flyby. However, this is proving problematic, as the transfer from my parking orbit to Polta is out of phase with the start of the flyby mission, so getting the orbital parameters to line up is proving problematic.

Would it be better to recalculate MFMS with a very narrow start window based on my desired transfer from parking orbit to Polta? Is there some tool I'm missing specifically designed for this problem (transfer from parent to child with specific child inbound characteristics)? Is my approach completely insane? Any guidance on how to approach this problem would be appreciated.

One other small suggestion I've come across in dealing with this exercise: it would be nice to have "copy orbit to clipboard" be an option for entries in the event list in MA, rather than having to view state at event and then copy. Silly for sure, it's just two extra clicks, but I've done it about 10 times in the last hour so I figured I'd mention it.

And one final theory question for the evening: what circumstances cause the MA optimizer to bail after 0 iterations? I run into this sometimes and I have no idea what to do about it.

Edited July 5, 2016 by jakkarth

[Arrowstar]

16 minutes ago, jakkarth said:

Ok, I'm sure there's an obvious solution for this, and I feel silly for asking, but here goes anyway. So I've made it to Urlum, I've done my insertion burn and I've got a nice circular orbit. Now I just need to wait a little while for the moons to align, and I can set off on a cheap flyby of the moons. I set MFMS to open the window after several orbits are completed around Urlum, and it finds me a nice set of maneuvers. This is where I get stuck. In the tutorials, I was going from Kerbin to Eve or similar; they're both children. Now I'm going from orbit of a parent body to orbit of a child body. This means I can't use the initial orbit in MFMS to calculate my burn to start the flybys, and I can't use the main porkchop plot because the start and end have different parents. This leaves me with the Rendezvous Maneuver Sequencer, which gives me some information about the burn, but I can't specify an arrival time and orbit to optimize for. My plan was to take the burn parameters and transit duration, subtract the duration from my desired arrival time and use the parameters as initial guesses, and let MA's optimizer find me a burn that will send me off to Polta with the right values to be on track for the start of the flyby. However, this is proving problematic, as the transfer from my parking orbit to Polta is out of phase with the start of the flyby mission, so getting the orbital parameters to line up is proving problematic.

Would it be better to recalculate MFMS with a very narrow start window based on my desired transfer from parking orbit to Polta? Is there some tool I'm missing specifically designed for this problem (transfer from parent to child with specific child inbound characteristics)? Is my approach completely insane? Any guidance on how to approach this problem would be appreciated.

Using RMS is in fact the correct approach.  Put your pre-burn orbit into the "Initial Orbit Info" area and select the target celestial body in the "Final (Desired) Orbit Info" area.

You actually can specify an arrival time, of sorts.  No, you can't specify an exact arrival time.  But set the "Initial Epoch" area to, for example, the epoch of the initial orbit.  Make sure you set the search window length to an appropriate value (You may have to play around with it).

You can try to use MA to target the burn directly, of course, optimizing on the burn true anomaly and burn delta-v vector, with the objective function set to "Minimize Distance to Body".  You may have varied results with this approach though.

Does this makes sense?

Quote

One other small suggestion I've come across in dealing with this exercise: it would be nice to have "copy orbit to clipboard" be an option for entries in the event list in MA, rather than having to view state at event and then copy. Silly for sure, it's just two extra clicks, but I've done it about 10 times in the last hour so I figured I'd mention it.

Good suggestion, thanks!

Quote

And one final theory question for the evening: what circumstances cause the MA optimizer to bail after 0 iterations? I run into this sometimes and I have no idea what to do about it.

This occurs when one of a few things occur:

1. The optimizer can't find a direction to move because all of the gradients it evaluates are upwards (basically the optimizer thinks it's at a local minimum).
2. The optimizer can't find a direction that minimizes the maximum violated constraint value.

The way around this is to either change up your objective function or loosen up at least one of your constraints.

[jakkarth]

2 minutes ago, Arrowstar said:

Using RMS is in fact the correct approach.  Put your pre-burn orbit into the "Initial Orbit Info" area and select the target celestial body in the "Final (Desired) Orbit Info" area.

2 minutes ago, Arrowstar said:

You actually can specify an arrival time, of sorts.  No, you can't specify an exact arrival time.  But set the "Initial Epoch" area to, for example, the epoch of the initial orbit.  Make sure you set the search window length to an appropriate value (You may have to play around with it).

So, basically that's what I had tried. The issue is that the Final Orbit Info is relative to the parent body, while I wanted to specify orbit values for the child body when crossing the SoI boundary. So it sounds like I was on the right track and I just need to beat my head against it some more.

2 minutes ago, Arrowstar said:

You can try to use MA to target the burn directly, of course, optimizing on the burn true anomaly and burn delta-v vector, with the objective function set to "Minimize Distance to Body".  You may have varied results with this approach though.

This is where I end up after following the above suggestion. I take the values that RMS provides and use them as a basis for MA to try to get to Polta, and I can get into the SoI, but apparently the angle is so wrong that MA can't find a way to swing me around to point the way I want to go. I may have to resort to one or two additional corrective burns to get the right attitude at periapse.

2 minutes ago, Arrowstar said:

Does this makes sense?

Using RMS  to do a transfer to Polta makes sense. Using MA to target the Polta orbital parameters I need makes sense. I even have some sense for how they achieve their results. They are oracles; they can always provide an answer. The difficulty lies in formulating the question.

2 minutes ago, Arrowstar said:

This occurs when one of a few things occur:

1. The optimizer can't find a direction to move because all of the gradients it evaluates are upwards (basically the optimizer thinks it's at a local minimum).
2. The optimizer can't find a direction that minimizes the maximum violated constraint value.

The way around this is to either change up your objective function or loosen up at least one of your constraints.

I don't see "create forehead-shaped dent in the nearest wall" on your list. I'll try your suggestions instead.

[Arrowstar]

6 minutes ago, jakkarth said:

Using RMS  to do a transfer to Polta makes sense. Using MA to target the Polta orbital parameters I need makes sense. I even have some sense for how they achieve their results. They are oracles; they can always provide an answer. The difficulty lies in formulating the question.

You've basically got the process I use down.  RMS to get the estimated burn parameters and timing and Mission Architect to adjust these parameters to target the orbit you want.  You may need another maneuver at some point within the SoI of the moon you're going to.  Look at using the Optimal Two Burn Orbit Change application to estimate what those maneuvers might need to be.

Quote

I don't see "create forehead-shaped dent in the nearest wall" on your list. I'll try your suggestions instead.

Sorry about that, Mission Architect does have a bit of a learning curve!  Take solstice in the fact that it's even harder to do this stuff in real life.

[blu3wolf]

2 hours ago, Arrowstar said:

Sorry about that, Mission Architect does have a bit of a learning curve!  Take solstice in the fact that it's even harder to do this stuff in real life.

Speaking of which, would it be feasible for a future version of this tool to support planning for Principia?

[Arrowstar]

13 hours ago, blu3wolf said:

Speaking of which, would it be feasible for a future version of this tool to support planning for Principia?

Possible?  Yes. Feasible?  Not really. The whole of Mission Architect is based on the patched conics model and depends on it. I could rip that out, but it wouldn't be easy or pretty.

Sorry! :-) 

[blu3wolf]

So... I wonder if there are some real world mission planning tools that could be used for that purpose.

I want to try out Principia, but I dont think Im going to start a career game where I couldnt rely on Mission Architect. Although... up to a point, the patched conics model is close to n body gravitation, right? Perhaps MA would still be useful to a point anyway.

[Arrowstar]

34 minutes ago, blu3wolf said:

So... I wonder if there are some real world mission planning tools that could be used for that purpose.

I want to try out Principia, but I dont think Im going to start a career game where I couldnt rely on Mission Architect. Although... up to a point, the patched conics model is close to n body gravitation, right? Perhaps MA would still be useful to a point anyway.

As long as you're not relying on significant third body gravity (Lagrange points, 3-body problem type orbits, etc), Mission Architect will be a fine approximation.  Otherwise, you may not have much luck unfortunately.

There are some free mission analysis tools you could look at.  Best bet might be GMAT, but I've never used it myself.  I have no idea how hard or easy it is to use.  You're welcome to try it though!

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

I'm happy to announce that I've compiled pre-release 7 of the KSP Trajectory Optimization Tool v1.5.5.  Changes are below (from pre-release 5 as I didn't really announce 6, heh):

• Replaced the previous end-of-optimization prompt with a scorecard that allows the user to choose between the final optimization result, the optimization iteration with the best objective function value, or the optimization iteration with the best constraint value.
• Added "Copy Orbit After Selected Event" item to MA script context menu
• Lists of celestrial bodies which contain the full body list are now arranged in a hierarchical order with appropriate indenting.
• Fixed bug with MFMS in which the waypoint panel header did not update when the central body is changed.

Download link: https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v155_prerelease7.zip

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

[jakkarth]

15 hours ago, Arrowstar said:

• Replaced the previous end-of-optimization prompt with a scorecard that allows the user to choose between the final optimization result, the optimization iteration with the best objective function value, or the optimization iteration with the best constraint value.
• Added "Copy Orbit After Selected Event" item to MA script context menu
• Lists of celestrial bodies which contain the full body list are now arranged in a hierarchical order with appropriate indenting.
• Fixed bug with MFMS in which the waypoint panel header did not update when the central body is changed.

You are giving Kris Kringle a run for his money and it's only July! No bugs encountered yet.

I did have a question about how MA does the "advance script to this point" function. Am I correct that it basically involves using the data from "view state after selected event" to create a new initial state, and then throws away all of the events up to and including the one that was originally selected? If so, I possible optimization (that you have probably already thought of) would be to use this functionality internally when optimizing, creating an initial state in the same manner based on the event just prior to the first event with optimizable input variables. This would mean getting to skip SoI searches etc for all the events leading up to the first event with an optimizable input variable, which could conceivably save a bit of processing time. You probably already do this, or have a good reason not to, but on the off chance it hadn't occurred to you I figured I'd mention it.

Great work as always! What's the next killer feature you've got in the works?