Arrowstar

Hi everyone! This morning I'm happy to announce the release of KSP Trajectory Optimization Tool v1.6.9! This is a major release that primarily focuses on adding additional functionality to Launch Vehicle Designer (LVD). Here are some of the major highlights of this new release: Migration of the underlying MATLAB Compiler Runtime to version R2022a. LVD now includes an improved drag model that can be populated from data generated by an included kOS script. LVD now includes an ability to have user defined variables which can be used with LVD plugin code. These plugin variables can then be used to with the new Case Matrix Runner to run a variety of cases of the same MAT file. Here's the full change log: Converted all remaining maneuver planning tools to App Designer. Converted all remaining Launch Vehicle Designer UIs to Ap Designer. Converted a few misc UIs to App Designer. MFMS: Inclusion of a new button on the UI that allows for binary data from the last run to be exported to file. LVD: New menu item to create a new mission scenario from MFMS binary data. MA/LVD: Initial state and final state shown in the UI are now the earliest and last (chronological) state in the state log, as opposed to the first and last state log entries. This is important in LVD because of the ability to use Set Kinematic State actions to move around in time, and because propagation can be both forwards and backwards. LVD: The Edit Constraint UI now shows the current scaled value of the selected constraint. LVD: Added functionality to the script event list right click context to convert Add Impulsive Delta-V actions to finite burns. LVD: Final and initial spacecraft state displays now show earliest and latest state and not first and last state in state log. LVD: Added new UI to fine-tune creating continuity constraints. LVD: Added gravity only RKN1210 high precision integrator. LVD: There should be a 5%-10% performance increase when running scripts for most scenarios, especially those that make use of 3rd body gravity. All single UI apps (MFMS, RMS, etc) now display their central body spheres with the texture and not the colormap, if available. LVD: Added the options dialog for the Second Order propagator. LVD: Tooltip for the warning/error labels is custom and now shows the proper width so everything that is meant to be on one line is actually on one line. Fixed bug in main UI options dialog. LVD: The tool tip string on the time slider text now shows the proper events. MFMS: New constaint that allows you to set a max delta-v limit on flyby maneuvers. LVD: Added "plugin variables" which allow users to create their own plugin-accessible quantities which can be optimized. Refreshed the icons of many UIs. LVD: Performance improvements for 3rd body gravity. LVD: Updated the version of the IPOPT optimizer. LVD: Initial implementation of the Case Matrix Runner tool. LVD: Performance improvement for generic polynomial steering model. LVD: Fixed issue with mission optimization observation UI always popping up back on top when drawing plots. LVD: Migrated the optimization observer and optimization scorecard UIs to App Designer. LVD: Added tooltips to main UI's menu items. LVD: Added icons to many of the buttons in many of the user interfaces. LVD: Added ability to show markers on trajectory lines for events. LVD: Added new geometric vector x,y,z constraints LVD: Added ability to normalize vectors to the geometric Scaled Vector. LVD: Added new geometric vectors: point velocity vector, vector difference vector. LVD: Added graphical analysis tasks for point velocities. LVD: Added feasibility mode option for FMINCON solver. LVD: Added auto scaling for constraints. See Optimization menu -> Scale Constraints LVD: Bug with position marker not showing when there's only one state in the internal state log (such as when LVD starts or a new mission is created). LVD: Added ODE78 and ODE89 integrators for use. LVD: Lots of Graphical Analysis UI improvements, including proper selection of figure background colors based on axis color, resizable UI, arrow buttons for changing the order of tasks, and settings being remembered from session to session. Old list dialog box now replaced with custom App Designer implementation throughout all of KSPTOT. LVD: New drag models added, including new higher fidelity kOS-based drag model. LVD: Added total angle of attack GA task. LVD: Added createDragData.ks kOS script for use with the new kOS drag model in LVD. LVD: New example showing how the kOS drag model ("complex drag model") is used. LVD: Edit Event UI now shows the event number being edited in the title of the window. LVD: Updated kOS control script to have a T- timing if the script is called before the control sequence starts. LVD: Added thrust to weight constraint. LVD: Added the ability to compute constraint Jacobian to fmincon optimizer. This can improve optimization performance at the expense of additional calculation time. LVD: Added projection type to view settings. Default is perspective now. Added available textures for Earth, Moon, Mercury, Venus, Mars, and Pluto. (For RSS.) LVD: Added a "LVD trajectory" point type that reads in an LVD case MAT file and propagates that trajectory in the current LVD case. LVD: In Adjust Variable UI, angle variables now show units of degrees and not radians. LVD: Migrated the steering and throttle model selections away from the listbox dialog. LVD: Added a new coordinate system which is parallel to a reference frame at a given universal time. Many other performance improvements and bug fixes! NOTE: If you are upgrading from KSPTOT v1.6.8 or earlier, you MUST download the R2022a MATLAB Compiler Runtime (MCR)! KSPTOT v1.6.9 will not run without this! You can find the R2022a MCR download for your platform here: https://www.mathworks.com/products/compiler/matlab-runtime.html Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire. As usual, the release can be downloaded from the first post of this thread. Please let me know if you have any questions or find any bugs. Thanks, and happy orbiting!

