Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,562

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    A few things: The error you see is because the bodies.ini file is missing the parentID line for a body. You need to add that: "parentID = 0" most likely, but just grab whatever you're using for the ID of the Sun. You can load bodies files from the main KSPTOT File menu. There's no need to hack them or whatnot. Yes, LVD and MA cache their celestial body data so that changes the user makes to what's in memory at any given time don't disrupt the current mission plan.
  2. Arrowstar
    Okay, take a look now.
  3. Arrowstar
    Ah, right. Well, stand by a bit longer then lol.
  4. Arrowstar
    Okay, try downloading PR7 again and see if it works. I've updated the Windows binary.
  5. Arrowstar
    Alright, I'm working on what is hopefully a fix and I should have a new build of PR7 up soon-ish for you to test.
  6. Arrowstar
    Yeah, when LVD errors on load, you'll see that broken UI. Are you able to get LVD to properly load at all?
  7. Arrowstar
    The first warning is because I disabled the drag model when this was for the Mun, since calling that needlessly just slows the simulation down a bit. You need to turn it back on for Mars. The second (min altitude reached) is because you're crashing. Makes sense, the steering was set up for a munar mission but you're on a completely different body now. Play around with adjusting the a term in the linear tangent steering law until you get something that gets you out of the atmosphere. I have seen this before but I can't reliably reproduce it. In any event, it usually only happens once. Try starting LVD again and it should be okay. I'll keep digging into what might be causing it...
  8. Arrowstar
    Hi everyone, Tonight I'm pushing out KSPTOT v1.6.7 pre-release 7. Here's the change log with some welcome updates: LVD: Fixed bug with the time slider sucking up a bunch of CPU time after sliding it around a bunch. The missing parentID lines of the SolarSystemBodies.ini file have been added. LVD: Added a linear tangent steering model to the available options in LVD. This is a great way to get an optimal ascent from the surface of a body to space, as the linear tangent steering law is actually derived directly from optimal control theory. As of now, only "pitch" type angles can use this steering. The linear tangent steering law is: tan(pitch_angle) = a*t + b, where t is time after the steering law is initiated and a and b are constants. There is a new lvd example MAT file that shows how to use it, and best of all, shows how it can be used to get off of the Mun in a single event! I've included this in the pre-release. MA/LVD: Added a flight path angle graphical analysis task and constraint. For reasons that I still want to understand better, setting up your launch vehicle orbit insertion targets as radius/velocity/flight path angle works way better with an optimizer than asking for SMA/eccentricity or apogee/perigee. I've noticed this in my professional life too. There may be some performance improvements with computing atmospheric temperatures over the previous PR, but I've had trouble determining if they're real or not, so your mileage may vary. Please let me know if you have any questions or find any bugs, especially with the new linear tangent steering code. Thanks!
  9. Arrowstar
    Units in KSPTOT are always kilometers, seconds, and radians. (With the annoying exception of mean anomaly in the bodies.ini files, which is degrees because KSP uses degrees here). If you are inputting the gravitational parameter, it is in km^3/s^2. With your Ceres entry there, be sure you have a line called "parentID = 0" in there. Look at Earth for an example. This is a bug that it is missing from some of the bodies in that solarSystemBodies.ini file that was mentioned before. It will be fixed for the next release. What is being minimized is the sum of the flyby delta-v magnitudes, plus the departure and arrival Vinf values, if you so choose.
  10. Arrowstar
    I would need to see the MAT file to understand what's going on. Most likely you're running into a stiff section of integration where the integrator has to take small step sizes to meet the tolerances. The save button just writes the internal data structure to MATLAB's proprietary file format. It never takes more than a moment or two.
  11. Arrowstar
    PLAD hasn't been around in 2.5 years. I'm guessing yes.
  12. Arrowstar
    If you're using a modded install, then it could be that one of those mods changes the time system to something that is not built into KSPTOT. Don't worry about it too much, only the UT seconds are authoritative. The days/hours/minutes etc are just for user convenience. Issue resolved for next release. Thanks for the report! You're not going to be able to use true anomaly to place your burn "exactly" in KSP. You can eyeball it, which I think you're doing. You can also take that burn plan, but it into Mission Architect or Launch Vehicle Designer, and re-optimize the burns to achieve the trajectory you want without the zero-sized local gravity well size limitation that is present in MFMS in there. The former will be way easier but will also involve some playing around with the burn parameters in order to actually get what you want. The latter is exact but will take a fair bit of time and practice. I optimize the departure burn location in MFMS to determine the best place to center the delta-v of the burn. There is no way to recompute the burn in order to place it at a different point in time or along the pre-departure orbit. It would be sub-optimal there anyway. Hope that helps! Let me know if you have any other questions.
  13. Arrowstar
    In other news, I finally fixed the stupid issue in LVD where if you slid the time slider around a bunch, it would freeze the UI for a long time. You're welcome, everyone. Okay, so something outside of MATLAB and KSPTOT is wiping those files it sounds like. You'll have to do some digging on your end. It could be anything I suppose...
  14. Arrowstar
    I'm not really sure to tell you. Yes, there should be lots of files in that directory. If they're being deleted, it's because something on your PC is deleting them. Is there maybe some anti-virus software that's misbehaving? Do the files stick around after you close KSPTOT once? Are they still there if you restart your PC?
  15. Arrowstar
    Right, now that the PR is out, is there anything anyone has brought up in the past few months that I haven't already addressed? @Drew Kerman?
  16. Arrowstar
    I've just uploaded an updated ZIP file with a Linux binary in there.
  17. Arrowstar
    Alright, here is KSPTOT v1.6.7 pre-release 6. Here's the change log: LVD: Drawing plots should be faster when plotting other celestial bodies. The slow multiprocessing stuff from a previous pre-release is gone here. LVD: Added a feature to output the wall clock run time for each event to the ksptot.log file upon propagation. See Settings menu.
  18. Arrowstar
    I have some debug code in LVD that I use to help me understand bottlenecks. It never occurred to me until tonight that others might find that useful, but I can see now that it could be. I've added a feature to the upcoming PR6 that will allow those event propagation wall clock times to be output to the KSPTOT.log file. Yes, using ODE5 will give slightly different answers, but the result should still be acceptable. If you need accuracy, then generally ODE45 or any of the other adaptive step size are the go to, but sometimes the internal step sizes get really small and things take forever. In those cases, use ODE5 and select a step size that is reasonable for the time scales you're working with. Anything that speeds up script execution also speeds up optimization, so should be both. Stiff problems show up when the time scales of the functions being integrated are very different. In our case, this usually means cases when lots of drag is involved, especially in cases where the vehicle has reached terminal velocity. Yeah, I do allow a variety of input values for ease of use, but the constraint codes do have to output values in a specified range. It happens that MATLAB tends to return things in 0-360, so that's what I do. Remember that you can perform math operations in numeric text boxes, so if you need to add 360 to something, just type "<num> + 360" where <num> is your number and it'll do the addition for you. Also, it's taking an hour to run? That's a bit insane. Are your constraint values at least getting close to a small (~ 0) number? I'll take a look, thanks! So it was working, and then nothing changed, and then it stopped again? That is... odd. Please follow the instructions in the Accepted Answer area of this webpage and see if it helps any. Thanks! https://www.mathworks.com/matlabcentral/answers/98050-why-do-i-get-an-error-saying-undefined-function-or-variable-matlabrc-when-executing-a-program-th
  19. Arrowstar
    I see two issues: Events 3-5 are taking forever to propagate. Consider moving to ODE5 as an integrator to seriously speed this up. Your constraints are -40 but the indicator in the bottom right shows that the constraint value is +320. You need to add 360 to your constraint values. That's all I've seen for now.
  20. Arrowstar
    You're welcome! It's my pleasure. KSPTOT v1.6.7 pre-release 5b with fix in MA for bug in computing position of spacecraft wrt to Sun.
  21. Arrowstar
    Hey everyone, sorry for disappearing for awhile. Life got busy and I needed a creative break as well. Hopefully I can look at some bug fixes in the next days and weeks and resolve everyone's recently-ish reported issues. I couldn't reproduce your mean anomaly / true anomaly issue. I checked and it does look like I'm pulling mean anomaly directly. Are you sure this is what you were seeing? I'll look into this. Thanks for the request! A few things here: You're probably not going to be able to reproduce the results from MFMS in MA, honestly. Most people discount it, but the infinitesimal local gravity field assumption in use in MFMS is actually not super great with a solar system the scale of KSP's system. I mean, it gets you close, but you should never expect to be able to hit exactly what MFMS shows you. It's just a guide for more high fidelity analysis. Because of this, I'm not super surprised that your burn true anomaly and delta-v components are a bit different. Finally, remember that MA is a numerically optimized propagated trajectory and MFMS uses Lambert arcs. It could very well be that your differences are just optimizer noise or that the optimizer either doesn't have a fully optimized solution (regardless of what it reports out) or is in a different solution family due to SoI differences. Finally, for working with gravity assist maneuvers and interplanetary tours like you're talking about, I would use Launch Vehicle Designer actually. Look at some of the gravity assist example files I've included. These will work out to be much, much easier to optimizer and to duplicate (or improve upon!) what MFMS gives you. The big take away here should be that MFMS is only a low fidelity guide and your solutions in higher fidelity tools like MA and LVD will be different because of that difference in fidelity. Resolved for next release, I'll put up a new build whenever it finishes building tonight. Sorry for the delay in getting back to you.
  22. Arrowstar
    I noticed that myself when looking at your MAT file. Maybe try running the NOMAD solver on it first and see if that helps. It does a little better on hard problems, but usually takes longer to run. It could be a Linux specific thing, but it shouldn't be. I'll try to look into it tomorrow, but I have to apologize to everyone, my workload at work has exploded and along with some other things going on, I haven't had as much time to dedicate to this over the past few weeks as I might normally. Sorry about that.
  23. Arrowstar
    Could not reproduce. Are you just loading it up and tapping control-p to propagate? That's what causes the error?
  24. Arrowstar
    As a quick guess at what might be going on, select the rotation tool in the main LVD GUI and right click on the display axes, then select something along the lines of "reset to original view", should be at the top of the context menu that comes up. I noticed that part of your trajectory wasn't rendering beceause it was being cut off by z-limits. If you want to avoid this in the future, go into the view settings and select "update view limits" or something to that effect. I'm hoping that the issue is just that the trajectory looks wrong, when in reality it's fine and just the way things are rendering that is the issue.
  25. Arrowstar
    Can I correctly assume that this started after you changed the names of the propellants in the MAT file?
×
×
  • Create New...