Arrowstar

Members
  • Content Count

    1,886
  • Joined

  • Last visited

Community Reputation

719 Excellent

1 Follower

About Arrowstar

  • Rank
    Astrodynamicist

Contact Methods

  • Website URL Array

Recent Profile Visitors

2,825 profile views
  1. It's on the to-do list! No, it should just work. Can you post the contents of your ksptot.log file here? How much RAM does your PC have? What about number of cores on the CPU?
  2. Hi everyone, Tonight I've compiled KSPTOT v1.6.5 pre-release 1. Here's the change log: MA/LVD: Added option to auto-propagate (or not) the mission script when changes are made to it. Useful when your script takes forever to propagate and you have lots of changes to make. Improved robustness of "coast to function value" in MA. MA/LVD: Editing mission notes prompts user to save file (asterisk in window title). LVD: Overhaul of optimization: Added new optimizer: NOMAD Added new option for computing gradients of objective function (a custom finite difference scheme) Added a new UI for selecting optimization algorithm. Added many new options for FMINCON and Pattern Search algorithms (including two new UIs for them). Removed all the old optimization options (they are incorporated to the new options now). Caveats: The custom finite difference scheme still needs a UI for its options. NOMAD is not yet available on Linux. I can't get the code to compile properly yet and both the developer and I are perplexed to say the least. Still working on this. Please let me know if you find any bugs or issues with this build. A lot of the optimization changes are experimental at this point so the more testing the better. Thanks!
  3. Hi everyone, I wanted to take a moment to talk about what's coming in v1.6.5. I've been doing a bunch of work on improving the optimization experience in Launch Vehicle Designer (LVD). Right now there are two different algorithms (FMINCON and Pattern Search) but PS was sort of hacked in there and almost none of the available options for either are exposed. In general, optimization in LVD can feel a bit rough and unproductive to me. I want to change this with v1.6.5. In addition to the items I've already posted about above, here's what I see coming for this release: New optimizer interface Right now the current optimizer interface is menu driven, exposes only a very small number of options for each algorithm, and is not the easiest to make sense of. That's all going to change. A new "Optimizer Algorithm Selection" user interface is coming that will allow users to cleanly select the algorithm they want. In addition, each optimizer will have its own options user interface that will allow users to set many more options than a few that are currently available now. New optimizer(s) As I mentioned before, there are two optimizer available in LVD right now. FMINCON works pretty well for what it does, and Pattern Search has its strengths, but it tends to work poorly on problems where feasibility is hard to find. Enter NOMAD, or "Non-smooth Optimization by Mesh Adaptive Direct search." NOMAD works astoundingly well at taking a trajectory with many constraint violations and reducing those violations to a place where something like FMINCON can pick it up and solve it. (It also does pretty well at finding feasible solutions in general if you give it enough time.) Right now NOMAD's biggest draw back is that it can't be run in parallel, but I've contacted the developers to see what I can do. (The software itself supports parallelization but something funny happens when you try to use it in MATLAB.) I may also include "IPOPT", where is pretty similar to FMINCON's "interior point" algorithm, but seems to work better in some cases. Both NOMAD and IPOPT are part of the OPTI Toolbox, and if I do end up including them, will (sadly) only be available on the Windows build because OPTI is only built for Windows. Constraint Jacobian visualization The constraint Jacobian is a matrix where each row represents a constraint and each column is a particular variable. Each element of the matrix is the sensitivity of that constraint to that variable. In general, you want each element to be roughly about 1.0, and you achieve this by scaling your constraints using the scale input in the Edit Constraint dialog box. A new feature to LVD is the ability to compute and visualize this matrix in a heat map so that you set those scale factors accordingly. That's all I've got for now. The dialog boxes for FMINCON and Pattern Search are done, the selection dialog box is basically done, and I'm actually running NOMAD right now to solve a full Kerbin - Mun - Kerbin mission in LVD, and it's doing pretty well. Just need to get an options dialog box together for that, check on the possibility of parallelization, and decide on IPOPT (which might just come in a later release if I decide I want to include it after all). Thoughts?
  4. Alright, I've got something whipped up that will be in the next pre-release. Note that there's a non-trivial performance cost to finding the first root of the coast function, but there's not much that can be done to avoid that. Note that this isn't going to be a perfect solution. Here the two solutions (alt = 70 km) are pretty close together. Before the root finder was just falling in towards one of them and finding that one. Now I'm using a slightly more robust algorithm that should find the first one, but there are definitely cases where it may not find any of them if they are too close together. For example of the time in the atmosphere was only a few seconds, this algorithm will probably just skip both of them entirely. This is where you as the analyst might need to come up with a better way to formulate the problem. The tool can do a lot but it can't do everything.
  5. Thanks! I haven't had a chance to fully dive into what you wrote but hopefully I'll have a chance this weekend. I'll see what I can do. You can already do this in Mission Architect (MA), actually! You define your trajectory and then place a number of "other spacecraft" in orbit somewhere. There is a communications network analysis tool in MA that will then figure out how to join your spacecraft with any other "node" (including KSC) via the network of satellites created. Let me know if you need help figuring it out and I'll see what I can do. You're welcome!
  6. I could add a setting into MA and LVD that turns on or off the auto-propagation of the script, with a button on the main MA/LVD UIs that propagates the script on command and indicates in some way if the current script needs to be run. Would this be helpful?
  7. @Maravone: This is probably it. The first run can take a few minutes because the whole program needs to unpack onto your hard drive. Sadly I have no control over this, nor can I insert a progress bar or something to show that the program is working. Restart your computer and then give the program a go again, and give it a few minutes to work. It should load. If not, please follow the steps within this post and then try running it again (may take a few minutes to load after doing this):
  8. Hello everyone! This evening I'm pleased to announce the release of the KSP Trajectory Optimization Tool v1.6.4. This release is primarily a bug-fix and feature/performance enhancement release that has been in the work for a few months now. Both Mission Architect and Launch Vehicle Designer has seen some work on them. The single biggest change is an update to the internal atmospheric temperature model in order to include a number of mathematical terms which were previously left out and have now been included. The method used to interpolate on atmospheric data has also been updated to a spline fit. This should result in far more accurate atmospheric density calculations, and thus more accurate missions in both MA and LVD. Please note that the KSPTOTConnect plugin has been updated to accommodate the new atmospheric temperature models. You should update your existing plugin with the one in the new KSPTOT v1.6.4 download package. Here's the complete change log: LVD: Added tooltip to edit constraints dialog box listbox. LVD: Added drag coefficient GA task LVD: Performance enhancements to cross product and the deep copy stage state functions LVD: Fix bug that was causing improper handling of non-sequential events in the sim driver LVD: Added radius beyond SoI radius validator. LVD: Option to set event specific initial step size for integrator, and then optimize that step size via context menu. LVD: When holddowns are enabled, integrate in the body-fixed frame with zeros for the pos/vel rates. (Performance enhancement) LVD: Added event termination condition direction option. Flyby Porckchop Plot: Resolved "not enough inputs" bug MA/LVD: All NEW MA and LVD cases will use spline interpolation for their atmospheric table interpolations. MA: Resolved an issue with atmo data being overwritten in MA when any undo/redo state is created. LVD: T2W is now computed at true altitude and not sea-level. MA/LVD: Update to temperature model. All missing terms have been added now. MA: Updates to soi transition to eliminate a case where the soi max search UT was infinite when the go to tru DT was 0. Has been fixed to just assume that no time is passing. Resolved potential issue where atmo curves for bodies would not load correctly when loading a new bodies.ini file if the order of bodies in the old bodies.ini was different than in the new bodies.ini file. Clearing a persistent var in processINIBodyInfo does the trick. ...and other bug fixes and performance improvements. As usual, the download is available in the first post of this thread. If you have any questions or discover any bugs, please drop me a line in some fashion to let me know and I'll do my best to address it! In particular, it would be great if those using the Linux version could provide any feedback on how it's working out. There are some known graphical issues, but those aside, if you discover any bugs that appear to be Linux-related, please let me know. Thanks! Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire. In any event, I hope you all enjoy! Happy orbiting!
  9. Okay, I think I see what's going on. I think there is confusion between the Solar Day and the Sidereal Day shown in the KSP wiki for Kerbin. The sidereal day is the amount of time that Kerbin takes to rotate with respect to the fixed stars. The solar day is how long it takes the sun to show up in the same place in the sky. These are not the same: remember that Kerbin is orbiting, so the sun takes a bit longer each day to show up in the same place because the planet has to rotate just a bit more than 360 degrees to get the same in the same spot again. The sidereal time is the proper time to use for the surface velocity calculation because it is measured against the fixed reference frame. If you do: >> (2*pi/21549.425) * 600 ans = 0.174942541822241 You get the answer you see on the wiki, but that speed corresponds to the sidereal period and not the solar period. In the MM config you shared, you had the 21651 seconds time... I'm guessing this is a solar day period? (I would think it should be the sidereal day period, but I've never played with MM configs myself so I don't know.) In any event, the diference between the 21651 and the 21600 AND the 21600 and 21549 (shown on the wiki) is both ~51 seconds, so I'm wondering if that's where the confusion is coming from. In any event, I think KSPTOT is computing it correctly, as is kOS. Double check that you are using the correct values in both LVD and the MM config, and that you know which type of rotational period goes in each. In KSPTOT's bodies.ini file, those are sidereal rotation periods.
  10. Got it, I'll take a look. Are you aware of any other issues that need to be resolved before I could release v1.6.4? Otherwise I'm thinking it's about time to get it out the door properly.
  11. When you have two consecutive assists of the same planet, make sure to set the "max number of revolutions" on the leg from the first pass of the body to the second pass of the body to an integer greater than zero. (Highlight the first instance of the body in the waypoint list.) Usually 1 is fine, and don't go more than 2 or 3. The only other thing I did was set the launch window close to 283824000 and multiplied the default maximum flight time for each leg of the journey by 10. That was it!
  12. I think part of the issue is that you are going down very deep into the solar gravity well. I suspect this mission sequence (Kerbin -> Cerb. -> Tempest -> Rev.) isn't viable. I played around with a number of launch windows and this was the best I found: Hyperbolic Departure & Flyby Orbits --------------------------------------------- Hyperbolic Departure Orbit from Kerbin --------------------------------------------- Semi-major Axis = -1194.4900 km Eccentricity = 1.669741849 Inclination = 0.9026 deg Right Ascension of AN = 241.6813 deg Argument of Periapse = 359.9713 deg --------------------- Out. Hyp. Vel. Vect Rt. Asc. = 8.4468 deg Out. Hyp. Vel. Vect Declin. = 0.7231 deg Out. Hyp. Vel. Magnitude = 1.645167460 km/s --------------------------------------------- Inbound Hyperbolic Flyby Orbit to Cerberus --------------------------------------------- Semi-major Axis = -1283.7331 km Eccentricity = 2.173269321 Inclination = 179.7915 deg Right Ascension of AN = 176.8907 deg Argument of Periapse = 90.7452 deg Periapse Radius = 1506.1646 km --------------------------------------------- Outbound Hyperbolic Flyby Orbit from Cerberus --------------------------------------------- Semi-major Axis = -720.1869 km Eccentricity = 3.0914 Inclination = 179.7915 deg Right Ascension of AN = 176.8907 deg Argument of Periapse = 90.7452 deg Periapse Radius = 1506.1646 km --------------------- Out. Hyp. Vel. Vect Rt. Asc. = -22.7280 deg Out. Hyp. Vel. Vect Declin. = -0.0700 deg Out. Hyp. Vel. Magnitude = 4.678249801 km/s --------------------------------------------- Inbound Hyperbolic Flyby Orbit to Tempest --------------------------------------------- Semi-major Axis = -339.0596 km Eccentricity = 11.471947281 Inclination = 178.4609 deg Right Ascension of AN = 312.8840 deg Argument of Periapse = 261.5711 deg Periapse Radius = 3550.6145 km --------------------------------------------- Outbound Hyperbolic Flyby Orbit from Tempest --------------------------------------------- Semi-major Axis = -339.0372 km Eccentricity = 11.4726 Inclination = 178.4609 deg Right Ascension of AN = 312.8840 deg Argument of Periapse = 261.5711 deg Periapse Radius = 3550.6145 km --------------------- Out. Hyp. Vel. Vect Rt. Asc. = -43.6888 deg Out. Hyp. Vel. Vect Declin. = -0.0920 deg Out. Hyp. Vel. Magnitude = 10.776517402 km/s --------------------------------------------- Inbound Hyperbolic Orbit to Revenant --------------------------------------------- Inb. Hyp. Vel. Vect Rt. Asc. = -62.9966 deg Inb. Hyp. Vel. Vect Declin. = -0.2271 deg Inb. Hyp. Vel. Magnitude = 7.3009 km/s Sun-Centric Transfer Orbits --------------------------------------------- Phase 1 Transfer Orbit (Kerbin -> Cerberus) --------------------------------------------- Semi-major Axis = 4733408.7843 km Eccentricity = 0.385647947 Inclination = 0.2010 deg Right Ascension of AN = 106.6816 deg Argument of Periapse = 176.3870 deg Period = 3349787.4312 sec Departure True Anomaly = 183.6130 deg Arrival True Anomaly = 110.7691 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Phase 2 Transfer Orbit (Cerberus -> Tempest) --------------------------------------------- Semi-major Axis = 2919112.6712 km Eccentricity = 0.702894161 Inclination = 0.2030 deg Right Ascension of AN = 142.6789 deg Argument of Periapse = 84.6158 deg Period = 1622305.0394 sec Departure True Anomaly = 166.5432 deg Arrival True Anomaly = 107.4057 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Phase 3 Transfer Orbit (Tempest -> Revenant) --------------------------------------------- Semi-major Axis = 2079356.7442 km Eccentricity = 0.693896594 Inclination = 0.0534 deg Right Ascension of AN = 27.0685 deg Argument of Periapse = 180.0217 deg Period = 975325.8572 sec Departure True Anomaly = 127.6101 deg Arrival True Anomaly = 0.1129 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Kerbin Departure Date = Year 2, Day 39 22:11:05.562 (34899065.5620 sec UT) Cerberus Arrival Date = Year 2, Day 65 14:14:17.214 (37116857.2135 sec UT) Tempest Arrival Date = Year 2, Day 79 00:15:46.018 (38276146.0180 sec UT) Revenant Arrival Date = Year 2, Day 88 23:20:45.424 (39136845.4243 sec UT) --------------------------------------------- Total Mission Duration = 49 Days 01:09:39.862 DV Maneuver Information --------------------------------------------- Burn Information to Depart Kerbin --------------------------------------------- Total Delta-V = 1.2750 km/s Prograde Delta-V = 1273.9776 m/s Orbit Normal Delta-V = 51.7415 m/s Radial Delta-V = 1.0287 m/s --------------------- Burn True Anomaly = 241.6813 deg --------------------------------------------- Burn Information to Depart Cerberus --------------------------------------------- Total Delta-V = 0.7807 km/s Prograde Delta-V = 780.7330 m/s Orbit Normal Delta-V = -0.0000 m/s Radial Delta-V = -0.0002 m/s --------------------- Burn True Anomaly = 0.0000 deg --------------------------------------------- Burn Information to Depart Tempest --------------------------------------------- Total Delta-V = 0.0003 km/s Prograde Delta-V = 0.3270 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.0561 km/s Keep in mind that the solver in MFMS is nondeterministic, so you may have to run it a few times. I would try different sequences of waypoints. Maybe Kerbin -> Cerberus -> Cerberus -> Rev. Do a bit of exploration of the problem.
  13. Okay, so not stock KSP. Can you post your bodies.ini file that you're using? I'll load it in and see what I come up with. I'll also need some information about your waypoints (the names of bodies and the min and max flight times). Thanks!