Hey! I think the Multi-flyby Maneuver Sequencer bit of my trajectory design software, KSP Trajectory Optimization Tool, is probably what you're looking for. This is an external tool for KSP, not something that you'd run inside KSP itself. If you're interested take a look and let me know if you have any questions!

Awesome! Please let me know if you have any more questions about KSPTOT. Happy orbiting!

Hey! So don't worry top much about the time system stuff. It's just a way to convert seconds of universal time to a more typical year/day/hour/minute/second representation. Under the hood, though, everything is done in seconds of universal time, both in KSP and KSPTOT. That's my way of saying just use the universal time numbers and ignore the year/day/hour/minute/second stuff. KSPTOT will still work great! Btw, if you are using a different solar system than the stock one (and scaled solar aystems are different) , you'll need to use the KSPTOTConnect plugin for KSP and generate a bodies.ini file for your solar system. I can show you how to do that if you need help.

Hi everyone, Today I've built KSPTOT v1.6.9 pre-release 10. This is the v1.6.9 release candidate build. Here's the change log from PR9: LVD: Added projection type to view settings. Default is perspective now. Added available textures for Earth, Moon, Mercury, Venus, Mars, and Pluto. (For RSS.) LVD: Added a "LVD trajectory" point type that reads in an LVD case MAT file and propagates that trajectory in the current LVD case. LVD: In Adjust Variable UI, angle variables now show units of degrees and not radians. LVD: Migrated the steering and throttle model selections away from the listbox dialog. LVD: Added a new coordinate system which is parallel to a reference frame at a given universal time. A ton of bug fixes and a few performance enhancements, especially with LVD reference frames. As always, please let me know if you find any bugs! Happy orbiting!

I've got a fun new feature to introduce today. One of the tricky bits with space mission design is integrating multiple spacecraft into one mission plan. Getting all of those different vehicles modeled at the same time can often be clumsy and adds additional propagation CPU time. Enter a solution: the "LVD Trajectory Point". This is a type of geometric point, part of the geometry system. All you have to do is create the Point and load the LVD file that contains the trajectory you're looking to integrate. LVD will load the LVD case MAT file you select, parse the trajectory, and create the Point. Once you've done that, you can interact with it as you would any other Point. This means that you can plot it, as I've done here. The red line in the display is the circular Kerbin orbit that I'm actually modeling. The cyan dashed-dotted line is the imported LVD trajectory as a Point. I've got it plotted here so you can see. The big advantage to this system is that the Point's trajectory does not need to be propagated constantly: it's loaded into memory and interpolation is used to get the state of the point at any moment in time. There are a few caveats. First, the loaded trajectory has to reference celestial bodies that are in the current session of LVD. If your LVD MAT file uses Earth and Mars but your current session of LVD is in the Kerbol system, this will not work and that's intentional. Second, if you ask the Point for its position and velocity at a time outside its trajectory, it will provide its position and velocity at the nearest point in time on its trajectory. Third, the loaded trajectory is static and can't be optimized. This means this functionality is more suited for stations or other "static" vehicles whose trajectory is complex but otherwise can be known ahead of time. What do you all think? Could this be useful for you in your mission design activities? Happy orbiting!

