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

[Arrowstar]

8 hours ago, dlrk said:

I'm trying to plan a mission by copying an orbit created by Mission Architect into Rendezvous Maneuver Sequencer, but it gives me an error that the initial orbit mean anomaly at epoch must be within the range [-180, 360] (entered -293). Is there a conversion step I missed?

Add 360 to your -293 and you'll be all set.

[dlrk]

Thanks! What's going on there

[Arrowstar]

5 hours ago, dlrk said:

Thanks! What's going on there

You just need to get the angle (-293 deg) back into the acceptable range for that field.  Angles wrap every 360 degrees so adding 360 degrees doesn't change the value of the angle .

[EwTE_H]

Are there any other places to download KSPTOT besides Google Drive? Google Drive is not available in my country.

Edited April 2, 2022 by EwTE_H

[Arrowstar]

On 3/31/2022 at 6:27 AM, EwTE_H said:

Are there any other places to download KSPTOT besides Google Drive? Google Drive is not available in my country.

There's not unfortunately.

[Arrowstar]

Hi everyone,

I have a few KSPTOT related announcements for tonight. 

First, this is the official note that as of the next version of KSPTOT (and, in fact, the next pre-release), KSPTOT will be moving to MATLAB R2022a.  There's a few UI features that I want to take advantage of, as well as a few under the hood improvements that seem nice.  Everyone will need to use the R2022a MCR going forward.  I'll put a note in the post that has the next pre-release in it so you don't forget.

Second, tonight I want to introduce you to the new "Case Matrix Runner" in Launch Vehicle Designer!  This goes hand-in-hand with the new plugin variables I showed off earlier.

The Case Matrix Runner is an automated tool to automatically run and optimize a set of LVD missions derived from a user-created template.  Each "case" in the set is a combination of some set of Plugin Variable values.  Users select a lower bound, an upper bound, and a step size for each one of the Plugin Variable parameters in their LVD missions.  The Case Matrix Runner then computes all the combinations of each set of parameter values, creates the associated LVD data for each new case, and runs/optimizes them in parallel.  Some special trickery under the hood is performed to help cases that are "far away" from the template case optimize better.  Here's a shot of it in action.

Here you can see that I'm running two parameters.  The second one, "Initial SMA" is selected and its range is shown at the top of the dialog box.  I'm running initial SMAs from 700 km to 1500 km in increments of 100 km: 700 km, 800 km, 900 km... to 1500 km.  I'm also running initial inclinations from 30 deg to 60 deg in increments of 10 deg, but that's not visible on the UI directly.  (It would be if I selected the "Initial Inc" item in the listbox at the top there.)

In the center we have some user definable parameters that show how the cases will be run.  The output data folder is defined first, I'm using 3 parallel workers, and Case Matrix Runner will attempt to solve each case 2 times.

The table at the bottom of the dialog box shows some information on the cases and their current status.  Each row represents a case and shows the combination of parameters that make it up, the run status.  Here you see some cases that have completed successfully, three cases running, one on each worker, and one run at the bottom still waiting to be run.  To start a run you push the big "Run Case Matrix" button.

At the very bottom of the dialog box there's some information and controls.  You see that the last run status update was Case 14 moving from Not Run to Running status at 6:19 PM.  The total run duration is shown on the bottom right (6 minutes, 49 seconds so far).  Finally, users can cancel the case matrix run completely with the Cancel button.

