Jump to content

Arrowstar

Members
  • Posts

    2,557
  • Joined

  • Last visited

Everything posted by Arrowstar

  1. Okay thanks. Can you confirm that the mass of the vehicle is correct and the engine mass flow rate and ISP is correct?
  2. Hmm, yeah, that is a bit annoying. Try playing with the scale factors on the constraints. If you set the scale factor to the desired value, that can help with convergence (maybe).
  3. Okay, thanks for looking into this! Definitely a good effort. The only two forces that should be acting on the vehicle at this point are gravity and thrust. I would first check that the gravitational parameter of Kerbin is the same in LVD and KSP. Next thing I would look at is making sure that the pitch profile is being executed as closely as possible to what's in LVD. If that doesn't match, then the thrust vector will be wrong and you'll see differences.
  4. Well, you could just change your engine parameters to be vacuum levels regardless of atmosphere pressure. That would be easier than changing the bodies.ini file and recreating the mission again I would assume.
  5. Okay, I see now, I was looking at your density plots from the last post, not the first one on this subject. Sorry, reading these posts too fast. Still, the density difference does seem small in comparison to the massive difference in altitudes that you're showing between what's being modeled and what's being flown in KSP. Of course, that could be poor intuition on my part, too. What would be interesting is to see what happens if you turn off the Kerbin atmosphere in KSP (is that possible in the debug menu?) and then turn off drag in LVD. If your planned and flown trajectories are much closer then, then we'll know the difference is in atmosphere modeling. Is that something you'd be able/willing to look into? Regarding the chart: There's no discernible difference in the LVD adjusted plot between what and what? I can look into changing the max allowable thrust profile scale factor, but it's not as straight forward as it sounds as there's something bounds checking code that depends on having a known, fixed maximum scale factor in there. I guess I could always just set the max to be 2 or 10 or something like that...
  6. Thanks for the tip! Can I see a comparison plot of altitude vs time? Because the quantities vs altitude plots look reasonable, I'm wondering if there's a non-trivial difference in your altitudes over time. And yes, I can see about adding an atmospheric temperature plot. Note that I did eliminate a small temperature adjustment factor in the interest of code performance, but given that atmospheric density looks spot on, I'm guessing that it doesn't have a huge impact. I think the molar mass is fixed for each atmosphere, so that doesn't vary with time.
  7. Alright, here's the build of KSPTOT v1.6.4 pre-release 6. The change log is short: Resolves an issue in Mission Architect's SoI transition search where the bisection search would return NaN while still returning a valid distance to target celestial body. All NEW MA and LVD cases will use spline interpolation for their atmospheric table interpolations. Please let me know if you find any bugs. Thanks!
  8. I had to add some additional code to jump into a different root-finding algorithm, but I think I've got this one figured out. My bisection search code was throwing an NaN and not finding a solution that should have been obvious. Anyway, new build coming tonight with this and the smooth spline fit of the atmospheric data. Keep in mind that you'll either need to create a new mission case or have me update your MAT file for you to use the new spline fit, because those splines are generated once when you start KSPTOT and used everywhere.
  9. @Drew Kerman: I checked and it does look like I have a linear interpolation on the atmospheric data, probably for performance reasons. I can change it back to a smooth spline though for testing if that would help you. Regarding the MA SoI transition miss, I will take a look this weekend or next week and see if I can't figure it out. Thanks for bringing it to my attention.
  10. In real life our constraints are pretty tight. We generally expect apogee and perigee altitudes to be within 1 km of their nominal values, and inclination and RAAN should be +/- 0.01 degree or so. But real life also has lots of very smart people with decades of experience working on this stuff, so it's achievable.
  11. Honestly, that looks great! I'm really digging the fact that LVD can model these missions that well! Thanks for sharing.
  12. Here you go. I only fixed the interpolation for Kerbin but I figure that should get you off the ground (literally).
  13. This had to do with the interpolation scheme used to get pressure and temperature values. The old scheme has the double humps and the new scheme does not. However, the interpolation scheme is stored within the MAT file, so for old files, you'll still see the issue even if I fixed it going forward. I can try to fix up your MAT file if you'd like me to. It'll be a matter of replacing the old scheme with the new.
  14. Sorry I've been out of touch recently, all, I've needed a bit of a creative break. I have been keeping up with the discussion here though. Thanks for investigating all this! I tracked it down very easily tonight with your help. I think this build should resolve the issue, if you could give it a go? KSPTOT v1.6.4 Pre-release 5
  15. I'll look into it and see if that's an intuitive thing to add. It might be, but I could also see it being confusing for the user. You got it. Body Fixed Aero angles are relative to the body-fixed rotating frame velocity vector, whereas the the inertial aero angles are relative to your inertial velocity. If you want to true prograde, use the inertial aero angles with all three angles set to 0 degrees. Unfortunately it is not. I don't model torques directly, steering is only proscribed, it isn't computed. This is actually not a trivial thing to do. Maybe the analysis tools in FAR can help? Regarding the atmo question: I guess I could have some very specific warnings for the original planets/moons that have an atmosphere, but it would be impossible to do generically. Why did your atmosphere disappear again? Do you know?
  16. Added for next build (which is hopefully coming tonight). EDIT: And here it is: KSPTOT v1.6.4 pre-release 4. Change log: Resolved issue with multi-flyby porkchop plotter. Resolved issue with LVD constraint dialog box. Added periapsis and apoapsis altitude event termination conditions to LVD. Please let me know if you find any bugs. Thanks!
  17. This is working as intended. The engine's state is still "active" even if the stage is inactive. This should indicate to the user that if the reactivate the stage, that engine will still be on. I'd rather not reorder anything without the user doing it themselves, could be confusing later. I could always have a button or context menu that reorders by event number for the user, if that would work? These could be done, yes! Good suggestion.
  18. Hey that's great! The big things would be atmospheric pressure, atmospheric density, atmospheric temperature, and drag coefficient. If I can think of anything else, I'll be sure to let you know.
  19. I couldn't duplicate this, can you give me some more information regarding how to get this error to show up?
  20. The burn is most likely in the wrong point in the orbit. Move the maneuver node around until you get the intersection you're looking for.
  21. Okay, fixed! See KSPTOT v1.6.4 pre-release 3 here. Here's the change log: Resolved an issue with comparing spacecraft generated body object IDs; LVD: Added patternsearch solver to the available optimization routines. @Drew Kerman, please let me know if this resolves (or not) your issue.
×
×
  • Create New...