Hi everyone, Today I've built KSPTOT v1.6.9 pre-release 9. Here's the change log: LVD: Lots of Graphical Analysis UI improvements, including proper selection of figure background colors based on axis color, resizable UI, arrow buttons for changing the order of tasks, and settings being remembered from session to session. Old list dialog box now replaced with custom App Designer implementation throughout all of KSPTOT. LVD: New drag models added, including new higher fidelity kOS-based drag model. LVD: Added total angle of attack GA task. LVD: Added createDragData.ks kOS script for use with the new kOS drag model in LVD. LVD: New example showing how the kOS drag model ("complex drag model") is used. LVD: Edit Event ui now shows the event number being edited in the title of the window. LVD: Updated kOS control script to have a T- timing if the script is called before the control sequence starts. LVD: Added thrust to weight constraint. LVD: Added the ability to compute constraint Jacobian to fmincon optimizer. This can improve optimization performance at the expense of additional calculation time. I've included both the new LVD example with the new complex kOS data-based drag model and the updated kOS scripts for LVD control and producing the drag coefficient data needed for the kOS based drag model. Please check them out if this is something you're interested in. As always, please let me know if you find any bugs! I think we're getting close to the v1.6.9 release and I'd like to make sure there's nothing horrible in the code before that happens. Happy orbiting!

Quick update on the efforts to get drag modeled more precisely: I've found that Ren0k's Project Atmospheric Drag is probably going to be the best we get as far as getting decent estimates for drag coefficient as a function of Mach number and vehicle attitude. I've written a kOS script that will loop over various angles of attack and sideslip angles and calls Ren0k's code to generate drag coefficient as a function of Mach number. These all get spit out into a giant CSV file which you can then read into LVD using Yet Another Drag Model (TM). See image below. I'm now debating about keeping the Kerbal Wind Tunnel drag models in LVD since they required hacking the source code to use and didn't really account for attitude all that well. It may be more intuitive to users if I don't include them at all. When I use my kOS control script to run a launch vehicle trajectory modeled in LVD, what I find is that the LVD predicted performance is still less than what shows up in KSP proper. I believe that's due to the fact that I'm not modeling the lift force, but the end result even without lift is pretty close. I was aiming for a circular 750 km orbit in this particular trial and I ended up with a roughly circular 770 km orbit instead. So not terrible. Unfortunately, I have no idea how to model lift in KSP and unlike drag, no one seems to have done much work in figuring out that system that I could find. So this might be as good as it gets for now. Of course, if anyone does have information on how lift is modeled in KSP, or at least how it could be approximated, please let me know!

Would anyone be interested in user-defined themes for KSPTOT?

Does anyone know if there's a way to export the data FAR shows in the vehicle editor UIs to CSV files or similar? I'd like to be able to output Cd*A data as a function of Mach number, vehicle attitude, etc for use in external applications.

Hi everyone! Tonight I want to share with you some new functionality that is coming to KSPTOT's Launch Vehicle Designer soon. One of the big weaknesses that I've been aware of with LVD has always been to aerodynamic forces. Drag forces, in particular, have never really been modeled well. Thankfully, some of that is now changing. There are now four different drag models you can select from in LVD when you edit your drag properties (either in the initial state or by using the appropriate event action). The "One Dimensional" drag model is what you will have seen in LVD now. This is the drag coefficient as a function of some independent variable. The "Constant" model is just that, Cd*A is a specified constant value. Where things get interesting is with the new "Kerbal Wind Tunnel" (KWT) models. These use data from the Kerbal Wind Tunnel mod in order to model drag coefficient (Cd*A) as a function of speed and altitude. The two dimensional version (just speed/altitude) assumes that Cd*A does not change as a function of vehicle attitude (angle of attack in this case). While not strictly true, it's also the easier KWT drag model to generate. You basically just point it to the "Flight Envelope" data file that gets generated by KWT and it does the rest. Notice that the Cd*A grid gets plotted with a nice heat map so that you can visualize the data you've imported. As I said, this functionality doesn't consider vehicle attitude, angle of attack though. For that, I have a 3D drag model that involves taking a number of these 2D models, evaluated at fixed AoAs, and then doing 3D interpolation across all of it. This is a tad more complicated, but the same basic idea of "load KWT output file" still holds, you just do that more than once. Here you can see all of the AoA "slices" of data, each being represented by a KWT output file at a given angle of attack. Note that each slice has to have the same grid of speed and altitude for this to work, which is why I display the properties of the data and some warnings/alerts if the code detects issues. Interpolation is handled automatically under the hood, you don't have to worry about that. There is one big caveat with using all of this KWT stuff right now: it doesn't work this way "out of the box." Right now, if you go download KWT, it will spit out the drag "flight envelope" data at a bunch of different AoAs corresponding to some level flight AoA that would be more useful for airplanes. In order to get all this to work, I had to hack the source code a bit to fix the AoA used to a given value. I also had to up the maximum altitude to 70 km for Kerbin, because otherwise your altitude grid tops out at 25 km I think. These are sort of a big deal, and I'm happy to help anyone interested in editing the KWT source code so that it will generate the data products necessary to use all this. I have also been talking with the author of KWT about producing the speed/altitude grids at a specified AoA and with user-defined grid min/max/step size so that hacking around with his code isn't necessary anymore, but I have no idea when and if he'll get around to implementing any of the suggestions I asked for. Anyway, I'm open to A) questions about what I've got here, and B) suggestions for other mods I could tap that produce drag coefficient (Cd*A) data. Happy orbiting!