Once a run has completed, the output location will be populated with all the output products.  First, each case has a corresponding LVD MAT file generated so you can see what happened to it under the hood.  Similarly, the log file from the optimization run is generated.  Finally, a giant spreadsheet is created. It contains a summary of the entire case matrix run and a worksheet for each case populated with data from the Graphical Analysis tasks that are defined in the template LVD file.  You can see an example of that here (Excel file) or here (Google Sheets, but sort of gimped because the Excel conversion wasn't perfect).

There are a few caveats here that should be mentioned as well.  First, while there's technically no limit to how many different parameters you can sweep over, unless you want your run to take forever to complete, you're realistically limited to 3 or (maybe) 4 parameters as the number of cases will start to increase exponentially.  Second, and similarly, this feature is definitely for those with beefy CPUs.  Each case gets optimized using serial calculations, so it's not unusual to see your Case Matrix run take overnight.  The more CPU cores and RAM you have available here, the better.  Third, it definitely takes a bit of practice to get a template LVD case to the point where you can sweep over a bunch of parameters like this and the optimizer will solve the problem well.  Expect to put in a bunch of time tuning constraint scale factors, optimizer parameters, and other LVD inputs in order to get this to work.  And finally, since this does interface exclusively with the Plugin Variables stuff, learning a bit of code will be mandatory in order to use this in any real way.

So why use this?  Well remember in my last big post how I was talking about how if you could get a big look up table of orbit insertion state as a function of launch azimuth you could cut out modeling the ascent directly and just do the in-space portion of LVD?  Well, one use case for this tool is the ability to generate that table.  In fact, the two data files I linked to above contain the data to do just that.  Another use case would be to step a solar system tour scenario forward and backwards in time, day by day, to verify that you have the best launch day or to see what happens if you miss a launch day or need to launch early or whatever.  The sky's the limit really.

I'm going to be running a few more tests over the next day or so, but I'm anticipating having this ready to put into a pre-release soon.  Before then, though, please definitely pass along any thoughts or comments or suggestions you might have. 

Happy orbiting, everyone!

[Razgriz1]

13 hours ago, Arrowstar said:

Spoiler

Hi everyone,

I have a few KSPTOT related announcements for tonight. 

First, this is the official note that as of the next version of KSPTOT (and, in fact, the next pre-release), KSPTOT will be moving to MATLAB R2022a.  There's a few UI features that I want to take advantage of, as well as a few under the hood improvements that seem nice.  Everyone will need to use the R2022a MCR going forward.  I'll put a note in the post that has the next pre-release in it so you don't forget.

Second, tonight I want to introduce you to the new "Case Matrix Runner" in Launch Vehicle Designer!  This goes hand-in-hand with the new plugin variables I showed off earlier.

The Case Matrix Runner is an automated tool to automatically run and optimize a set of LVD missions derived from a user-created template.  Each "case" in the set is a combination of some set of Plugin Variable values.  Users select a lower bound, an upper bound, and a step size for each one of the Plugin Variable parameters in their LVD missions.  The Case Matrix Runner then computes all the combinations of each set of parameter values, creates the associated LVD data for each new case, and runs/optimizes them in parallel.  Some special trickery under the hood is performed to help cases that are "far away" from the template case optimize better.  Here's a shot of it in action.

Here you can see that I'm running two parameters.  The second one, "Initial SMA" is selected and its range is shown at the top of the dialog box.  I'm running initial SMAs from 700 km to 1500 km in increments of 100 km: 700 km, 800 km, 900 km... to 1500 km.  I'm also running initial inclinations from 30 deg to 60 deg in increments of 10 deg, but that's not visible on the UI directly.  (It would be if I selected the "Initial Inc" item in the listbox at the top there.)

In the center we have some user definable parameters that show how the cases will be run.  The output data folder is defined first, I'm using 3 parallel workers, and Case Matrix Runner will attempt to solve each case 2 times.

The table at the bottom of the dialog box shows some information on the cases and their current status.  Each row represents a case and shows the combination of parameters that make it up, the run status.  Here you see some cases that have completed successfully, three cases running, one on each worker, and one run at the bottom still waiting to be run.  To start a run you push the big "Run Case Matrix" button.

At the very bottom of the dialog box there's some information and controls.  You see that the last run status update was Case 14 moving from Not Run to Running status at 6:19 PM.  The total run duration is shown on the bottom right (6 minutes, 49 seconds so far).  Finally, users can cancel the case matrix run completely with the Cancel button.

Once a run has completed, the output location will be populated with all the output products.  First, each case has a corresponding LVD MAT file generated so you can see what happened to it under the hood.  Similarly, the log file from the optimization run is generated.  Finally, a giant spreadsheet is created. It contains a summary of the entire case matrix run and a worksheet for each case populated with data from the Graphical Analysis tasks that are defined in the template LVD file.  You can see an example of that here (Excel file) or here (Google Sheets, but sort of gimped because the Excel conversion wasn't perfect).

There are a few caveats here that should be mentioned as well.  First, while there's technically no limit to how many different parameters you can sweep over, unless you want your run to take forever to complete, you're realistically limited to 3 or (maybe) 4 parameters as the number of cases will start to increase exponentially.  Second, and similarly, this feature is definitely for those with beefy CPUs.  Each case gets optimized using serial calculations, so it's not unusual to see your Case Matrix run take overnight.  The more CPU cores and RAM you have available here, the better.  Third, it definitely takes a bit of practice to get a template LVD case to the point where you can sweep over a bunch of parameters like this and the optimizer will solve the problem well.  Expect to put in a bunch of time tuning constraint scale factors, optimizer parameters, and other LVD inputs in order to get this to work.  And finally, since this does interface exclusively with the Plugin Variables stuff, learning a bit of code will be mandatory in order to use this in any real way.

So why use this?  Well remember in my last big post how I was talking about how if you could get a big look up table of orbit insertion state as a function of launch azimuth you could cut out modeling the ascent directly and just do the in-space portion of LVD?  Well, one use case for this tool is the ability to generate that table.  In fact, the two data files I linked to above contain the data to do just that.  Another use case would be to step a solar system tour scenario forward and backwards in time, day by day, to verify that you have the best launch day or to see what happens if you miss a launch day or need to launch early or whatever.  The sky's the limit really.

I'm going to be running a few more tests over the next day or so, but I'm anticipating having this ready to put into a pre-release soon.  Before then, though, please definitely pass along any thoughts or comments or suggestions you might have. 

Happy orbiting, everyone!

 

This looks amazing, and I can't wait to try it! I can finally start to characterize gravity turn information for different payloads without just trial and error!

I also wanted to ask if you could point me to any reference material on mission design/optimization? Like "What constraints are better than others for given goals" and things like that. I've also never really understood the constraint scaling all that much and just kind of brute forced my way through it, but I would definitely need to get better at setting up the initial mission before even attempting to use this new feature.

[Arrowstar]

3 hours ago, Razgriz1 said:

This looks amazing, and I can't wait to try it! I can finally start to characterize gravity turn information for different payloads without just trial and error!

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.

Quote

I also wanted to ask if you could point me to any reference material on mission design/optimization? Like "What constraints are better than others for given goals" and things like that. I've also never really understood the constraint scaling all that much and just kind of brute forced my way through it, but I would definitely need to get better at setting up the initial mission before even attempting to use this new feature.

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.

[Razgriz1]

4 hours ago, Arrowstar said:

You can check out "Space Mission Analysis and Design" by Wertz

This is definitely what I was looking for, thanks! All great advice though!

[Arrowstar]

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:

1. Open up KSPTOT v1.6.9 PR7, then open LVD.
2. Open up the "lvdExample_PluginVariablesAscentStateLookupTable.mat" file in LVD.
3. Open up the Case Matrix Runner (Scenario menu -> Run Case Matrix)
4. 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!

[dlrk]

@Arrowstar

Could you help me understand how to use KSPTOT for a particular use case: Planning a rendezvous with a station in the SOI of one body beginning with a craft in orbit around another body?

For example:

Beginning in low kerbin orbit, how would I plan an rendezvous with a station in a polar or inclined to Mun orbit.

Beginning in LKO, plan a rendevous with a station in a polar or inclined Duna orbit

Thanks very much. Any resources you or anyone else can point to is appreciated

[Arrowstar]

1 hour ago, dlrk said:

@Arrowstar

Could you help me understand how to use KSPTOT for a particular use case: Planning a rendezvous with a station in the SOI of one body beginning with a craft in orbit around another body?

For example:

Beginning in low kerbin orbit, how would I plan an rendezvous with a station in a polar or inclined to Mun orbit.

Beginning in LKO, plan a rendevous with a station in a polar or inclined Duna orbit

Thanks very much. Any resources you or anyone else can point to is appreciated

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!

[Razgriz1]

One interesting thing to note with the R2022a version is that when using the slider to scroll through and visualize a mission in LVD, it seems to be slower at drawing the updates than previous versions, resulting in the displayed frames being behind what is currently selected on the slider. Not really an issue, just an observation.

[dlrk]

So, I'm a bit lost with LVD. Is there a way to do this with Mission Architect, or a tutorial or something for LVD? I'm sorry, I'm totally lost with LVD

Actually, I guess should ask this question more specifically. So, I don't get the LVD functions relating to attitude control or thrust specifics at all, but I think for this, I don't need to get into that?

But I don't understand how to put a coast in LVD at all. There's no "coast to" option or anything.

Edited April 6, 2022 by dlrk

[Arrowstar]

3 hours ago, Razgriz1 said:

One interesting thing to note with the R2022a version is that when using the slider to scroll through and visualize a mission in LVD, it seems to be slower at drawing the updates than previous versions, resulting in the displayed frames being behind what is currently selected on the slider. Not really an issue, just an observation.

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.

45 minutes ago, dlrk said:

So, I'm a bit lost with LVD. Is there a way to do this with Mission Architect, or a tutorial or something for LVD? I'm sorry, I'm totally lost with LVD

Actually, I guess should ask this question more specifically. So, I don't get the LVD functions relating to attitude control or thrust specifics at all, but I think for this, I don't need to get into that?

But I don't understand how to put a coast in LVD at all. There's no "coast to" option or anything.

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.

[dlrk]

53 minutes ago, Arrowstar said:

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.

Will do, and I appreciate the help!

EDIT: Figured out the coast to SOI situation. It looks like there may be a bug in the prerelease though,when I try to import an orbit from SFS, the window is unclickable and just pings (Windows). Also, in LVD, I can't seem to find a way to optimize for the central body. Looking at the LVD examples, the coasts are specified in terms of seconds or specific times. So, I'm not sure how to say "coast to periapsis", for example

Edited April 6, 2022 by dlrk

[Arrowstar]

15 hours ago, dlrk said:

Will do, and I appreciate the help!

EDIT: Figured out the coast to SOI situation. It looks like there may be a bug in the prerelease though,when I try to import an orbit from SFS, the window is unclickable and just pings (Windows). Also, in LVD, I can't seem to find a way to optimize for the central body. Looking at the LVD examples, the coasts are specified in terms of seconds or specific times. So, I'm not sure how to say "coast to periapsis", for example

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.

Edited April 6, 2022 by Arrowstar

[dlrk]

So, with regard to the second method, I'm still lost because I'm not sure how to determine the time to e.g. periapsis or tell the optimizer to determine time to periapsis. I suppose altitude could work, but not if I don't know what the periapsis is.  Also, if I could get some help on how to optimize for central body (adjust a burn to wind up in the Mun's SOI for example)

Again, thanks for your help and patience! I did try looking at the LVD MAT file you linked, but it won't load for me for some reason.

Edited April 6, 2022 by dlrk

[Arrowstar]

4 minutes ago, dlrk said:

So, with regard to the second method, I'm still lost because I'm not sure how to determine the time to e.g. periapsis or tell the optimizer to determine time to periapsis. I suppose altitude could work, but not if I don't know what the periapsis is.  Also, if I could get some help on how to optimize for central body (adjust a burn to wind up in the Mun's SOI for example)

