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

[Arrowstar]

5 hours ago, Drew Kerman said:

How did you know it was these events holding things up?

I have some debug code in LVD that I use to help me understand bottlenecks.  It never occurred to me until tonight that others might find that useful, but I can see now that it could be.  I've added a feature to the upcoming PR6 that will allow those event propagation wall clock times to be output to the KSPTOT.log file.

Quote

Switching to ODE5 did indeed bring down the execution time from 6s to 2s, but it also gave me a slightly different result. ODE5 has me coming down 3km from where ODE45 says the rocket will - which isn't really a huge difference so I'm not concerned about that. I'm just wondering though if the speed has sacrificed accuracy or improved it - could potentially make a difference on problems requiring more precision

Yes, using ODE5 will give slightly different answers, but the result should still be acceptable.  If you need accuracy, then generally ODE45 or any of the other adaptive step size are the go to, but sometimes the internal step sizes get really small and things take forever.  In those cases, use ODE5 and select a step size that is reasonable for the time scales you're working with.

Quote

Also is this speeding up just the script execution or the optimizer execution as well?

Anything that speeds up script execution also speeds up optimization, so should be both.

Quote

For my understanding in choosing between integrator options in the future, what would be considered a "stiff problem"?

Stiff problems show up when the time scales of the functions being integrated are very different.  In our case, this usually means cases when lots of drag is involved, especially in cases where the vehicle has reached terminal velocity.

Quote

