Arrowstar

Members
  • Content count

    1561
  • Joined

  • Last visited

Community Reputation

494 Excellent

1 Follower

About Arrowstar

  • Rank
    Astrodynamicist

Recent Profile Visitors

1666 profile views
  1. Okay, give this a try. KSPTOT v1.5.10 pre-release 1. As far as I can tell, this corrects the issue you found with the SFS import. 1) The method you described, using the Upload Maneuver feature, is the correct way to execute the maneuver in KSP itself. This will automatically place a maneuver node in the correct place for execution. 2) If you upload the maneuver to KSP, it will get the timing correct as long as you tell KSPTOT the epoch of the orbit and the mean anomaly of the orbit at that epoch. If you don't provide timing information to KSPTOT, then it will assume that less than one revolution is sufficient to phase the maneuver. Please let me know if you have any other questions. Happy orbiting!
  2. Are you running the matlab source code or the executable I package in the zip?
  3. The build process is pretty easy. You just load up the project file and tap "build." It spins for 5-10 minutes and then it's done. Couldn't be easier. Just a note, I would prefer (and my license requires) that any 3rd party compiling for distribution be done in coordination with me. If you want to go ahead with something like this, please PM me or whatnot so we can discuss specifics. Thanks! I'm also pleased to announce tonight the release of KSPTOT v1.5.9! This release has lots of good changes to it, most notably the update to the most recent version of the MATLAB MCR, R2017b. You will need this new MCR to run the software. (See the OP for a link.) Here are the changes: Update KSPTOT to use MATLAB Compiler Runtime version R2017b. Resolved issue with KSPTOT RTS. Added minimum periapsis radius constraint for MFMS. Fixed issue with KSPTOT Mission Architech drag calculations. The Mission Architect optimization algorithm is now select-able from the Script -> Execution Options menu. Mission Architect aerobraking events can now select a color to use for drawing on the UI. Added the MATLAB version the application is running on to various splash screens and informational texts. Mission Architect orbit display clipping parameter updated to "rectangle"; should help with some funny clipping issues that existed previously. "Central Body ID" constraint should now be smooth instead of discrete. This should help with using this constraint during optimization. New "Eve Aerobraking" MA example Added a total mission duration constraint in MFMS. Increased the fidelity of the Mission Architect SoI search routine with the addition of another algorithm. Added an error message to MA when the optimizer hits a NaN for a control variable. Messages are written to MA output when you change optimizer algorithm. As always, please let me know what bugs you find and happy orbiting!
  4. I honestly think someone would have to have a copy of MacOS and MATLAB on it to compile for Mac. I had a guy helping me with that a while ago but I have not heard from him in a long time. WINE and KSPTOT have never really cooperated in my experience, sadly. No need to get a "variant!" It is possible. From the Q&A on the first post of the thread: Let me know if you need any help with this, I'm happy to try. EDIT: Btw, if you do use KSPTOT for your work, please A) credit me for the software, b) share the results of your work on this thread so others can see what neat things people are doing with KSPTOT (if you are able)!
  5. Okay sounds good, I think I will put the formal release together this weekend then.
  6. 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?
  7. 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.
  8. 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.
  9. 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!
  10. 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!
  11. 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.
  12. 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. Good find, fixed for next build!