Again, thanks for your help and patience! I did try looking at the LVD MAT file you linked, but it won't load for me for some reason.

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!

 

[dlrk]

Thanks that's very helpful! I do have a couple more questions: How would I tell the optimizer to decide where to put a burn, and what is the position vector magnitude and scale factor? I realize that may be a fairly basic question, but it's not exactly my IRL field, so I could use some help (:

Also, sometimes the otpimizer gets stuck at this for a while

 

Edited April 6, 2022 by dlrk

[Arrowstar]

3 hours ago, dlrk said:

Thanks that's very helpful! I do have a couple more questions: How would I tell the optimizer to decide where to put a burn

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.

Quote

what is the position vector magnitude and scale factor?

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.

Quote

Also, sometimes the otpimizer gets stuck at this for a while

Does it stay like that forever?  Is your computer doing anything while it looks like that?

[dlrk]

49 minutes ago, Arrowstar said:

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?

Okay, so leave the event termination time zero, and check "opt?"
 

I get position vector now, but why set scale factor to 1000x?

It stays like that for a while, but eventually after a few minutes starts to run. The optimizer seems quite slow

[Arrowstar]

19 minutes ago, dlrk said:

Okay, so leave the event termination time zero, and check "opt?"

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.

Quote

I get position vector now, but why set scale factor to 1000x?

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.

Quote

It stays like that for a while, but eventually after a few minutes starts to run. The optimizer seems quite slow

How long does it take to propagate your script when you tap control-p?

[dlrk]

2 minutes ago, Arrowstar said:

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?

How would I arrive that estimate though? Perhaps take the time between burns 1 and 2 from the RMS?

Characteristic length meaning number digits before zero?

About 5 seconds

[dlrk]

Is there perhaps a step by step tutorial for planning a mission in the LVD? I'm trying to plan Kerbin-Mun transfer by putting the initial parking orbit as initial state, calculating the maneuver in RMS, and creating an event in LVD to propagate to the burn True Anomaly, then apply a delta v of the calculated maneuver, followed by a terminate next SOI event with no actions, and it winds up like this: https://imgur.com/a/WgnKJRB

Edited April 7, 2022 by dlrk