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

[Arrowstar]

1 hour ago, Tonas1997 said:

Sorry for not getting back at you, but it worked! Sadly it ate up all my memory and froze my computer when I tried to calculate a transfer with 3 gravity assists, so next time I'll go lighter on TOT

I'm sorry you had some issues with KSPTOT.  Out of curiosity, could you tell me a bit about your computer?  How much RAM and hard drive storage space do you have?  Do you know what the processor is?  KSPTOT can be a bit intensive, but the flyby tool shouldn't be causing your computer to crash.

[Tonas1997]

8 hours ago, Arrowstar said:

I'm sorry you had some issues with KSPTOT.  Out of curiosity, could you tell me a bit about your computer?  How much RAM and hard drive storage space do you have?  Do you know what the processor is?  KSPTOT can be a bit intensive, but the flyby tool shouldn't be causing your computer to crash.

Well, it didn't crash, but it froze. RAM usage went up to 98% on the "calculating Delta-V" stage - possibly even more, but even the task manager was clogged up at that time.

Anyways, here are my specs:

RAM: 16Gb

CPU: i5-8265U

HDD: 1Tb, about half of which is free

[Arrowstar]

13 hours ago, Tonas1997 said:

Well, it didn't crash, but it froze. RAM usage went up to 98% on the "calculating Delta-V" stage - possibly even more, but even the task manager was clogged up at that time.

Anyways, here are my specs:

RAM: 16Gb

CPU: i5-8265U

HDD: 1Tb, about half of which is free

Wow, that should not have been the case with those specs.  Could you tell me how to reproduce this freezing and high RAM usage?

[Drew Kerman]

@Arrowstar it doesn't seem like the drag aero properties event allows you to change only the frontal area. I mean, you should be able to change the drag coefficient values too if needed but if not, can there be a preserve option like for steering?

also I did not think through the implications of that new Cd import tool. FAR can log its data now (yay!) and so I was able to import 939 data points for my drag calculations. Then I asked the optimizer to constrain my ascent path and it took... sooo.. loooong....... to do.... anythinggggggggg like literally 10min before I saw it update an iteration. I finally realized why when I opened an earlier case file where I was still manually putting in drag update events and the file had like twice as many main sequence events but loaded faster. So I went and reduced the FAR log data by 1/2 (mid) and 1/4 (coarse). Now I start with the coarse data when initially plotting my ascent using large constraints. Tighten the constraints and load up the mid data then finally tighten them more and load up the fine data. Actually next time I might just start with no drag at all for the very rough ascent profile.

An additional concern about the optimizer is that KSPTOT had ballooned to over 2GB of RAM by the time I had gotten what I wanted and it didn't seem to slim down on its own. I think that's probably more of a matlab issue tho

Edited June 22, 2020 by Drew Kerman

[Arrowstar]

12 hours ago, Drew Kerman said:

@Arrowstar it doesn't seem like the drag aero properties event allows you to change only the frontal area. I mean, you should be able to change the drag coefficient values too if needed but if not, can there be a preserve option like for steering?

I'll look into it, thanks for the suggestion.

Quote

also I did not think through the implications of that new Cd import tool. FAR can log its data now (yay!) and so I was able to import 939 data points for my drag calculations. Then I asked the optimizer to constrain my ascent path and it took... sooo.. loooong....... to do.... anythinggggggggg like literally 10min before I saw it update an iteration. I finally realized why when I opened an earlier case file where I was still manually putting in drag update events and the file had like twice as many main sequence events but loaded faster. So I went and reduced the FAR log data by 1/2 (mid) and 1/4 (coarse). Now I start with the coarse data when initially plotting my ascent using large constraints. Tighten the constraints and load up the mid data then finally tighten them more and load up the fine data. Actually next time I might just start with no drag at all for the very rough ascent profile.

Could I see one of the MAT files where things are running slowly?  I'd like to profile it to see where the slowdown is.  But yes, in general, try not to use more data than is strictly needed to get things to run accurately.

Quote

An additional concern about the optimizer is that KSPTOT had ballooned to over 2GB of RAM by the time I had gotten what I wanted and it didn't seem to slim down on its own. I think that's probably more of a matlab issue tho

This may not be fully me, as you mentioned.  There's a lot of code in memory with LVD and MATLAB holds all that for performance reasons.  It is starting to feel like at least 4 GB RAM is necessary to run KSPTOT plus the rest of the Windows operating system and other applications, yeah.  I wish I had better news in this regard, but more features in KSPTOT means more code and that means more RAM usage.

