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

[Arrowstar]

2 hours ago, drunkeNNN said:

That sounds great. Maybe I just had bad RNG luck with the optimizer there.

I do agree that including the inclination component is computationally not feasible. But I dont think that a good estimate of the injection and ejection dv requires a lot of computation time if you already optimize  the hyperbolic excess velocity. The dv needed is fairly straightforward to compute using energy conservation if you neglect inclination changes. After simplification you end up with:

dv_inject=sqrt(v_inf^2+2*mu/R)-sqrt(mu/R)

All this requires are two additional user parameters (the radii of the circular orbits R). According to the formula the circularization burn dv is not that different when the excess velocity is below the escape velocity of the associated circular orbit. For example, departing from a 100km orbit around Kerbin with an excess velocity of 500m/s costs 969m/s, departing with 1500m/s only costs 1267m/s, so you get additional 1000m/s for burning only 300m/s more. In contrast, leaving with 5000m/s costs 3678m/s while leaving with 6000m/s costs 3543m/s so you have to pay an additional ~900m/s. This means that the hyperbolic excess velocity generally isn't a good parameter to optimize for ejection and injection if that makes sense to you.

Neglecting the inclination would not be a big deal here. A vessel can always be launched into the correct orbital plane and the arrival orbital plane can be easily changed with only a couple of m/s. If I understood you correctly, the current solution is good if one would always circularize at the edge of the SOI (where the associated escape velocity is basically 0) and for very small planets (where typical transfer excess velocities exceed the low orbit escape velocities). This was the reason why I was interested in the feature.

So the issue is that I do not assume a circular parking orbit.  You'll note that the UI has inputs for the full set of orbital elements.  I allow the user to enter in any sort of eccentric orbit, and that flexibility comes with the cost of eliminating the use of simple equations like you suggested.  Negating the inclination is also not particularly realistic.  Plane change maneuvers can make up the bulk of the departure burn delta-v if the user selects the "wrong" orbit plane (inclination + RAAN).  If I drop this, it would be very easy for the application to provide incorrect results.

There is one other aspect of this beyond the math.  That is, optimizing on the C3 energy (or in this case, the square root of the C3 energy, which is the hyperbolic excess velocity) is the "industry standard" way of going about it because it provides a parking orbit-agnostic method for optimizing the transfer orbit from body to body.  This makes the results easier to port from mission to mission, as needed. 

Quote

the current solution is good if one would always circularize at the edge of the SOI

So this really isn't true.  It's not that the solution is only "good" at the edge of the SOI or whatnot.  Try not to think about optimizing the departure/arrival excess velocity as optimizing the parking orbit or anything like that.  It's merely a metric I use to ascertain how "cheap" it is to execute a departure burn to get onto the desired transfer orbit.  When it comes to very CPU-intensive problems that require hundreds of thousands of function evaluations such as flyby optimization, you want to use the quantity that is fastest to compute and provides reasonable results.  The excess velocity is that, and while it's not perfect, it's quick, does a reasonably good job, and is accepted practice.

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

In other news, I have another pre-release ready.  KSPTOT v1.5.8 pre-release 2 contains the desired upgrade to the Multi-Flyby Maneuver Sequencer that allows users to let the optimizer find multi-rev trajectories between any waypoints.  @EpicSpaceTroll139 and @drunkeNNN, this one's for you.   Please try it out and let me know what bugs you find or issues you discover.  Thanks!

[Drew Kerman]

I'm moving over to the latest pre-release but wanted to report with the latest release there have been times I've added a coast state that didn't show up in the list, although the coast was applied. If I did an Undo/Redo it would show up, same if I did a save and reload. So far I have not noticed what I'm doing to cause it, so don't have any repro steps. Will keep an eye on it and try to remember to check the log next time I notice its missing

[Arrowstar]

40 minutes ago, Drew Kerman said:

