jakkarth

Hey Arrowstar, I'm back at it again. Today I wanted to do an experience-gathering mission for some of my 'nauts, so I put them in a ship and into a parking orbit. I fired up KSPTOT, imported bodies from ksp, loaded the resulting file, opened mission architect, imported the initial state from the active vessel, and designed a mission that did a flyby of mun and then on to minmus. Once things were optimized to my liking, I uploaded the first maneuver to the running ksp instance. Unfortunately it was way off, it hit mun's altitude when mun was on the opposite side of kerbin. Any ideas what would cause this? I figured with a perfect bodies file and a perfect import of the orbit data, that uploading the maneuver back to ksp should likewise be perfect. On a separate note, it seems odd that I have to save bodies to a file and then load it from the file. While I like the ability to persist the bodies I want to use, I think that importing from running ksp should automatically load those values into ksptot in addition to (optionally) saving them. Thanks as always!

Nothing comes to mind yet but I'll keep an eye out for one. Can you explain a little bit about how the fuel usage is intended to work? I've got a lot of engines and fuel types and other oddness from all the mods I have installed and I'm not sure how best to utilize this functionality. The dV summary tends to be what I look at when I'm verifying that my craft is going to meet the mission specs. I'm not sure I understand what the mass of the spacecraft has to do with the calculations MA does, or what value there is in putting the right engine in the dropdown box of the burn. Maybe if I understood that a little better I could make some suggestions? For the comm stuff, I'm not sure how the upcoming KSP antenna range stuff is going to work. Dealing with RemoteTech, a lot of the antennae are highly directional, so I tend to do my comm planning independent of KSPTOT since there doesn't seem to be an easy way to model that.

You are giving Kris Kringle a run for his money and it's only July! No bugs encountered yet. I did have a question about how MA does the "advance script to this point" function. Am I correct that it basically involves using the data from "view state after selected event" to create a new initial state, and then throws away all of the events up to and including the one that was originally selected? If so, I possible optimization (that you have probably already thought of) would be to use this functionality internally when optimizing, creating an initial state in the same manner based on the event just prior to the first event with optimizable input variables. This would mean getting to skip SoI searches etc for all the events leading up to the first event with an optimizable input variable, which could conceivably save a bit of processing time. You probably already do this, or have a good reason not to, but on the off chance it hadn't occurred to you I figured I'd mention it. Great work as always! What's the next killer feature you've got in the works?

So, basically that's what I had tried. The issue is that the Final Orbit Info is relative to the parent body, while I wanted to specify orbit values for the child body when crossing the SoI boundary. So it sounds like I was on the right track and I just need to beat my head against it some more. This is where I end up after following the above suggestion. I take the values that RMS provides and use them as a basis for MA to try to get to Polta, and I can get into the SoI, but apparently the angle is so wrong that MA can't find a way to swing me around to point the way I want to go. I may have to resort to one or two additional corrective burns to get the right attitude at periapse. Using RMS to do a transfer to Polta makes sense. Using MA to target the Polta orbital parameters I need makes sense. I even have some sense for how they achieve their results. They are oracles; they can always provide an answer. The difficulty lies in formulating the question. I don't see "create forehead-shaped dent in the nearest wall" on your list. I'll try your suggestions instead.

Ok, I'm sure there's an obvious solution for this, and I feel silly for asking, but here goes anyway. So I've made it to Urlum, I've done my insertion burn and I've got a nice circular orbit. Now I just need to wait a little while for the moons to align, and I can set off on a cheap flyby of the moons. I set MFMS to open the window after several orbits are completed around Urlum, and it finds me a nice set of maneuvers. This is where I get stuck. In the tutorials, I was going from Kerbin to Eve or similar; they're both children. Now I'm going from orbit of a parent body to orbit of a child body. This means I can't use the initial orbit in MFMS to calculate my burn to start the flybys, and I can't use the main porkchop plot because the start and end have different parents. This leaves me with the Rendezvous Maneuver Sequencer, which gives me some information about the burn, but I can't specify an arrival time and orbit to optimize for. My plan was to take the burn parameters and transit duration, subtract the duration from my desired arrival time and use the parameters as initial guesses, and let MA's optimizer find me a burn that will send me off to Polta with the right values to be on track for the start of the flyby. However, this is proving problematic, as the transfer from my parking orbit to Polta is out of phase with the start of the flyby mission, so getting the orbital parameters to line up is proving problematic. Would it be better to recalculate MFMS with a very narrow start window based on my desired transfer from parking orbit to Polta? Is there some tool I'm missing specifically designed for this problem (transfer from parent to child with specific child inbound characteristics)? Is my approach completely insane? Any guidance on how to approach this problem would be appreciated. One other small suggestion I've come across in dealing with this exercise: it would be nice to have "copy orbit to clipboard" be an option for entries in the event list in MA, rather than having to view state at event and then copy. Silly for sure, it's just two extra clicks, but I've done it about 10 times in the last hour so I figured I'd mention it. And one final theory question for the evening: what circumstances cause the MA optimizer to bail after 0 iterations? I run into this sometimes and I have no idea what to do about it.