Hi everyone, Today I've built KSPTOT v1.6.9 pre-release 8. Here's a list of the changes from the previous pre-release, which are fairly extensive. As previously mentioned, this PR is going to be on MATLAB R2022a, so you will need that version of the MATLAB compiler runtime to use it. The big thing you'll notice right away is that I've added icons to many buttons in the LVD user interface and dialog boxes. The goal here was to both help users understand the functionality of each button at a glance as well as make the program more visually appealing. Hopefully I've accomplished these things, but feedback is always welcome! LVD: Performance improvement for generic polynomial steering model. LVD: Fixed issue with mission optimization observation UI always popping up back on top when drawing plots. LVD: Migrated the optimization observer and optimization scorecard UIs to App Designer. LVD: Added tooltips to main UI's menu items. LVD: Added icons to many of the buttons in many of the user interfaces. LVD: Added ability to show markers on trajectory lines for events. LVD: Added new geometric vector x,y,z constraints LVD: Added ability to normalize vectors to the geometric Scaled Vector. LVD: Added new geometric vectors: point velocity vector, vector difference vector. LVD: Added graphical analysis tasks for point velocities. LVD: Added feasibility mode option for FMINCON solver. LVD: Added auto scaling for constraints. See Optimization menu -> Scale Constraints LVD: Bug with position marker not showing when there's only one state in the internal state log (such as when LVD starts or a new mission is created). LVD: Added ODE78 and ODE89 integrators for use. ...plus a bunch of other bug fixes and a few performance improvements. Please let me know if you have any questions or find any bugs. Happy orbiting!

You're welcome!

The goal is always to make things easier for users lol. For what it's worth the auto scaling is only an estimate and there's plenty of room to tinker, haha.

I wanted to share tonight a couple of updates coming to Launch Vehicle Designer in the next KSPTOT pre-release. Now that we're definitively going to MATLAB R2022a, I've added the ODE78 and ODE89 integrators. As it turns out, ODE78 seems to be faster than ODE113 for those interplanetary arcs, especially for those gravity assist tours we all like to do. I get a nice little speed up when I use it in this case. There's now auto-constraint scaling in the code. Under the Optimization menu you'll find the ability to scale your constraints by either their current value or by the constraint Jacobian matrix, all rounded up to the nearest power of 10. This is super nice because it was always a pain to manually set the constraint scale factors before. I've added "feasibility mode" to the Fmincon optimizer's options menu. You can read up more on it at the link I've provided. I imagine I'll push out a new pre-release in the next week or so. As usual, I welcome reports of any bugs with either the current production version of KSPTOT or the pre-releases! Happy orbiting.

Yep! No quotes, of course. Okay, a few things. Don't use the Set Kinematic State action on the first event. Instead, just set the Initial State (Scenario -> Edit Initial State). You can actually just delete your first event once you do this. Don't use the Next SoI termination condition on the 4th event. Use an event duration termination condition and just let the optimizer figure out how long to coast for. Right now you're not actually getting to the next SoI because your orbit apogee is too low, and that's why it's just coasting forever (it's looking and looking for an SoI change and not finding one, so it just propagates until it hits the maximum script propagation time of 5 seconds and quits). I promise if you just stick with the "event duration" condition and use constraints everything will work out much more smoothly. Here's your MAT file back with some tweaks.

Yep, that would work. Meaning the typical length scale of the problem. So like the Mun's orbit around the 12000 km, so that could be your scale factor if you're looking at constraints in position in between Kerbin and the Mun. Okay, that's really way too long. Can you send me your MAT file so I can take a look and find out why? There's a tutorial that ships with the main KSPTOT download called "Mission to Eve" or something like that. It's a bit out of date but should still give you a decent idea about how to set up a mission in general.

No, I would set the event duration to whatever you think is a good estimate for where the burn should be, and then set your upper and lower bounds give the optimizer room to find a better solution. You typically want to set your scale factor to be roughly whatever the characteristic length of that quantity is. I usually set lengths to be 1000 or 10000. Velocities might be 10 or so. How long does it take to propagate your script when you tap control-p?