I'm moving over to the latest pre-release but wanted to report with the latest release there have been times I've added a coast state that didn't show up in the list, although the coast was applied. If I did an Undo/Redo it would show up, same if I did a save and reload. So far I have not noticed what I'm doing to cause it, so don't have any repro steps. Will keep an eye on it and try to remember to check the log next time I notice its missing

Got it, thanks.  If you can find a way to reproduce it, let me know!  I've not yet encountered that sort of behavior, but it's something I want to squash if I can.

[Drew Kerman]

oh, here's a definite issue I noticed - the option to "Get Orbit from KSP" does not work at all - just comes up with a blank list. I stumbled on this by accident clicking the wrong selection (wanted to get the Active Vessel info) a while ago but always kept forgetting to go back and confirm - it happened on my save game with a ton of asteroids so I figured it was that, but just tried it on a save with only a few vessels and nothing showed up. This option is a more direct method than manually choosing an SFS file to read from, but is still a bit redundant. Up to you if you want to fix it or toss it.

Edited May 28, 2017 by Drew Kerman

[Arrowstar]

4 hours ago, Drew Kerman said:

oh, here's a definite issue I noticed - the option to "Get Orbit from KSP" does not work at all - just comes up with a blank list. I stumbled on this by accident clicking the wrong selection (wanted to get the Active Vessel info) a while ago but always kept forgetting to go back and confirm - it happened on my save game with a ton of asteroids so I figured it was that, but just tried it on a save with only a few vessels and nothing showed up. This option is a more direct method than manually choosing an SFS file to read from, but is still a bit redundant. Up to you if you want to fix it or toss it.

Okay I'll look into it.  What version of KSP are you on?  Latest version of KSPTOTConnect?

EDIT:  Seems to work for me on KSP v1.2.2 and the latest KSPTOTConnect DLL.

Edited May 29, 2017 by Arrowstar

[Drew Kerman]

3 hours ago, Arrowstar said:

Seems to work for me on KSP v1.2.2 and the latest KSPTOTConnect DLL

that's what I have. If someone else can repro I'll help look into it but for myself it's a non-issue and I don't have time to run it down at the moment

[Stract]

On 28.05.2017 at 7:57 PM, Arrowstar said:

Could you post a mat file that shows the issue you're talking about with the moons?  Also the new and old bodies files, if you could. :-) 

Ok, I think I have an update. It seems initial epoch in TOT for RSS is correct after all. Periods of the planets are correct too, I've re-checked it manually more carefully - the true anomalies of the moons in TOT are the same as in the game itself for every given time. But still TOT have small but stable error for transitions at little moons. Maybe it is just a numercal error though. Good thing is that this error is noticable for little moons only and that this error is not grow with in-game time.

So here is an example (picture below). The probe is going to enter Charon SOI in hour and a half.  Game shows that periapse altitude at Charon is 212 km, while TOT expects -40 km. Other orbital parameters are also not exaclty the same. So if the position of Charon is correct (and it seem to be so), then maybe something is wrong with the SOI radius? On my picture I marked SOI transition in TOT body information and radius of probe just after SOI transition (green boxes). It looks like for some reason TOT made transition into Charon SOI 2 km below it's own database. It matches with altitude of the probe just after transition and predicted altitude in TOT (red boxes). I doubt this 2 km difference could create this error anyway but anyway I've decided to let you know

I can upload mission file if you wish but this result is easy to reproduce, I've had similar situation in every try.

Update. Just noticed: difference in altitude at the moment of SOI transition is tiny but the difference in vertical velocity is significant, 116.7 m/s in game vs 125.7 m/s in TOT. Just checked - velocity relative to Pluto just before transition in TOT and in game were similar. But if the speeds of spacecraft relative to Pluto are similar then maybe the speed of Charon is wrong here? Maybe TOT still uses old orbital speed while recalculating velocity in new reference frame?

 

Edited May 29, 2017 by Stract

[Arrowstar]

13 hours ago, Drew Kerman said:

