Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,557

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    1) Sure, this could be done. Elevation with respect to the local horizontal plane? 2) I'll check this afternoon to be sure but this functionality should already be in there. If you use the Spacecraft -> Ground Targets menu, you can add ground station locations. I believe these will show up in the Comm Network Analysis tool.
  2. Arrowstar
    Hi everyone! I have a brief announcement regarding a new feature coming to KSPTOT in v1.6.3. In the course of putting together the Eve tutorial for Launch Vehicle Designer, I realized that in order to determine how big my vehicle needed to be in order to complete the mission, I needed to do a bunch of rocket equation-based math that turned out to be not so simple. This inspired me to write a solution that I am happy to introduce to you as the new "Vehicle Sizing Tool (VST)"! The use of the tool is very straight forward. Every mission can be broken up into logical phases that have some set maneuvers. These maneuvers define the delta-v requirements for that phase. For example, to ascend from Kerbin to low Kerbin orbit, a delta-v map might show 3400 m/s required. This is one mission phase. The next might be a transfer to the Mun (1170 m/s) and the final might be that required to land on the Mun (580 m/s). Every phase uses a number of discrete rocket stages to meet the user-defined required delta-v. Each stage has its own engine specific impulse, mass fraction, and desired thrust to weight ratio. (The latter is important if you want to understand how much thrust is needed to get off Kerbin, but also useful if you're in deep space and you just don't care about needing high thrust engines as well.) When you tap the "Run Sizing Analysis" button, the the code will attempt to minimize the total mass of the rocket while meeting the delta-v for each stage and the required stage mass fraction. I came up with an intelligent methodology that provides decent initial guesses for the solver, so unless the vehicle or mission is completely infeasible, it should generally come up with a solution. The outputs include mass data on the full vehicle as well as each stage. The masses shown should be taken as targets for the designer as they develop their vehicle. In addition, the delta-v, required thrust to meet desired thrust to weight, and stage burn time are also computed and provided. The first build of KSPTOT with the VST included will be the next v1.6.3 pre-release, which should get pushed out sometime this weekend. Some future enhancements I have my eye on are the ability to compute stages with side-mounted boosters (think SLS or the Space Shuttle), as well as the standard KSP asparagus staging set up. What do you all think?
  3. Arrowstar
    Issue resolved for next release. So I could remove the "Sea Level" part of it, but honestly it's both arbitrary and doesn't change all that much for most altitudes where you care. Unless a use case arises where the local gravitational acceleration at the current altitude is important, I'm inclined to just leave it as is. The only thing I could think of is if you were very high above Jool or the Sun and falling directly into it and wanted to exactly counteract the pull of gravity to "hover" there. Then local T2W would be important. That's all I can think of off the top of my head.
  4. Arrowstar
    Yeah, unfortunately comm links can't be used as an optimization constraint. They're really CPU intensive to compute and binary on/off types of things don't really work well with optimizers that need smooth gradients to figure out which way to go. This is the same reason why eclipses aren't a constraint you can use either. They are either on or off (there or not there) and optimizers just don't work well with that. Good thoughts about using Mission Animator, though! That should be accurate as I do model the position of the Sun directly in that. I'll take a look at the TWR error later today if I can. Thanks for the report! And yes, that is what the Perturb Optimization Variables feature does! You give it a percentage and it computes that percent of the width between the upper and lower bounds of every variable and modifies them by up to that much (the actual amount changed is random for each variable each time). It's a good way to give the optimizer a little nudge if it needs it to home in on a solution.
  5. Arrowstar
    Your Kerbin atmosphere curves are empty again, which means that the default pressure / density of the atmosphere, 0.0, is being returned. This is causing the dynamic pressure to be computed as 0.0.
  6. Arrowstar
    Are you using Mission Architect? If so, you can save what you're working on as a MAT file and send it to me and I can try to help.
  7. Arrowstar
    Strictly speaking, it doesn't really match with either. However, it's probably more appropriate to say that it's the time of the departure burn when leaving and the time of closest approach when arriving. Thanks, I'll take a look! Sounds good, did you still have a question?
  8. Arrowstar
    Okay should be fixed now...
  9. Arrowstar
    Try again, it may have still be uploading when I posted that.
  10. Arrowstar
    Hi everyone, Tonight I built KSPTOT v1.6.3 pre-release 6. Here's the change log. All items are w.r.t. Launch Vehicle Designer. Added a Mission Notes area (as in Mission Architect) - see the Edit Menu Fixed issue with stop watch termination condition New Cd default for aero drag state is 0.3 Some code refactoring in the SimulationDriver Please let me know if you find any issues (aside from the Non-Sequential event duration termination condition issue previously reported above), or if you have any thoughts on the Eve Sample Return tutorial (which is also included in the download in this post). Thanks!
  11. Arrowstar
    A warning is a good idea. I'll look into that. Thanks!
  12. Arrowstar
    So this is not unusual (it's also the single most common question when using KSPTOT lol). The porkchop plot uses a "infinitesimal" sized sphere of influence of Kerbin, which basically means that the departure point inherits from Kerbin's position and velocity but ignores any Kerbin gravity. Only solar gravity is used. This assumption simplifies the problem immensely at the cost of some accuracy. What you're finding with having the adjust the departure time a bit is that lack of perfect accuracy. The other aspect, now that it occurs to me, is that KSPTOT doesn't necessarily know where you are in your orbit when you compute the maneuver. (It does if you use the "Mean Anomaly" and "Epoch" checkbox when you define the initial orbit.) If it doesn't know, it just assumes that you're in the right place in the right time. If you do want to model maneuvers better, you can try Mission Architect or Launch Vehicle Designer, both of which will model burns exactly as KSP models them, giving you that accuracy. These tools are more complex than the porkchop plot tool, though. Good question! Does that help any?
  13. Arrowstar
    It has to be a MATLAB bug. The built-in integrator's event handling just sort of stops behaving normally in this case. I watched it completely ignore any semblance of event detection root-finding when the non-sequential event termination condition is "event duration" of 0.0 (or very close to 0.0, as in 1E-14). I'll keep looking at it, but for now I think just avoid non-sequential event termination conditions with event duration of 0.0.
  14. Arrowstar
    Issue resolved for next release. This was a weird one... Can you provide me a MAT file that demonstrates this? I tried on the last file you provided but I couldn't reproduce. Yes, added for next release.
  15. Arrowstar
    These are all resolved. Thanks!
  16. Arrowstar
    No, you're correct. The value in there is actually for a particular geometry that I came across a while ago. In any event, it's a good idea, I've changed it to 0.3. Also! I updated the download for pre-release 5 to include the draft of my Eve Sample Return tutorial for Launch Vehicle Designer. I would definitely appreciate a few others looking at it and providing feedback. Thanks! I'll take a look, thanks for the report.
  17. Arrowstar
    Here is KSPTOT v1.6.3 pre-release 5. The change log: Mission Architect: Added line width to Other Spacecraft; LVD: Reverted some performance optimizations because they were causing issues with tank states; LVD: Fixed issues with computing throttle in graphical analysis @Drew Kerman this should resolve the issues you've identified thus far.
  18. Arrowstar
    Issue resolved for next release.
  19. Arrowstar
    Yes, it's in now. I need to build a new pre-release but it'll be in there. Unfortunately, this behavior is not possible with the non-sequential events because they can be executed more than once. I also don't store the time at which those events execute. They basically operate like interrupts on the main events in order to "do things" in the middle of a sequential event. I'll take a look tonight. My initial reaction is that your pitch rates should not be on "altitude" events (at least, not until your ascent profile is very stable and you switch to these) because if the optimizer screws up the ascent and you go crashing down, you might not reach a particular altitude and then the code will spin its wheels until it either hits the minimum altitude or the maximum simulation time is reached. Use time instead, it'll be more friendly to the optimizer and the goofy decisions it might make early on. EDIT: I was curious and took a look. The error you're seeing is a bug in some optimizations I wrote for pre-release 3 or 4. I'll take a look tonight and see if I can't figure out what's going on...
  20. Arrowstar
    This is great, thanks! Where are the MachConvectionFactor, MachConvectionDensityExponent, and MachConvectionVelocityExponent defined? Are there "typical" values for these quantities? Also, if I'm reading this right, the expression you provided is the heat transfer coefficient for hypersonic convection. There must be an expression then for the heat flux or heating rate of a body that uses this, then? Could I see that, too? Those are really what I'm after. I'm honestly very pleasantly surprised that KSP uses such a detailed heating model. Great work to the people who put it together.
  21. Arrowstar
    As long as the event termination is 1.0 second, then the timer will stop at that time within a few nanoseconds (well, specifically, it will be related to your integration tolerances). So no, it won't be a problem.
  22. Arrowstar
    Either approach is acceptable. I actually thought I had a "reset timer" action in there but apparently I don't. The single timer to 2 seconds might be slightly faster from a propagation perspective but it should only be a minor difference.
  23. Arrowstar
    Can you try to reproduce the error on KSPTOT v1.6.3 pre-release 4? After I made those fixes from earlier, I was unable to reproduce this error, so I'm hopeful that I resolved the issue. Also, I did confirm that both the atmospheres of Kerbin and the Sun are goofed up (AKA missing) in that LVD MAT file you provided earlier. The other atmospheres look okay though. Not sure how that would happen...
  24. Arrowstar
    Can you send me the bodies.ini file?
  25. Arrowstar
    Issue resolved for next release. These two issues are related. Your celestial body data is invalid. Your bodies.ini file has an altitude height of 600 km but no data for the atmosphere's pressure or temperature curves. This is causing the error. I'll put a check that if the required data is missing, then the pressure/temperature returns 0.0. But the real fix is that the bodies.ini file you're using needs to be fixed by adding the atmosphere curves that are missing. Should be fixed now. Please go ahead and add what you'd like!
×
×
  • Create New...