You would optimize the duration of the coast immediately prior to the burn. That is, tick the "opt?" checkbox in the event termination condition dialog box. The position vector is simply where you are relative to the center of the selected reference frame (here, the one located at the center of the Mun). It's magnitude is its length, or the distance between the center of the Mun and your vehicle. The scale factor is a numerical trick we used to make all the constraints and objective functions have an absolute value that's about 1 or less. This is to help the optimizer understand that all the constraints are equal in importance, and it also helps with some of the underlying optimization math. Does it stay like that forever? Is your computer doing anything while it looks like that?

Well okay, so what are some properties of periapsis? True anomaly is 0.0 deg. Altitude rate is 0.0 m/s and going from decreasing to increasing. Your altitude corresponds to your periapsis altitude. Any of these parameters will get you what you want and should be specifiable as either a constraint or a event termination condition (careful with true anomaly termination conditions, though, they don't always behave correctly.) That all said: why do you need to go directly to periapsis? Can't you just put a burn in there and let the optimizer figure out where to put it? (As an example, but the same rationale applies for anything really.) As far making sure you're within the SoI of some body, which is what the old central body constraint did in MA, you can always set a position vector magnitude constraint relative to the Mun centered inertial frame. Something like this: The upper bound there should be the SoI radius for the Mun. Set the applicable event accordingly and maybe set the scale factor to be 1000 km or something like that. Let me know if you have any more questions!

Okay, so in general I think you're asking "how do I coast to achieve a particular condition?" There are a few ways to do this. Check out this LVD MAT file for both examples. In the first event (red), we do something like what you're asking. I set the "termination condition" on the event to be of the True Anomaly type and then specify the true anomaly to be (in event 1) 90 degrees. In the second event (blue), I stick with the event duration termination condition, but then I also set a constraint (Optimize menu -> Constraints) that says that the true anomaly at the end of the event must be equal to 270. I then run the optimizer and it figured out how long to let the segment work for to get that true anomaly. The second method is the preferred method for doing things in LVD. This is because using the non-time termination conditions adds non-trivial calculation time to figure out each segment, and also because it can be dangerous. What happens, for example, if you never get to your "Altitude" termination condition? Well the code will just keep on propagating and propagating forever (not really as I have fail-safes built in for that but you get the idea). This will also really screw up gradient calculations when you go to optimize if you run into a case like this. Using time and constraints avoids all these potential pitfalls. Thanks the bug report, btw. I'll take a look. Let me know if you have any questions about any of that! EDIT: Bug fixed, the fix will be in the next PR.

Thanks for the report. Yeah it looks like there's some small differences in the way MATLAB is handling the value changing event with that slider. Not much I can do about it sadly but I'll keep poking at it. So the brilliant part about LVD is that each event can be anything. You can have engines running (or not), you can have drag active (or not), you can do quite a bit with the flexibility. So a coast in LVD is just having the throttle set to zero and/or having no engines active. If you want to simplify things, just make everything "coasts" and don't worry about steering or throttle. Just use impulsive delta-v actions on your events and you'll be all set. It'll be an approximation but close enough for your first time. To answer the MA question: I wouldn't try to do a rendezvous from another planet in MA. The way problems are formulated is simpler, yes, but it's also worse for optimizing because the start of each problem can influence the final state directly. With LVD, when you break the problem up into parts split with those Set Kinematic Events you also make the problem less sensitive to small changes in state up stream. This makes it easier for the optimizer to find a goods solution (or any solution!). I'd encourage you to try learning LVD. Space mission design is hard but I'm sure you can do it and I'm happy to help! Let me know if you want to see particular examples or have particular questions while you're working.

Okay, so this is definitely a bit tricky, yeah. I guess I would do this in LVD and break up the problem into three sub-problems. First, I would model my Kerbin departure fairly normally. You have your initial coast in your parking orbit, your departure burn, and then the outbound coast away from Kerbin and towards Duna. This coast should terminate about halfway to Duna, time wise. Second, I would put in an event called "Duna Periapsis" or something like that and use a Set Kinematic State action on that event. In that action, using Universal Elements, set estimates for your hyperbolic inbound orbit to Duna. Set your C3 to be greater than 0 (so it's hyperbolic) and set your time past periapsis to be maybe -60 seconds (you can optimize this a bit so long as it's negative). Optimize all the other parameters, the radius of periapsis, the inclination, RAAN, and argument of periapsis. Set the plotting mode for that event to be Skip First Event so it looks right on the display. Okay, now here's the kicker. You're going to create another event after that one and propagate backwards from that point back out into space about half way to Kerbin. Then, right click on the event you just created, select something like "Create Continuity Constraints", and select the outbound Kerbin to Duna coast you created earlier. Select time, position, velocity, and mass continuity. Third, you need to now propagate forward in time from your Duna periapsis state. So create another event with a Set Kinematic State action and then inherit everything from that Duna Periapsis state. Then insert your Duna orbit insertion burn and any other coasts and burns you want to model after that. Finally, as part of Step 3, you need to create one more Event with a Set Kinematic State. You're going to use this event to model the orbit of the station you want to rendezvous with. Then the idea will be to create a set of Continuity Constraints (like you did before in Step 2) between this Station orbit event and the end of your inbound trajectory to Duna. If you've set up everything correctly and you've manually adjusted the solution a bit so that things are at least kinda close, it should snap it really well and you'll have your answer. If you want to see some examples of how this is done, you can download PR7 above and look at the "lvdExample_InsertionStateLookupTable.mat" file. I do everything you want to do but the station rendezvous in there (and it's around Minmus, not Duna, but the principle is the same). If you look at the "lvdExample_TwoStageToOrbit.mat" LVD example file that comes with KSPTOT in the main download, you can also see an example of station rendezvous and how I did that. Let me know if you have any questions!

Hi everyone, This afternoon I've built KSP Trajectory Optimization Tool v1.6.9 pre-release 7. Here are the major feature updates in the pre-release: LVD: Added "plugin variables" which allow users to create their own plugin-accessible quantities which can be optimized. Refreshed the icons of many UIs. LVD: Performance improvements for 3rd body gravity. LVD: Updated the version of the IPOPT optimizer. LVD: Initial implementation of the Case Matrix Runner tool. Some other bug fixes and performance improvements. If you'd like to see the Case Matrix Runner tool in case, you can start with the "lvdExample_PluginVariablesAscentStateLookupTable.mat" example LVD file. To use it: Open up KSPTOT v1.6.9 PR7, then open LVD. Open up the "lvdExample_PluginVariablesAscentStateLookupTable.mat" file in LVD. Open up the Case Matrix Runner (Scenario menu -> Run Case Matrix) Turn on one or more of the parameters, update the output location/folder, then tap the Run Case Matrix button at the bottom and let it do its thing. If you'd like to see an example of the thing I talked about a few weeks ago where I use a look up table to provide an ascent insertion state based off real KSPTOT LVD simulations, then open up the "lvdExample_InsertionStateLookupTable.mat" LVD file. The look up table data for that file is located in "LaunchVehicleLookupTable.csv" and it was generated by running the Case Matrix Runner tool on the "lvdExample_TwoStageToOrbit_PluginVar.mat" LVD file. The output from that Case Matrix run, including the look up table which demonstrates how I put that together, is located in the "LVD_Case_Matrix_Run_20220404_083435.xlsx" Excel file. Please let me know if you have any questions. Happy orbiting!

Yep, this is another great use for it. It's pretty cool to see how different payloads or different insertion orbits changes, for example, your pitch profile over time. When you see that pitch up right at stage separation because you're moving to a lower thrust engine... just wonderful. To be honest, there's no resource out there that will tell you exactly how trajectory design should be done. A lot of it is from personal experience or instinct. That said, there's a few things you can do to get better: 1) Learn how the optimizers work. Read up on FMINCON and the interior point optimization algorithm. If you can implement it yourself, go for it. A lot of people treat these as black boxes when they really should have a better understanding of what's going on under the hood. Especially try to understand what you're looking for when you define objective functions and constraints. 2) Make sure you're familiar with what parameters aren't "smooth" and where, and what good alternative quantities could be. For example, SMA goes to infinity between eccentric and hyperbolic orbits, so if you could be on that line it might make sense to use C3 energy instead. Or eccentricity does weird things to your constraint gradients around 0.0, so it might make sense to go to H1 =0 and K1 = 0 in that case instead. 3) You can check out "Space Mission Analysis and Design" by Wertz and "Fundementals of Astrodynamics" by Vallado for some more academic tips and theories. 4) Read papers on real missions and how they were designed. Pay attention to the objective functions and constraints used if the authors describe them. 5) Just play around and ask for help! I'm always happy to share with people particular advice and to take a look at LVD case files and describe what I would do differently if it were me. This is the best way to learn in my opinion.