that's what I have. If someone else can repro I'll help look into it but for myself it's a non-issue and I don't have time to run it down at the moment

Is there anything in the KSP debug log or the KSPTOT log file that you can share which might pin down what's going on?  Do you see any error messages anywhere?

2 hours ago, Stract said:

Ok, I think I have an update. It seems initial epoch in TOT for RSS is correct after all. Periods of the planets are correct too, I've re-checked it manually more carefully - the true anomalies of the moons in TOT are the same as in the game itself for every given time. But still TOT have small but stable error for transitions at little moons. Maybe it is just a numercal error though. Good thing is that this error is noticable for little moons only and that this error is not grow with in-game time.

So here is an example (picture below). The probe is going to enter Charon SOI in hour and a half.  Game shows that periapse altitude at Charon is 212 km, while TOT expects -40 km. Other orbital parameters are also not exaclty the same. So if the position of Charon is correct (and it seem to be so), then maybe something is wrong with the SOI radius? On my picture I marked SOI transition in TOT body information and radius of probe just after SOI transition (green boxes). It looks like for some reason TOT made transition into Charon SOI 2 km below it's own database. It matches with altitude of the probe just after transition and predicted altitude in TOT (red boxes). I doubt this 2 km difference could create this error anyway but anyway I've decided to let you know

I can upload mission file if you wish but this result is easy to reproduce, I've had similar situation in every try.

Yes, please send a mission file!  That would be very helpful for me.

Quote

Update. Just noticed: difference in altitude at the moment of SOI transition is tiny but the difference in vertical velocity is significant, 116.7 m/s in game vs 125.7 m/s in TOT. Just checked - velocity relative to Pluto just before transition in TOT and in game were similar. But if the speeds of spacecraft relative to Pluto are similar then maybe the speed of Charon is wrong here? Maybe TOT still uses old orbital speed while recalculating velocity in new reference frame?

Can you illustrate this with a screenshot or two, please?

[Stract]

Ok, that's the story. Look at two screenshots:

Spoiler

Before transition

After transition

The first was made in Pluto SOI one second before entering Charon sphere. All parameters in game and in TOT matches perfectly. Second one was made two seconds later, already in Charon SOI. The altitude of the probe in TOT is fine (well, more or less), but velocity is wrong. I assumed that since velocity relative to Pluto in TOT is correct but velocity relative to Charon at basically the same moment is wrong then probably TOT used incorrect Charon speed by switching into new reference frame. Well, just my guess

Link to the mission file <<click>>

Edited May 29, 2017 by Stract

[drunkeNNN]

Thank you for the quick update to allow multiple revs in the MFMS in version 1.5.8. You're awesome. I have been trying to find a good Kerbin-Kerbin-Moho-transfer but did not have any success with it yet. There seems to be something odd with the solver. Try the following:

Do a Kerbin-Kerbin transfer with a flight time of 430 to 450 days (so about one Kerbin year) and set the number of max revs to 1.0. Then do a standard transfer to Duna within 60 to 100 days. Very often I end up with a solution that has an orbit far larger than Kerbins orbit but the Kerbin arrival time shows about 1 Kerbin year (but I would say its rather 2 years). Are you sure the flight time is correct for multiple revs?

The idea of this set-up would be to find a burn that changes the orbits radial component at departure but to keep the orbital time constant at the same time. That way, one would arrive at Kerbin after one revolution at an angle which gives the possibility to get a decent amount of energy.

[Arrowstar]

8 hours ago, Stract said:

Ok, that's the story. Look at two screenshots:

  Hide contents

Before transition

After transition

The first was made in Pluto SOI one second before entering Charon sphere. All parameters in game and in TOT matches perfectly. Second one was made two seconds later, already in Charon SOI. The altitude of the probe in TOT is fine (well, more or less), but velocity is wrong. I assumed that since velocity relative to Pluto in TOT is correct but velocity relative to Charon at basically the same moment is wrong then probably TOT used incorrect Charon speed by switching into new reference frame. Well, just my guess