[Drew Kerman]

1 hour ago, Arrowstar said:

Could I see one of the MAT files where things are running slowly?

I'll do better than that. Here you go. I included the 3 CSV drag files as well as 3 MAT files with the values pre-loaded and in a state where the pitch constraints on the ascent profile aren't quite on target and the min/max steering values are still pretty wide if you want to run the optimizer like that and then also with them more constrained. For comparison I have an i7-4790K running at ~4.4GHz and it takes me 5.991 seconds to execute the Coarse case file, 9.840 seconds to execute the Mid case file and 17.356 seconds to execute the Fine case file

1 hour ago, Arrowstar said:

This may not be fully me, as you mentioned.  There's a lot of code in memory with LVD and MATLAB holds all that for performance reasons.  It is starting to feel like at least 4 GB RAM is necessary to run KSPTOT plus the rest of the Windows operating system and other applications, yeah.  I wish I had better news in this regard, but more features in KSPTOT means more code and that means more RAM usage.

No worries on my end, I'm running 24GB of RAM now. Just wanted to bring it to your attention

[Arrowstar]

50 minutes ago, Drew Kerman said:

I'll do better than that. Here you go. I included the 3 CSV drag files as well as 3 MAT files with the values pre-loaded and in a state where the pitch constraints on the ascent profile aren't quite on target and the min/max steering values are still pretty wide if you want to run the optimizer like that and then also with them more constrained. For comparison I have an i7-4790K running at ~4.4GHz and it takes me 5.991 seconds to execute the Coarse case file, 9.840 seconds to execute the Mid case file and 17.356 seconds to execute the Fine case file

