Brian17 Posted August 5, 2020 Share Posted August 5, 2020 @Arrowstar Thanks for the quick reply! As for the .mat file, I've tried loading up a couple of the sample files into MA and get the same message. So I opened up the LVD, which I haven't played around with much, and loaded the sample Two Stage to Orbit. It immediately gave the same popup message that parallel mode failed to start. I created the plugin with that little code, and checked the log file and voila! Starting parallel pool (parpool) using the 'local' profile ... Starting parallel pool (parpool) using the 'local' profile ... connected to 4 workers. As a bonus, now when I go into MA and hit Script -> Execution Settings -> Parallelize, I get "Parallel optimization mode enabled" in the output window. While the optimization for interplanetary transfers seems marginally faster, easier ones like planetary orbits are noticeably quicker, and the program as a whole seems much more responsive. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 5, 2020 Author Share Posted August 5, 2020 (edited) 11 hours ago, Brian17 said: @Arrowstar Thanks for the quick reply! As for the .mat file, I've tried loading up a couple of the sample files into MA and get the same message. So I opened up the LVD, which I haven't played around with much, and loaded the sample Two Stage to Orbit. It immediately gave the same popup message that parallel mode failed to start. I created the plugin with that little code, and checked the log file and voila! Starting parallel pool (parpool) using the 'local' profile ... Starting parallel pool (parpool) using the 'local' profile ... connected to 4 workers. As a bonus, now when I go into MA and hit Script -> Execution Settings -> Parallelize, I get "Parallel optimization mode enabled" in the output window. While the optimization for interplanetary transfers seems marginally faster, easier ones like planetary orbits are noticeably quicker, and the program as a whole seems much more responsive. 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. Edited August 5, 2020 by Arrowstar Quote Link to comment Share on other sites More sharing options...
vitorboschi Posted August 5, 2020 Share Posted August 5, 2020 (edited) Hey guys, I'm trying to plan a science return mission to Jool and Moho using a window I've found on the MFMS. Here's the complete report for reference Spoiler Hyperbolic Departure & Flyby Orbits --------------------------------------------- Hyperbolic Departure Orbit from Kerbin --------------------------------------------- Semi-major Axis = -277.1564 km Eccentricity = 3.882508179 Inclination = 23.1729 deg Right Ascension of AN = 250.0648 deg Argument of Periapse = 356.6385 deg --------------------- Out. Hyp. Vel. Vect Rt. Asc. = -7.3871 deg Out. Hyp. Vel. Vect Declin. = 22.6760 deg Out. Hyp. Vel. Magnitude = 3.569631040 km/s --------------------------------------------- Inbound Hyperbolic Flyby Orbit to Jool --------------------------------------------- Semi-major Axis = -48429.2622 km Eccentricity = 2.464063778 Inclination = 10.4569 deg Right Ascension of AN = 37.3961 deg Argument of Periapse = 240.4379 deg Periapse Radius = 70903.5286 km --------------------------------------------- Outbound Hyperbolic Flyby Orbit from Jool --------------------------------------------- Semi-major Axis = -42438.8937 km Eccentricity = 2.6707 Inclination = 10.4569 deg Right Ascension of AN = 37.3961 deg Argument of Periapse = 240.4379 deg Periapse Radius = 70903.5286 km --------------------- Out. Hyp. Vel. Vect Rt. Asc. = 29.9475 deg Out. Hyp. Vel. Vect Declin. = -1.3706 deg Out. Hyp. Vel. Magnitude = 2.580172390 km/s --------------------------------------------- Inbound Hyperbolic Flyby Orbit to Moho --------------------------------------------- Semi-major Axis = -2.7273 km Eccentricity = 92.667272592 Inclination = 100.1756 deg Right Ascension of AN = 212.6209 deg Argument of Periapse = 78.7768 deg Periapse Radius = 250.0001 km --------------------------------------------- Outbound Hyperbolic Flyby Orbit from Moho --------------------------------------------- Semi-major Axis = -2.7273 km Eccentricity = 92.6673 Inclination = 100.1756 deg Right Ascension of AN = 212.6209 deg Argument of Periapse = 78.7768 deg Periapse Radius = 250.0001 km --------------------- Out. Hyp. Vel. Vect Rt. Asc. = 34.5154 deg Out. Hyp. Vel. Vect Declin. = 10.4362 deg Out. Hyp. Vel. Magnitude = 7.862813305 km/s --------------------------------------------- Inbound Hyperbolic Orbit to Kerbin --------------------------------------------- Inb. Hyp. Vel. Vect Rt. Asc. = 18.9181 deg Inb. Hyp. Vel. Vect Declin. = -1.3922 deg Inb. Hyp. Vel. Magnitude = 8.6739 km/s Sun-Centric Transfer Orbits --------------------------------------------- Phase 1 Transfer Orbit (Kerbin -> Jool) --------------------------------------------- Semi-major Axis = 42791228.3318 km Eccentricity = 0.694708132 Inclination = 6.7026 deg Right Ascension of AN = 303.7030 deg Argument of Periapse = 334.6690 deg Period = 51367276.6298 sec Departure True Anomaly = 25.3310 deg Arrival True Anomaly = 195.4295 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Phase 2 Transfer Orbit (Jool -> Moho) --------------------------------------------- Semi-major Axis = 36634561.3085 km Eccentricity = 0.842376511 Inclination = 1.3724 deg Right Ascension of AN = 350.7865 deg Argument of Periapse = 306.0179 deg Period = 40690301.1678 sec Departure True Anomaly = 177.0558 deg Arrival True Anomaly = 324.4466 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Phase 3 Transfer Orbit (Moho -> Kerbin) --------------------------------------------- Semi-major Axis = 38294351.6094 km Eccentricity = 0.849061098 Inclination = 1.4668 deg Right Ascension of AN = 11.9325 deg Argument of Periapse = 284.6072 deg Period = 43486703.9826 sec Departure True Anomaly = 324.7178 deg Arrival True Anomaly = 255.3928 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Kerbin Departure Date = Year 3, Day 266 07:59:10.084 (85996750.0842 sec UT) Jool Arrival Date = Year 4, Day 289 13:51:14.902 (119541074.9023 sec UT) Moho Arrival Date = Year 5, Day 181 22:07:56.892 (141775676.8916 sec UT) Kerbin Arrival Date = Year 6, Day 310 00:11:23.749 (184378283.7493 sec UT) --------------------------------------------- Total Mission Duration = 3 Years, 43 Days 16:12:13.665 DV Maneuver Information --------------------------------------------- Burn Information to Depart Kerbin --------------------------------------------- Total Delta-V = 2.8396 km/s Prograde Delta-V = 2164.0589 m/s Orbit Normal Delta-V = 1825.6530 m/s Radial Delta-V = 216.6158 m/s --------------------- Burn True Anomaly = 250.0648 deg --------------------------------------------- Burn Information to Depart Jool --------------------------------------------- Total Delta-V = 0.0000 km/s Prograde Delta-V = 0.0000 m/s Orbit Normal Delta-V = 0.0000 m/s Radial Delta-V = -0.0000 m/s --------------------- Burn True Anomaly = 0.0000 deg --------------------------------------------- Burn Information to Depart Moho --------------------------------------------- Total Delta-V = 0.0000 km/s Prograde Delta-V = 0.0000 m/s Orbit Normal Delta-V = 0.0000 m/s Radial Delta-V = -0.0000 m/s --------------------- Burn True Anomaly = 0.0000 deg --------------------------------------------- Total Mission Delta-V = 2.8396 km/s Following the same instructions found on the "Solar System Edge - MA Tutorial", I've set the initial state to be in the same plane as the Kerbin hyperbolic departure orbit: Quote Inclination = 23.1729 deg Right Ascension of AN = 250.0648 deg Argument of Periapse = 356.6385 deg Note: I see that if I later return to the initial state event, Argument of Periapse is now 0 and its angle was set to the True Anomaly instead. Is that expected? Then there's a coast to True Anomaly (optimizable), followed by a burn and 2 coasts. The problem is that I can't optimize it to reach the Jool at the correct time: Quote Jool Arrival Date = Year 4, Day 289 13:51:14.902 (119541074.9023 sec UT) If I disable the time constraint, it's able to reach Jool, but at a completely wrong timing, so I can't proceed any further. Could any of you help me understand what I'm doing wrong? Here's the link to my current mission plan -> https://www.dropbox.com/s/tzba6tlgdhi1ap9/Jool-Moho-mission.mat?dl=0 Update: Not exactly sure how I did, but I've got much closer now, but still not able to reach the target Jool Inbound orbit: Target orbit: Quote Semi-major Axis = -48429.2622 km Eccentricity = 2.464063778 Inclination = 10.4569 deg Right Ascension of AN = 37.3961 deg Argument of Periapse = 240.4379 deg Currently achieved orbit: Quote Semi-major Axis = -50628.35 km Eccentricity = 2.851741 Inclination = 132.2147 deg Right Ascension of AN = 337.09 deg Argument of Periapse = 279.7493 deg Current mission plan: https://www.dropbox.com/s/8xfnvjga52jpq8r/Jool-Moho-mission2.mat?dl=0 Edited August 5, 2020 by vitorboschi Improved the plan Quote Link to comment Share on other sites More sharing options...
Brian17 Posted August 5, 2020 Share Posted August 5, 2020 (edited) @Arrowstar Okay, we definitely got it now. Downloaded the debug version, started up MA, and got this in the log file when trying to start the parallel pool: Quote Starting parallel pool (parpool) using the 'local' profile ... You requested a minimum of 6 workers, but the cluster "local" has the NumWorkers property set to allow a maximum of 4 workers. To run a communicating job on more workers than this (up to a maximum of 512 for the Local cluster), increase the value of the NumWorkers property for the cluster. The default value of NumWorkers for a Local cluster is the number of cores on the local machine. Looks like the code only allows up to 4 workers, but the default is set to the number of local cores, which in my case is 6 (Core i7-4960X). And I assume that plugin code must override the property of the local cluster and force it to start. I'm glad it was simple enough to figure out so quickly. Edited August 5, 2020 by Brian17 Fixed quote block Quote Link to comment Share on other sites More sharing options...
salajander Posted August 6, 2020 Share Posted August 6, 2020 On 8/4/2020 at 7:40 PM, Arrowstar said: 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. Will you be releasing a Linux build of the prereleases? Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 6, 2020 Author Share Posted August 6, 2020 2 hours ago, Brian17 said: @Arrowstar Okay, we definitely got it now. Downloaded the debug version, started up MA, and got this in the log file when trying to start the parallel pool: Looks like the code only allows up to 4 workers, but the default is set to the number of local cores, which in my case is 6 (Core i7-4960X). And I assume that plugin code must override the property of the local cluster and force it to start. I'm glad it was simple enough to figure out so quickly. 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? 1 hour ago, salajander said: Will you be releasing a Linux build of the prereleases? 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. Quote Link to comment Share on other sites More sharing options...
vitorboschi Posted August 6, 2020 Share Posted August 6, 2020 9 hours ago, Arrowstar said: I'd consider it, though, if you're interested in testing the software on Linux. Would love to have the prerelease on Linux too. Quote Link to comment Share on other sites More sharing options...
vitorboschi Posted August 6, 2020 Share Posted August 6, 2020 @Arrowstar I see that there are three optimizer algorithms available on KSP-TOT's Mission Architect. Is there an explanation somewhere about advantages/disadvantages of each one in this context? Quote Link to comment Share on other sites More sharing options...
Brian17 Posted August 6, 2020 Share Posted August 6, 2020 @Arrowstar I checked the new debug build, and it seems to have started the parallel pool correctly in MA, with the message that it connected to 6 workers in the log file. However, I did get a ding and an error about matrix dimensions when the orbit passed outside of Kerbin's SOI. It also dinged and logged an error when trying to actually run the optimizer. This was with a new mission plan made for this test. I've shared the folder link to the log file and the .mat file used for the test below. Parallel Test - https://drive.google.com/drive/folders/1MEVg6vHwwFl8jp7NSS4PL9YZbDPTlyOA?usp=sharing Hopefully the link works, that's the first time I've linked to anything with Drive. I also noticed that when using the Porkchop plotter in any of the pre-release builds (including the debug versions), I would get an error popup about matrix dimensions. I'm not sure if that's just part of pre-release code or another bug, but that log file includes the matrix error from within MA when testing, just in case. @vitorboschi I've tried playing around with the different solvers a little bit. So far I've found that Interior Point and SQP(?) seem to be gradient solvers, so sometimes they can get themselves into a rut and get stuck, but they tend to make big moves in generally the right direction very early on. With Active Set, it doesn't seem to get stuck as easily as the others, but it tends to make small, incremental progress over many iterations so it can take longer overall. That's just my limited experience though. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 6, 2020 Author Share Posted August 6, 2020 2 hours ago, Brian17 said: @Arrowstar I checked the new debug build, and it seems to have started the parallel pool correctly in MA, with the message that it connected to 6 workers in the log file. However, I did get a ding and an error about matrix dimensions when the orbit passed outside of Kerbin's SOI. It also dinged and logged an error when trying to actually run the optimizer. This was with a new mission plan made for this test. I've shared the folder link to the log file and the .mat file used for the test below. Parallel Test - https://drive.google.com/drive/folders/1MEVg6vHwwFl8jp7NSS4PL9YZbDPTlyOA?usp=sharing Hopefully the link works, that's the first time I've linked to anything with Drive. I also noticed that when using the Porkchop plotter in any of the pre-release builds (including the debug versions), I would get an error popup about matrix dimensions. I'm not sure if that's just part of pre-release code or another bug, but that log file includes the matrix error from within MA when testing, just in case. 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. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 6, 2020 Author Share Posted August 6, 2020 3 hours ago, Brian17 said: @vitorboschi I've tried playing around with the different solvers a little bit. So far I've found that Interior Point and SQP(?) seem to be gradient solvers, so sometimes they can get themselves into a rut and get stuck, but they tend to make big moves in generally the right direction very early on. With Active Set, it doesn't seem to get stuck as easily as the others, but it tends to make small, incremental progress over many iterations so it can take longer overall. That's just my limited experience though. 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. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 7, 2020 Author Share Posted August 7, 2020 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. Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted August 7, 2020 Share Posted August 7, 2020 10 hours ago, Arrowstar said: RTGs provide a constant EC charge rate Should be easy enough to add half life as well? User provides the number of years (conversion to Kerbal/Earth years done under the hood based on settings) and the mission start UT. A few mods out there support/enable decaying RTGs Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 7, 2020 Author Share Posted August 7, 2020 1 hour ago, Drew Kerman said: Should be easy enough to add half life as well? User provides the number of years (conversion to Kerbal/Earth years done under the hood based on settings) and the mission start UT. A few mods out there support/enable decaying RTGs If you can provide me with some information regarding how that decay is modeled in some mods, I can incorporate it, sure. Quote Link to comment Share on other sites More sharing options...
vitorboschi Posted August 7, 2020 Share Posted August 7, 2020 @Arrowstar Tried running PR9 on Linux and it seems to start, but I guess there's a typo somewhere on the code: Quote Undefined function or variable 'ismepty'. Got this line when starting the optimization process using SQP optimizer and having "Parallelize Script Optimization" enabled. There're some errors after this one and the optimizer screen appeared empty, but all of that is likely due to the first bug above ^ Complete log: Quote Starting parallel pool (parpool) using the 'local' profile ... connected to 4 workers. Undefined function or variable 'ismepty'. Error in executeOptimProblem (line 9) Error in ma_MissionOptimizerGUI>optimizeMissionButton_Callback (line 585) Error in gui_mainfcn (line 95) Error in ma_MissionOptimizerGUI (line 42) Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_MissionOptimizerGUI('optimizeMissionButton_Callback',hObject,eventdata,guidata(hObject)) Error using uiwait (line 81) Error while evaluating UIControl Callback. Works fine if I disable the "Parallelize..." option. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 7, 2020 Author Share Posted August 7, 2020 (edited) 2 hours ago, vitorboschi said: @Arrowstar Tried running PR9 on Linux and it seems to start, but I guess there's a typo somewhere on the code: Got this line when starting the optimization process using SQP optimizer and having "Parallelize Script Optimization" enabled. There're some errors after this one and the optimizer screen appeared empty, but all of that is likely due to the first bug above ^ Complete log: Works fine if I disable the "Parallelize..." option. You found a typo... I'll recompile and reupload. EDIT: I've recompiled the Windows version and reuploaded. Linux is still on the way. Edited August 7, 2020 by Arrowstar Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted August 7, 2020 Share Posted August 7, 2020 (edited) 1 hour ago, Arrowstar said: If you can provide me with some information regarding how that decay is modeled in some mods, I can incorporate it, sure. AFAIK standard decay? Did not realize there were different models. Nothing fancy just if for example my RTG is set to 0.15EC with a half life of 9.2yr then after 1.9yr it will only put out 0.13EC - https://www.calculator.net/half-life-calculator.html?type=1&nt=0.13&n0=0.15&t=&t12=9.2&x=76&y=25 Also, when you get a chance have a look at this LVD case file - if I try to advance the date to something like 123513780 UT in the initial vessel settings it will throw an error. Additionally if I move the time slider to the right the spacecraft icon disappears and I'm not sure how to extend the view to include the whole trajectory. I'm liking the ability to manually tweak the event values to get a rough approximation that I can then send to the optimizer with really tight constraints for nailing the specific values - but if you open the window to do this you'll find two entries for Event 0 and selecting Event 5 doesn't show an adjustment bar. Maybe? When I reloaded the file it now shows only Events 1-5 and still no bar for Event 5. It seems the Ground Objects in the View Settings is bugged - or at least it is not working as I would expect. When I select an object and Save, only then does the object show up on the surface but only one at a time. re-opening the View Settings returns selection to the first object but if I just Save right away the first object isn't shown instead. I would also expect that selecting an object in the list would let me set its properties individually but the check boxes appear to be global and not specific to each object When editing the drag area for an in-flight event is it really necessary to re-import or re-enter the Cd values again? Edited August 7, 2020 by Drew Kerman Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 7, 2020 Author Share Posted August 7, 2020 1 hour ago, Drew Kerman said: AFAIK standard decay? Did not realize there were different models. Nothing fancy just if for example my RTG is set to 0.15EC with a half life of 9.2yr then after 1.9yr it will only put out 0.13EC - https://www.calculator.net/half-life-calculator.html?type=1&nt=0.13&n0=0.15&t=&t12=9.2&x=76&y=25 Also, when you get a chance have a look at this LVD case file - if I try to advance the date to something like 123513780 UT in the initial vessel settings it will throw an error. 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. Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted August 7, 2020 Share Posted August 7, 2020 (edited) 11 minutes ago, Arrowstar said: 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. Not sure if you saw my edits, but if you only downloaded the LVD case once, redownload it again since I updated it to see what I'm talking about with the other issues Edited August 7, 2020 by Drew Kerman Quote Link to comment Share on other sites More sharing options...
Brian17 Posted August 7, 2020 Share Posted August 7, 2020 I'll check the new version since I'm on Windows and see if I get any issues. That error that @vitorboschi had looks pretty similar to what I had with the debug build once the parallel pool got started. I'll let you know if I find anything unusual. Quote Link to comment Share on other sites More sharing options...
vitorboschi Posted August 7, 2020 Share Posted August 7, 2020 So continuing my quest to make the Kerbin -> Jool -> Moho -> Kerbin mission, I realized that even though I've got very small constraint violations when arriving at Jool inbound orbit, I still had to to a pretty big (near 500m/s dv) on Jool periapsis in order to hit Moho. Since MFMS's plan expected an unpowered assist at Jool, that correction should be small, right? One thing that is bothering me a bit is that Inbound and Outbound orbits are different, even though no dV maneuver was predicted at Jool. Does that mean that there'll be one or more encounters with Jool's moons? I thought that Inbound and outbound orbits (relative to the planet) should always be the same when no burns are applied. What am I missing here? Predicted Inbound/outbound Jool orbits Quote --------------------------------------------- Inbound Hyperbolic Flyby Orbit to Jool --------------------------------------------- Semi-major Axis = -48429.2622 km Eccentricity = 2.464063778 Inclination = 10.4569 deg Right Ascension of AN = 37.3961 deg Argument of Periapse = 240.4379 deg Periapse Radius = 70903.5286 km --------------------------------------------- Outbound Hyperbolic Flyby Orbit from Jool --------------------------------------------- Semi-major Axis = -42438.8937 km Eccentricity = 2.6707 Inclination = 10.4569 deg Right Ascension of AN = 37.3961 deg Argument of Periapse = 240.4379 deg Periapse Radius = 70903.5286 km Predicted burns at Jool Burn Information to Depart Jool Quote --------------------------------------------- Total Delta-V = 0.0000 km/s Prograde Delta-V = 0.0000 m/s Orbit Normal Delta-V = 0.0000 m/s Radial Delta-V = -0.0000 m/s --------------------- Burn True Anomaly = 0.0000 deg In a related question, should I use the information from the outbound orbit anywhere at the mission planner? The tutorial seems to use only inbound orbit info Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 7, 2020 Author Share Posted August 7, 2020 1 hour ago, Drew Kerman said: Not sure if you saw my edits, but if you only downloaded the LVD case once, redownload it again since I updated it to see what I'm talking about with the other issues Which other issues besides the Out Of Memory error that was showing up in the other MAT file? Quote Link to comment Share on other sites More sharing options...
Brian17 Posted August 7, 2020 Share Posted August 7, 2020 @Arrowstar I think he mentioned an issue with ground objects. I haven't messed around with them yet so I don't have any info. I tried out the new version, doing a quick check of the different solvers and options. As for the parallel pool, I didn't have any problems at all. Started up easily and worked well. Mission Architect didn't have any issues with any of the solvers, doing a quick test of an orbital altitude change. I did run into 3 issues though, so I linked a .zip with a copy of the log file and the .mat file I used for testing in the LVD. #1 - Starting the program and running the Porkchop plotter with the default settings resulted in a ding and an error in the log file. I have had this error occur every time so far, including with other settings (Kerbin - Eve, etc). This happens immediately after the plot is displayed, as soon as the progress bar for "optimal departure/arrival" appears, but before any info is displayed in the output window. #2 - Loading the .mat file in the LVD and trying to run the optimizer using the IPOPT solver results in an immediate ding and error in the log file. I have not been able to run this solver at all, this error happens every time. #3 - Loading the .mat file for the LVD and using the Pattern Search solver results in the optimizer window starting, running what seems to be just 2 iterations, and then just locking up with no ding or anything. Using the Stop button does nothing, so I am forced to close the window. I noticed an entry in the log file for this as well, so I included it with the others. ZIP file - https://drive.google.com/file/d/1A8_Ar76Ct9hpSIqAAx2l-pkFVeC9P9d4/view?usp=sharing That's all so far. The algorithm issues aren't too bad to work around as I still have FMINCON and NOMAD, but the Porkchop plot is pretty necessary for initial planning and trajectory info. Luckily, I still have 1.6.5 so I can use that for the plotter for now. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 7, 2020 Author Share Posted August 7, 2020 7 hours ago, Drew Kerman said: Also, when you get a chance have a look at this LVD case file - if I try to advance the date to something like 123513780 UT in the initial vessel settings it will throw an error. Additionally if I move the time slider to the right the spacecraft icon disappears and I'm not sure how to extend the view to include the whole trajectory. I'm liking the ability to manually tweak the event values to get a rough approximation that I can then send to the optimizer with really tight constraints for nailing the specific values - but if you open the window to do this you'll find two entries for Event 0 and selecting Event 5 doesn't show an adjustment bar. Maybe? When I reloaded the file it now shows only Events 1-5 and still no bar for Event 5. It seems the Ground Objects in the View Settings is bugged - or at least it is not working as I would expect. When I select an object and Save, only then does the object show up on the surface but only one at a time. re-opening the View Settings returns selection to the first object but if I just Save right away the first object isn't shown instead. I would also expect that selecting an object in the list would let me set its properties individually but the check boxes appear to be global and not specific to each object When editing the drag area for an in-flight event is it really necessary to re-import or re-enter the Cd values again? Okay I see this now, I'll take a look. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted August 7, 2020 Author Share Posted August 7, 2020 9 hours ago, Drew Kerman said: Also, when you get a chance have a look at this LVD case file - if I try to advance the date to something like 123513780 UT in the initial vessel settings it will throw an error. 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. Quote Additionally if I move the time slider to the right the spacecraft icon disappears and I'm not sure how to extend the view to include the whole trajectory. I'm liking the ability to manually tweak the event values to get a rough approximation that I can then send to the optimizer with really tight constraints for nailing the specific values - but if you open the window to do this you'll find two entries for Event 0 and selecting Event 5 doesn't show an adjustment bar. Maybe? When I reloaded the file it now shows only Events 1-5 and still no bar for Event 5. 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. Quote It seems the Ground Objects in the View Settings is bugged - or at least it is not working as I would expect. When I select an object and Save, only then does the object show up on the surface but only one at a time. re-opening the View Settings returns selection to the first object but if I just Save right away the first object isn't shown instead. I would also expect that selecting an object in the list would let me set its properties individually but the check boxes appear to be global and not specific to each object. 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. Quote When editing the drag area for an in-flight event is it really necessary to re-import or re-enter the Cd values again? 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? 3 hours ago, Brian17 said: #1 - Starting the program and running the Porkchop plotter with the default settings resulted in a ding and an error in the log file. I have had this error occur every time so far, including with other settings (Kerbin - Eve, etc). This happens immediately after the plot is displayed, as soon as the progress bar for "optimal departure/arrival" appears, but before any info is displayed in the output window. 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... Quote #2 - Loading the .mat file in the LVD and trying to run the optimizer using the IPOPT solver results in an immediate ding and error in the log file. I have not been able to run this solver at all, this error happens every time. I believe this has been resolved now for the next release. Quote #3 - Loading the .mat file for the LVD and using the Pattern Search solver results in the optimizer window starting, running what seems to be just 2 iterations, and then just locking up with no ding or anything. Using the Stop button does nothing, so I am forced to close the window. I noticed an entry in the log file for this as well, so I included it with the others. 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.