Link to the mission file <<click>>

I agree that it appears to have something to do with Charon's orbit, as setting up the SOI targeter to hit exactly the edge of the SoI (as opposed to the two kilometers in that you saw) does not change my answer very much.  Do you have any way to obtain the position and velocity vectors of Charon within the game?  I could compare them with what I get here and that could verify that Charon's orbit is the issue.

For the record, here's what I get for Charon's orbit at UT = 153757.07654467 seconds.  Distances in km and speeds in km/s.

Quote

rVectBody =

         -17599.4747655589
         -8620.01963601694
       -0.0960565046869299

vVectBody =

        0.0979754295391343
        -0.200047004279161
      3.73125176226885e-06

And if I convert that to Keplerian orbit elements I get the following.  Distances in km, angles in radians.

Quote

K>> [sma,ecc,inc,raan,arg,tru]=getKeplerFromState(rVectBody,vVectBody,getParentGM(childBodyInfo,celBodyData))

sma =

           19596.193835404

ecc =

      5.08220000000211e-05

inc =

      1.74532931674587e-05

raan =

          3.88170604269758

arg =

          3.28948949271376

tru =

          2.70902748096807

What do you think?

[Arrowstar]

11 hours ago, drunkeNNN said:

Thank you for the quick update to allow multiple revs in the MFMS in version 1.5.8. You're awesome. I have been trying to find a good Kerbin-Kerbin-Moho-transfer but did not have any success with it yet. There seems to be something odd with the solver. Try the following:

Do a Kerbin-Kerbin transfer with a flight time of 430 to 450 days (so about one Kerbin year) and set the number of max revs to 1.0. Then do a standard transfer to Duna within 60 to 100 days. Very often I end up with a solution that has an orbit far larger than Kerbins orbit but the Kerbin arrival time shows about 1 Kerbin year (but I would say its rather 2 years). Are you sure the flight time is correct for multiple revs?

The idea of this set-up would be to find a burn that changes the orbits radial component at departure but to keep the orbital time constant at the same time. That way, one would arrive at Kerbin after one revolution at an angle which gives the possibility to get a decent amount of energy.

Yes, the flight time is correct for multiple revs.   Try opening up your boundaries some and see what happens.  I get a reasonable result when I use wider flight time bounds.

Edit just to say that I did find a bug in the way departure orbits are computed if the first two way points are the same body. You might get a crash or weird results. :-) 

Edited May 30, 2017 by Arrowstar

[Stract]

Ugh. Great, just great... I think I've found the answer after all. I have a crazy idea that RSS calculates orbital periods using G(M+m) BUT use GM for calculation of new spacecraft speed during SOI transition. Look: I've modified bodies.ini by put there Charon position at the moment just before transition (to make sure the Charon mean anomaly at this moment is correct) and run TOT with GM gravitational parameter. Well, look at the screenshot. RSS way of calculations is VERY counter-intuitive...

Spoiler

This is my modified bodies file. You can check it with mission file I've uploaded before, just choose old GM settings. If I am right then things become more complicated: TOT has to track SOI transition using G(M+m) to find correct location of the body but re-calculate new rVectBody and vVectBody during transition with just GM.

[Arrowstar]

2 minutes ago, Stract said:

Ugh. Great, just great... I think I've found the answer after all. I have a crazy idea that RSS calculates orbital periods using G(M+m) BUT use GM for calculation of new spacecraft speed during SOI transition. Look: I've modified bodies.ini by put there Charon position at the moment just before transition (to make sure the Charon mean anomaly at this moment is correct) and run TOT with GM gravitational parameter. Well, look at the screenshot. RSS way of calculations is VERY counter-intuitive...

  Hide contents

This is my modified bodies file. You can check it with mission file I've uploaded before, just choose old GM settings. If I am right then things become more complicated: TOT has to track SOI transition using G(M+m) to find correct location of the body but re-calculate new rVectBody and vVectBody during transition with just GM.

