Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,557

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    Okay, so I was able to resolve the issue with holding down the arrow keys causing a massive mess that would take minutes to work out. Unfortunately, I can't resolve the issue with the few seconds delay when you move the slider around a lot. This looks like some internal MATLAB slowness that I don't have access to. It'll have to do for now. Should be resolved for next release. I could create a checkbox to either plot all data with the selected color or plot all data with the event colors. How does that sound? So here's the choice: we can either make the sun dot normal caching stuff transient, meaning that it won't save to file but you'll have to regenerate it each time you open it, or we can leave it as is and get big files. Do you have a preference? EDIT: Never mind, I'm making it transient. It'll reset the cache on load to empty, but it'll not start the cache from 0, which is what's going on with you, but with the first time in the first integration time step, which makes way more sense and will eliminate the super long first run time in most cases I think.
  2. Arrowstar
    Generally if you right-click on text boxes designed to input time in universal time seconds, you'll get an option to enter the time as a date/time, and it will do the conversion for you. I think this will basically do what you're looking for here. There is not, I'm afraid. I generally only promise to support stock KSP, so you'll have to do the math for that outside of KSPTOT and plug it in yourself.
  3. Arrowstar
    I'll take a look. Thanks for letting me know. Okay, so the issue is that the master list that tracks variables got out of sync with some variables in use in the initial state and one of the events. Do you know when variables stop showing up in the Adjust Variables drop down menu? Or how I can reproduce that? This is going to be tricky to fix without any idea of what causes it. Yeah, I've seen that delay. Basically when you move the slider around, all of the callbacks to that slider are still getting called, even after the slider has stopped moving. I have logic to check for this and dismiss the callback before it does anything CPU intensive, but I honestly don't know how to kill the callbacks entirely. Sure, that'll be easy I think. Just for LVD? The arrow buttons are for moving around between Mission Segments (basically SoIs) when you use the "View by SoI Grouping" event plotting style in the View Settings. This is the classic way of viewing MA and LVD data, though I much prefer the "View All" setting these days (in which the arrow buttons do nothing useful).
  4. Arrowstar
    Yeah, this is a one time event to build the SunDotNormal cache for Kerbin. Now that I have a use case, I'm going to try to speed this up a bit before the 1.6.6 release. Try turning the pitch rate variable off and on again. That should reset it and it'll show up in the list. I'm not sure why it's not showing up now, to be honest. I looked into it briefly this morning and couldn't see anything obvious.
  5. Arrowstar
    Alright, I know what happened. MATLAB has a built-in function called "lambert" in the Mapping toolbox and I have a function called "lambert." In "normal" MATLAB, my function took precedence over the builtin function, but in the deployed version I've started building, for some reason I don't understand, the builtin function takes precedence. The issue occurred when I started using a Mapping Toolbox function in KSPTOT and the whole toolbox got imported into the software. In any event, I've come up with a fix that appears to work and we're off to the races again. Speaking of which, I have rebuilt the PR9 executables and re-uploaded them in the same ZIP file as before. Go ahead and download those. They contain all of the fixes that we've discussed today. If people could verify that their issues are now resolved, that would be great. Thanks! EDIT: Give it 10-20 minutes from the time of this message to give the new ZIP file time to upload, it's taking a bit longer than I thought. And yes, Windows and Linux executables are both in there. EDIT: And it's uploaded.
  6. Arrowstar
    Yes, it can be useful to change the drag coefficient during a mission. If the vehicle geometry changes substantially, so will the drag coefficient. Ooo forgot about one, whoops. You're probably zoomed in too far. Right click on the display and click revert to original view or something to that effect. LVD now remembers your zoom and pan settings when updating the display, and if your display was originally zoomed in (because there was no trajectory there or otherwise) then you'll probably see what you're seeing.
  7. Arrowstar
    This issue related to caching of the SunDotNormal factor used for computing atmospheric temperature. There was an out of memory error thrown if you advanced the date too far into the future. I've split up the calculation now into manageable chunks which should not have this issue. Resolved for next release. I couldn't reproduce the two Event 0 entries issue. The disappearing bar for event 5 was because your variable value was outside of the bounds. I now check for this and handle it correctly (variables must be inside bounds lol). This is resolved for next release. This was a one-line bug that I have found and resolved for next release. And yes, the checkboxes are global because you can select as many different ground stations to show at one time as you want. It's a multi-select listbox. I mean, I'm sure I could find a workaround, but in general, when you create a new Edit Drag action, it creates a new drag model under the hood with new drag coefficients and areas created. I could split up the action into two actions: drag coefficient and drag area if that would be helpful? So... I know what is causing this error but not why you are getting it. For some reason, the software isn't finding the compiled lambert solvers I built when I generate the deployed version of the software, and it is instead defaulting to a built-in MATLAB function called "lambert", hence the funny error. I'll investigate but I'm not sure what else I can do, especially since I don't get the error on my end. Let me poke at it though and see if I can't uncover anything. Clearly this worked before... I believe this has been resolved now for the next release. This actually isn't an error/bug, believe it or not. If the constraints on a problem are too tight, patternsearch will look for a viable solution for a very, very long time before ultimately giving up. I wouldn't use pattern search with equality constraints (lower bound == upper bound) or where the difference between the upper bound and lower bound is small.
  8. Arrowstar
    Okay I see this now, I'll take a look.
  9. Arrowstar
    Which other issues besides the Out Of Memory error that was showing up in the other MAT file?
  10. Arrowstar
    Thanks for the link, I think I've got it figured out. Yes, I'll look into putting in half life for RTGs. Should be fairly straight forward. I found the bug in the case file you sent, thanks for that! I've got a fix implemented, will be in the next release.
  11. Arrowstar
    You found a typo... I'll recompile and reupload. EDIT: I've recompiled the Windows version and reuploaded. Linux is still on the way.
  12. Arrowstar
    If you can provide me with some information regarding how that decay is modeled in some mods, I can incorporate it, sure.
  13. Arrowstar
    Hi KSPTOT community! Tonight I've built KSPTOT v1.6.6 pre-release 9. Aside from a number of bug fixes over the previous PR8, the major feature of this pre-release is the initial cut of electrical power systems modeling capability for KSPTOT Launch Vehicle Designer (LVD). I want to give a provide a basic overview of what EPS modeling is, what's involved, and what you can expect. As requested, this build was done in both Windows and Linux. Apologies for the larger download size that is a product of this. (By the way: I had issues with the Linux VM I use to compile the Linux version being very, very, very slow tonight and I couldn't even get the software to start because of it. If KSPTOT doesn't start on Linux, please let me know. If you're new, be aware that you need the MATLAB Compiler Runtime R2017b installed for whatever your OS is.) There are three new types of components that can be added to launch vehicles: power sinks, power sources, and power storage. Power sinks remove electrical charge (EC) from batteries in much the same way that engines remove fuel from tanks. You can use these to model components of your spacecraft that use power, like antennas, capsules, etc. Power sources provide electrical charge (EC) to your batteries. There are three types of power sources at the moment: RTGs, fixed solar panels, and rotating solar panels. RTGs provide a constant EC charge rate. Fixed solar panels are oriented in a fixed way in the spacecraft body frame and point only in that direction. Rotating solar panels rotate about a fixed rotation axis in the body frame and, like in KSP, always orient to be closest to the Sun vector. Power storage at this time is just batteries, which storage electrical charge. Batteries are required for the EPS modeling engine to do anything during simulation runs. If batteries are full, the charge rate of the vehicle will drop to 0 and if batteries are empty, the discharge rate of the vehicle drops to 0. You'll notice that rocket engine alternators are missing at this time. I'm considering those for Phase 2 of the EPS modeling engine, but I wanted to get the basics out the door for the upcoming release first. Engine alternators can be approximated by using RTGs with the correct charge rate associated with whatever throttle you're flying at for the time being. With this system there a bunch of new functionalities you will see in LVD: Graphical Analysis has been updated to show you both component and vehicle level EPS information, including power source charge rate, power sink discharge rate, and power storage "state of charge" (how full the battery is). Vehicle level state of charge can be used as a constraint and objective function. Vehicle net charge rate and total state of charge can be used as event termination conditions and optimized like any other termination condition. Event actions now exist to toggle the active status of all three types of EPS components. This works exactly like it does for engines, stages, etc. Finally, a new steering mode exists called Generic Angles Steering which allows you to specify the reference frame and angles you which to use generically. For example, you can set your vehicle to steer relative to the Sun North-East-Down frame and then set pitch to -90 degrees. This will point the nose of your vehicle towards the Sun regardless of where you are in the solar system. A warning: Solar panels are a bit slow right now, even if I've spent days optimizing their code to run faster. This is because I have to find the position of the spacecraft relative to the Sun at every time step, and I also have to find the position of nearby celestial bodies relative to the Sun at every time step too, in order to look for eclipses. Sorry about this, I'm working on trying to improve performance more, but the low hanging fruit has generally been taken care of at this point. To conclude, I'll leave you with a few screenshots that show off how the system works.
  14. Arrowstar
    SQP and Interior Point are probably the two solvers to try first. All of them are gradient-based methods. Active-Set is generally considered to be outdated and should only be tried when everything else fails.
  15. Arrowstar
    Thanks for finding that bug, I know what was causing it and I've corrected it for the next release. I'm also glad that the parallel pool starts correctly.
  16. Arrowstar
    I think I've got a fix. Can you please take a look at this rebuild of the debug pre-release I put out earlier today and let me know if it resolves the issue? I usually don't because it can be kind of a hassle and the vast majority of KSPTOT users are on Windows. I'd consider it, though, if you're interested in testing the software on Linux.
  17. Arrowstar
    I'm glad to hear it's working. I still need to understand why your parallel processing pool isn't starting normally, though, so if you have Dropbox, Google Drive, or anything like that, and would be willing to share a link to a MAT file, that would be awesome. EDIT: Actually, stand by, I'm going to provide a new build of KSPTOT with some debug output around the MA and LVD parallel start functionality. I think I know what is causing the issue, but I need to be sure. If you could download the new build when I post it, run it, and try to start parallel computing. It should fail but a message should be written to the ksptot.log file. Please share what's in the log with me. Thanks! EDIT 2: Here's the link: https://drive.google.com/open?id=1Uv0mDhLwInq8rhHtXRKgeEd5a1Upo_RG&authuser=hardena%40alumni.msoe.edu&usp=drive_fs Please be aware that there's a bunch of in-work code in LVD, so don't look too closely at any bugs or whatnot you see that aren't related to the parallel pool stuff.
  18. Arrowstar
    You don't have a parallel pool started, and so the parfevealOnAll functions are throwing an error. Can I see the MAT file that generates this error? I might need to look into a bug fix. The other thing you can do is create a new LVD case, open up the plugins, create a new plugin with the following code, and set it to run before propagation. This should start a parallel pool or hopefully throw the reason it's not starting to the KSPTOT log file. pp = gcp('nocreate'); if(isempty(pp)) parpool('local'); end What would be useful to see is thrust vs atmospheric density. If there's an issue with how thrust is computed as a function of density, that'll do it. I think I'm just doing a linear interpolation of thrust on the two densities that are requested (1 atm and 0 atm), because that's what the game shows, but if it needs to be more complicated than that in order to match KSP under the hood, it can certainly be made to work that way.
  19. Arrowstar
    I can look into adding JNSQ's time system. Is the only difference between that and Earth time the 12 hours = 1 day thing? First, if you haven't tried running the latest pre-release of KSPTOT (should be v1.6.6 PR 8), download that and give it a try. It might resolve the issue with starting the parallel pool. As far as optimization speed goes: yes, I know about it, and it pains me every day that it is as slow as it is. Getting the parallel pool up and running will help a lot. If you're in LVD, you can also make sure you've disabled thrust forces when the engines are all off and the drag models when not in atmosphere. That will speed up propagation. Eventually I'm going to be moving KSPTOT from MATLAB R2017b to R202xx, and I know from some trialing I've done that there is a non-trivial performance increase from doing that (on the order of 10%-15% decrease in runtime in some cases). The delay in upgrading is mostly because I'm hoping The Mathworks will add some functionality to their new thread-based parallel pools (which should speed up optimization on their own) so that I can use them with KSPTOT. They haven't yet, though. For now, @Drew Kerman is right, you just have to wait it out. Sorry about that, I know it sucks. I have an old Core i5-3330 that only runs at 3.0 GHz, so believe me when I say I experience it regularly lol.
  20. Arrowstar
    Where are you referring to? I think I've been using mT for metric ton for a long period of time in KSPTOT.
  21. Arrowstar
    Metric ton. If you're trying to model atmospheric effects, I'd highly recommend using Launch Vehicle Designer instead. It's basically Mission Architect, but far more advanced, and actually has some decent drag and lifting modeling built into it. In MA, that functionality was tacked on second-hand and never really worked out as well as I was hoping it would.
  22. Arrowstar
    I'm afraid not. I had to work out all of the SoI transfer logic myself because in general, commercial software does not work like KSP does. It's not that hard in principle though: when you get to an SoI edge, you transform your position and velocity to be relative to the new SoI you're moving into, and then you propagate with the new gravity source.
  23. Arrowstar
    So if I'm understanding you correctly, it's current altitude above the Sun divided by the reference radius? I have to admit that's really a bizarre way of defining it, since the quantities aren't the same. Maybe it's changed since then, any idea who I would ask?
  24. Arrowstar
  25. Arrowstar
    Thanks for the insight! And yes, your caveat is important, I need to keep that in mind.
×
×
  • Create New...