Thanks for pointing this out.  The amount of drag coefficient data is definitely going to be a part of it, not so much from the overhead in holding that in memory (it's pretty small), but the way the integrator needs to control error by handling the fact that the drag coefficient is changing more frequently, which results in more time steps.  You have a few choices to mitigate this:

• Accept the performance as-is (which, btw, is half the time I spent propagating the "fine" MAT file lol); or
• Reduce the integration tolerance on ODE45 and consider switching to ODE113 for the longer two coasts at the end of the file; or
• Switch events 4-8 to use the ODE5 integrator with a time step that you believe offers sufficient accuracy.

I was able to get the run time down from 30 seconds to 7 seconds by a combination of the latter two items and I believe the impact to accuracy wasn't so bad that it wouldn't be acceptable for me, but that decision is up to you.  Just remember with ODE5, smaller time step means more CPU time and higher accuracy; and larger time step means less CPU time and lower accuracy.

[Arrowstar]

Hi, KSPTOT community!

Tonight I'm excited to announce that I'm working on an experimental feature I'm calling "plugins" for Launch Vehicle Designer.  Have you ever found yourself wanting to do something complicated in LVD,  something that would require a lot of work under the LVD hood and might only be useful for your specific situation?  Plugins are designed to handle these sorts of cases by allowing you, the user, to write active MATLAB code that can interact with the LVD data in memory, modify it, and even manipulate some minor elements of the LVD UI:

I envision that plugins will be allowed to execute at one or more of five points during trajectory propagation:

1. Immediately prior to execution of the mission script;
2. Immediately prior to the execution of sequential events;
3. Immediately after the execution of sequential events;
4. Immediately after the execution of the mission script; and
5. Immediately after each integrator time step.

The first four of these is basically already working, as you can see in the image above.  The fifth will come later, as it will require some additional complexity to interface with the ODE suite's output function interface.

I envision that plugins will be coded by the user in a user interface that I still need to create, but that would work somewhat like the MATLAB IDE, though significantly more limited (think syntax highlighting and line numbers only).  I want to also have a tree menu that breaks down the object structure of the LVD data in memory and shows object properties and methods.

I will warn people ahead of time that use of this feature will have a steep learning curve, as it will involve learning not only the MATLAB language but also the LVD data and how it is structured.  I will also warn that it will be possible to completely hose your mission with this functionality, though luckily the Undo and Redo functionality should be helpful in making sure you don't lose everything completely.  (Undo/Redo stores the complete LVD data set in memory after each action and "undoing" or "redoing" just involves loading that data set up and propagating again.)  However, if you can get over those hurdles, this should be an immensely powerful tool to do things not currently possible in LVD, and that may never be possible in stock LVD.

Since this work basically just started, I'm open to comments and suggestions for functionality you might like to see.  Please let me know, thanks!

[Drew Kerman]

2 hours ago, Arrowstar said:

I'm open to comments and suggestions for functionality you might like to see

I wish I had some but this is so beyond me right now still. However I can see it becoming a powerful tool in the future as my rocket and mission complexity gradually increases so excited to see it implemented even in a basic form to begin with

[Drew Kerman]

@Arrowstar I tried to use LVD to determine when there would be an eclipse over KSC and also was wondering if this would work so I could use it for checking stuff like sun position over future bases and such. I set the lat/lng to KSC and the alt to .7km and enabled hold down clamps, increased the max sim time so I could set the first event to a week's worth of seconds and also made the integrator step output 60s. but when I plotted for eclipse it just showed 1 for the entire time, and plotting for altitude came up with a crazy result rather than just a flat .7km. Is this whole concept out of bounds?

Edited June 25, 2020 by Drew Kerman

[Arrowstar]

3 hours ago, Drew Kerman said:

@Arrowstar I tried to use LVD to determine when there would be an eclipse over KSC and also was wondering if this would work so I could use it for checking stuff like sun position over future bases and such. I set the lat/lng to KSC and the alt to .7km and enabled hold down clamps, increased the max sim time so I could set the first event to a week's worth of seconds and also made the integrator step output 60s. but when I plotted for eclipse it just showed 1 for the entire time, and plotting for altitude came up with a crazy result rather than just a flat .7km. Is this whole concept out of bounds?

Can I see a MAT file?

[Drew Kerman]

3 hours ago, Arrowstar said:

Can I see a MAT file?

Certainly

[Arrowstar]

2 hours ago, Drew Kerman said:

Certainly

Alright, well, I can certainty see that there's a problem.  I'll dig into it, thanks!

EDIT: Well that was easy.  Should be resolved for next release.

Edited June 25, 2020 by Arrowstar

[Arrowstar]

Something like this?  Can you verify for me if there's a munar eclipse in there somewhere around the halfway point?  That funny spike in the otherwise uniform distribution shouldn't be happening if only Kerbin was involved.

 

[Chocolat Oreos]

On 5/26/2020 at 4:33 PM, Gilph said:

Hi, sorry for the late response...been playing No Man's Sky for the past few weeks.

Without some more data, I can try and give some general answers. I'm a long time user of TOT, although I'm not a huge expert in orbital mechanics.

Most things in TOT give approximations of a solution, and those should be input into Mission Architect (MA). There are several MA examples to help you with how to set it up including multi-flybys.  MA is the thing that will take the approximate values and fine tune them based on your criteria to give a more solid answer. But, there is always some general tweaking to make it work once you import, and, once you start, there will always be tweaking based on how well you executed the prior step.

Some of the manouver utilities, which I use heavily, are amazingly accurate without the need for MA, but if you are needing to plan a multi manouver plan, MA is usually the final word.

I haven't been able to learn the multi flyby to find specific routes yet, but I sometimes will find one in game by playing around a bit. When I do, I start TOT and put the steps in MA to see if MA will calculate the same answer. Then I'll experiment with the different ways to run the optimizer in MA and see the result. That was a really good tutorial for me.

Hope this helps.

Great, I'll start digging into the MA part of the program, see if I can figure it out a little bit.

Thanks man, and also, sorry for the late replay  

[Drew Kerman]

On 6/25/2020 at 10:52 PM, Arrowstar said:

Something like this?  Can you verify for me if there's a munar eclipse in there somewhere around the halfway point?  That funny spike in the otherwise uniform distribution shouldn't be happening if only Kerbin was involved.

 

I’m away from my PC until 7/8 to do the 4th of July fireworks show down in DC. However you’re right that’s what I was expecting to see in the plot

[Arrowstar]

Hi everyone!

A week or two ago I mentioned that I was working on a plugin system for Launch Vehicle Designer in KSPTOT.  I'm happy to announce that I've got something that is working reasonably well.  Let's take a look at the new user interface, which is accessible from a new Plugins menu on the LVD main user interface.

So what do we see here?  On the left, you'll see a list of all the plugins contained within the current LVD mission file.  The ability to add plugins, remove the selected plugin, and move plugins up and down in the list is identical to other places in LVD which this sort of functionality.

In the center is the code editor.  Right now it's a bit sparse, but you'll see a space that shows line numbers and highlights text according to the MATLAB language syntax.  The drop down menu above the code box is mostly a way to change  the context with which the plugin is executed, which in turn is basically a reference for what the function call to execute the plugin looks like, and tells you what inputs are available with that context.

On the right, you'll see a place for setting the name of the plugin and a space for text that can be used to describe the plugin or put in notes.  There's also a checkbox to turn execution of all plugins on an off in one switch, which might be useful for testing purposes or the like.

You'll also see a bunch of check boxes in a "plugin execution" panel.  Checking each of these boxes enables the plugin to be executed at that point in the propagation.  In this way, you can control when and where a plugin's is run, as some code may only be applicable before propagation, or after an event is propagated, etc.  You can also execute plugin code at each integrator time step, which might be useful for computing quantities that are not available in Graphical Analysis, if you can do the math for them.

Finally, you'll see a Data Explorer button on the bottom right.  This is a convenient way to take a look at the data structures are available within each execution context, and will be helpful for knowing what data you have available when coding and how to call it.  Here's some images of what that UI looks like.

The top level of data shown is always the function scope, which shows you all the data structures available to you as a plugin coder.  Double clicking on each element in the list will change the data shown to that element of data, and the bread crumbs on the top of the UI will update to show you were you are at in exploring the data structures.  Clicking a button in the bread crumbs will jump you to that data structure, and right clicking in the bread crumb area (not on a button) will give you a menu option to copy that data path to clipboard in a format that can be immediately used in your plugin code.

Note that data is not editable in the data explorer at this time.  Data should be edited in the plugin code directly, if needed.

A few items that I'd like to try implementing in the future (that is, forward work) include:

• The ability to save and load plugins to/from file;
  • Done and implemented.
• The ability to run plugin code with notional inputs directly in the editor as a method of debugging; and
• The ability for plugins to share data with each other.
  • Done and implemented.

I'm open to thoughts and suggestions!  Thanks for reading, everyone.

Edited July 1, 2020 by Arrowstar

[Drew Kerman]

9 hours ago, Arrowstar said:

if you can do the math for them

Oh ****   

Seriously tho, looks cool. No real feedback yet as I’m not able to concptualize any use cases at the moment but will probably figure some out once I can mess around with it & better grasp its functionality 

[Arrowstar]

2 hours ago, Drew Kerman said:

Oh ****   

Seriously tho, looks cool. No real feedback yet as I’m not able to concptualize any use cases at the moment but will probably figure some out once I can mess around with it & better grasp its functionality 

A possible use case would be to compute the value of some quantity that isn't in Graphical Analysis.  Yes, you can always just ask your friendly neighborhood KSPTOT developer to add it to GA, but in cases where it's something too specific to really make sense, you can now create a plugin to:

1. Open a CSV file on your computer;
2. At every time step, compute the value of the quantity you wish to save; and
3. After propagation, close the file and save.

Another would be to set the value of a constraint to be a number that comes out of propagating the trajectory.  For example, if you wanted the end position of Event 1 to be equal to some other position that couldn't be known ahead of time, you could use this to do that programmatically.

[CraigCottingham]

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

Have you ever found yourself wanting to do something complicated in LVD,  something that would require a lot of work under the LVD hood and might only be useful for your specific situation?  Plugins are designed to handle these sorts of cases by allowing you, the user, to write active MATLAB code that can interact with the LVD data in memory, modify it, and even manipulate some minor elements of the LVD UI:

In other words: "Stop asking for new features, and build them your damn self!" :-P <j/k>

[Arrowstar]

On 7/1/2020 at 2:41 PM, CraigCottingham said:

In other words: "Stop asking for new features, and build them your damn self!" :-P <j/k>

No no, nothing of the sort, haha.  This is just a way for people to do things that LVD doesn't currently do that wouldn't make sense for me to implement either because they're too specific to one use case or because there isn't enough value to add the functionality based on the effort required.  Quite a few commercial trajectory design software packages have a plugin feature and I felt my should, too.

Speaking of which, here is KSPTOT v1.6.6 pre-release 2 that contains the first version of the plugin functionality!  There's also a MAT file in there that shows an example usage, but really, most of the MATLAB language is now at your beck and call.  Feedback on usage improvements and bugs is welcome.

EDIT: Change log for my own future self's sake:

• LVD/MA: Fixed issue with eclipse calculations being wrong;
• LVD: Implemented initial cut of plugin system.
• Performance improvement when looking up celestial body data by body ID number.

Edited July 2, 2020 by Arrowstar

[Drew Kerman]

Didn’t you also release LVD’s first version while I was away on a show?? Now I have to wait until next week...   

Oh and don’t forget to check KSPTOTConnect against the new 1.10 release that just dropped today if you were unaware

[Arrowstar]

23 hours ago, Drew Kerman said:

Didn’t you also release LVD’s first version while I was away on a show?? Now I have to wait until next week...  

It's a conspiracy, @Drew Kerman.

Quote

Oh and don’t forget to check KSPTOTConnect against the new 1.10 release that just dropped today if you were unaware

Thanks for the heads up, I'll take a look.  Most likely it'll be fine, but it's good to be sure.

EDIT:

1. I ran the KSPTOTConnect plugin against v1.10 and didn't see any issues, but please let me know if anyone sees anything or finds a bug.
2. I reploaded the pre-release 2 build because I found a bug that I wanted to get patched.  Luckily for you all, this build also includes a new performance improvement that I stumbled upon.  In atmospheric flight, I was seeing performance gains of ~10%-15%.  It's pretty awesome.

 

Edited July 2, 2020 by Arrowstar

[Arrowstar]

Hi KSPTOT community!

I've got some more exciting news for you all today.  A while back I decided that the view options in Launch Vehicle Designer (LVD) were in need of an update, mostly due to things being pretty hacked together, especially with the addition of the different Orbit Displays (really, reference frames) that you could use. I've finished my update of this system so that things are now A) much more modular, and B) less hacked together, making new additions to the view system much easier to implement.