There's no way to add some random jitter to the weights of the constraints or optimizing function perhaps? While you're tweaking labels and such, in the MFMS I noticed that changing the root celetisal body doesn't correctly update the window labels directly below the target list. It tends to say kerbin->eve when I select Urlum. Obviously trivial but I figured I'd mention it. https://imgur.com/4Gbfb5N Loving it so far! I tried running it on a different machine so I could ksp simultaneously, but the other machine's performance was suboptimal. I recall something earlier in the thread about printable report sheets for maneuvers, that had diagrams and burn details etc. Is there something like that I could use to make pretty pictures for tutorial purposes?

My intention wasn't to optimize the entire path at once, but rather to check the opt? flags on the initial departure burn and run, then turn them off and turn on the ones for arrival at jool and run, etc. What I've been doing so far today has been to take the values from MFMS and plug them into each coast/burn as I go along, using MFMS values as initial guesses, and it's working out surprisingly well. I can understand the concern of someone not understanding that doing it in steps is required though. Perhaps a better approach would be to be able to copy-paste burns similar to how we can sometimes copy-paste orbits now. Or maybe it really won't save any trouble after all. You may have talked me out of this one. Is that 30 seconds per operation, or 30 seconds at application start? Even in the second case that sounds absurd. I've written multithreaded applications, including ones that use prebuilt pool libraries and ones where I've built my own, that don't have that kind of start-up penalty. I guess you've got to work with what you've got though. Not a criticism, just surprising to me. My goal in suggesting it was that perhaps you could have the vectorized code running different passes at the same time, but you've shot that down as well. I was under the impression that MA's optimizer had some element of randomness to it as it adjusted the input variables. If it is deterministic, then running multiple of them in parallel will not provide any benefit, I agree. I don't know whether it makes sense to suggest adding some randomness or not; it seems like a genetic algorithm approach wouldn't be out of the question here, would it? Or perhaps we could use some GPU/CUDA/OpenCL horsepower? This is likely just naivety on my part. If I hit the boundaries, that would seem to indicate that I'm asking the optimizer the wrong questions. If I max out my prograde on the jool assist burn, maybe that means I should be decreasing my periapsis instead, for example. The problem I'm facing at the moment is that I'm not familiar enough with what's going on to understand intuitively which variables hitting the boundaries would indicate what I should try next, and my default mode of operation is to try to collect more data on which to base my decisions. I agree that the information you've already included in the scorecard is more valuable than the input variable values, and if you don't think it's worth including I'm inclined to trust your judgement. I already have enough ways to shoot myself in the foot It might be as simple as making the text shorter, or putting the event numbers at the beginning of the string instead of the end. Hopefully I won't be bumping into the boundaries in the first place, but if I do, perhaps you could display a note in the warnings and errors pane that some input variables are now outside of their designated tolerances? There's already a warning for being near them, it seems simple enough to update the verbiage if they're actually outside. While not a perfect fix, it could possibly avoid some confusion. Enough writing, time to try out the new build!

It seems that, at least when calculating flybys with MFMS, only a single core is utilized effectively. https://imgur.com/u1CiZtR

As I continue to learn new things today, I came across an option in MFMS titled "Number of Runs". It appears to simply run the MFMS calculations over and over. Perhaps such an option could be appropriate for MA's optimizer? I understand the rationale behind not letting users directly tweak the optimizer's stop conditions, but perhaps this would be a reasonable compromise? The Stop button would need to terminate not only the current run, but skip any subsequent runs as well, and then the scorecard could be shown using the best data from each run completed plus the last iteration of the last run. I am glad to find myself in such good company