Oh dear. Okay, thanks for investigating. That honestly sounds like a bug in RSS. That behavior makes very little sense to me. Gravitational parameter should be consistent. Do we have any way of talking to a dev over there to ask?

[Stract]

14 minutes ago, Arrowstar said:

Oh dear. Okay, thanks for investigating. That honestly sounds like a bug in RSS. That behavior makes very little sense to me. Gravitational parameter should be consistent. Do we have any way of talking to a dev over there to ask?

Well, it is a bug of Kopernicus, not just RSS. As I understand, Kopernicus creates new solar system with this modification of orbital periods, but doesn't change the way spacecrafts are propagating (maybe it is not easy to change, I don't know). And unfortunately the game itself calculates relative speeds during SOI transition using default bodies mean motion. We can try to talk to devs about this inconsistency but I'm not sure they'll consider it as a bug.

[Phineas Freak]

RSS uses mostly hard-coded values for it's body (calculated via the JPL HORIZONS ephemeris computation service) so it also uses G(M + m) when calculating the ephemeris data. Now, if KSP forces the vessels to use just GM then, as @Stract says, we will be SOL.

The easiest thing to do would be to redefine all GM values of RSS but we will lose accuracy for historical events. Or maybe Principia could help with the vessel calculations.

[Stract]

6 minutes ago, Phineas Freak said:

 

RSS uses mostly hard-coded values for it's body (calculated via the JPL HORIZONS ephemeris computation service) so it also uses G(M + m) when calculating the ephemeris data. Now, if KSP forces the vessels to use just GM then, as @Stract says, we will be SOL.

 

No, the ephemeris data are correct (well, if I understand the term right ). I'm talking about the following thing: suppose we have vectors v1 for velocity of the spacecraft and v2 for the velocity of the moon both relative to the central body. Then v=v1-v2 is the velocity of the spacecraft relative to the moon. What I've noticed is that at the moment of SOI transition KSP use the value for v2 as it would be in stock game. Maybe KSP calculates it separately from RSS using just orbital parameters from database as it always do. That's only my assumption and I it would be great if someone can confirm it.

[Arrowstar]

1 hour ago, Stract said:

No, the ephemeris data are correct (well, if I understand the term right ). I'm talking about the following thing: suppose we have vectors v1 for velocity of the spacecraft and v2 for the velocity of the moon both relative to the central body. Then v=v1-v2 is the velocity of the spacecraft relative to the moon. What I've noticed is that at the moment of SOI transition KSP use the value for v2 as it would be in stock game. Maybe KSP calculates it separately from RSS using just orbital parameters from database as it always do. That's only my assumption and I it would be great if someone can confirm it.

Any idea if this happens on upwards transitions too?  That is, Charon to Pluto?

[EpicSpaceTroll139]

Hmmm... was I supposed to do something other than replace the old .exe with the new .exe? Everything went fine until I tried Compute Flyby Maneuver Sequence. Then... nothing. Nothing happened. Tried putting in a different sequence with no repeats. Still wouldn't do anything. Tried with one flyby. Nothing. Also tried messing with the max number of revolutions. Same results. Tried just going from one planet to another. Nope.

I get the feeling I've goofed somewhere.

If you don't think I've goofed I can see if I can find the logs.

If it works like it looks the update is great! Thanks!

Edited May 30, 2017 by EpicSpaceTroll139
Picture

[Arrowstar]

25 minutes ago, EpicSpaceTroll139 said:

Hmmm... was I supposed to do something other than replace the old .exe with the new .exe? Everything went fine until I tried Compute Flyby Maneuver Sequence. Then... nothing. Nothing happened. Tried putting in a different sequence with no repeats. Still wouldn't do anything. Tried with one flyby. Nothing. Also tried messing with the max number of revolutions. Same results. Tried just going from one planet to another. Nope.

I get the feeling I've goofed somewhere.

If you don't think I've goofed I can see if I can find the logs.

