cmet24

@infinite_monkey So, in this mod, atmospheric fields (e.g. temperature, humidity, pressure, etc.) were interpolated to a 1 x 1-degree rectangular grid. A five-year, hourly, climatology of Kerbin was subsequently produced by averaging this gridded weather data over time. Since the data is averaged by the hour the climatology captures the diurnal cycle of weather on Kerbin. The climate data has four dimensions: (t, z, lat, lon) where t is the hour of the day, z is height, and lat/lon are geospatial coordinates. In the main version of KWP this 4D "climatology" dataset is ~52MB. In the lite version its reduced in size to ~13MB. This reduction is achieved by reducing the geospatial resolution of the climatology by half (so from 1x1 deg to 2x2 deg). In-game the weather/climate data is inteprolated to the position of the craft. In my experience, the data itself isn't the biggest constraint in this mod. The most computationally taxing part is computing the effects of wind, temp, etc. on flight dynamics rather than interpolating or reading in the weather/climate data itself.

@doxid310Correct! So, in general, the atmosphere is pretty close to hydrostatic balance most of the time (i.e. vertical motions are small). There are some exceptions when the atmosphere becomes statically unstable. In that event, convection will happen to restore stability. That said, convection takes place on a very short time scale (~ few hours). Since we perform some temporal averaging (to get the climatology) the atmosphere is generally statically stable - meaning little vertical motion. In some places, like the tropics, the mean state can be marginally unstable; however, to capture that we would've required a much more high resolution simulation capable of resolving convection. I'm glad you figured it out! Feel free to make a fork of the mod on Github (if you haven't already).

@blackrack Sorry, for the delayed response. I finally had some time to spin up KSP this weekend and check back on the forum. Good find! I didn't realize there was a GPU-enabled branch of MPAS . Unfortunately, it's scope is quite narrow. The version of the model is not up to date (the GPU branch uses MPAS v6) and is only supported on IBM's AC922 architecture. Not to say that one couldn't get it to compile on a home GPU but I don't think the effort would reap much benefit. The radiation code is still run through the CPU and the physics options are highly limited in the GPU branch. FYI: Here is the link to the NASA model: ROCKE-3D. I've run it successfully but it requires quite a bit of manual adaption to modify the terrain and land surface of the planet being modeled. Regarding the quality of a lower resolution simulation, reducing the resolution to 2x2 or 2.5x2.5 degrees wouldn't be unreasonable. In fact, many global climate models used to project the impacts of anthropogenic climate change are run at coarse resolutions on the order of a (1-2.5 deg). It should be noted that, on Kerbin, 1 x 1 deg (at the equator) is on the order of ~25 x 25 km. So, when projected onto Kerbin's coordinate grid, a little goes a long way. This is why KWP is able to resolve difference in climate conditions between the mountains west of the KSC and the ocean to the east. In the model, the mountains are ~200 km away from the KSC. In the game, they're maybe ~20 km from the KSC, since the planet has a radius of 600 km. In MPAS the terrain is scaled up and the model is run with the planetary radius set to Earth's radii. The reasoning behind this approach is outlined in the background section of the KWP webpage. @RocketRyleigh So, KWP should still work in JNSQ its just that the point-weather data was run for the stock planet and not the JNSQ version of Kerbin. So, the data may not line up perfectly with what you might expect for the local micro climate. If I recall correectly, the JNSQ KSC site is at a similar latitude as the KSC site in the stock game. In JNSQ the KSC is also relatively close to the water so I wouldn't expect the point weather data at the KSC (for JNSQ) to be terribly off base. That said, one potential complication of using KWP on a modified version of Kerbin is the difference in the length of the day. In JNSQ, Kerbin is ~2.5X larger and the day length is 12 hours (instead of 6). This means that the diurnal cycle of weather (from KWP) would be invalid in a JNSQ playthrough. Basically, when playing JNSQ, you'd have two days of weather in one. While this is wholly inaccurate it's probably not game breaking. With respect to other launch sites. KWP supports a selection of launch sites from the Kerbinside Remastered mod in addition to the other stock launch sites (i.e. DLS and WLS). In JNSQ, moving to a different site added by KK would simply result in KWP grabing point weather data from the nearest site in its database. For example, say KK adds a site at 35 N, 120 E. If you spawned at this site, KWP would use the point weather data from the Woomerang Launch Site location (45 N, 136 E) as that would be the closest site (coordinate) for which point weather was available. Essentially KWP grabs data from the nearest site it can find, if the current location is not in its database. For the climate data this is irrelevant, only for point weather data does the latitude/longitude location matter.

@Bit Fiddler What you describe is definately possible, although it is not what KWP was originally designed for. That said, if you wanted to create your own mod that solely implented vertical motions (i.e. udrafts/downdrafts) that would be totally doable. The implementation of wind in KWP is found here. If your familiar with C# you might find this module helpful, particular lines 191-300. You could use this code as a baseline for adding adding vertical wind to the game.

@blackrack Excellent questions! Your correct. Currently, the API is set up to request point data. I honestly have little knowledge of rendering textures in KSP. That said, I do think it would be possible to pass a 2D array (with a timestamp) containing cloud cover data for the entire planet. The issue is that the GIF showed in the first post was produced from the full MPAS simulation. The climatological data used in the mod was averaged by hour (across 5-years of data) so that it could be loaded during gameplay. Taking a look at the MPAS cloud cover data it appears that a full year (2557 hours) of data at 1 x 1 deg resolution (~24 km on Kerbin) is around 633 MB. That said, there are ways the data could be compressed. The horizontal resolution could be halved and the time-series could be sliced to retrieve cloud cover data over a smaller chunk of the year. Regarding the simulation. MPAS is a state of the art global climate model for Earth! It was developed by scientists at Los Alamos National Laboratory (COSIM) and the National Center for Atmospheric Research. I got MPAS to work for Kerbin because Kerbin is actually quite similar to earth in terms of atmospheric composition and solar irradiance. Modelling planets whose atmospheric composition differs significantly from Earth's (e.g. Mars, Venus, etc.) is quite tricky because a lot of the assumptions that are made in Earth-based climate models break down big-time! NASA does have a model for simulating the climate of exoplanets and other Solar System terrestrial planets. In my experience, their model is quite difficult to customize. To simulate custom KSP planets there would have to be an easy way to modify the surface terrain within the model. With respect to model performance, I ran MPAS with half precision. I also choose to output only variables which I found necessary for understanding Kerbin's climate. I used 55 vertical levels to ensure model stability. When your running a numerical weather model with a vertical top of 70-km you need to have quite a few layers to adequately resolve vertical motions and vertically propagating waves. For the MPAS models runs, perhaps around 1/4 - 1/3 of the RAM was used. This is because numerical weather prediction at coarse resolution (1 x 1 degree) is largely constrained by computation limits (CPU clock speed). When you increase the horizontal resolution of the model that's when your RAM usage goes up! It'd be nice if one could run numerical weather models on a high-end GPUs. Nevertheless, porting millions of lines FORTRAN code to run on modern GPUs remains an ongoing and challenging process. There are a few industry leaders (Nividia/IBM) and quite a few Ph.D. students working on this very problem. Unfortunately, MPAS does not yet have the capability to utilize GPUs. As an aside, I think the real power of KWP is the framework it provides for incorporating meteorological data into gameplay. One could produce a climatological (4D) dataset for their planet and use KWP's framework to implement that data into the game. The challenge is how to produce that climatology. Modders could design their own or modify existing data from real terrestrial planets. Either way it's not all about realism. For me its really all about having fun with meteorology and KSP!

@RocketRyleigh The full MPAS simulation with 5-years of data is on the order of ~0.5 TB. Obviously we can't load all this data into the game! So, as a compromise I compressed the simulation data into two datasets: point weather data (1) and climatological data (2). The point weather data was drawn from the MPAS simulation at the latitude/longitude of each launch site. Thus, at each launch site, the dataset has two dimensions: height and time. This means that if you were to load the KSC launch site and fly around the planet you wouldn't notice a big surface temperature drop as you headed toward the poles since the point weather data was extracted from an equatorial site! The point of including point weather data was to allow for a more dynamic simulation of weather at a single point. When you use the point weather data, the weather will be different every day at the launch site! This is great for roleplaying rocket launches since, when you launch a rocket equatorially, most of your time in the atmosphere is spent relatively close (latitudinally) to the KSC. Climatological data was drawn from the MPAS simulation at all latitude and longitudes across Kerbin. However, the climatological data was averaged along the hourly dimension over a period of 5-years. The result is a dataset that has the following dimensions: height, latitude, longitude, hour. Consequently, the climatological data provides data that will be the same day every day but that will vary by hour (simulating a diurnal cycle) and by location! So, the climatological data isn't the best for roleplaying rocket launches since the temperature, pressure, etc. will repeat each day. However, it is quite nice for atmospheric flight! If you like flying around Kerbin then climatological data is for you! When using climatological data you can actually experience the jet stream as you fly at altitude across the mid-latitudes. If you fly from the KSC to the poles you'll find the air density and surface temperature changes quite a bit! In addition, if you launch a satellite orbiting Kerbin you can use climatological data to remotely sense atmospheric conditions at the point below you. TLDR: The point weather dataset was designed for roleplaying rocket launches from fixed sites. The climatological dataset was designed for atmospheric flight and passive remote sensing (i.e. when in space). When you run KWP both the point and climatological weather data are loaded. Thus the performance impact between the two should be negligible. Calculations performed in KWP related to meteorological data are mostly limited to linear interpolations.

KWP has been updated to version 1.0.7 Compatibility update. Updated static file paths to platform-independent file paths. Updated KSP compatibility version to 1.12.3 Thanks to @CraigCottingham for pointing out hardcoded file paths which compromised compatibility on Unix systems.

@blackrack Your correct. The addition of forces to individual parts results in greater performance impacts when part counts are high. In the initial release there was a bug wherein forces were applied to occluded parts. This bug was fixed in a previous release (1.0.5). To examine the latest performance stats I unlocked the framerate and tested three KSP crafts from KerbalX: A-6E-Intruder A-10A A7100-100 Below are my results with and without KWP for each craft (links show screenshots): 1. A-6E-Intruder (127 parts) Stock: 61 FPS KWP: 60 FPS For the A-6E craft the difference in framerate was negligible. 2. A-10A (267 parts) Stock: 33 FPS KWP: 22 FPS For the A-10A craft the difference in framerate was more notable. In the stock playthrough framerates hovered around 30 FPS whereas in the KWP playthrough framerates were in the low 20s. On average, I'd say framerates were reduced by about 10 FPS (~33%) between stock and KWP. 3. A7100-100 (639parts) Stock: 9 FPS KWP: 7 FPS For the A7100-100 craft the difference in framerate wasn't terribly noticeable as the game ran quite slowly regardless of whether KWP was installed or not. Stock framerates were around 8-9 FPS while KWP framerates averaged out at ~7 FPS. I haven't tested the performance with the "Lite" version of the mod. I suspect the only difference observed would be in the MEM and/or RAM usage. During testing the following mods were used in each playthrough. The game version was KSP 1.12.2. KWP Playthrough: Click Through Blocker Toolbar Controller Zero MiniAVC AtmosphereAutopilot (Fly-By-Wire) Kerbal Weather Project (KWP) MechJeb2 ModularFlightIntegrator Module Manager Stock Playthrough: AtmosphereAutopilot (Fly-By-Wire) MechJeb2 Module Manager

@charliepryor This is correct. Wind direction is displayed in the meteorological sense, that is in the direction the wind is coming from. So, if you launch a balloon when the winds are out of the west you should expect it to drift downrange, in the opposite direction, toward the east. When the climate tab is selected KWP will use climatological data which varies geographically, vertically, and diurnally. When the weather tab is selected KWP will use weather data that varies with height and time and is only valid for a fixed location (i.e. the launch site). The difference between the two datasets is further elucidated below and on the mod webpage. Climate Data Atmospheric fields (e.g. temperature, humidity, pressure, etc.) from the MPAS simulation were interpolated to a 1 x 1-degree rectangular grid. A five-year, hourly, climatology of Kerbin was produced by averaging this gridded weather data over time. Since the data is averaged by the hour the climatology captures the diurnal (daily) cycle of weather at every point on Kerbin. Weather Data At select Kerbal launch sites, weather time series were extracted from the 1x1 degree gridded weather dataset. These year-long time series allow players to experience dynamic weather that changes each day. Since these time series were retrieved from point locations, the weather varies temporally but not spatially. This is in contrast to the climatology discussed above, wherein the weather varies spatially but does not change from day to day.

I should note that there have been several performance improvements to KWP since its initial release. Also, there is a "Lite" version of the mod that should have minimal impact on framerates. After its initial release I did some performance testing on a desktop and laptop computer. I posted my results in an earlier comment within this forum topic. . FYI: KWP has a built-in API for modders: https://kerbalweatherproject.readthedocs.io/en/latest/index.html If there are folks out there who interested in creating visual addons for KWP the API linked above may be helpful.

KWP has been updated to version 1.0.6 Bugfix to address toolbar and GUI scaling. Modified texture icons for blizzy toolbar compatibility. KWP GUI will now scale with stock UI. Thanks to @charliepryor for pointing out the issue with Blizzy's toolbar and the UI interface. Note: If running KSP at 4K you can adjust the stock UI scale in the game settings (the KWP GUI will scale accordingly). The mod will still run, even if a modified version of Kerbin is present in the game. I just tested KWP with JNSQ installed. The mod executes fine. In JNSQ the atmosphere has a depth of 85 km. Above 70-km the default JNSQ atmosphere is used. Below 70-km the KWP atmosphere is used and weather, wind, etc. will affect flight. Interestingly, when I tested the mod with JNSQ, I didn't real detect any sort of obvious boundary at 70-km where the transition between the KWP atmosphere and JNSQ atmosphere occurs. That said, KWP's weather simulation is wholly inaccurate in JNSQ as the topography and geography of JNSQ's Kerbin is markedly different from stock Kerbin. If you don't care much about accuracy/realism and just want wind effects in your non-stock Kerbin playthrough than you shouldn't have a problem running KWP for any version of Kerbin.

@OHara Sounds good to me! Feel free to fork the repo on GitHub. In designing the mod my original goal was simply to make weather have an influence on flight and reentry. I acknowledge that the implementation of wind in the game is far from perfect (especially on the ground). The game physics are a little finicky, which is part of the reason why I think there are so few wind mods in existence! That said, If you have any ideas on how to improve realism I'm all ears! KWP has been updated to version 1.0.5 Update for KSP 1.12 Fixed issue that prevented fairings from occluding drag. Updated DLL references. Thanks to @Infinite_Maelstrom for pointing out the fairing occlusion bug.

@OHara So the way the wind simulation works, is that it performs vector addition twice. First the total velocity of the vehicle in the absence of wind is calculated (this is the stock velocity). Next the wind velocity vector is subtracted from the stock velocity vector to get an estimate of the true velocity of the vehicle. Now, this calculation alone does nothing. To actually make wind have an impact in the game, forces are applied to the vehicle. In-game forces (e.g. lift and drag) are calculated using the stock velocity estimate and then again using the true velocity estimate. Forces are calculated twice since lift/drag depends upon the velocity of the vehicle. Finally, the difference in the calculated forces, between the stock velocity and true velocity, is computed. This difference in magnitude, representing the force of the wind, is then applied to each part. Note that forces are calculated separately for individual parts. The code for this is available here and is present between lines 190 - 300. Even if you're not familiar with C# I've commented the lines to specify what they do. The ground speed is calculated by the stock game. KWP calculates the true airspeed by subtracting the wind speed from the ground speed. In this convention a negative windspeed (i.e., a headwind) results in a higher airspeed. Relative winds are calculated using vector projection. The code for this is fairly straightforward and is available here (between lines: 387-396)

@SpeacXPersonally, I haven't tried it with RSS. I would give it a try and see what happens! One issue you may run into is that the atmospheric boundary in RSS is higher than in stock KSP. The MPAS data KWP uses is valid up to 70 km ASL. So, if your altitude is above 70-km ASL (and your in the atmosphere) KWP will retrieve weather/climate data from the highest model level (i.e. 70-km). That is there would be no vertical changes in weather/climate data above 70-km. Oddly enough KWP's atmosphere is more similar to Earth's than stock KSP since the scale height in MPAS simulations matches that of Earth (8.5 km) not Kerbin (5.6 km). @traisjames Thanks for sharing your issues. I've yet to re-create this issue myself but when I do hopefully I'll find a fix for it! @Dman979 Pretty well! My university seminar was great. I got a lot of good questions and had a fruitful discussion about global circulation and heat-transport! By the way, I've shared my presentations (poster and seminar slides) on the KWP website where they're available to download.

@ItsJustLuci So precipitation information is included with the mod, and is available to fellow modders via the API. In space, KWP provides information on precipitation rate. That said, there are no visual effects added by this mod. Rain, snow, etc. won't affect your launches. Precipitation, cloud cover, and visibility are provided via the KWP API mainly so that other modders could utilize the data to design visual effects or incorporate it into their mods.