Drew Kerman Posted December 16, 2017 Share Posted December 16, 2017 17 hours ago, Arrowstar said: I can take a look at the MAT file and SFS file if you'd like me to confirm. so you're asking for the MAT file from the first image, where I loaded the orbit from the SFS right? new bug: when plotting porkchops (mmmm... porkchops) that exceed the max Dv in the options the program asks to allow it to be increased. If you say yes it tells you the option has been updated but when I check afterwards it is still the same. When it asks you to modify the synodic period for better results and you say yes that one works Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 17, 2017 Author Share Posted December 17, 2017 10 hours ago, Drew Kerman said: so you're asking for the MAT file from the first image, where I loaded the orbit from the SFS right? Yes, and the associated SFS please. Whatever I need to reproduce that funny circular orbit in Kerbin's SoI. Though as I explained in my previous post, I believe the cause is the way the orbit is defined in the SFS file (relative to Sun but with a position vector that places the spacecraft within Kerbin's SoI). I'll check though. Quote new bug: when plotting porkchops (mmmm... porkchops) that exceed the max Dv in the options the program asks to allow it to be increased. If you say yes it tells you the option has been updated but when I check afterwards it is still the same. When it asks you to modify the synodic period for better results and you say yes that one works Good find, fixed for next build! Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 17, 2017 Share Posted December 17, 2017 (edited) 2 hours ago, Arrowstar said: Whatever I need to reproduce that funny circular orbit in Kerbin's SoI I think you're misunderstanding the post? That "funny circular orbit" is the orbit of the asteroid already around Kerbin (see the game screenshot). This isn't an asteroid that just came from sun orbit but one that's already been in orbit for some time. Edited December 17, 2017 by Drew Kerman Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 19, 2017 Share Posted December 19, 2017 You know what, let me just do some more testing over here. What I'm going to try next is I'm going to load the asteroid in flight and pull orbital data straight from the game. Doing this will also update the orbital elements in the save file: SFS Before flight scene load SMA = 15600879.928555444 ECC = 0.235650487308428 INC = 130.48647876651356 LPE = 97.572253966611527 LAN = 106.555831899488 MNA = 0.96636781499848312 EPH = 39824530.459937654 REF = 1 SFS After flight scene load SMA = 15600879.801565172 ECC = 0.23565053784577689 INC = 130.48648159392644 LPE = 97.572273881161507 LAN = 106.55583039375381 MNA = 2.5231528960659149 EPH = 40287624.98670084 REF = 1 KSPTOTConnect import SMA = 15600.8798015712 ECC = 0.235650537845278 INC = 130.486481593927 LPE = 97.57227388119 LAN = 106.555830393757 TA = 157.075802287994 EPH = 40287621.2467002 REF = N/A So from here on out I won't load the asteroid into the flight scene again and the SFS will remain at the values listed above - until the next SOI transition. I will let that happen from the Tracking Station rather than the flight scene and compare the results. Then I'll revert and allow the SOI transition to happen within the game and compare the results. Next SOI transit is Feb 20th according to this data so it will be a while but I will report back eventually. Arrowstar if you want to play ahead rather than wait you can just manually assign the SFS orbit data above to anything you throw up into orbit and see what happens Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 20, 2017 Author Share Posted December 20, 2017 10 hours ago, Drew Kerman said: Next SOI transit is Feb 20th according to this data so it will be a while but I will report back eventually. Arrowstar if you want to play ahead rather than wait you can just manually assign the SFS orbit data above to anything you throw up into orbit and see what happens I can do that. Remind me again what I'm looking for? I've gotten a bit lost with all the things we've looked at recently. Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 20, 2017 Share Posted December 20, 2017 (edited) 53 minutes ago, Arrowstar said: I can do that. Remind me again what I'm looking for? I've gotten a bit lost with all the things we've looked at recently. the exercise here is how accurate I can keep the propagation from KSPTOT in relation to the game. So, for the first attempt I made at predicting where and when this asteroid was going to cross into Mun's SOI it was accurate to milliseconds on the first encounter then off by a few seconds on the second encounter then off by weeks for the third encounter. I've plotted out 3 future encounters with the data I referenced above and now I need to see if they all remain accurate or start falling out of sync. The first attempt I made was pulling orbital data from the SFS file. This new attempt just above is from pulling data straight from the game through KSPTOTConnect. At no point moving forward in both instances did I load the asteroid into the flight scene, so the only time the SFS data should be updated is when it crosses an SOI Edited December 20, 2017 by Drew Kerman Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 22, 2017 Author Share Posted December 22, 2017 On 12/19/2017 at 7:28 PM, Drew Kerman said: the exercise here is how accurate I can keep the propagation from KSPTOT in relation to the game. So, for the first attempt I made at predicting where and when this asteroid was going to cross into Mun's SOI it was accurate to milliseconds on the first encounter then off by a few seconds on the second encounter then off by weeks for the third encounter. I've plotted out 3 future encounters with the data I referenced above and now I need to see if they all remain accurate or start falling out of sync. The first attempt I made was pulling orbital data from the SFS file. This new attempt just above is from pulling data straight from the game through KSPTOTConnect. At no point moving forward in both instances did I load the asteroid into the flight scene, so the only time the SFS data should be updated is when it crosses an SOI Okay got it thanks. I have a theory: if it's truly SoI transitions that seem to cause the issue, than it might be down to the fact that I actually target about 2 km into the SoI on every transition to make sure that when the code searches for the next SoI transition, it doesn't detect that the spacecraft is already outside the SoI it's supposed to be in. Not surprisingly that causes problems. I could see how this could compound over time like you're seeing, especially if more than a few SoI transitions are involved. As a test, take a look at this next KSPTOT prerelease. It's identical to the other in every way except that where SoI transitions are computed, I have greatly increased the fidelity of the SoI search routine with the addition of another algorithm that should get the accuracy down to about 10 meters or so. Warning, this will slow down the calculation time some, but it's worth a shot. Can you try this prerelease out and see if the issue is still the same or if it improves any? Thanks! Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 22, 2017 Share Posted December 22, 2017 16 hours ago, Arrowstar said: Okay got it thanks. I have a theory: if it's truly SoI transitions that seem to cause the issue, than it might be down to the fact that I actually target about 2 km into the SoI on every transition to make sure that when the code searches for the next SoI transition, it doesn't detect that the spacecraft is already outside the SoI it's supposed to be in. Not surprisingly that causes problems. I could see how this could compound over time like you're seeing, especially if more than a few SoI transitions are involved. Yea I've been beginning to suspect SOI transitions more and more myself lately. I did some testing and was getting some pretty weird results so I just kept things basic and tried the very first encounter with both PR6 and PR7 SFS test file PR7 import from active vessel and propagation to first SOI encounter, the UT time after the event is 17156837.0167387 (3/30 @ 13:47:17) - without leaving the game for the Tracking Station and warping ahead, the actual SOI entry time is 3/30 @ 13:47:11 PR6 import from active vessel and propagation to first SOI encounter, the UT time after the event is 17156837.0969646 (3/30 @ 13:47:17) - without leaving the game for the Tracking Station and warping ahead, the actual SOI entry time is 3/30 @ 13:47:11 what - that several seconds discrepancy is huge, and like I said the last time I did an asteroid study the first SOI intercept was accurate to within milliseconds. If you have v1.3.1 see if you can reproduce. It may just be from me still being on v1.2.2 Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 27, 2017 Share Posted December 27, 2017 (edited) I have completed my upgrade to KSP v1.3.1 and will re-run my tests sometime over the next few days. Stand by! Edited December 27, 2017 by Drew Kerman Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted January 11, 2018 Share Posted January 11, 2018 so, haven't had time yet to test out any propagation stuff but I did finally get around to writing up that post about my interplanetary travel preparations I promised @wile1411 back in October - it actually took until the end of Dec for me to wrap up all the calculations! You can check it out here on the KSA site. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted January 11, 2018 Author Share Posted January 11, 2018 14 hours ago, Drew Kerman said: so, haven't had time yet to test out any propagation stuff but I did finally get around to writing up that post about my interplanetary travel preparations I promised @wile1411 back in October - it actually took until the end of Dec for me to wrap up all the calculations! You can check it out here on the KSA site. Wow, phenomenal job! That's all quite impressive! Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted January 12, 2018 Share Posted January 12, 2018 6 hours ago, Arrowstar said: Wow, phenomenal job! That's all quite impressive! was curious to see what you'd think of it. Thanks, but it also really makes me appreciate the work you guys actually have to do for real spacecraft. Ooof! Quote Link to comment Share on other sites More sharing options...
HealingPotatoJuice Posted January 13, 2018 Share Posted January 13, 2018 I'm having a problem with planning a gravitational maneuver for Kerbin-Eve-Moho flight. Using "Solar system edge" tutorial as a reference, I managed to create a somewhat realistic plan. The problems started when I realised that my craft would not be able to do ejection burn at once and tried to assemble a flight plan with split burns. While fist two stages of building flyby trajectory (finding Eve and fitting inclination, RAAN and argument of periapsis), constraint violation cannot be lowered down to zero when performing optimization against SMa and eccentricity. I tried changing objective function, but it doesn't really help: only "Minimize distance..." gives somewhat better results. Still, the resulting trajectory doesn't bring me in vicinity of Moho. What I also tried: changing time of 1st ejection burn, tinkering with objective functions, replacing SMa with radius of periapsis, building coast to next ejection burn via "coast to apoapsis"+"coast to periapsis", and via "coast to periapsis" with Revs prior to coast = 1. I'm using stable version of KSP TOT 1.5.8. MFMS summary: https://pastebin.com/y0E7jYtw, plan with a single ejection burn https://drive.google.com/file/d/1F_05C_G0AXd7A_SOG3xyZh2NknrRBT_X/view?usp=sharing, plan with 2 ejection burnshttps://drive.google.com/file/d/1BalsGEEYSLUgIBmnk96tQQRE_3XOqw8g/view?usp=sharing What advice can you give on planning multiple-burn ejection trajectories? What has gone wrong in this case? Quote Link to comment Share on other sites More sharing options...
Snoman314 Posted January 15, 2018 Share Posted January 15, 2018 (edited) I've been getting this error over and over again recently, during optimisation in the Mission Architect: Here's the .mat file that causes it: https://drive.google.com/file/d/1_oncvYfTLmVHH77dgq2zPs-4m9Vak_Dl/view?usp=sharing I keep tweaking the optimisation parameters, but it keeps coming up during optimisation. Sometimes 55 iterations, sometimes 28, sometimes something else. Seems to happen every time though at this point. I'm using KSPTOT 1.5.8, on KSP 1.3.1 Edited January 15, 2018 by Snoman314 Quote Link to comment Share on other sites More sharing options...
Snoman314 Posted January 17, 2018 Share Posted January 17, 2018 (edited) On 1/15/2018 at 8:56 PM, Snoman314 said: I've been getting this error over and over again recently, during optimisation in the Mission Architect: Here's the .mat file that causes it: https://drive.google.com/file/d/1_oncvYfTLmVHH77dgq2zPs-4m9Vak_Dl/view?usp=sharing I keep tweaking the optimisation parameters, but it keeps coming up during optimisation. Sometimes 55 iterations, sometimes 28, sometimes something else. Seems to happen every time though at this point. I'm using KSPTOT 1.5.8, on KSP 1.3.1 This is now happening constantly, and I'm reminded that it's why I stopped playing KSP when 1.1 came out. Please help! Even the simplest circularisation mission optimisation crashes. I can't go back to the coarse controls of the vanilla node planning! It seems to happen around the time the optimiser goes way off track. For example when I'm trying to perfect an orbit around the Mun, and the optimiser kicks the endstate out to Kerbol orbit or something like that. This is even when I've got the central body ID condition set. Not always though. The only workaround I've found so far is to try again several in-game hours later, with a different set of starting conditions. Sometimes this is just an inconvenience, but sometimes it's not an option, as it would mean missing the only window for a maneuver. Usually the optimiser has made good progress, and if only I could use the results from one or two iterations back, I'd be happy. Instead everything is lost, and I keep getting the error every time I re-run it. Edited January 17, 2018 by Snoman314 Added more info about the bug. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted January 17, 2018 Author Share Posted January 17, 2018 (edited) 10 hours ago, Snoman314 said: This is now happening constantly, and I'm reminded that it's why I stopped playing KSP when 1.1 came out. Please help! Even the simplest circularisation mission optimisation crashes. I can't go back to the coarse controls of the vanilla node planning! It seems to happen around the time the optimiser goes way off track. For example when I'm trying to perfect an orbit around the Mun, and the optimiser kicks the endstate out to Kerbol orbit or something like that. This is even when I've got the central body ID condition set. Not always though. The only workaround I've found so far is to try again several in-game hours later, with a different set of starting conditions. Sometimes this is just an inconvenience, but sometimes it's not an option, as it would mean missing the only window for a maneuver. Usually the optimiser has made good progress, and if only I could use the results from one or two iterations back, I'd be happy. Instead everything is lost, and I keep getting the error every time I re-run it. Looking at it now, sorry for the wait. EDIT: Okay, in the mean time, use Script -> Execution Settings -> Optimizer Algorithm -> SQP That should help things along. There's something funny going on with the interior point solver. The issue you're seeing is because the optimizer algorithm itself is passing NaN as some control variables, which is very strange (and very wrong). I'm not sure why, could be something in my code that's causing it, or could not be. I'll need to investigate. Thanks for the report! Edited January 17, 2018 by Arrowstar Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted January 17, 2018 Share Posted January 17, 2018 4 hours ago, Arrowstar said: EDIT: Okay, in the mean time, use Script -> Execution Settings -> Optimizer Algorithm -> SQP I've been meaning to ask for a while what the differences are for the algorithms because I have no clue how the option should be used. Can they be broken up into general use cases? Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted January 17, 2018 Author Share Posted January 17, 2018 2 minutes ago, Drew Kerman said: I've been meaning to ask for a while what the differences are for the algorithms because I have no clue how the option should be used. Can they be broken up into general use cases? You can read more about the various algorithms here. (Scroll to the bottom to the "algirthms" section.) As for use cases, not really. They are all generalized optimizers, and by their numerical nature, some will work better than others in different problems, but it's very hard to predict what those will be. Interior point is the MATLAB recommended algorithm, and SQP is very good too. (I use a modified SQP solver at work for trajectory design.) Active Set is an older technique but I included it for completeness. It's worth a shot if everything else fails. An update on the bug above: I couldn't trace the problem to anywhere in my code, so I have set up the wrapper around the optimizer to call it quits with an error message if the optimizer ever returns NaNs for control variable values. The message will instruct the user to use a different optimizer algorithm. That seems to be the best I can do at the moment. I can't debug the MATLAB internals because they are all encrypted in the software. Quote Link to comment Share on other sites More sharing options...
Snoman314 Posted January 17, 2018 Share Posted January 17, 2018 Thanks for taking a look! Support ticket to MATLAB perhaps? I'm not seeing that Optimiser Algorithm option. Perhaps I have an old version? Or maybe I'm looking in the wrong place? As for the version, I did download the pre-release you linked on 22 December, but it was asking me to install a new version of the Matlab runtime, or something. I'm using the version off the first post. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted January 18, 2018 Author Share Posted January 18, 2018 Just now, Snoman314 said: Thanks for taking a look! Support ticket to MATLAB perhaps? I'm not seeing that Optimiser Algorithm option. Perhaps I have an old version? Or maybe I'm looking in the wrong place? As for the version, I did download the pre-release you linked on 22 December, but it was asking me to install a new version of the Matlab runtime, or something. I'm using the version off the first post. Yes, I updated to the new version of the MCR for this upcoming release (which the pre-releases are on). Can you grab the new MCR? Should be for MATLAB R2017b. The Optimizer Algorithm options are in the new pre-release only. Speaking of which, here is the latest KSPTOT pre-release (v1.5.9 pre-release 8), which includes: The error message discussed above when the optimizer hits a NaN for a control variable. Messages to Output when you change optimizer algorithm. Please let me know if you have any questions! @Snoman314, grab this pre-release after the new MCR, please. Quote Link to comment Share on other sites More sharing options...
Snoman314 Posted January 18, 2018 Share Posted January 18, 2018 (edited) I'm downloading now. I'll report back once it's finished, and I've tried the new pre-release. Thanks for your work! ++ OK, I have the new version, and changing the optimising algorithm seems to be a viable workaround. So thanks for that. It's interesting watching the different optimisers work, SQP seems to be far more 'conservative' than Interior Point. It makes much smaller changes, that are more incremental in nature, following the gradient towards the optimal solution it seems. Whereas Interior Point jumps all over the place, as if it's mapping out the solution space, and then comes back towards the optimal point later. Or maybe I've just been staring at optimisation runs for too long! It's been far too long since I studied computational modelling to know what I'm talking about! Regardless, thanks again for the update. Love your work, as always! Edited January 18, 2018 by Snoman314 Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted January 18, 2018 Author Share Posted January 18, 2018 Glad it works well! Is anyone else aware of anything else for this update that I said I would do that I haven't yet? @Drew Kerman? Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted January 18, 2018 Share Posted January 18, 2018 1 hour ago, Arrowstar said: Is anyone else aware of anything else for this update that I said I would do that I haven't yet? @Drew Kerman? Hrrmmmmmmmmmmmmmmmmmmmmmmm Not to my recollection, no Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted January 19, 2018 Author Share Posted January 19, 2018 17 hours ago, Drew Kerman said: Hrrmmmmmmmmmmmmmmmmmmmmmmm Not to my recollection, no Okay sounds good, I think I will put the formal release together this weekend then. Quote Link to comment Share on other sites More sharing options...
brooklyn666 Posted January 23, 2018 Share Posted January 23, 2018 Is there a currently up-to-date way to install this on mac? Both the mac install and the wine install are out of date Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.