Arrowstar

Members
  • Content Count

    1,741
  • Joined

  • Last visited

Community Reputation

620 Excellent

1 Follower

About Arrowstar

  • Rank
    Astrodynamicist

Recent Profile Visitors

2,121 profile views
  1. Thanks for the info! The parallel workers (the ctfxlauncher processes) are only used for optimization, so it makes sense that you only see minimal activity from them when you were just running the script. If you take that example MAT file I provided and start optimizing it, you should see those eight worker processes begin to do something.
  2. Hi everyone, Tonight I've built KSPTOT v1.6.2 pre-release 4. This is primarily a bug fix and performance improvement release, and I think we're nearing the v1.6.2 official release. As with before, this pre-release includes both Windows and Linux builds. Here's the change log: Added a few more Graphical Analysis tasks to Launch Vehicle Designer (LVD): "Two Body Impact Latitude", "Two Body Impact Longitude", and "Two Body Time to Impact" These provide information on where your spacecraft would impact the current central body under the influence of only two body gravity. Works well as an initial estimate for stage disposal impact points (because here everyone cares about not dropping stages on populated areas, right?). Fixed bugs reported here since last pre-release. A number of important performance improvements that should be noticeable. Please let me know if you find any bugs or issues in this release. Thanks! Also, could I ask a favor from people using the new pre-releases? I'm trying to get a feel for what sort of performance everyone is seeing on their systems in LVD. If you'd like to help, please do the following and report back with results to this thread. Either Windows or Linux platforms are fine. Download and run KSPTOT v1.6.2 pre-release 4. Open Launch Vehicle Designer. Load the "lvdExample_asparagusStagingToMun.mat" example included with the pre-release package. After it loads, use the Simulation -> Run Script menu command (or just ctrl-p, it does the same thing) five or six times. Basically just run the script with no changes five or six times. Report the lines in the output window that state how long it took the script to execute here in this thread (in a quote or code box). When you report, please include your CPU model (or number of CPU logical cores and CPU clock rate) and amount of RAM onboard your system. If you know them, of course. Thank you!
  3. Hi everyone, Here is a link to KSPTOT v1.6.2 pre-release 3. This file is about twice as big as the previous pre-releases as I wanted to push out a Linux v1.6.2 release to see how that goes for people. Feel free to delete the files you don't need after downloading. The change log is pretty straightforward: LVD: Added "extrema" to allow for recording and constraining of minimum and maximum values of various quantities. Lots of bug fixes as discussed above. Please note that if you're a Linux user and you don't have the MATLAB Compiler Runtime installed, you need to install it at "/usr/local/MATLAB/R2017b/ " for the software to work. Please let me know if you find any bugs or problems. Thanks! I think I actually just fixed this bug in the latest v1.6.2 pre-release, so check out what I just posted. And yes, that's all it does is rerun the optimizer with the last settings. It's a convenience, nothing more.
  4. Thanks for the file. I took a look but didn't have much luck that was better than you. I did notice that since it's your eccentricity (or really, SMA, since with the radius of periapsis constraint in there, they are one in the same) that won't come in, you might consider adding another course correction maneuver just before arrival to Eve's SoI. Or, just insert the 32 m/s Eve departure burn and let that try to make up the difference. You'd need to remove the constraints on the inbound Eve orbit and put them into the outbound Eve orbit. That's better practice anyway, really since if you've got the time and outbound orbits figured out, then it really doesn't matter much. Also keep in mind that the MFMS output makes the infinitesimal SoI assumption, so those outbound/inbound orbits are only approximate anyway. If you can't get a constraint to come in, you can always drop it and try to let the optimizer figure out the mission without that constraint. Let me know if you have any more questions!
  5. I have been working on something for a bit now that I can finally share! In Launch Vehicle Designer, one thing that has not been capable up until now is to look at the minimum or maximum values of some quantity. For example, want to constraint maximum dynamic pressure during your lift off and ascend? This is not possible in KSPTOT v1.6.1. However, it is now. I call the new feature "Extrema", as that's what they are. These are plots of dynamic pressure. The top is the straight up quantity: it is the time history of dynamic pressure during some ascent from Kerbin to orbit. The bottom plot, however, is the time history of the maximum dynamic pressure. This means that as dynamic pressure goes up, the maximum keeps increasing. However, after the peak dynamic pressure (when dynamic pressure starts dropping), the maximum stays up where it was at the peak. This allows you to set constraints for, say maximum dynamic pressure or minimum altitude or any such thing. Just about every quantity in the Graphical Analysis tool is available for use as Extrema, and of course both minimum and maximum extrema are available. I look forward to seeing how the KSPTOT community makes use of this.
  6. I wouldn't worry too much about triggering inferior SoI transitions. Work on setting up the SoI transition you want first and make it stable so that perturbations to the script don't send you somewhere you don't want to go, and then use the "Go to Next SoI transition" event. As far as what you're talking about with the function value... you could do something like that in theory, but it'd be pretty touchy and prone to failure I think. Best to not use the Central Body ID stuff as much as possible (because it has no slope or anything to help the optimizer key off of). You can minimize delta-v by using the "maximize spacecraft mass" objective function. It does the same thing in the end. It's not a dumb approach at all actually. I do something like that myself. Just use the maximize spacecraft mass objective function and you should be all set.
  7. The issue in the 4x example case is that the initial state for the SRB-S engines 2, 3, and 4 is "inactive". This causes the runtime on the script to be 4x longer. The script terminates because the minimum altitude of -1 km is reached. This is configuration in the integration settings. I'll try to put a warning in for this for the next release. EDIT: Done for next release.
  8. Assuming I wanted to go the second route and have Linux users create a symlink as you described, could you provide me some easy to follow instructions I can post in the OP of this thread for them to follow? Yes, this is a known bug with MATLAB. You'll need to disable HiDPI scaling for KSPTOT in order to get things to show up correctly. There's not much I can do about it. Sorry! MATLAB's fmincon function, which is the most full-featured optimizer in the package, treats the objective function and constraints differently. I could dig into the algorithms more, but that's the gist of it. There isn't a way to change the weighting in Mission Architect (it tries to pick it intelligently). It Launch Vehicle Designer, constraints do have a scale factor you can set that works essentially as you described. Implemented for next release.
  9. "Standard" model error resolved for next release. Yes, I could do this. Would not be hard. I'll implement it for v1.6.2. Ground Station tab order issue resolved. Yes, there is! Right click on any area that holds an orbit and you should see dialog boxes for importing the orbit from either an SFS file or from KSP using the KSPTOTConnect plugin. Yeah, something is goofy with that. I'll have to see if I can't build it with that file included or something (though it should be in the MCR... so I'm not sure what the deal is). If there's not a way to resolve this by changing the way that MEX file is built, any suggestions for something I can include in the download ZIP to handle this directly? I really don't have much Linux experience...
  10. Go ahead and redown the package I linked to above. That should resolve the issue. Please let me know if you find any more problems!
  11. Yes, any periodic "wobbling" around a vector will cause the vehicle to not gain as much altitude as it would otherwise. This is because when it spins some thrust goes into a vector component not along the velocity vector, and half a revolution later, that component is canceled out by an equal but opposite component. Energy is wasted on each revolution. It is okay to refer to Yaw as Heading in that case because, given the way I've defined it, yaw actually is heading in that context.
  12. Well, it's not pretty, but... @CraigCottingham, if you're interested and able, I'd like to tap you to test out the Linux version of KSPTOT, assuming you can? EDIT: It lives! (As a deployed Linux application.) EDIT 2: For anyone who wants to try it out, here's the link to KSPTOT v1.6.1 Linux. Please make sure you read the readme file, as it explains how to actually run the application via the .sh script and what argument needs to be passed to said script for it to run.