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

[Arrowstar]

Tonight I've built KSPTOT v1.6.8 pre-release 4.  Here's the change log:

• LVD: Added a flight path angle event termination condition.
• LVD: Added a new "vector magnitude" constraint type.
• LVD: Added a new "angle magnitude" constraint type.

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

[Tacombel]

Thank you, I will test the new version it now.

Meanwhile this is the best I got with the previous version.

.mat

The mission consist of a probe already in Kerbol orbit. The first burn is to take Pe down to 180000km, as per the mission parameters. Next there are to burns to go back to Kerbin. Intuitively I would expect an encounter 1 year after departure, so approximately around Y3D146, but it  happens 20 days later. Without comparing solutions I don't know if this is more economic than what I expected, but could be.

Also, I can't get a solution closer than 27882km for the distance to reference object. The optimizer stops without hitting any constrain.

And lastly, although the solution is well inside kerbin SOI the Final State is still Orbiting Sun.

 

[Arrowstar]

15 hours ago, Tacombel said:

Thank you, I will test the new version it now.

Meanwhile this is the best I got with the previous version.

.mat

The mission consist of a probe already in Kerbol orbit. The first burn is to take Pe down to 180000km, as per the mission parameters. Next there are to burns to go back to Kerbin. Intuitively I would expect an encounter 1 year after departure, so approximately around Y3D146, but it  happens 20 days later. Without comparing solutions I don't know if this is more economic than what I expected, but could be.

Also, I can't get a solution closer than 27882km for the distance to reference object. The optimizer stops without hitting any constrain.

And lastly, although the solution is well inside kerbin SOI the Final State is still Orbiting Sun.

 

1. I was able to get something that satisfied the constraints by:
   1. Enabling the checkbox on the delta-v action dialog box that subtracts mass;
   2. Changing the objective function to be maximize total spacecraft mass;
   3. Setting appropriate scale factors on the constraints; and
   4. Using the NOMAD solver with parallel processing enabled.
2. FMINCON doesn't do a great job with this problem.  As I said above, try NOMAD.
3. Yeah, so with this one, you somehow managed a bug that should have been impossible lol.  There was something goofy going on where the cached inertial reference frame for Kerbin was actually Sun-centric instead.  I have no idea how that happened, but a quick change to the code to make that property transient (meaning it has to be regenerated on each save/load cycle) corrected the issue.

Here's your updated MAT file back with my changes.  Let me know if you have questions!

[russm]

3 hours ago, Arrowstar said:

Setting appropriate scale factors on the constraints

I'd been meaning to ask about this - I've assumed the scale factor is applied to the score on how badly a constraint is failed, so eg. doubling every scale factor in a case changes nothing (or perhaps makes the solver try harder to satisfy all constraints before it cares about optimising¹?), and doubling one constraint makes the solver try harder to satisfy that constraint wrt all the others. Is that correct-ish?

1. yeah I get this isn't how the optimiser really works

[Tacombel]

7 hours ago, Arrowstar said:

1.  
2. Yeah, so with this one, you somehow managed a bug that should have been impossible lol.  There was something goofy going on where the cached inertial reference frame for Kerbin was actually Sun-centric instead.  I have no idea how that happened, but a quick change to the code to make that property transient (meaning it has to be regenerated on each save/load cycle) corrected the issue.

Here's your updated MAT file back with my changes.  Let me know if you have questions!

Ja ja ja, I understand nothing, but great!! Thank you.

[Arrowstar]

11 hours ago, russm said:

I'd been meaning to ask about this - I've assumed the scale factor is applied to the score on how badly a constraint is failed, so eg. doubling every scale factor in a case changes nothing (or perhaps makes the solver try harder to satisfy all constraints before it cares about optimising¹?), and doubling one constraint makes the solver try harder to satisfy that constraint wrt all the others. Is that correct-ish?

1. yeah I get this isn't how the optimiser really works

It's the other way around.  The naming is unfortunate (but also industry standard): scale factors divide the quantity the optimizer sees.  So scaled_constraint = raw_constraint / scale_factor.  It makes sense to do it this way, though, because often times we're trying to scale down a value and it's just more straight forward to input a large number we can easily guess than a small number we can't. 

Scale factors should generally be selected so the value of the scaled constraint is on the order of 1.0 or so.  A bit less or a bit more is fine obviously.  What you're trying to avoid is having all of your constraints be different orders of magnitude.

[Tacombel]

@ArrowstarThe flight path termination worked perfectly, after I realized that it is zero at both Pe and Ap 

I have got a solution that is in the range of 6 Km/s while the one that you sent me needs around 11.5 Km/s. The SOI was detected without problem.

https://drive.google.com/open?id=1KQBjSGwGRVQ5XnSdbv4AfpPlO1TXP8Ab

Is there a way to make the algorithm go in the right direction? Mainly when there are going to be situations where I don't know where to go in the right direction.

 

[Arrowstar]

1 hour ago, Tacombel said:

Is there a way to make the algorithm go in the right direction? Mainly when there are going to be situations where I don't know where to go in the right direction.

What do you mean by "go in the right direction"?

[Tacombel]

8 hours ago, Arrowstar said:

What do you mean by "go in the right direction"?

Basically to find the optimal solution deltaV wise.

[Arrowstar]

7 hours ago, Tacombel said:

Basically to find the optimal solution deltaV wise.

There are a few things here.  Keep in mind, though, that the "right direction" is ultimately determined by the optimizer and it may not be in the direction you expect!  Give it the benefit of the doubt some times.  That said:

1. Scale all of your constraints as I've described above;
2. If using the FMINCON solver, use the option that computes your finite difference step sizes for you; and
3. Bound your variables and add constraints to eliminate regions of the solution space that are not desirable to you.

Let me know if you have any questions with any of that.

[Gilph]

On 2/27/2021 at 8:13 PM, Arrowstar said:

Tonight I've built KSPTOT v1.6.8 pre-release 4.  Here's the change log:

• LVD: Added a flight path angle event termination condition.
• LVD: Added a new "vector magnitude" constraint type.
• LVD: Added a new "angle magnitude" constraint type.

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

Hi, was using PR3 and found a bug in MA. I know it's being depreciated, but wanted to let you know.

I was adding a coast step and tried to change from coast to True Anomaly to coast to UT. The window usually switches from deg. to UT field to allow for edits, but it stayed on the deg field. I could not get a time field to display.

Thanks

[Arrowstar]

2 hours ago, Gilph said:

Hi, was using PR3 and found a bug in MA. I know it's being depreciated, but wanted to let you know.

I was adding a coast step and tried to change from coast to True Anomaly to coast to UT. The window usually switches from deg. to UT field to allow for edits, but it stayed on the deg field. I could not get a time field to display.

Thanks

I couldn't duplicate this in a simple case.   Can I see the MAT file and get details steps on what I need to do to reproduce it?

[Tacombel]

Must be doing something wrong. That's  the sun orbiting Kerbin 

[Gilph]

17 hours ago, Arrowstar said:

I couldn't duplicate this in a simple case.   Can I see the MAT file and get details steps on what I need to do to reproduce it?

OK...will need to recreate the MAT file and will let you know if I can reproduce.

[Gilph]

On 3/2/2021 at 4:54 PM, Gilph said:

Hi, was using PR3 and found a bug in MA. I know it's being depreciated, but wanted to let you know.

I was adding a coast step and tried to change from coast to True Anomaly to coast to UT. The window usually switches from deg. to UT field to allow for edits, but it stayed on the deg field. I could not get a time field to display.

Thanks

 

On 3/2/2021 at 7:04 PM, Arrowstar said:

I couldn't duplicate this in a simple case.   Can I see the MAT file and get details steps on what I need to do to reproduce it?

Sorry, tried to type the issue from memory and made an error.

When I switch to Go to UT, I do get the UT window. Underneath is the checked option to optimize and below it , there are two entry fields for the optimize range. They used to be changed to the UT value by default, but they they stay set to 0 and 360

Screenshot is Here

To create, I open MA, set initial state by importing from my active vessel, and try to create a coast to UT

Edited March 4, 2021 by Gilph

[Tacombel]

Where is the time information for the burn in the MFMS tool?

[Arrowstar]

On 3/3/2021 at 6:33 PM, Gilph said:

Sorry, tried to type the issue from memory and made an error.

When I switch to Go to UT, I do get the UT window. Underneath is the checked option to optimize and below it , there are two entry fields for the optimize range. They used to be changed to the UT value by default, but they they stay set to 0 and 360

Screenshot is Here

To create, I open MA, set initial state by importing from my active vessel, and try to create a coast to UT

I don't believe the bounds have ever updated actually.  There are some reasons why that doesn't happen, mostly due to the annoyance of making sure that the lower bound stays lower than the upper bound.

2 hours ago, Tacombel said:

Where is the time information for the burn in the MFMS tool?

There is no time information associated with the burns in MFMS because there is no thrust and Isp information in the tool.  It's delta-v only.  You turn those delta-vs into burn durations when you bring them into LVD or MA.

[Tacombel]

8 hours ago, Arrowstar said:

I don't believe the bounds have ever updated actually.  There are some reasons why that doesn't happen, mostly due to the annoyance of making sure that the lower bound stays lower than the upper bound.

There is no time information associated with the burns in MFMS because there is no thrust and Isp information in the tool.  It's delta-v only.  You turn those delta-vs into burn durations when you bring them into LVD or MA.

I am not talking about how long, but when to do them.

[Arrowstar]

On 3/6/2021 at 2:37 AM, Tacombel said:

I am not talking about how long, but when to do them.

Oh got it.  All powered gravity assist maneuvers in MFMS occur at periapsis, so you can use that as your timing.

[Tacombel]

4 hours ago, Arrowstar said:

Oh got it.  All powered gravity assist maneuvers in MFMS occur at periapsis, so you can use that as your timing.

Any periapsis, like any moment from now? The position of the planets doesn't mind?

[Arrowstar]

22 minutes ago, Tacombel said:

Any periapsis, like any moment from now? The position of the planets doesn't mind?

It's at the periapsis of the inbound hyperbolic orbit of each gravity assist.

[Tacombel]

1 minute ago, Arrowstar said:

It's at the periapsis of the inbound hyperbolic orbit of each gravity assist.

And the initial burn?

[Arrowstar]

5 minutes ago, Tacombel said:

And the initial burn?

The true anomaly of the initial departure burn is listed.  That's the burn location in the initial orbit.

By the way, the arrival and departure dates for the mission are shown in the second, "Transfer Orbit" box on the right.

[Tacombel]

9 minutes ago, Arrowstar said:

By the way, the arrival and departure dates for the mission are shown in the second, "Transfer Orbit" box on the right.

This is what I was asking for. I never went to the bottom of that box, stopped in the phase 1 transfer orbit. My bad.

 

Thx

Edited March 7, 2021 by Tacombel

[Tacombel]

Is it possible to include moons in MFMS? I have a mission Mun-Eve-Duna, and don't know exactly how to do it. My best bet at this moment is to go back to Kerbin to do the Mun fly-by, but that nearly doubles the needed dV.