Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,559

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    Yes, this is all correct. Gilph, do you have a bodies.ini file for this mod you'd be willing to share here? That might help @OverlordMorgoth out a lot. ---- In other news, I put together KSPTOT v1.5.9 pre-release 5 tonight. The changes are as follows: 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 will be included in next build. Another experimental update to the Kepler solver (tightened tolerances after comparison to external solver).
  2. Arrowstar
    Sorry about that, I was hoping the tag would work. It could just be a KSPTOTConnect thing, but it should work with KSP v1.3. Let me know if you have issues in the coming weeks after you upgrade.
  3. Arrowstar
    Does KSPTOTConnect not work with that mod? And yes, all versions from here on out will be on MCR R2017b, which I linked to previously.
  4. Arrowstar
    Okay, here is KSPTOT v1.5.9 pre-release 4. It includes the following changes: 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. I made an experimental update to the Kepler solver which seems to provide results more consistent with KSPTOT running under MATLAB 2015b. This one could be touchy, so in particular if you see issues with the way orbits are being propagated, please let me know! I added the MATLAB version the application is running on to various splash screens and informational texts. Please let me know if you have any questions or have found any bugs. Thanks!
  5. Arrowstar
    I'll investigate the bug, thanks! EDIT: Okay, @Drew Kerman, so I could not reproduce the issue. I can pull in both asteroid orbits and normal spacecraft orbits using the Get Orbit From KSP option (not the Active vessel option, the one that presents the list). Can I see the error message you get? Are you on the latest version of KSPTOTConnect? Or maybe the issue is that you're on KSP v1.2.2, which I technically don't support anymore...
  6. Arrowstar
    Okay, so let me confirm, because I think I'm a bit confused: The issue you're reporting is between actual KSP and KSPTOT, right? And it just appeared when I started using the R2017b MCR? If this is the case, it could be precision, but it could also be differences in the integrator (the numerical subroutine that propagates the orbit). In fact, KSPTOT exclusively uses two body propagation for all non-thrusting orbit arcs, and I think KSP numerically integrates the equations of motion (unless the spacecraft/body is "on-rails" which is KSP-speak for the two body analytical motion). The latter will be less precise by definition. If you propagate over long periods of time in KSP, it's reasonable to think you might slowly see a divergence between KSPTOT and KSP. Is this what you're doing? Finally, if you're importing from an SFS file, the numerical precision will be limited by the limited number of digits that show up in the SFS file. The SFS file is a far less precise data source that using KSPTOTConnect. If my initial assumptions are correct, does any of this sound like it could be the culprit?
  7. Arrowstar
    Here are two versions of the same code base, one compiled for 2015b and one for 2017b. Can you take a look and see if you spot a difference in how they behave? Just to note, I have not tested the 2015b executable in any real way, so if something doesn't work, please let me know... Thanks!
  8. Arrowstar
    Thanks for the MAT files! Btw, does the Alaba offset issue show up if you use the last R2015b version of KSPTOT? Done. I increased the figure number offset so it should not be a problem in the future. This will be in the next pre-release. I'll get a line color in for the aerobraking stuff, thanks for finding that. So... where are we at with the drag coefficient stuff now? I have made the labels more obvious (everything is "Area * Drag Coefficient" now). Does anything else still need fixing?
  9. Arrowstar
    Okay, thanks for the clarification. Can I get the MAT file that you did this in, by any chance? It would help my investigation! I'm still trying to understand what you're seeing with what I believe the correct result should be, and that would definitely help. EDIT: Just to be clear, I agree that 0.477 is a proper value of Cd, but I also note that what Mission Architect uses as an input for aerobraking is not Cd, but instead CdA. That's why I wasn't bothered by seeing 919 earlier, because, given that it's a huge asteroid, there's probably a massive amount of frontal surface area there. Well, that is certainly troubling! Could I get this MAT file too? Or some more details of how you were doing your comparison/prediction? I'm not sure how I'll get to the bottom of this one, but I can try. Sure, I don't see why not. You just want to be able to constrain the amount of time from the initial state epoch to the epoch of the final event's final state? ------------------------------------------------- Also, some good news! I actually got parallel optimization in Mission Architect working this evening (I found a number of bugs that were, weirdly, only kicking in under the parallel case). This will be in the next pre-release build and the next stable build as well!
  10. Arrowstar
    So... a dig through the code actually suggests that number, the 919.977 we're seeing, is Cd*A, or the drag coefficient times the frontal surface area. That would make 1) the units on the drag coefficient output make sense, and 2) make the actual number output make more sense. This obviously isn't clear, though, so I can update the UI to reflect that. Given this interpretation, does that help resolve the issue? I agree that 0.477 actually makes far sense as a true blue drag coefficient. Can you explain further where this number came from? Not quite. The difference is purely between how the two versions of MATLAB are storing and computing doubles. KSP itself is not related to this.
  11. Arrowstar
    I think I've got this resolved. Here is KSPTOT v1.5.9 pre-release 2, please let me know if this takes care of the issue! I successfully tested it on my end. This build also includes the handful of other items I mentioned I resolved since the first pre-release. Still requires the r2017b MCR, as with last time.
  12. Arrowstar
    So I have bad news about this one. After investigating tonight, I believe I know what the issue is. Between MATLAB R2015b and R2017b, it looks like the MATLAB developers figured out how to get MATLAB to carry more digits per number internally in memory. This means that numbers in R2017b are more precise after digits around 1E-10 to 1E-14 or so. I ran an experiment to be sure. In both versions, I ran a coast propagation from UT=35860529.8244236 seconds to UT=1.00000000000372e+19 seconds (so a massive propagation, but done analytically, very quick). The large numbers are needed to get the difference in memory storage to appear easily. On MATLAB R2015b, the final result was: In MATLAB R2017b, the final result was: These are very different. To illustrate further, here's what happens when I look at the initial state even further. This is the first element of the position vector. MATLAB R2015b: MATLAB R2017b: And the difference between these: These little differences in position mean that over many propagations, or even just one long propagation, and many revolutions of propagation, the solution becomes more and more off. The position and velocity differences start small, but after a long period of time in the MATLAB file you gave me, grow to centimeters of difference, then meters, then kilometers, etc. And the numerical differences accelerate as the differences get larger, so the issue sort of compounds on itself. I'm not sure what to tell you as there's not much I can do about this. Have you noticed any other places where this has impacted things?
  13. Arrowstar
    Generally just fiddling with numbers. But you could also use the optimizer to target the ascending point at zero altitude to have the same longitude by strictly adjusting the RAAN of the orbit. That might be faster.
  14. Arrowstar
    Oh I get what you want. You'll have to adjust the RAAN of each manually to get them from the same point.
  15. Arrowstar
    Setting the same RAAN, Argument, and Epoch should do it... what happens when you try that?
  16. Arrowstar
    Okay I think I figured it out! It's just a KSP quirk: In this case, KSP generates the asteroid orbit by starting at some future time that defines where the asteroid should be relative to Kerbin. It then back propagates the orbit about 60-70 days or so to the current game time (look at the time stamp on the asteroid orbit you import from KSP as opposed to the timestamp actually in the game). So the reason the asteroid starts out in Kerbin's SoI is because it was designed to do that... but not for a long while in the game time. The "reference" orbit around the Sun that's getting imported is this future timestamp orbit, because that's what is stored in the game's memory and in the SFS file. Does this make sense? In other news! The MATLAB developers finally made it so that 3D axes don't just explode into the window they're embedded into when you zoom or pan around in them, so I'm happy to announce that Mission Architect's main UI window will have this feature in the next release!
  17. Arrowstar
    Okay, I believe the issue is that the asteroid is getting spawned funny. I imported another asteroid from the scenario (generated later) and it works fine. Additionally, I imported the same asteroid from the SFS file and via KSPTOTConnect and got the same result. Looks like just a funky asteroid.... Except that it doesn't look funky in the tracking window. There it's well outside Kerbin's SoI. Boy, I'm not sure what's going on there, maybe some issue with Kerbin's location over an extended period of time. Not sure...
  18. Arrowstar
    Okay, so there's funny business going on with the "bad" MAT file. It looks like when the SoI transition occurs, the spacecraft is already well within Kerbin's SoI. In fact, it looks like it starts out in a Sun-centric orbit that really should be Kerbin-centric, because the distance between Kerbin and the spacecraft is only a few thousand kilometers at that initial state. I suspect this might be part of the issue... any idea why this might be?
  19. Arrowstar
    Thanks! You'll probably notice that there are slight differences in the way that MA propagates stuff in this build. It has to do with the SoI transition code, I'm still pinning it down.
  20. Arrowstar
    I'll take a look! Okay, I've put together a new pre-release build for what I'm calling v1.5.9. Here it is. It contains the bug fix for the KSPTOTConnect issue and the new constraint for MFMS. Note that this was build on a new MCR version, MATLAB R2017b. You'll need a new MCR download to run this. Grab the Windows MCR download on the row labeled "R2017b (9.3)". https://www.mathworks.com/products/compiler/matlab-runtime.html
  21. Arrowstar
    If that's all it is, I can do it via MATLAB's internal variable editor. No need for you to put the work in. Just tell me which event to trim to. Got it! So how would you like to see the constraint implemented then? If it's fairly easy, I can put it together however you'd like. ------------------------ In other news, I've begun migrating over to MATLAB R2017b. I suspect v1.5.9 (or maybe I'll call it 1.6.0, haven't decided yet) will be running on this version of MATLAB. Unfortunately, there appears to be an annoying issue with the way the SOI transitions are computed and I've noticed differences in the way the same mission plan is executed on the same code. I suspect neither is technically wrong and it's just a matter of some tolerances somewhere, but it's something to track down. Anyway, stay tuned!
  22. Arrowstar
    As far as I can tell, it's a solver tolerance issue. There's a piece of numerical code that is responsible for figuring out if a trajectory crosses an SoI and the search routine for that code uses a tolerance value to figure out when to stop when determining when the SoI crossing occurs. Because of that tolerance, things might execute slightly differently here and there depending on initial conditions, and I suspect that's what's the at the root of the problem. If I can get a simpler case that demonstrates the issue, I can play around with this more. I've added a constraint in for next release. Right now it's just MFMS central body radius + atmosphere height as the minimum periapsis of the transfer orbits. I assume this will be fine for now as it will stop people from running into the central body. If that's insufficient and there's enough demand, I can look into adding more flexibility to that number. Issue resolved for next release.
  23. Arrowstar
    So... I'm not exactly sure what's happening. It doesn't make sense, as you said, because the way that function works just grabs the initial state from the event that you're advancing up to, deletes everything between the current initial state and the selected event, and rewrites the initial state event. Any chance you can reproduce this on a file that has fewer events so that it's easier to run? I hadn't thought of this, good idea. How close would you suggest the minimum should be? I can take a look. Thanks for the report!
  24. Arrowstar
    I'll take a look! What was this for again? Which feature? This is just the display unit. The math is still always done in seconds.
  25. Arrowstar
    I ran through the code and there's definitely no aerobraking happening. (I watched the code skip that part directly.) The error is functioning as it should, as well. In the MAT file, the periapsis altitude was in fact above the atmosphere of Jool. Some thoughts: 1) You are optimizing with many constraints on at once. Instead, activate constraints it in stages: first target Jool, then set your periapsis altitude, then target your Laythe intercept, etc. After each stage, turn off variables you no longer need and then turn off the corresponding constraints. The idea is to keep the number of active constraints in MA's optimizer to a minimum because the optimization algorithm does better that way. 2) It looks like your TLI_Burn is occuring shortly after Jool periapsis if I'm seeing this correctly. 3) Keep up the practice with KSPTOT and Mission Architect. It's not easy software to use because spacecraft mission design is hard stuff. Keep asking questions here, too. You'll get it!
×
×
  • Create New...