As far as I can tell in the two PDF tutorials included, both of them push as close to the assisting body as possible (calculations shown for equatorial radius plus height of atmosphere plus fudge room). If it would be easy to do so, finding an example (such as the one I'm working through) to use that shows that scraping the atmosphere isn't always optimal might be beneficial. Otherwise, mentioning it the first time you add the radius of periapsis constraint would be sufficient. In the Solar System Edge tutorial, it might make sense to include it on page 23, where you talk a bit about why you're using radius instead of SMA. Since the mission I'm planning now includes an example of this, basing a tutorial on it might be fun. I'm less convinced this is the case now, as actually using the data it provided turned out to be quite helpful once I realized what I was missing. Instead, I'd like to drop this suggestion and replace it with another. After using the MFMS to find some flybys, it would be convenient if there was a single-click way to import the results into MA. This would be as simple as coast to true anomaly + (burn + coast to peri) * remaining bodies. Probably also set the initial state. Could optionally include adding constraints for inbound hyperbolic orbital parameters with reasonable bounds. Then one could proceed in adjusting with the optimizer to ensure all bodies are reached correctly, and from there refine the maneuvers for specific mission goals. Saves a little setup time. Disappointing, but an excellent explanation. The machine I'm running KSPTOT on is an 8-core with 32gb ram. Obviously being a 32bit application it can't use all of that memory. How does KSPTOT do with using available cpu cores? I see a lot of mention of vectorization in this thread, but parallelization a bit less often. Perhaps I'll open up the task manager and monitor my next few runs and report my observations. I hope this makes it in. My current method involves either googling for OPM wiki pages or using the Celestial Body Catalog and brute forcing it by hand. This is absolutely fantastic! The method of selecting which results to use (or discarding) is exactly what I was hoping for, and the display of which values were optimized in which case is great. This is somewhat less ideal. I had two thoughts behind asking for the variables to be included, which I should have mentioned originally. First, sometimes I forget which variables I selected when I opened the optimizer, and I've realized at the end of a run that I was tweaking something I didn't intend to. User error to be sure, but labelling the variables with a name (jool flyby burn - prograde) would be a nice safety measure. The other reason is that sometimes I'm not very good at picking my bounds for the variables, and it would be nice to know (possibly even during the optimization run in addition to the end) how close the variables are to their bounds. I don't particularly care about the real values, just how likely it was that the optimal solution was outside of them, without having to look inside each event to see. On a side note for that last point, I see the yellow warning listing the events close to boundary, but I have to hover over it to see the actual event numbers; they're off the right edge of that list item, and there's no horizontal scrolling. Any luck with the bug about optimizer pushing the variables out of their bounds? Excellent. Assuming I can get this mission planned, I'd like to do a three-part series. The first would be getting to Urlum by way of Jool and Sarnus, and the second part would be doing flybys of the moons there. The first part would focus more on the gravity assist aspects of it and how to tune the optimizer to get where you want to go, while the second would focus more on timing, dV efficiency and doing rendezvous with planets and moons in a system not centered on Sun. Part three would be about getting all the science back to Kerbin. Basically it would be a MFMS plan kerbin->jool->sarnus->urlum->kerbin, with some stuff mixed in at ulrum in the middle of the circuit. Assuming I can actually figure out how to do all that, and the tutorial document I provide for your review meets with your approval, I'd be open to suggestions for further ideas to cover. I know I've barely scratched the surface of what KSPTOT is able to accomplish. Many thanks for your work, and even on a holiday! Any chance I can get a dev build of the optimizer scorecard?

I had a breakthrough this morning when I was looking over my notes. It turns out that the initial radius of periapse for the Jool flyby isn't 6200km after all. I had this idea that I had to skim the top of the atmosphere almost in order to make the best use of a gravity assist, but that seems to not by the case in my example. I guess it would have added too much dV? Anyway, adjusting the radius of periapse constraint to match MFMS's suggestion made everything work significantly better. My Jool correction burn is now under 30m/s, and I have had no trouble following the same steps to achieve my Sarnus and Urlum flybys. Thanks for your patience Arrowstar, as we had surmised it was a user error problem, not an issue with the tool. I do occasionally end up with variables outside of their assigned limits though (not constraints, but input variables), but it's manageable.

Alright, giving up for the day. I spent a solid 11 hours today working on this mission and I still haven't gotten to Sarnus, let alone Urlum. It went from exciting to challenging and now frustrating. Here's my current attempt. Note that somehow the optimizer got event 3's radial component outside of the optimizer bounds, which I believe is a bug. You can see I added coasts to Sarnus, but the inbound hyperbolic to Jool was so screwed up that my correction burn at Jool was in excess of 1500m/s when I was planning for 0. My attempts to get the Jool inbound back on track have been unsuccessful. At this point I have no idea why it can't find a workable solution or what to do about it, and I'm too frustrated to keep beating my head against the problem for now. I may look at it again in a couple of days. Thanks for all your help today, have a fun holiday Edit: event 6 is way out of bounds on all three components as well.

Alright, while this Jool flyby correction burn for Sarnus is calculating, here are the top four things I wish were different/available in KSPTOT. Please forgive me if these already exist, don't exist for a reason already discussed, or are sheer lunacy. Maybe they wouldn't even be helpful and I just don't realize it. Anyway, here they are in no particular order. MFMS warning. Somewhere around page 15 I think, there was a discussion about infinitesimal SoI sizes in KSPTOT tools other than MA. I don't know if this is still the case or not. It was cited as a reason that MFMS results shouldn't be used directly, because you might hit other intermediate SoIs or encounter other problems, and that the results should be used as initial guesses in MA instead. If it is still the case that MFMS results shouldn't be used directly, having some kind of warning on that tool's view might be helpful to people unaware of that. (This would have saved me about 30 minutes when I first got started) MA Optimizer persistence setting. Sometimes it doesn't even get 1 iteration done before it gives up. Sometimes it stops at a severely suboptimal solution when a better one might exist. Sometimes it just goes on and on and on with no apparent significant change in results. Sometimes you're going to let it run overnight and you don't care how long it takes. It would be nice to have a setting where you could set how aggressively it tries to continue the search, including a "keep looking until I tell you to stop" option. Paired with this, there have been times when the optimizer has found a good solution, then found steadily worsening solutions. When it stops working and asks you to accept, hitting yes currently accepts the last solution developed, rather than a better one several iterations ago. In my view, it would be better to store the best solution found so far, and when it concludes, Yes should select the best, rather than the most recent. Without this change to the acceptance behavior, running longer isn't likely to be very useful. Modify the display of celestial body lists. This applies for example to the list of bodies to consider in SoI transition coasts. It's hard for me to remember whether Hale is a moon of Sarnus or Urlum. Since we already have a heirarchy of planet SoIs, I propose that the hierarchy be displayed when the user is prompted for a list of celestial bodies to choose from. This could be accomplished by a pre-order traversal of the body hierarchy, with prepending of spaces or dashs to each body name equal to its distance from the root of the heirarchy. For example, Sun would have nothing prepended, Kerbin would be indented one space or dash, and Mun would get two. Entities with a common parent would be sorted in order of smallest SMA to largest SMA. The indentation coupled with the pre-order traversal of the tree would result in a logical grouping of planets and moons for the user to choose from. Post-optimization scorecard. Sometimes when I'm optimizing in MA, the objective function has improved while the constraints have worsened, or vice versa. It can also be unclear which variables have been changed to result in this new outcome. Proposal: in addition to having a Yes/No dialog to choose whether to accept the new solution, provide an explanation of what changed as well. This would include an explanation of which variables were being tweaked by the optimizer, what their initial and final values were (with delta). Same for the constraints: which constraint was met or unmet, and by how much. This would make it easier for people to identify sticky wickets, like RAAN in our previous discussion, and help identify how much dV is being expended for course corrections etc. Also include the final orbit data, as is currently visible while the optimizer is running. Having all this information available would make it much easier to determine whether the new solution is superior to the original, in the eyes of the orbit analyst. This item would also include a "keep working on it" button, re the persistence setting discussed above. If I can finish planning this mission, I'd have a couple of suggestions for tweaks to the included tutorials. I'd be happy to provide pull requests for those, though I only see one of them in the source tree on github. I also have an idea or two for additional tutorial PDFs that I might be able to write if someone's willing to verify their technical accuracy. Anyway, take these or leave them. The tool is already awesome as it is. Much thanks as always! Edit: also, it would be nice if the optimizer window didn't keep popping to the foreground every time it repainted. Makes it hard to multitask.

And lo, the bug was squashed, and the optimizer hummed happily along to itself having forgotten the words. Perhaps a once-only issue, but starting KSPTOT pre5 took over 2 minutes before the logo showed up on the screen. I had to verify it was running in the task manager. I don't mind the waiting, and I suspect there's not much you could do about it, just thought you might want to know.

Don't you have a life, some friends to set fireworks off with, etc? Instead you're here fixing bugs for me. What a guy I'll buy you a beer next time you're in town.