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

[Drew Kerman]

and of course I managed to break it, because that is my superpower. Repro steps:

1. Open MA
2. Insert a coast event
3. Change nothing, close & save
4. Attempt to insert any other event
5. Check error log for details

Can also repro this in 1.6.5. Which caught me cause I just did some MA work recently in it so dug a bit deeper and I can make things work if I change the coast from TA (which I haven't used recently) to something else.

wow goes back to 1.6.4 too. Haven't been using MA as much lately!

Works if you change the TA from 0

Edited August 16, 2020 by Drew Kerman

[Arrowstar]

2 hours ago, Drew Kerman said:

and of course I managed to break it, because that is my superpower. Repro steps:

1. Open MA
2. Insert a coast event
3. Change nothing, close & save
4. Attempt to insert any other event
5. Check error log for details

Can also repro this in 1.6.5. Which caught me cause I just did some MA work recently in it so dug a bit deeper and I can make things work if I change the coast from TA (which I haven't used recently) to something else.

wow goes back to 1.6.4 too. Haven't been using MA as much lately!

I've got it resolved.  I'm going to rebuild and reupload v1.6.6.  I'll edit this post when I'm done.

EDIT: Alright, new builds are live.  Thanks for the find, @Drew Kerman!

Edited August 17, 2020 by Arrowstar

[vitorboschi]

Hey @Arrowstar, @Drew Kerman and any other who wants to chime in, how do you go after planning a launch using LVD? It doesn't look easy to manually fly the planned profile, and as far as I know, there's no way to make MJ follow the planned profile.

Is the only real option using something like kOS?

Development suggestion for the MCC/LVD: plot real time trajectory over the final LVD planned trajectory, so that we can see how closely the ship is following the plan

[Arrowstar]

1 hour ago, vitorboschi said:

Hey @Arrowstar, @Drew Kerman and any other who wants to chime in, how do you go after planning a launch using LVD? It doesn't look easy to manually fly the planned profile, and as far as I know, there's no way to make MJ follow the planned profile.

Is the only real option using something like kOS?

Yeah, kOS is probably the way to go for this.  Keep in mind that in-game trajectories are never going to perfectly match the LVD model, but they should be pretty close if you set up LVD correctly.

Quote

Development suggestion for the MCC/LVD: plot real time trajectory over the final LVD planned trajectory, so that we can see how closely the ship is following the plan

I'll keep it in mind.  For now, you can use GA to pull LVD's trajectory information in and use Excel or Google Sheets to do the plotting for you.

[CanisLupus518]

@Arrowstar I would like to setup a scenario where my friend can run TOT from his home and connect via IP to the plugin running in my KSP instance at my home. (Kind of like he’s my mission control). What ports would I need to open up in my router to allow this?

[Arrowstar]

2 hours ago, CanisLupus518 said:

@Arrowstar I would like to setup a scenario where my friend can run TOT from his home and connect via IP to the plugin running in my KSP instance at my home. (Kind of like he’s my mission control). What ports would I need to open up in my router to allow this?

I believe it's ports 8282 through 8295.  Let me know if you have any trouble.

[vitorboschi]

Hey @Arrowstar, I've been messing around the LVD for some time now (it's awesome!) that I feel confident to ask questions/report bugs, so these are my findings:

Bugs

Note that I'm running the Linux version. This is likely relevant for the window layout issues

• Can't add power storage on vehicle editor. When I click the "Add power storage" button, it beeps and the following log is written, but I get no other reaction from the GUI:

Undefined variable "LaunchVehiclePowerStorageEnum" or class "LaunchVehiclePowerStorageEnum.getListBoxStr".

Error in lvd_EditElectricalPowerStoragesGUI>addStorageButton_Callback (line 161)


Error in gui_mainfcn (line 95)


Error in lvd_EditElectricalPowerStoragesGUI (line 42)


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

Error using uiwait (line 81)
Error while evaluating UIControl Callback.

 

• The "Constraint Type" is too small, so it's not possible to read the complete constraint name:

 

• There's a warning being written on the logs a lot of times with my current mission. I'm not sure this is really a bug or something I messed up with KSP TOT's settings. Just opening the .mat or running the script should generate some of these:

Warning: Failure at t=2.099825e+07.  Unable to meet integration tolerances without reducing the step size below the smallest value allowed (5.960464e-08) at time t.
> In ode45 (line 308)
  In ODE45Integrator/integrate (line 23)
  In ForceModelPropagator/propagate (line 49)
  In LaunchVehicleSimulationDriver/integrateOneEvent (line 143)
  In LaunchVehicleSimulationDriver/processIntegratorTerminationCauses (line 181)
  In LaunchVehicleSimulationDriver/integrateOneEvent (line 154)
  In LaunchVehicleEvent/executeEvent (line 157)
  In LaunchVehicleScript/executeScript (line 272)
  In ConstraintSet/evalConstraints (line 93)
  In FminconOptimizer>@(x)lvdOpt.constraints.evalConstraints(x,true,evtToStartScriptExecAt,true,[]) (line 27)
  In optimfcnchk/checkfun (line 240)
  In barrier
  In fmincon (line 800)
  In lvd_executeOptimProblem (line 26)
  In FminconOptimizer/optimize (line 66)
  In LvdOptimization/optimize (line 50)
  In ma_LvdMainGUI>optimizeMissionMenu_Callback (line 564)
  In gui_mainfcn (line 95)
  In ma_LvdMainGUI (line 42)
  In matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('optimizeMissionMenu_Callback',hObject,eventdata,guidata(hObject))
  In waitforallfiguresclosed (line 9)

• Sizing problems at the "Edit Objective Function" window too:

 

• LVD tutorial needs to be updated to match the current version. I could follow it, but I can see people getting confused because of some descriptions not matching the latest version. Maybe it'd be better to keep them at the project's wiki on github, so that anyone can help keep it updated

Suggestions:

• Add a way to duplicate events on LVD. This would make it so much easier to create things like the pitch profile events
• Better way to model electric engines consumption/generation. It's possible to use them now by manually setting it's consumption, but doing this prevents us from optimizing thrust so that the ship doesn't run out of power

 

 

[Arrowstar]

@vitorboschi:

Thanks for the report!  Looks like you found a couple things which were Linux specific.  I have corrected them:

• Undefined "LaunchVehiclePowerStorageEnum" should now be resolved.
• The constraint dialog list box has been widened to 300 px, which should be wide enough for most or all constraint types.
• I've resolved the issue with the Objective Function dialog box looking funny.

I'll take a look at updating the tutorial one of these days, thought it may be a bit before I get to it.

I can look into a way to duplicate events.  It had never occurred to me that anyone would want to do that.

Engine-related EPS components will be coming in the future.  I will be adding alternators as well as engines that require EC to run.  These are on the radar, though it may be a bit before I get to them.

Anyway, I've updated the v1.6.6 release download packages.  Can you redownload the Linux build and see if your issues have been resolved?  Sorry about all the funny display errors.  Linux doesn't behave the same way Windows does and I have to configure UIs a certain way to mitigate this.  I don't always get it right evidently.

[vitorboschi]

Thanks @Arrowstar. I can confirm those were fixed, so the only issue that remains is the warnings I keep getting at the console.

Warning: Failure at t=2.100148e+07.  Unable to meet integration tolerances without reducing the step size below the smallest value allowed (5.960464e-08) at time t.
> In ode45 (line 308)
  In ODE45Integrator/integrate (line 23)
  In ForceModelPropagator/propagate (line 49)
  In LaunchVehicleSimulationDriver/integrateOneEvent (line 143)
  In LaunchVehicleEvent/executeEvent (line 157)
  In LaunchVehicleScript/executeScript (line 272)
  In ma_LvdMainGUI>propagateScript (line 171)
  In ma_LvdMainGUI>openMissionPlanMenu_Callback (line 915)
  In ma_LvdMainGUI>openMissionPlanToolbar_ClickedCallback (line 1047)
  In gui_mainfcn (line 95)
  In ma_LvdMainGUI (line 42)
  In matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('openMissionPlanToolbar_ClickedCallback',hObject,eventdata,guidata(hObject))
  In waitforallfiguresclosed (line 9)

 

Any idea why they happen?

I'm also trying to optimize my mission but I can't get the optimizer to achieve a Dres encounter, even though the original departure orbit from the porkchop plot was achieved. It just stops without doing any iteration. Any tips to solve that?

Hyperbolic Departure Orbit from Kerbin
---------------------------------------------
Semi-major Axis =               -822.6289 km
Eccentricity =                  1.850706432
Inclination =                   8.0532 deg
Right Ascension of AN =         246.2978 deg
Argument of Periapse =          358.3683 deg
---------------------
Out. Hyp. Vel. Vect Rt. Asc. =  7.6241 deg
Out. Hyp. Vel. Vect Declin. =   6.8915 deg
Out. Hyp. Vel. Magnitude =      2.071971425 km/s


Transfer Orbit about Sun
---------------------------------------------
Semi-major Axis =             26759201.8422 km
Eccentricity =                0.491899604
Inclination =                 1.2563 deg
Right Ascension of AN =       281.7300 deg
Argument of Periapse =        357.7428 deg
Kerbin Depart True Anomaly =  2.2572 deg
Dres Arrive True Anomaly =    179.9481 deg
---------------------
Departure Date = Year 1, Day 244 04:09:51.186
                      (21010191.1864 sec UT)
Arrival Date = Year 2, Day 25 12:27:57.394
                      (33654477.3939 sec UT)
Duration =          146 Days 08:18:06.207


Burn Information to Depart Kerbin
---------------------------------------------
Total Delta-V =              1.60070 km/s
Prograde Delta-V =           1508.35688 m/s
Orbit Normal Delta-V =       531.21731 m/s
Radial Delta-V =             70.11482 m/s
---------------------
Burn True Anomaly =          246.29780 deg
Burn Time Past Peri. =       1339.67426 sec
Burn Time Before Peri. =     618.45417 sec
Initial Orbit Period =       1958.12844 sec

 

[Arrowstar]

36 minutes ago, vitorboschi said:

Thanks @Arrowstar. I can confirm those were fixed, so the only issue that remains is the warnings I keep getting at the console.

Warning: Failure at t=2.100148e+07.  Unable to meet integration tolerances without reducing the step size below the smallest value allowed (5.960464e-08) at time t.
> In ode45 (line 308)
  In ODE45Integrator/integrate (line 23)
  In ForceModelPropagator/propagate (line 49)
  In LaunchVehicleSimulationDriver/integrateOneEvent (line 143)
  In LaunchVehicleEvent/executeEvent (line 157)
  In LaunchVehicleScript/executeScript (line 272)
  In ma_LvdMainGUI>propagateScript (line 171)
  In ma_LvdMainGUI>openMissionPlanMenu_Callback (line 915)
  In ma_LvdMainGUI>openMissionPlanToolbar_ClickedCallback (line 1047)
  In gui_mainfcn (line 95)
  In ma_LvdMainGUI (line 42)
  In matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('openMissionPlanToolbar_ClickedCallback',hObject,eventdata,guidata(hObject))
  In waitforallfiguresclosed (line 9)

 

Any idea why they happen?

I'm also trying to optimize my mission but I can't get the optimizer to achieve a Dres encounter, even though the original departure orbit from the porkchop plot was achieved. It just stops without doing any iteration. Any tips to solve that?

Hyperbolic Departure Orbit from Kerbin
---------------------------------------------
Semi-major Axis =               -822.6289 km
Eccentricity =                  1.850706432
Inclination =                   8.0532 deg
Right Ascension of AN =         246.2978 deg
Argument of Periapse =          358.3683 deg
---------------------
Out. Hyp. Vel. Vect Rt. Asc. =  7.6241 deg
Out. Hyp. Vel. Vect Declin. =   6.8915 deg
Out. Hyp. Vel. Magnitude =      2.071971425 km/s


Transfer Orbit about Sun
---------------------------------------------
Semi-major Axis =             26759201.8422 km
Eccentricity =                0.491899604
Inclination =                 1.2563 deg
Right Ascension of AN =       281.7300 deg
Argument of Periapse =        357.7428 deg
Kerbin Depart True Anomaly =  2.2572 deg
Dres Arrive True Anomaly =    179.9481 deg
---------------------
Departure Date = Year 1, Day 244 04:09:51.186
                      (21010191.1864 sec UT)
Arrival Date = Year 2, Day 25 12:27:57.394
                      (33654477.3939 sec UT)
Duration =          146 Days 08:18:06.207


Burn Information to Depart Kerbin
---------------------------------------------
Total Delta-V =              1.60070 km/s
Prograde Delta-V =           1508.35688 m/s
Orbit Normal Delta-V =       531.21731 m/s
Radial Delta-V =             70.11482 m/s
---------------------
Burn True Anomaly =          246.29780 deg
Burn Time Past Peri. =       1339.67426 sec
Burn Time Before Peri. =     618.45417 sec
Initial Orbit Period =       1958.12844 sec

 

• The warning you're seeing suggests that the ODE problem may be becoming stiff at the time indicated.  This is not a bug in KSPTOT but instead an issue with the way the mission is formulated.  It could be that you're running into funny business with drag (in which case, try the ODE23s solver).  You can also try to increase the ODE45 tolerances up to 1E-6 or so, for both relative and absolute tolerances.  Do this for the problem event by opening the event and editing the integrator options.  Let me know if you still have issues and provide a MAT file so I can take a look.
• Is your MAT file for LVD or Mission Architect?  I'll try to take a look in the next day or two.

[vitorboschi]

11 minutes ago, Arrowstar said:

• The warning you're seeing suggests that the ODE problem may be becoming stiff at the time indicated.  This is not a bug in KSPTOT but instead an issue with the way the mission is formulated.  It could be that you're running into funny business with drag (in which case, try the ODE23s solver).  You can also try to increase the ODE45 tolerances up to 1E-6 or so, for both relative and absolute tolerances.  Do this for the problem event by opening the event and editing the integrator options.  Let me know if you still have issues and provide a MAT file so I can take a look.
• Is your MAT file for LVD or Mission Architect?  I'll try to take a look in the next day or two.

I'll try those settings, thanks!

The mat is for LVD and it's linked in my previous post

[CanisLupus518]

On 8/18/2020 at 10:09 PM, Arrowstar said:

I believe it's ports 8282 through 8295.  Let me know if you have any trouble.

 

I got it to work, looks like my real problem was that I didn't notice the whitelist file in the mod, so I have it all working, thanks.

This is a great tool, I am starting to see the power in it, but I'm struggling to bridge the gap between planning a mission (with MA or LVD) and actually executing it. I tried loading up a sample mission in MA (the EveJoolEeloo mission) as I thought it would help me just learn how to execute a planned mission, but I'm not sure how it is possible to launch into the planned initial state with the precision required to keep the rest of the mission on track. I launch into an orbit that seems reasonably similar, but reoptimizing on the new initial state fails. What am I missing? What should be the process\workflow from event to event while actually flying a mission?

[vitorboschi]

15 minutes ago, CanisLupus518 said:

 

I got it to work, looks like my real problem was that I didn't notice the whitelist file in the mod, so I have it all working, thanks.

This is a great tool, I am starting to see the power in it, but I'm struggling to bridge the gap between planning a mission (with MA or LVD) and actually executing it. I tried loading up a sample mission in MA (the EveJoolEeloo mission) as I thought it would help me just learn how to execute a planned mission, but I'm not sure how it is possible to launch into the planned initial state with the precision required to keep the rest of the mission on track. I launch into an orbit that seems reasonably similar, but reoptimizing on the new initial state fails. What am I missing? What should be the process\workflow from event to event while actually flying a mission?

Launching exactly into the planned initial orbit is almost impossible, specially when there's an atmosphere to go through. Tools like kOS and Mechjeb are of great help to achieve more accuracy, but you'll always end up having to reoptimize and/or add some correction burns.

It's hard to know why the optimizer is failing in your case, but you must make sure that you optimize a small mission segment at a time. If you try to optimize a burn at Kerbin and set it to minimize your distance to Eeloo after passing through Eve and Jool, it'll fail for sure. Instead, after getting into Kerbin orbit, you can either plan a new burn to put you in the correct orbit, or reoptimize the first burn to achieve the desired arrival orbit at Eve.

If that fails (perhaps you deviated too much from the expected orbit), step back a little: first optimize the burn to reduce distance to Eve (without any constraint), and after achieving that, add constraints to achieve the desired inbound orbit and optimize again.

 

 

[Arrowstar]

Hi KSPTOT community!

The most common complaint I get with KSPTOT is generally that it's easy to put together a mission using the porkchop plot or a gravity assist tour in Multi-Flyby Maneuver Sequencer (MFMS) but it is then very challenging to translate those missions into Mission Architect (MA) or Launch Vehicle Designer (LVD).  I'm happy to share today that I believe I have implemented a great solution in LVD that makes this process much easier.

The big problem with trying to do a gravity assist tour in chronological order is that getting those flyby orbits right is a real pain for optimizers because the gradient of constraints near celestial bodies get to be extremely steep.  (Basically,  small changes far away make large changes near the body.)  A good first step to solving this problem was introduced a few releases ago with the Set Kinematic State action, where you can define the time and state of the vehicle in the middle of the mission.  However, even using Universal elements and defining the initial state well before the periapsis of the flyby orbit still generally put you pretty close to the celestial body in question and only improved the situation somewhat.  Ideally, you'd find a way to define the flyby orbit, then propagate that orbit backwards in time towards a more neutral patch point with an orbit that was propagated forwards in time from the previous celestial body that is being departed from.  As long as this patch point stayed somewhat in the middle of empty space, then the gradients are benign and the optimizer should have no problem.

This is precisely what I've done.  It is now possible to propagate an event backwards in time using a new menu item in the Edit Event dialog box.

Note that when you propagate backwards, termination condition direction (increasing or decreasing) is still relative to the forward flow of time.  So if you set your termination condition to Altitude of 100 km and increasing, even going backwards in time you'll still terminate the event when the forward flow of time would yield an altitude with a positive time derivative.  I felt this would be more intuitive this way.

So how does this play out in practice?  Pretty well!  Here's my mission I designed from Kerbin to Jool to Eeloo in MFMS.

And here's how it looks in LVD.

You'll notice that the Jool encounter looks almost identical.  The Eeloo encounter takes place a bit farther down the arc but is generally in the right place.  I would call this pretty much a success!

And guys?  Here's the crazy part: setting the mission up this way made it extremely easy to get the optimizer to converge on a valid solution.  This is basically unprecedented in KSPTOT history and what's more, it should be possible to add as many flybys or gravity assists or what have you without adding too much additional complexity to the optimizer.

Let's talk about the process here in the mission script.  First, you'll notice that most events have a plus or minus sign after their name.  I use this to denote forward or backwards propagation.  Let's use the Jool flyby as an example.  First, you'll notice the Coast to Jool + event.  This is the red arc from Kerbin orbit extending out towards Jool.  Notice that the next event, 3, is the flyby periapsis state.  Here I use a Set Kinematic State action to optimize the flyby parameters.

Event 4, Coast to Jool -, is the black segment leading up to the orbit of Jool.  This actually starts at the Jool periapsis point and propagates backwards in time, hopefully to meet up with the end of Event 2.  Finally, Event 5 simply uses another Set Kinematic State to inherit from Event 3 so that we can propagate forwards again to Eeloo.  Remember that the script executes from top to bottom, so if you need to jump in time or state from the end of the previous event, you need to use a Set Kinematic State action.

The next this we need to do is constrain our end states of Events 2 and 4 to meet up in position, velocity, and time.  We do this using 7 constraints: 3 position continuity constraints, 3 velocity continuity constraints, and 1 time continuity constraint.

Set the Applicable Event to Event 4 (always the event with the higher number in the event list) and the Constraint Event to Event 2.  For example:

Then optimize!  You'll want to make sure that you're letting the location and steering of the departure burn as well as all elements of the flyby orbit (except true anomaly or time past periapsis depending on your element set).  Also, it can be useful to put an Impulsive Delta-v action at the end of the forward propagated segments (here, Event 2), and optimize those burn elements, in order to provide the solver with a few more degrees of freedom in hitting the target velocity.  If you've set up everything correctly, FMINCON should have no problem achieving the target time, position, and velocity continuity.

----

This new functionality is ready to be previewed in the KSPTOT v1.6.7 pre-release 1 build.  There are also a few bug fixes I found.  Here's the full change log:

• LVD: Implementation of backwards propagated events.
• LVD: Bug fix to issue in Set Kinematic State action.
• LVD: Bug fix for rare issue where trajectory marker in display could get off of the trajectory lines.
• LVD: Position and velocity continuity constraints should be faster to compute now.

I've also included my example LVD file I showed above in the download for everyone to take a look at.

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

Edited August 22, 2020 by Arrowstar

[Drew Kerman]

ooohhh maannn I'm so glad I haven't actually had time to really do any serious work on the Kerbin->Eve->Jool->Plock flyby that MFMS found me back in 2018 for late 2021 launch. Good to know that when I do have time, less of it will be spent on it! Unfortunately for me that time is still at least a month or two away while I deal with still just getting into orbit reliably...

[Arrowstar]

Hi everyone,

Last night I was thinking about what would be required to finish up the Launch Vehicle Designer (LVD) electrical power system by including engine alternators and requiring EC to run certain engines.  Turns out I really should have just included this in the previous release because it was pretty straight forward, far more straight forward than I was anticipating.

To use this feature in the new pre-release (see below), add or edit an engine:

You'll see the checkboxes there for adding an alternator to the engine as well as for requiring electric charge for the engine to run.  You specify the charge and discharge rates, respectively, relative to 100% throttle, and the actual charge and discharge rates scale proportional to throttle.  It's pretty easy to use overall.

Some caveats:

• At least one power storage storage device is required to use electric engines.  If the vehicle doesn't have a battery , your electric engine will not run.
• You can get into some very problematic numerical territory if the following occurs all at once:
  • You have an electric engine running on the vehicle;
  • One or more of your batteries hits 0.0 state of charge; and
  • You have a power source device on your vehicle, such as an alternator, solar panel, or RTG.

In the case of the latter, what will happen is the engine will quickly alternate between being on and off.  (You see this is KSP too, btw, when your ion engine flickers rapidly when EC hits zero.)  The integrator will not like this and your simulation run time will essentially go to infinity, only stopped by the max run time limit in the code.

To avoid this problem, make sure all of your batteries have some charge in them at all times when using an engine that requires electric charge.  If you do run into this, jump over to the ODE5 integrator on the problem event(s).  It's slower than the other integrators (though you can set the time step to be larger to compensate for this at the expense of accuracy) but will not have the same slowness issue as the other adaptive step size integrators.  I'm thinking about ways around this right now, but honestly, discontinuous ODEs (ordinary differential equations) are a thorny area without a ton of practical application of theory in the real world, so I'm not sure what I'll be able to do, if anything.

Anyway, here's the KSPTOT v1.6.7 pre-release 2.  The change log is basically what I wrote above plus some minor bug fixes:

• LVD: Implementation of alternators and electric engines.
• LVD: Fix for broken plot background color option.
• LVD: GA now respects event plotting setting when plotting data.

I would appreciate it if someone would give the new electric engine stuff a try and provide some feedback if there's anything to provide back.  Thanks!

 

Edited August 23, 2020 by Arrowstar

[DBowman]

 

@Arrowstar it looks awesome!

Am I reading your 1.6.7 note above correctly? It sounds like you have added the backward propagation which will make trajectories coming out of MFMS "more digestible" by MA and LDV, and that they way it's done also makes it easier for MFMS to find the flybys in the first place? If that is so then it's likely that using backward propagating segments could find flybys that were missed before?

I've been early waiting till I get a chance to play with LVD to optimizing an ascent with constraints on G and aero forces, now I can add flybys to my list... 

[Arrowstar]

6 hours ago, DBowman said:

 It sounds like you have added the backward propagation which will make trajectories coming out of MFMS "more digestible" by MA and LDV, and that they way it's done also makes it easier for MFMS to find the flybys in the first place? If that is so then it's likely that using backward propagating segments could find flybys that were missed before?

It's only the former and only for LVD: the technique I've put into LVD should make it easier to use data out of MFMS.  There have been no changes to MFMS's output or anything of that sort.

Let me know if you have any other questions.

[Drew Kerman]

On 8/4/2020 at 9:45 PM, Arrowstar said:

What would be useful to see is thrust vs atmospheric density.  If there's an issue with how thrust is computed as a function of density, that'll do it.  I think I'm just doing a linear interpolation of thrust on the two densities that are requested (1 atm and 0 atm), because that's what the game shows, but if it needs to be more complicated than that in order to match KSP under the hood, it can certainly be made to work that way.

Fixed the issue with my atmo logging code. Here is thrust over density from a solid rocket motor that is using a thrust curve, for a more complex example:

the kOS code doesn't report good data when the rocket is just getting moving, as exemplified below in just density over altitude:

I'm missing VOID data because it's not working well with KSP 1.9.1 yet

I am confident in the values the kOS code is reporting because it does properly calculate the Mach number. The rocket went supersonic during L+15s (MET in upper left, mach # in FAR window to the left of resources panel) and when I use the kOS atmo data to calculate its Mach number I see L+15 @ mach 0.975209378981002 and L+16 @ mach 1.02457377154838

I can do a more basic test with a LF/O engine, just launch it straight up at full thrust. Only have the data above right now as I'm working on a flight analysis to publish tomorrow so won't be able to do the simpler test until later this week, maybe weekend. Let me know what else you'd like me to do

Edited August 24, 2020 by Drew Kerman

[KC_073]

First off, continued thanks for developing KSPTOT - it is a huge help with KSP and even when I'm taking breaks from KSP is it fun to watch the cool improvements in TOT itself.

Quick bug report - if I enable optimization for RAAN in the initial states in MA, the optimizer hangs on the "Please wait while the optimizer initializes..." popup and I get an error ding from windows.  Clicking X on the popup lets me return to the MA windows.

Another which might be a misunderstanding on my part - putting  a number into Arg.Peri. in the initial states  "edit state" pane and then saving will add it to the true anom. field and reset the Arg.Peri. to 0.  Not 100% an expert on orbital mechanics so this could easily be me not knowing what I'm doing.

Finally, a request - for parallel workers, let us set the number to start. My issue is that I'm running on a 3900x, and starting up 24 parallel workers takes a good bit of time and memory.  I imagine that's well down on the diminishing returns curve, so starting 8 or so might be just as good and not take nearly as long?

Again, thanks for all the cool work here, appreciate it.

[Arrowstar]

Thanks, @Drew Kerman and @KC_073.  I'll respond to your comments after I've had a bit of time to think on them.

I do need a bit of help with some testing an experimental LVD performance improvement feature if people are up for it.  Here's what I need done:

• Open KSPTOT v1.6.6, start LVD, and load the "lvdExample_TwoStageToOrbit.mat" file.
• Tap control-p a few times (4-5 at least) to run the script and record the script run time that is displayed in the output window.
• Now download and run KSPTOT v1.6.7 pre-release 3 from the link.
• Start LVD and load the "lvdExample_TwoStageToOrbit.mat" file again.
• Tap control-p a few times to run the script and record the script run time that is displayed in the output window.
• Provide me here with both sets of script run times.

I'm experimenting with a way to mitigate the cost of computing atmospheric temperature, which is the single most performance intensive calculation in LVD.  Basically what I've done is vectorize the function that computes temperature and then I run it at a bunch of times, latitudes, longitudes, and altitudes and cache the results.  I then interpolate between them after that and avoid more calls to the expensive temperature function.  Note that this means that the first time you run a case or if you move the initial state time around, you're going to see a pause while the cache rebuilds itself.  This is normal.

Thanks everyone!

[Drew Kerman]

13 minutes ago, Arrowstar said:

I do need a bit of help with some testing an experimental LVD performance improvement feature if people are up for it.

You betcha. 1.6.6 run:

(16:31:17) Executed mission script in 3.234 seconds.                                         
(16:31:31) Executed mission script in 1.599 seconds.                                         
(16:31:33) Executed mission script in 1.572 seconds.                                         
(16:31:36) Executed mission script in 1.426 seconds.                                         
(16:31:39) Executed mission script in 1.525 seconds.    

1.6.7 PR3 run:

(16:38:00) Executed mission script in 7.593 seconds.                                         
(16:38:08) Executed mission script in 2.018 seconds.                                         
(16:38:11) Executed mission script in 1.729 seconds.                                         
(16:38:14) Executed mission script in 1.763 seconds.                                         
(16:38:17) Executed mission script in 1.916 seconds. 

[Arrowstar]

6 minutes ago, Drew Kerman said:

You betcha. 1.6.6 run:

(16:31:17) Executed mission script in 3.234 seconds.                                         
(16:31:31) Executed mission script in 1.599 seconds.                                         
(16:31:33) Executed mission script in 1.572 seconds.                                         
(16:31:36) Executed mission script in 1.426 seconds.                                         
(16:31:39) Executed mission script in 1.525 seconds.    

1.6.7 PR3 run:

(16:38:00) Executed mission script in 7.593 seconds.                                         
(16:38:08) Executed mission script in 2.018 seconds.                                         
(16:38:11) Executed mission script in 1.729 seconds.                                         
(16:38:14) Executed mission script in 1.763 seconds.                                         
(16:38:17) Executed mission script in 1.916 seconds. 

Perfect.  So a decrease of about 0.2 seconds, or ~12%.  I'll take it.

Thanks!

Wait, I misread.  It got worse?

Edited August 24, 2020 by Arrowstar

[vitorboschi]

3 hours ago, Arrowstar said:

Thanks, @Drew Kerman and @KC_073.  I'll respond to your comments after I've had a bit of time to think on them.

I do need a bit of help with some testing an experimental LVD performance improvement feature if people are up for it.  Here's what I need done:

• Open KSPTOT v1.6.6, start LVD, and load the "lvdExample_TwoStageToOrbit.mat" file.
• Tap control-p a few times (4-5 at least) to run the script and record the script run time that is displayed in the output window.
• Now download and run KSPTOT v1.6.7 pre-release 3 from the link.
• Start LVD and load the "lvdExample_TwoStageToOrbit.mat" file again.
• Tap control-p a few times to run the script and record the script run time that is displayed in the output window.
• Provide me here with both sets of script run times.

Here you go:

1.6.6

(20:37:45) Executed mission script in 2.404 seconds.                                         
(20:38:04) Executed mission script in 1.314 seconds.                                         
(20:38:08) Executed mission script in 1.249 seconds.                                         
(20:38:11) Executed mission script in 1.214 seconds.                                         
(20:38:15) Executed mission script in 1.249 seconds.                                         
(20:38:21) Executed mission script in 1.204 seconds.                                         
(20:38:28) Executed mission script in 1.178 seconds.                                         

 

and 1.6.7 PR 3

(20:40:57) Executed mission script in 4.749 seconds.                                         
(20:41:06) Executed mission script in 1.236 seconds.                                         
(20:41:13) Executed mission script in 1.169 seconds.                                         
(20:41:15) Executed mission script in 1.191 seconds.                                         
(20:41:20) Executed mission script in 1.218 seconds.                                         
(20:41:33) Executed mission script in 1.123 seconds.                                         
(20:41:40) Executed mission script in 1.105 seconds.                                         

 

Edited August 24, 2020 by vitorboschi

[DBowman]

18 hours ago, Arrowstar said:

It's only the former and only for LVD: the technique I've put into LVD should make it easier to use data out of MFMS.  There have been no changes to MFMS's output or anything of that sort.

Let me know if you have any other questions.

thanks! I read the Solar System Edge tute, genetic algos, cool. I better play around first...

Edited August 25, 2020 by DBowman