If it works like it looks the update is great! Thanks!

Yes, please post the contents of the ksptot.log log file.  Thanks!

[EpicSpaceTroll139]

Spoiler

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Index exceeds matrix dimensions.

Error in multiFlyByManeuverSequencer>maxNumRevsText_Callback (line 1119)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('maxNumRevsText_Callback',hObject,eventdata,guidata(hObject))

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Index exceeds matrix dimensions.

Error in multiFlyByManeuverSequencer>maxNumRevsText_Callback (line 1119)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('maxNumRevsText_Callback',hObject,eventdata,guidata(hObject))

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

 

@Arrowstar Here ya go!

[Arrowstar]

9 hours ago, Stract said:

Ugh. Great, just great... I think I've found the answer after all. I have a crazy idea that RSS calculates orbital periods using G(M+m) BUT use GM for calculation of new spacecraft speed during SOI transition. Look: I've modified bodies.ini by put there Charon position at the moment just before transition (to make sure the Charon mean anomaly at this moment is correct) and run TOT with GM gravitational parameter. Well, look at the screenshot. RSS way of calculations is VERY counter-intuitive...

  Hide contents

This is my modified bodies file. You can check it with mission file I've uploaded before, just choose old GM settings. If I am right then things become more complicated: TOT has to track SOI transition using G(M+m) to find correct location of the body but re-calculate new rVectBody and vVectBody during transition with just GM.

Okay, so here's the deal.  I've played around with changing the way that the velocity of the spacecraft is computed on downward SOI transitions in an attempt to replicate what you have, but I can't figure it out.  If I change the grav parameter function for the state conversion but not for the SoI transition, then the position of the spacecraft is wildly off in the new SoI.  If I hack it so the position is computed with the G(M+m) but the velocity is just GM, then I ended up with a flat out wrong velocity.

I'm going to need more information on what's going on with RSS before I can try to replicate it.  This is more complicated than a one line fix on my end I suspect...

2 hours ago, EpicSpaceTroll139 said:

  Reveal hidden contents

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Index exceeds matrix dimensions.

Error in multiFlyByManeuverSequencer>maxNumRevsText_Callback (line 1119)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('maxNumRevsText_Callback',hObject,eventdata,guidata(hObject))

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Index exceeds matrix dimensions.

Error in multiFlyByManeuverSequencer>maxNumRevsText_Callback (line 1119)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('maxNumRevsText_Callback',hObject,eventdata,guidata(hObject))

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

Error using ga (line 351)
Unknown grav parameter option ""!

Error in multiFlybyExec (line 59)

Error in multiFlyByManeuverSequencer>computeFlybyManSeqButton_Callback (line 573)

Error in gui_mainfcn (line 95)

Error in multiFlyByManeuverSequencer (line 42)

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)multiFlyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))

Caused by:
    Failure in initial user-supplied nonlinear constraint function evaluation.

Error while evaluating UIControl Callback

 

@Arrowstar Here ya go!

Okay.  Try deleting your appOptions.ini file and then restarting the application.  Something didn't get upgraded correctly.  I'll fix that.

[Arrowstar]

Hi everyone, I have compiled KSPTOT v1.5.8 pre-release 3.  This fixes the bug I found in MFMS while investigating @drunkeNNN's post.  It also fixes the bug that @EpicSpaceTroll139 found.  It doesn't do anything for the SoI transition issue @Stract found with RSS, but I guess we'll continue investigating that.

Please let me know what issues you find.  Thanks!

[EpicSpaceTroll139]

@Arrowstar I'll check the new pre-release out. The deleting of the appOptions.ini indeed fix the problem of nothing happening. Although with it working I started to consistently get trajectories that sent me through planets lol.

[Arrowstar]

Just now, EpicSpaceTroll139 said:

@ArrowstarAlthough with it working I started to consistently get trajectories that sent me through planets lol.

Can you provide some screenshots that illustrate what you mean?