Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,558

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    Oh got it. All powered gravity assist maneuvers in MFMS occur at periapsis, so you can use that as your timing.
  2. Arrowstar
    I don't believe the bounds have ever updated actually. There are some reasons why that doesn't happen, mostly due to the annoyance of making sure that the lower bound stays lower than the upper bound. There is no time information associated with the burns in MFMS because there is no thrust and Isp information in the tool. It's delta-v only. You turn those delta-vs into burn durations when you bring them into LVD or MA.
  3. Arrowstar
    I couldn't duplicate this in a simple case. Can I see the MAT file and get details steps on what I need to do to reproduce it?
  4. Arrowstar
    There are a few things here. Keep in mind, though, that the "right direction" is ultimately determined by the optimizer and it may not be in the direction you expect! Give it the benefit of the doubt some times. That said: Scale all of your constraints as I've described above; If using the FMINCON solver, use the option that computes your finite difference step sizes for you; and Bound your variables and add constraints to eliminate regions of the solution space that are not desirable to you. Let me know if you have any questions with any of that.
  5. Arrowstar
    What do you mean by "go in the right direction"?
  6. Arrowstar
    It's the other way around. The naming is unfortunate (but also industry standard): scale factors divide the quantity the optimizer sees. So scaled_constraint = raw_constraint / scale_factor. It makes sense to do it this way, though, because often times we're trying to scale down a value and it's just more straight forward to input a large number we can easily guess than a small number we can't. Scale factors should generally be selected so the value of the scaled constraint is on the order of 1.0 or so. A bit less or a bit more is fine obviously. What you're trying to avoid is having all of your constraints be different orders of magnitude.
  7. Arrowstar
    I was able to get something that satisfied the constraints by: Enabling the checkbox on the delta-v action dialog box that subtracts mass; Changing the objective function to be maximize total spacecraft mass; Setting appropriate scale factors on the constraints; and Using the NOMAD solver with parallel processing enabled. FMINCON doesn't do a great job with this problem. As I said above, try NOMAD. Yeah, so with this one, you somehow managed a bug that should have been impossible lol. There was something goofy going on where the cached inertial reference frame for Kerbin was actually Sun-centric instead. I have no idea how that happened, but a quick change to the code to make that property transient (meaning it has to be regenerated on each save/load cycle) corrected the issue. Here's your updated MAT file back with my changes. Let me know if you have questions!
  8. Arrowstar
    Tonight I've built KSPTOT v1.6.8 pre-release 4. Here's the change log: LVD: Added a flight path angle event termination condition. LVD: Added a new "vector magnitude" constraint type. LVD: Added a new "angle magnitude" constraint type. Please let me know if you have any questions or find any bugs. Thanks!
  9. Arrowstar
    It's not just vectors in LVD the way it normally is in MA. In LVD, almost everything is done with finite burns. This is why there are actions to turn engines on and off, throttle controls, etc. It can get tricky to compute DV for events in LVD because you can't be sure if every engine running is actually on (what if the tank is out of fuel?), plus you can potentially have a variety of engines running with different flow rates and Isp. It's not impossible but it's a lot harder than MA.
  10. Arrowstar
    That's one way, yes. But I'm going to do you a solid since you really seem to want to have your event terminate at periapsis. I've added a Flight Path Angle event termination condition to LVD. You can use this to terminate the event at periapsis MUCH more cleanly than true anomaly. At periapsis, flight path angle is 0 degrees and is increasing. Use these two things in your event and you'll be all set. I'll try to build this today or tomorrow and push out v1.6.8 PR4 with this in it this weekend. It doesn't. It's a bit more complicated to this in LVD because of all the different engines that can be running at the same time, each with their own Isp and flow rates (not to mention throttle and all the different tanks). I would work with mass directly if you have a vehicle roughly designed or use one of the other Maneuver Planner tools in KSPTOT (such as the Multi-Flyby Maneuver Sequencer or the like) to get delta-v, if it applies. Alternatively, you can always spit out tank masses to a CSV file using Graphical Analysis and do your own delta-v calculations in Excel if you're savvy enough and the vehicle isn't too complicated.
  11. Arrowstar
    Not quite. Use constraints instead and set the bounds to be whatever you want them to be for that quantity.
  12. Arrowstar
    You're running into a case where the true anomaly target you want is too close to the discontinuity at 0 degrees and the integrator is getting confused. There's not much I can do about this except suggest using a smaller maximum integrator step size or smaller integration tolerances. That said: I cannot recommend enough avoiding the true anomaly termination condition in particular and most of the non-duration event termination conditions in general. Things can get numerically very unstable with these just as a matter of physics. Time is the only genuinely stable parameter to target orbit propagation with except in a small number of very limited cases. Trust me (and my professional experience) on this one: you will save yourself headaches down the road by only using the Event Duration termination condition in LVD.
  13. Arrowstar
    There's definitely nothing wrong with letting the code figure out the best place, so long as you get close. You can also always just set a true anomaly constraint at the end of your event and let that handle it if there's a definite place you want your maneuver. But the optimizers are pretty good, so as long as you get close, they should figure out the best spot on their own without much effort. I'd need to see the MAT file for the second thing you mentioned.
  14. Arrowstar
    Going to a true anomaly of zero is actually pretty tricky because of the 360 -> 0 discontinuity there. I would ask yourself if you really, truly need to propagate to periapsis. What are you trying to accomplish by doing that? Is it something that you can just let fall out of the optimization naturally? Same thing the "leave Kerbin SOI" event: do you really need to propagate to that or can you just coast for some period of time and let the SOI transition happen naturally?
  15. Arrowstar
    You can change the event termination condition to true anomaly and set it to 0.0 deg.
  16. Arrowstar
    When I went to go optimize, I saw this first thing in the log: This is definitely going to be the problem. One of your variables is probably right on a bound. Figure out which one it is and push it to be just inside the bounds. Also, I noticed that you had your optimization objective function as minimize distance to body and a constraint for periapsis. This is a bit redundant. I would consider switching your objective function to Maximize Mass. In general, I think LVD is the superior tool for just about everything at this point. Yes, it's more complicated, but it's worth the learning curve in my opinion. Take a look at the examples I provide and see if you can't figure out how they work, and then go try to do you own stuff.
  17. Arrowstar
    Okay, there's a bug in the dynamic pressure calculation in GA. I think I've got it isolated and I'll fix it tonight or tomorrow. EDIT: Nevermind, what I thought was wrong is not wrong. The search continues. EDIT2: Okay, here's what I think is going on, and why I think this isn't a problem. At 61.366 seconds, the vehicle in your MAT file hits a point where the slope of the atmospheric density curve (which, remember, is a piecewise linear curve as far as KSP models it goes) changes drastically. This point in time is also when the dynamic pressure curve starts ascending again. I'm going to chalk the "double hump" nature of the dynamic pressure curve to this, then. And since KSP models the atmospheric temperature and pressure using piecewise linear curves, I think it's "accurate" as far as KSP goes, even if it's not in real life. What do you think, @Drew Kerman?
  18. Arrowstar
    This afternoon I've build KSPTOT v1.6.8 pre-release 3. This PR has a bunch of new features that I'm looking forward to sharing. Here's the change log: LVD: T2W throttle model now checks minimum throttle T2W as well as maximum. LVD: Sim Driver now warns if integrator output event index (ie) is empty. LVD: When editing non-seq events, the event UI now greys out any non-relevant widgets. LVD: New geometry type: Angles. Angles measure the angle between other geometric objects. Right now there are angles between vectors and angles between a vector and planes. Angles can be viewed in the LVD view area. LVD: New geometry type: Planes. Planes are infinite, flat, 2D surfaces that run through a point and are perpendicular to a vector. There are two plane types: Planes formed from a vector and point, and Planes formed from three points. Planes can be viewed in the LVD view area. LVD: New "plane to point" geometric vector type. LVD: Added new Sum of Sines steering model. The Sum of Sines steering is particularly interesting. The model is a set of sine waves, each with their own amplitude, frequency, and phase shift. The number of sine waves is user-defined and each sine can have any of its parameters optimized. There is also a constant offset parameter that can be optimized. Here's an example of what I'm talking about: Why is this cool and helpful? Well, first of all, there's an idea out there that any arbitrary function can be defined as a sum of sines. (I believe this is known as a Fourier series.) Using this functionality, it should be possible to create complex steering models that can be far more flexible than polynominal steering. How complex? Well, here's a one event low thrust burn from low Kerbin orbit to KEO using the above sum of sines steering model. (Thrust is only 0.25 kN!) This would not have been possible with any of the previously existing steering models. I will note that optimizing the various sine values is best done with the NOMAD or patternsearch optimization algorithms. Once you get close with that optimizer, though, then FMINCON is perfectly happy optimizing something like the above. Please let me know if you find any bugs or have any issues in this new PR. Thanks, and happy orbiting.
  19. Arrowstar
    The final state does correspond to event 7. The issue is that your two coast segments both say to go to a true anomaly of 0, but event 4 is already at 0 and the Event 6 DV is all zeros, so there's nothing to be done. That's why they don't propagate out in time further.
  20. Arrowstar
    Okay. And can you describe for me what you wanted to do, what actually happened, and how I can reproduce the issue? EDIT: I couldn't reproduce any hanging while optimizing, but it did take a while because the optimizer step size got pretty small in the last iteration. This is probably because the constraint values aren't well scaled, which is sort of a flaw in the way MA is set up. I might encourage you to go give Launch Vehicle Designer a try. Despite its name, it's really an all-around better spacecraft mission design tool, and can help you avoid some of these issues.
  21. Arrowstar
    Check out the "lvdExample_TwoStageToOrbit.mat" example that's included with the main KSPTOT download. It's not a single stage to orbit like you're asking, but I think it's close enough to illustrate what you need. Let me know if you have any questions with it. Can I see the MAT file?
  22. Arrowstar
    Thanks for the reminder! At this point it'll be next week, but I'll look into it. It is not, sadly. LVD case files are basically made up of objects instatiated from user-defined classes, and there's no way to export those in a reasonable manner to anything other than a binary format like MAT. This is also why you're running into issues with trying to read the file externally: it's basically just a bunch of pointers with some data here and there that MATLAB can understand with the help of the class definitions (which you don't have). You're not going to be able to open LVD MAT in Octave or Scipy or anything like that. Yes, there is a warning in the warning/alerts area that tells you if variables are near their bounds. Yes, this option is under the settings menu in the main LVD UI. I've never considered this, but it's theoretically possible. The difficulty lies in copying the miriad of underlying objects that make up the event, and that could be pretty tedious. I'll consider it but no promises.
  23. Arrowstar
    I've tested KSPTOT on just about every version of MATLAB since R2019b and I've never had an issue with backwards compatibility thus far. I'm not saying it can't happen, but I haven't seen it. In general, KSPTOT should work fine on newer versions of MATLAB.
  24. Arrowstar
    If you have MATLAB R2017b, the executable should just work. If you have a version equal to or greater (newer) than R2017b, you can pull the source code off github and run it directly (projectMain.m).
  25. Arrowstar
    It's not deprecated, but it's also not under active development anymore. I still release bug fixes and the like for MA from time to time as needed, but LVD has quickly become much easier to maintain and expand. MA still has a place when you need very quick, analytic two-body propagation and impulsive delta-v in a simple trajectory, but LVD is generally what I've been recommending to people now.
×
×
  • Create New...