First, let's start with a tour of the new View Settings UI, accessible from the LVD View menu.

Here we introduce a new concept called "View Profiles."  These are individual settings for how a mission should be displayed on the display area of the LVD user interface.  An LVD mission case file can have as many profiles as necessary, and the profile with the * next to its name is the "active profile", meaning that is currently being used to display the mission.

There are some new settings here for you to check out.  First, you can now turn off the lat/long grid in the Body Fixed frame.  You can also play with the background color of the plot, as well as the grid line colors (as well as turn grid lines on and off). 

Finally, there is a new way to view trajectories.  You are all familiar with the current methodology for doing so, where the trajectory is rendered in "segments" that are grouped together by sphere of influence.  So, for example, you view all of the Kerbin segments until you get to the Mun, and then the Mun segments, and then the remaining Kerbin segments.  There are three mission segments here. 

The new way to view trajectories leverages my work with the reference update I made a few months ago.  You can now view all mission segments all at once, regardless of which SoI they are part of, because all trajectory elements are converted over to whatever reference frame you want to view them in automatically. 

You can also view trajectories with respect to a two body rotating frame, as well as the previously available inertial and body-fixed frames.  A two body rotating frame has one axis pointing from one body to the other body, another axes in the direction of the angular momentum of the one body to the other body, and the third completes the coordinate system.  This is very useful for missions from, say, Kerbin to the Mun because you can construct a reference frame where neither Kerbin nor the Mun move, making it easier to visualize.