Ah, okay. So this is a bit of an inconsistency then since the Initial State coordinates seem to be okay with accepting -180/180 values for longitude. I thought then that was valid input for anything longitude in LVD (I know MA doesn't like it and I have to convert to 0-360). Actually this has always annoyed me a little bit since everything in KSP is done -180/180. A related minor annoyance is how input fields and stuff like the popup tooltips report lng/lat instead of lat/lng ;P

Anyways yea adding 360 to make the conversion seems to have worked. At least, the optimizer has been running along now without issue for over an hour crunching on the problem and the constraint violation is trending downwards

Yeah, I do allow a variety of input values for ease of use, but the constraint codes do have to output values in a specified range.  It happens that MATLAB tends to return things in 0-360, so that's what I do.  Remember that you can perform math operations in numeric text boxes, so if you need to add 360 to something, just type "<num> + 360" where <num> is your number and it'll do the addition for you.

Also, it's taking an hour to run?  That's a bit insane.  Are your constraint values at least getting close to a small (~ 0) number?

Quote

Also, this popped up on the kOS reddit yesterday. Not sure if it will be applicable to LVD's own work with drag calculation tho.

I'll take a look, thanks!

1 hour ago, The Aziz said:

So I keep getting the same thing (and the quoted problem happened to the guy over 3 years ago)
And basically same situation, I updated both the runtime and the tool to versions linked in first post (as I had very outdated versions), got it working once, and suddenly when I tried today I kept getting that "ping" sound. In task manager the exe seems to appear for a moment and then disappears, but no window shows up. Log is identical as in the quote. Using the prerelease solution linked few posts below won't make sense as it's even more outdated.

So it was working, and then nothing changed, and then it stopped again?  That is... odd.

Please follow the instructions in the Accepted Answer area of this webpage and see if it helps any.  Thanks!

https://www.mathworks.com/matlabcentral/answers/98050-why-do-i-get-an-error-saying-undefined-function-or-variable-matlabrc-when-executing-a-program-th

Edited November 20, 2020 by Arrowstar

[Arrowstar]

Alright, here is KSPTOT v1.6.7 pre-release 6.  Here's the change log:

• LVD: Drawing plots should be faster when plotting other celestial bodies.  The slow multiprocessing stuff from a previous pre-release is gone here.
• LVD: Added a feature to output the wall clock run time for each event to the ksptot.log file upon propagation.  See Settings menu.

[vitorboschi]

12 hours ago, Arrowstar said:

Alright, here is KSPTOT v1.6.7 pre-release 6.  Here's the change log:

• LVD: Drawing plots should be faster when plotting other celestial bodies.  The slow multiprocessing stuff from a previous pre-release is gone here.
• LVD: Added a feature to output the wall clock run time for each event to the ksptot.log file upon propagation.  See Settings menu.

No Linux version this time around?

[Arrowstar]

1 hour ago, vitorboschi said:

No Linux version this time around?

I've just uploaded an updated ZIP file with a Linux binary in there.

[vitorboschi]

25 minutes ago, Arrowstar said:

I've just uploaded an updated ZIP file with a Linux binary in there.

Thanks man!

[The Aziz]

20 hours ago, Arrowstar said:

So it was working, and then nothing changed, and then it stopped again?  That is... odd.

Please follow the instructions in the Accepted Answer area of this webpage and see if it helps any.  Thanks!

I know, weird, the only thing that could have changed, could be windows update, but not sure.

However, I checked the link, but the answer that helped (and I could understand) was the second one. I deleted related files from appdata\temp, relaunched and waited until the files appeared again.

[Arrowstar]

Right, now that the PR is out, is there anything anyone has brought up in the past few months that I haven't already addressed?  @Drew Kerman?

[Drew Kerman]

On 11/19/2020 at 6:39 PM, Arrowstar said:

Also, it's taking an hour to run?  That's a bit insane.  Are your constraint values at least getting close to a small (~ 0) number?

Oh yea, the constraint started well below 0 and just kept getting smaller and smaller. It eventually quit on its own and the smallest constraint was 30 of 34 iterations. I was aiming for a very very specific number so I expected it would take time to work through the problem especially considering I use a lot of Cd values and had several pitch events as well. Didn't seem unreasonable to take that long although I also don't really know what reasonable would be

3 hours ago, Arrowstar said:

Right, now that the PR is out, is there anything anyone has brought up in the past few months that I haven't already addressed? 

I'll take some time later tonight or tomorrow to go back and double check for you

Edited November 21, 2020 by Drew Kerman

[The Aziz]

Aaand here we go, ping sound again. Worked like a charm yesterday.

I believe there is supposed to be a lot of files in C:\Users\username\AppData\Local\Temp\username\mcrCache9.3\KSPTra0 ? Because most of them are gone.

I just deleted the remainders manually and tried again - it created the files again and launched.

[Drew Kerman]

@Arrowstar nothing major missed in the last few months. There's still some deep analysis that needs to be done with some of the trajectory data I posted a while back where I found Mun encounters to be spoiling future plots of my captured asteroid but that's not a pressing issue still - something more to tackle in lieu of anything else.

More good stuff from reddit tho - this is an update to a post I linked to earlier:

 

[Arrowstar]

On 11/21/2020 at 10:51 AM, The Aziz said:

Aaand here we go, ping sound again. Worked like a charm yesterday.

I believe there is supposed to be a lot of files in C:\Users\username\AppData\Local\Temp\username\mcrCache9.3\KSPTra0 ? Because most of them are gone.

I just deleted the remainders manually and tried again - it created the files again and launched.

I'm not really sure to tell you.  Yes, there should be lots of files in that directory.  If they're being deleted, it's because something on your PC is deleting them.  Is there maybe some anti-virus software that's misbehaving?  Do the files stick around after you close KSPTOT once?  Are they still there if you restart your PC?

[The Aziz]

On 11/23/2020 at 4:27 PM, Arrowstar said:

I'm not really sure to tell you.  Yes, there should be lots of files in that directory.  If they're being deleted, it's because something on your PC is deleting them.  Is there maybe some anti-virus software that's misbehaving?  Do the files stick around after you close KSPTOT once?  Are they still there if you restart your PC?

Files were there after I closed the app, then I tried to restart my PC - still there.  The following day though, there is only one file: .created.ts,  and two directories: .matlab and .META, and they both look like they were created when I turned on the computer today.

I am going to fiddle with possibility of automatic deletion of files in Temp (however I don't have too much hope as there are still some files from several days ago).

[Arrowstar]

In other news, I finally fixed the stupid issue in LVD where if you slid the time slider around a bunch, it would freeze the UI for a long time.  You're welcome, everyone.

7 hours ago, The Aziz said:

Files were there after I closed the app, then I tried to restart my PC - still there.  The following day though, there is only one file: .created.ts,  and two directories: .matlab and .META, and they both look like they were created when I turned on the computer today.

I am going to fiddle with possibility of automatic deletion of files in Temp (however I don't have too much hope as there are still some files from several days ago).

Okay, so something outside of MATLAB and KSPTOT is wiping those files it sounds like.  You'll have to do some digging on your end.  It could be anything I suppose...

[The Aziz]

Back with the report. Turns out one of the system storage settings is just cleaning things up, probably on startup. Turned it off for now and everything is there.

But it's strange how few files still were present after previous wipes. Like some of the files had built-in protection from being deleted from Temp? I don't know.

[Ashnoom]

I seem to have an issue with the datetime report by KSP and what KSPTOT is telling me. The following image should give all the details of what I mean:

For some reason KSPTOT is reporting KSPtime + 5 days. (I am on RSS/RO/RP-1 if that is important). Converting back and forth the time in seconds reported by KSPTOT does translate to the correct delta in KSP. (So 1 day departure time in KSPTOT is 1 day departure time in KSP).

Second issue that I seem to have is that I just can't get the orbit calculated from KSPTOT in to KSP. I am sure it is a case of PEBKAC and/or not understanding the tool/orbital mechanics, but so far, not much luck in finding my own answers on the vast galactic interwebs.
I am trying to plot a trajectory from Earth -> Mercury with a Venus gravity assist.  So I am using the MFMS tool. The trajectory it calculates looks like (note, this is an example run, this is not the actual mission that I am trying to plot, there are more optimal solutions available at a different launch window):

Which ends up like (after tweaking the location where the burn starts along the line of the orbit):

Doing a maneuver burn around Venus to get me closer requires around another 800dV to get an encounter with Mercury. Is this expected? Should the example provided by MFMS be near perfect copyable to KSP?

[vitorboschi]

15 hours ago, Ashnoom said:

I seem to have an issue with the datetime report by KSP and what KSPTOT is telling me. The following image should give all the details of what I mean:

For some reason KSPTOT is reporting KSPtime + 5 days. (I am on RSS/RO/RP-1 if that is important). Converting back and forth the time in seconds reported by KSPTOT does translate to the correct delta in KSP. (So 1 day departure time in KSPTOT is 1 day departure time in KSP).

Second issue that I seem to have is that I just can't get the orbit calculated from KSPTOT in to KSP. I am sure it is a case of PEBKAC and/or not understanding the tool/orbital mechanics, but so far, not much luck in finding my own answers on the vast galactic interwebs.
I am trying to plot a trajectory from Earth -> Mercury with a Venus gravity assist.  So I am using the MFMS tool. The trajectory it calculates looks like (note, this is an example run, this is not the actual mission that I am trying to plot, there are more optimal solutions available at a different launch window):

Which ends up like (after tweaking the location where the burn starts along the line of the orbit):

Doing a maneuver burn around Venus to get me closer requires around another 800dV to get an encounter with Mercury. Is this expected? Should the example provided by MFMS be near perfect copyable to KSP?

Answering to your last question "Should the example provided by MFMS be near perfect copyable to KSP?": no, it shouldn't be directly usable. MFMS provides just a ballpark estimation and you usually need to use Mission Architect or LVD to properly model your mission using MFMS data as initial estimates.

[DBowman]

I switched bodies.ini to the solarSystem version by changing file names and started KSPTOT, LVD seems to hang while opening with errors in the log:

Error in KSPTOT_BodyInfo/getParBodyInfo (line 108)

Error in getAbsPositBetweenSpacecraftAndBody (line 15)

Error in getSoITransitionOdeEvents (line 29)

Error in AbstractPropagator.odeEvents (line 77)

Error in ForceModelPropagator>@(t,y)AbstractPropagator.odeEvents(t,y,eventInitStateLogEntry,eventTermCondFuncHandle,termCondDir,maxT,checkForSoITrans,nonSeqTermConds,nonSeqTermCauses,minAltitude,celBodyData) (line 61)

Error in ForceModelPropagator/callEventsFcn (line 70)

Error in LaunchVehicleSimulationDriver/integrateOneEvent (line 91)

Error in LaunchVehicleEvent/executeEvent (line 157)

Error in LaunchVehicleScript/executeScript (line 272)

Error in ma_LvdMainGUI>propagateScript (line 171)

Error in ma_LvdMainGUI>runScript (line 148)

Error in ma_LvdMainGUI>ma_LvdMainGUI_OpeningFcn (line 122)

Error in gui_mainfcn (line 220)

Error in ma_LvdMainGUI (line 40)

Error in mainGUI>launchVehicleDesignerMenu_Callback (line 916)

Error in gui_mainfcn (line 95)

Error in mainGUI (line 42)

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

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.
 

I hacked Mars data over Kerbin in the default bodies and LDV starts fine again

[Sppion1]

Hi !
I'm having trouble using this tool...

I recently wanted to plan flyby (start small, they said...). So I found this tool, read a tutorial, trying myself... Found out that the tool I wanted is the "multi-flyby Manoeuver sequencer". I put time in it (I don't know how to do it directly from KSP ?), I put my orbit (found how to do it with right clik => from KSP/FSF file), put my waypoint, that would be Kerbin Eve Kerbin to me. I hit the compute flyby manoeuver sequencer.... To find out a lot of information. And I can't put the first manoeuver node, which is supposed to drive me to Eve....

Got those informations :
Kerbin Departure Date =
                Year 2, Day 119 01:47:29.407
                      (11756849.4072 sec UT)

Burn Information to Depart Kerbin
---------------------------------------------
Total Delta-V =                 1.5954 km/s
Prograde Delta-V =              780.7456 m/s
Orbit Normal Delta-V =          1221.0937 m/s
Radial Delta-V =                666.7340 m/s
---------------------
Burn True Anomaly =             130.3310 deg

So I do understand almost all. But what about the true anomaly ? How do I set the manoeuver accordingly ? From what I found, it is the angle between periapsis and my vessel, as seen from Kerbin (in this case). Right. But precise node doesn't provide this information. And by eyeballing it, the departure date wasn't at the right moment. (more like 10/20° for my vessel). And by trying to place it close (but eyeballing, because I got no tools) I got something that get me a flyby Eve.

So I could go with that and try to get a burn to reintercept Kerbin later. But is there a way to :

• Exactly place my burn at the right place (with true anomaly, I guess, but how exactly) ?
• Re calculate the burn characteristic (prograde/normal/radial) for a specific time at a specific place on the orbit ? So when placed with previous question, I could just input new numbers and get my trajectories. So no more guess the best to come back.

 

[Arrowstar]

On 12/1/2020 at 3:16 PM, Ashnoom said:

I seem to have an issue with the datetime report by KSP and what KSPTOT is telling me. The following image should give all the details of what I mean:

For some reason KSPTOT is reporting KSPtime + 5 days. (I am on RSS/RO/RP-1 if that is important). Converting back and forth the time in seconds reported by KSPTOT does translate to the correct delta in KSP. (So 1 day departure time in KSPTOT is 1 day departure time in KSP).

If you're using a modded install, then it could be that one of those mods changes the time system to something that is not built into KSPTOT.  Don't worry about it too much, only the UT seconds are authoritative.  The days/hours/minutes etc are just for user convenience.

16 hours ago, DBowman said:

I switched bodies.ini to the solarSystem version by changing file names and started KSPTOT, LVD seems to hang while opening with errors in the log:

Error in KSPTOT_BodyInfo/getParBodyInfo (line 108)

Error in getAbsPositBetweenSpacecraftAndBody (line 15)

Error in getSoITransitionOdeEvents (line 29)

Error in AbstractPropagator.odeEvents (line 77)

Error in ForceModelPropagator>@(t,y)AbstractPropagator.odeEvents(t,y,eventInitStateLogEntry,eventTermCondFuncHandle,termCondDir,maxT,checkForSoITrans,nonSeqTermConds,nonSeqTermCauses,minAltitude,celBodyData) (line 61)

Error in ForceModelPropagator/callEventsFcn (line 70)

Error in LaunchVehicleSimulationDriver/integrateOneEvent (line 91)

Error in LaunchVehicleEvent/executeEvent (line 157)

Error in LaunchVehicleScript/executeScript (line 272)

Error in ma_LvdMainGUI>propagateScript (line 171)

Error in ma_LvdMainGUI>runScript (line 148)

Error in ma_LvdMainGUI>ma_LvdMainGUI_OpeningFcn (line 122)

Error in gui_mainfcn (line 220)

Error in ma_LvdMainGUI (line 40)

Error in mainGUI>launchVehicleDesignerMenu_Callback (line 916)

Error in gui_mainfcn (line 95)

Error in mainGUI (line 42)

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

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.
 

I hacked Mars data over Kerbin in the default bodies and LDV starts fine again

Issue resolved for next release.  Thanks for the report!

7 hours ago, Sppion1 said:

So I could go with that and try to get a burn to reintercept Kerbin later. But is there a way to :

• Exactly place my burn at the right place (with true anomaly, I guess, but how exactly) ?
• Re calculate the burn characteristic (prograde/normal/radial) for a specific time at a specific place on the orbit ? So when placed with previous question, I could just input new numbers and get my trajectories. So no more guess the best to come back.

 

1. You're not going to be able to use true anomaly to place your burn "exactly" in KSP.  You can eyeball it, which I think you're doing.  You can also take that burn plan, but it into Mission Architect or Launch Vehicle Designer, and re-optimize the burns to achieve the trajectory you want without the zero-sized local gravity well size limitation that is present in MFMS in there.  The former will be way easier but will also involve some playing around with the burn parameters in order to actually get what you want.  The latter is exact but will take a fair bit of time and practice.
2. I optimize the departure burn location in MFMS to determine the best place to center the delta-v of the burn.  There is no way to recompute the burn in order to place it at a different point in time or along the pre-departure orbit.  It would be sub-optimal there anyway.

Hope that helps!  Let me know if you have any other questions.

[DBowman]

Thanks for the Mars reply above.

I've been playing with MFMS. I added Ceres from (https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=1&orb=1). This source has epoch in days, is that also what your bodies.ini uses? I can just use that epoch? Also I noticed that your GM for Jupiter is gm = 1.266865349218008E+08 but https://en.wikipedia.org/wiki/Standard_gravitational_parameter is E+17, I see  a systematic E09 difference so I guess just different units?

For your reference I added:

[Ceres]
epoch = 2458600.5
sma = 4.142612098521883E+08
ecc = 0.0760090265983052    
inc = 10.59406719506626
raan = 80.30553090445737
arg = 73.59769469844186    
mean = 77.37209751948711
gm = 6.26325E+01    
radius = 469.73
0 for atmos stuff
rotperiod = 32400
rotini = 0
bodycolor = bone
canBeCentral = 0
canBeArriveDepart = 1
parent = Sun
name = Ceres
id = 559

I found a cool EVEC with E1 vinf 3.9 km/s and E2 vinf 11.2 km/s. The idea being use the low dV to set all the heavy stuff in motion, and then have crew jump on in a minimal vehicle at the E2 pass. From a 200x200 km orbit and using V^2=Vesc^2+Vinf^2 and V=Vorb+deltaV then E1 needs 4,060 m/s dV and E2 8,041. So we steal 3980 m/s from Venus, nice, it cuts propellant to 30% of just doing the 8 km/s burn.

here is a screenshot https://drive.google.com/file/d/1Qq3hKmghJmy5AJk68NC3dZiiX6UnC1mo/view?usp=sharing

But I'm not sure exactly what is being minimized. I had checked "include departure Vinf" and not "include arrival Vinf" - but what happens regarding the intermediate deltaVs at Venus and E2? there is about 600 m/s done on those flybys. Also, although I calculate by hand the deltaV for E1 as 4,060 m/s from the departure Vinf, MFMS shows 25,606.8 m/s departure deltaV (-3,000prograde, 20,000normal, 16,000radial) I figure if I set up my initial orbit correctly I could make that be 4,060 m/s. So I'm hoping the optimizer isn't looking at the 26km/s. Are you able to clear up my doubts?

[Sppion1]

@Arrowstar

Thanks for the reply, that's very much appreciated.

So if I understand the logic, I use MFMS to preplan a maneuver, which is a bit unrealistic, because I won't be at that place at that exact moment.

After that I use either mission architect or launch vehicle designer to replan exactly the burn, at a more realistic moment (as I am already in orbit, you know) with parameters that will let me go where I want ?

So I'm experimenting right now with mission architect. To be more realistic, I took a sandbox game, lanched a prob with 5000 m/s (so I'm pretty sure that's enough, and anyway I can refill it up with *magic*).

Now I'm in orbit, ready to go.

In MFMS, I indicated my current orbit, *now* in launch window open, *now* + 88 day in launch window close. Ran the simulation. I got :

UT launch : 2138399.9991

Burn Information to Depart Kerbin
---------------------------------------------
Total Delta-V =                 2.2242 km/s
Prograde Delta-V =              2221.2154 m/s
Orbit Normal Delta-V =          -115.7186 m/s
Radial Delta-V =                1.2678 m/s
---------------------
Burn True Anomaly =             121.4147 deg
---------------------------------------------
Burn Information to Depart Eve
---------------------------------------------
Total Delta-V =                 0.0318 km/s
Prograde Delta-V =              31.8188 m/s
Orbit Normal Delta-V =          0.0000 m/s
Radial Delta-V =                0.0000 m/s
---------------------
Burn True Anomaly =             0.0000 deg
---------------------------------------------
Total Mission Delta-V =         2.2560 km/s

So yeah, 5000 m/s are enough. Now, that's not realistic as at that exact time of launch, I won't be at 121° for the true anomaly.

If I understood well, I'm supposed to use from example mission architect. So I open it up, double click on initial state to set the actual orbit of my vessel, updated dry mass and propellant masses.

I added a coast event to go to the time of launch (minus 15 minutes, as my orbit period is about 30 minutes, 15 let me be as close as possible of the launch time while being at the true anomaly) (lot of waiting here, as I got a yellow "working" (waiting for 88days, so...))

I then added another coast event to go to the true anomaly. (waiting again :D)

I then added my maneuver node. Seeing that nothing changed in the orbit, I added another coast event, to go to Y2 D99 (waiting for almost one year....)
I can then see that it's pretty close to Eve orbit, but not really in Eve SOI. How do I make the tool adjust the burn so I end up in Eve SOI ?
I take the UT of the end of the cost event (coast to true anomaly), which is the start moment of the burn. I put it back in MFMS at launch window open, and in launch window close (1 second later).
I computed again the maneuver, got slightly different parameters, and updated the maneuver in mission architect. (waiting again). Then updated the last coast event (supposed to coast to Eve peri, as it is the one in MFMS).
And.. nothing. Is still end orbiting the sun. I added 2 seconds (maybe I was wrong and the time given in MFMS was not the peri but the encounter ?). Still orbiting the sun..


Questions :

• Is it normal that it take so long ?
• Am I doing it the right way ? Is it supposed to work this way ?
• What should I do to get this maneuver right ? To be able to exactly get the time of burn, and other parameters predefined so I get that encounter ?

[DBowman]

oh I think I've done a bad thing; I set LVD Maximum Script propagation time to 3600 (I was thinking five mins, but obv and hour), and I think now it's going to run for 6 more hours...

Is there any way to interrupt it? Killing the prog will loose unsaved changes, I think I had been changing a sequential event and it had been throwing 5 second exceeded warnings when closing them.

Obviously my fault, but what is it actually doing on each event close/save? Some of the GUI is live, and the task bar icon occasionally highlights.

I'm playing with a Mars ascent vehicle.

[Arrowstar]

19 hours ago, DBowman said:

oh I think I've done a bad thing; I set LVD Maximum Script propagation time to 3600 (I was thinking five mins, but obv and hour), and I think now it's going to run for 6 more hours...

Is there any way to interrupt it? Killing the prog will loose unsaved changes, I think I had been changing a sequential event and it had been throwing 5 second exceeded warnings when closing them.

Obviously my fault, but what is it actually doing on each event close/save? Some of the GUI is live, and the task bar icon occasionally highlights.

I'm playing with a Mars ascent vehicle.

I would need to see the MAT file to understand what's going on.  Most likely you're running into a stiff section of integration where the integrator has to take small step sizes to meet the tolerances.

The save button just writes the internal data structure to MATLAB's proprietary file format.  It never takes more than a moment or two.

[Arrowstar]

On 12/3/2020 at 11:53 PM, DBowman said:

Thanks for the Mars reply above.

I've been playing with MFMS. I added Ceres from (https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=1&orb=1). This source has epoch in days, is that also what your bodies.ini uses? I can just use that epoch? Also I noticed that your GM for Jupiter is gm = 1.266865349218008E+08 but https://en.wikipedia.org/wiki/Standard_gravitational_parameter is E+17, I see  a systematic E09 difference so I guess just different units?

For your reference I added:

[Ceres]
epoch = 2458600.5
sma = 4.142612098521883E+08
ecc = 0.0760090265983052    
inc = 10.59406719506626
raan = 80.30553090445737
arg = 73.59769469844186    
mean = 77.37209751948711
gm = 6.26325E+01    
radius = 469.73
0 for atmos stuff
rotperiod = 32400
rotini = 0
bodycolor = bone
canBeCentral = 0
canBeArriveDepart = 1
parent = Sun
name = Ceres
id = 559

I found a cool EVEC with E1 vinf 3.9 km/s and E2 vinf 11.2 km/s. The idea being use the low dV to set all the heavy stuff in motion, and then have crew jump on in a minimal vehicle at the E2 pass. From a 200x200 km orbit and using V^2=Vesc^2+Vinf^2 and V=Vorb+deltaV then E1 needs 4,060 m/s dV and E2 8,041. So we steal 3980 m/s from Venus, nice, it cuts propellant to 30% of just doing the 8 km/s burn.

here is a screenshot https://drive.google.com/file/d/1Qq3hKmghJmy5AJk68NC3dZiiX6UnC1mo/view?usp=sharing

But I'm not sure exactly what is being minimized. I had checked "include departure Vinf" and not "include arrival Vinf" - but what happens regarding the intermediate deltaVs at Venus and E2? there is about 600 m/s done on those flybys. Also, although I calculate by hand the deltaV for E1 as 4,060 m/s from the departure Vinf, MFMS shows 25,606.8 m/s departure deltaV (-3,000prograde, 20,000normal, 16,000radial) I figure if I set up my initial orbit correctly I could make that be 4,060 m/s. So I'm hoping the optimizer isn't looking at the 26km/s. Are you able to clear up my doubts?

Units in KSPTOT are always kilometers, seconds, and radians.  (With the annoying exception of mean anomaly in the bodies.ini files, which is degrees because KSP uses degrees here).  If you are inputting the gravitational parameter, it is in km^3/s^2.

With your Ceres entry there, be sure you have a line called "parentID = 0" in there.  Look at Earth for an example.  This is a bug that it is missing from some of the bodies in that solarSystemBodies.ini file that was mentioned before.  It will be fixed for the next release.

What is being minimized is the sum of the flyby delta-v magnitudes, plus the departure and arrival Vinf values, if you so choose.

[Arrowstar]

Hi everyone,

Tonight I'm pushing out KSPTOT v1.6.7 pre-release 7.  Here's the change log with some welcome updates:

• LVD: Fixed bug with the time slider sucking up a bunch of CPU time after sliding it around a bunch.
• The missing parentID lines of the SolarSystemBodies.ini file have been added.
• LVD: Added a linear tangent steering model to the available options in LVD.  This is a great way to get an optimal ascent from the surface of a body to space, as the linear tangent steering law is actually derived directly from optimal control theory.  As of now, only "pitch" type angles can use this steering.
  • The linear tangent steering law is: tan(pitch_angle) = a*t + b, where t is time after the steering law is initiated and a and b are constants.
  • There is a new lvd example MAT file that shows how to use it, and best of all, shows how it can be used to get off of the Mun in a single event!  I've included this in the pre-release.
• MA/LVD: Added a flight path angle graphical analysis task and constraint.  For reasons that I still want to understand better, setting up your launch vehicle orbit insertion targets as radius/velocity/flight path angle works way better with an optimizer than asking for SMA/eccentricity or apogee/perigee.  I've noticed this in my professional life too.
• There may be some performance improvements with computing atmospheric temperatures over the previous PR, but I've had trouble determining if they're real or not, so your mileage may vary.

Please let me know if you have any questions or find any bugs, especially with the new linear tangent steering code.  Thanks!

Edited December 7, 2020 by Arrowstar