Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,561

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    Have you tried creating the bodies file more than once? KSPTOTConnect definitely packaged things up and sent the data. This is pretty unusual. I'm not sure what to say honestly.
  2. Arrowstar
    Can I see your KSP log and your KSPTOT log files? Can I see the MAT file that you're seeing this in?
  3. Arrowstar
    It's all good! I really want to get to the bottom of this, too. ...so that's what I did tonight lol. What I did was rewrite a portion of KSPTOTConnect to grab the vessel relative atmospheric pressure, temperature, and density, as KSP sees it, and write it to a CSV file. I then plotted the calculations my code does for those quantities against the data KSP provided me. Here's what I got. KSPTOT is blue on top, KSP is red on top, and the difference is the bottom row. The temperature is pretty off... but look at that. KSP is using a linear interpolation model! This whole time I figured they had some smooth curve through their data internally, but nope, they basically just draw straight lines. Needless to say, I was shocked to see this. Anyway, correcting for the difference in model type (switching mine to linear) yields: This is obviously much better and the density differences are basically non-existent now. I'll need to write some additional code to switch everyone over to the linear model for temperature and pressure curves, but all new KSPTOT sessions (for both MA and LVD) will have the linear model applied. Btw, this also implies that the temperatures and pressures coming out of kOS are basically junk. You might want to have a word with the developer if that is something you require to be accurate in the future. It was pretty easy to grab from KSP itself, I just used the following: double atmoTemp = vessel.atmosphericTemperature; double atmoDensity = vessel.atmDensity; double atmoPress = vessel.staticPressurekPa; Thoughts?
  4. Arrowstar
    Hi everyone, Today I've compiled KSPTOT v1.6.7 pre-release 5. Here's the change log: LVD: Added ability to set positive output step sizes for all active integrators on events. LVD: Boosted performance when looking for downward SoI transitions. LVD: Can now create event continuity constraints via a context menu accessed by right clicking on the sequential events listbox. LVD: Fixed a number of reported bugs (thanks, @Drew Kerman!) Please let me know if you have any questions or I missed something. Thanks! (@Drew Kerman: I know I still need to look at importing/exporting ground objects. This is more complicated than it appears, though, so bear with me for the time being.)
  5. Arrowstar
    A few more updates on this: The bug with creating the additional objective function I believe is resolved now. The arrow buttons are only disabled in the View All mode. I have left them active in the Group by SoI mode, even if there's only one SoI in the mission. Would it make more sense to disable them in this case too? The true anomaly termination condition isn't going to be solvable, unfortunately. It has to do with the way the integrator's event root finding works and the fact that true anomaly is a cyclical quantity that repeats (and jumps from 360 degrees to 0 degrees instantaneously, which root finding hates). I would recommend only using true anomaly as a termination condition if you know that the target true anomaly is not on the other side of periapasis (if the target true anomaly is not near periapsis) or not on the other side of apoapsis (if the target true anomaly is near periapsis - this is your case here). I'm sorry, I completely misunderstood your last point and didn't see that you were doing it in Mission Architect initially. I think my previous point still makes sense though: the differences between impulsive and finite duration maneuvers is going to result in differences in final orbit after the maneuver. Since MAE doesn't propagate finite burns, it only estimates burn start based on centered delta-v, the fact that you got a different result is not unexpected. I'll put out a pre-release today, hopefully, with some of the changes/fixes involved it in.
  6. Arrowstar
    This probably has to do with the fact that each event is now getting plotted as its own data series. I think this ended up being necessary to support plotting each event with its own colors. Sorry about the annoyance. Yeah, I can look into this. The first I suspect I've fixed previously because I can't reproduce on my end. I'll keep looking into it though. The second is probably due to the atmospheric temperature caching I was doing. I've disabled this for now in the code, it's turning out to be more hassle than its worth unfortunately. Did they use to do this in the past? I honestly don't remember lol. Is there a bug associated with it or is it just weird? View -> Edit View Settings -> Uncheck "Update view axis limits" There seems to be limited functionality for this under the hood because all camera actions ultimately seem to update an axes' limits. That was just at a glance through the documentation though, I'll keep investigating. Done for next release. Fixed for next release. I'm working on this one but it's really obnoxious. Having a true anomaly target of 0 deg does some weird things with the root finding built into the integration. I'll keep poking at it. EDIT: This one will not be solvable it looks like. What's happening is that when you get 180 degrees away from 0.0, the true anomaly termination condition flips the sign of the value that gets passed to the integrator from positive (going away) to negative (going towards 0.0) and the integrator interprets this sign flip as a root and gets stuck at it. There's no mathematical way around this that I can see. If you need to go to zero, use a constraint and time as the termination condition. This should work better. (EDIT 2: There might be away for me to do this with flight path angle instead, but I'm not sure, so let's wait and see.) All MEA is doing is centering the burn delta-v over the arc of the burn. I wouldn't expect it to match LVD, especially if the burn is longer. MAE gives a better result than centering the burn in time, but it's still just estimating location based on a point impulsive delta-v. Use LVD for start times instead.
  7. Arrowstar
    Okay cool. Which kOS function are you using to grab atmospheric temp then? I want to take a look at the code and see if there's a discrepancy in there somewhere between what it does and what I do.
  8. Arrowstar
    Is this the method you're using in kOS? Because if so, it looks like it's not accurate either. Here's the kOS code that this function calls: It's the celestialBody.GetTemperature(alt) bit that's important. If I look at the KSP API, it has this to say on that function: Assuming this is accurate, I'm guessing base value is the base temperature curve for the body that is only a function of altitude, plus somehow it gets the latitude of the vehicle and plugs that into just one of the elements of the temperature offset. Basically, I don't think kOS is accurate here because it doesn't seem to be calling the full temperature model of the atmosphere. @NathanKell, do you have any idea how the celestialBody.GetTemperature(alt) method works?
  9. Arrowstar
    Sure, give it a shot. If you want to limit it to just stock KSP for now that would be fine with me.
  10. Arrowstar
    So I did a ton of comparison today in KSP, using my KSPTOTConnect plugin to basically just display temperature data and evaluate to temperature curves. I'm starting to believe that some of the differences you're seeing are: A) Due to interpolation differences; and B) An issue with the kOS temperature code. Most of my evaluations of those temperature curves were very close, within a Kelvin or so. There's still something not quite right, but it's not nearly as big as the differences in your output data. If you learn anything from the programmer, please let me know.
  11. Arrowstar
    Wow, thanks for all the data! This is really a treasure trove. It remains that temperature is the annoying one of the bunch. Can you check something for me? In the Stock data, why does temperature go crazy initially? It's reading 2000 K at the first data point and 411 K at the next. Something is wrong there, any ideas? EDIT: Does kOS have the ability to output more fundamental data from KSP? Can you ask it to evaluate methods on KSP classes? If you look at this thread, you'll see a section near the top ("understanding the temperature curves") where there's a few equations that describe KSP's atmo temperature model. Are these quantities something you can get out of kOS? For example, can you evaluate currentMainBody.atmosphereTemperatureCurve.Evaluate(altitude)?
  12. Arrowstar
    Use the 0.001 mT tank mass termination condition everywhere else you've got it, yes. The point of the C3 constraint is to make sure the optimizer forces the trajectory to leave the system. We only care about the lower bound in this case. Since we don't know (nor care) what the actual C3 is ahead of time, we just set the upper bound to a large number to get it out of the way. It's generally good to give your optimizer more room to work in unless you explicitly know the answer to something or you have a requirement that dictates a particular value.
  13. Arrowstar
    Typo fixed, thanks. As far as your issue goes, I figured out what it was. In event 6, your boosters are running out of propellant and then being jettisoned when their booster tank is empty (mass = 0.0 mT). However, engines cease to work if their connected tank has 0 or less mass in it, and this was causing some flip-flopping inside the integrator when it was trying to find the exact point at which the booster engine runs out of propellant. The fix is easy: set the stage jettison tank mass triggers to something just above 0.0 mT, like 0.001 mT. This does not incur any noticeable launch vehicle performance hit, resolved the integration issue for me, and your simulation propagates so much faster to boot! EDIT: Another note. You need to scale your continuity constraints to get better optimization performance. Try 1E6 for the position, 1.0 or 10.0 for the velocity, and 1000 for the time constraint. EDIT 2: Throw in a C3 constraint at Event 8 and set the lower bound to be just above 0.0, something like 0.01. The upper bound should be large (1000 or more). This will prevent the optimizer from getting trapped in the Kerbin system and throwing off the gradients. EDIT 3: The other thing that will really help your optimization is using Duna-centric Universal Elements with the C3 element constrained to be greater than some small positive number (0.01). Yours are currently Sun-centeric Keplerian, which is much harder for the optimizer to work with.
  14. Arrowstar
    Alright, new build of PR4 is up at the same link I used previously. If you reported a bug or feature request and I claimed to add or fix it, please check to make sure it's there. Thanks!
  15. Arrowstar
    Thanks! As my current build is basically a bug fix release on top of PR4, I think I'm going to go ahead and start rebuilding that, and then simply reupload PR4. I'll do that tonight and let everyone know when it's done.
  16. Arrowstar
    Tab order corrected for next release. New matrix issue corrected for next release. I couldn't reproduce the issue you saw while optimizing. Could you check that it is reproducible and see if it occurs when parallel mode both is disabled and enabled? Good QoL suggestion! I implemented the feature on the script listbox. Right click the event in the script listbox you want to create continuity constraints with, select the other event to create continuity with, and away you go.
  17. Arrowstar
    Alright, everyone, here's KSPTOT v1.6.7 pre-release 4 with a bunch of bug fixes. Namely: MA/LVD: Added option to set number of parallel workers for optimization. MA: Fixed bug with having more than one variable item in a variable (initial state). MA: LWA can now import target orbit data from KSP. MA: Added functionality to set launch site from ground target in Set State (estimate launch). LVD: Fixed bug with power sources (wrong matrix size stuff). MA: Resolved issue that causes error if an event does not have any states associated with it. If I said I fixed your bug earlier, can you please check to see that it's actually resolved in this pre-release? And if you asked for a feature and I added it, please make sure it does what you were expecting it to do. Thanks for your help everyone!
  18. Arrowstar
    Basically it assumes a "fast" launch (so instantaneous") and then determines when the orbit plane, defined by inclination and RAAN, intersects the launch site. That's your launch time. Azimuth is computed by spherical trig, basically. And yes, if there's interest, I imagine I could add LWA to LVD.
  19. Arrowstar
    It's not directly, but there are all sorts of places in KSPTOT where you can enter UT and get out the date. It's generally more useful to output the UT with KSPTOT because that's the authoritative number within KSPTOT, not the date string. Basically it just draws an ellipse between your launch site and your orbit insertion site, and then maps that ellipse to a spherical space instead of a Cartesian space. It's pretty crude and doesn't work all that well if you care about the launch at all, but if all you're after is some info about where you'll be in space when you separate your spacecraft from the launcher, it'll work fine. Yes, exactly. You'll need to know something about how your rocket flies with its payload in order to get those parameters. Yeah, so this is embarrassing. The reason nothing happens is because there's literally no code in that menu's callback function. Whoops. Looks like something I wanted to do and then forgot about lol. I'll add it back in. Good find, btw. That's probably been like that for years and no one has either noticed or said anything. EDIT: And now it does something. Easy fix. Yeah I could do that probably. Let me look into it. EDIT: Added for next release.
  20. Arrowstar
    Found it. Issue resolved for next release.
  21. Arrowstar
    Yeah, it's a good question and I realize it's a confusing point given the names. Basically, Mission Architect started out as an end-all be-all general spaceflight mission design tool for KSP, and it remains that today. Originally, LVD was going to be a component of MA that focused strictly on launch vehicle design: so it would model stages, fuel tanks, realistic engines, etc. What I found when I was developing it, though, is that the way I set up LVD was much more flexible than the old way of designing missions in MA. Since then I've been gradually adding functionality to LVD and at this point I almost consider LVD to be a full successor to MA. LVD can do just about everything MA can (aside from some of the "other spacecraft" stuff and communications network modeling), but it does it better, is more organized, and (I hope) smoother for the analyst to use. Going forward, I consider MA feature complete and while I'll certainly support it and fix bugs for it, I don't anticipate adding new things. My recommendation would be to use LVD going forward for all of your mission design needs, even those not requiring launch vehicles directly. There's just so much more LVD can do, even in generic spacecraft missions, that the choice seems pretty clear to me today.
  22. Arrowstar
    Strange, I still can't get it to optimize. I know what's causing the issue, though, so I have put in a fix that will hopefully work around the issue.
  23. Arrowstar
    How long does a single iteration take? It seems like it takes forever on my system, I never get past iteration 0.
  24. Arrowstar
    Resolved for both MA and LVD in next release. The default is still the number of cores in the system, but you can change it now. Can you provide me universal time, altitude, latitude, longitude, pressure, temperature, and density for this "more basic" test? A Google sheets doc would be fine for now. Thank you!
  25. Arrowstar
    Resolved for next release. I couldn't reproduce this one. What did you do to cause it to occur?
×
×
  • Create New...