I removed the Mercator projection 2D plot because it didn't work well, had limitations that didn't apply to the 3D views, and frankly didn't seem useful when you can make the same plots within GA. 

Finally, you may have noticed there is no checkbox to plot child bodies.  I removed this and added the ability to plot any body in the display area.  You can render those other bodies as either points ("Dots") or 3D spherical meshes.

Now, let's take a look at some modest changes to the LVD main user interface.

The first thing you should notice is that all those checkboxes and buttons under the display area are gone. They were either moved to the view settings UI, eliminated, or (in the case of the pop out frame button) moved directly to the View menu.

Replacing that mess is a time slider.  When you slide the slider around, you'll move the little diamond that represents the location of the spacecraft at that point in time around.  You'll also move any celestial bodies that you plotted around too.

Here's a simple example of what that looks like.  This image also shows a two body rotating frame with Kerbin as the primary body and the Mun as the secondary body.

The viewing stuff also natively supports the fact that multiple segments can have overlapping times, like in this mission.  The black icon is the station to be met up with, the green icon is the discarded first stage, and the other icon is the spacecraft's trajectory in orbit.

And here's that same Kerbin/Mun mission I showed first, but from an inertial frame so you can see the Mun moving.

That's all I've got tonight!  I'm open to thoughts and suggestions if you have any!  A build with this in all it should be available by tomorrow.

Edited July 5, 2020 by Arrowstar

[Drew Kerman]

So this is AMAZING and will continue to make my mission communication even better for my KSA audience. Plus just looks fun to play with. looking forward to getting home soon

one thing missing from your post however is what this means for Mission Architect. Is LVD gradually looking to replace it as a more complete and powerful start to end mission planner? If not will it be possible to also implement these types of views in MA?

Edited July 6, 2020 by Drew Kerman