[1.8x - 1.11x] Kerbal Weather Project (KWP) v1.0.0

[theonegalen]

I feel like this mod could really use a graphics/shader wizard like @blackrackto integrate visible weather using this simulation data. Imagine if the Scatterer oceans used this data for wave intensity, or EVE used it for cloud patterns. It is pretty amazing as it is, of course!

Edited September 20, 2021 by theonegalen

[Caerfinon]

6 minutes ago, theonegalen said:

Imagine if the Scatterer oceans used this data for wave intensity, or EVE used it for cloud patterns

WHERE TO WE SEND THE CHEQUES IN ORDER TO MAKE THIS HAPPEN? 

[blackrack]

6 hours ago, theonegalen said:

I feel like this mod could really use a graphics/shader wizard like @blackrackto integrate visible weather using this simulation data. Imagine if the Scatterer oceans used this data for wave intensity, or EVE used it for cloud patterns. It is pretty amazing as it is, of course!

Was thinking about it but the performance hit of this mod was really heavy last time I tried it, and the fact that it's simulation data limits how much artistic control you have over the final result.

Was thinking of adding my own simplified weather system instead that both EVE and Scatterer can use. I have a few things planned first though (true eve volumetric clouds and improvements+fixes to scatterer's atmo).

[theonegalen]

9 hours ago, blackrack said:

Was thinking about it but the performance hit of this mod was really heavy last time I tried it, and the fact that it's simulation data limits how much artistic control you have over the final result.

Was thinking of adding my own simplified weather system instead that both EVE and Scatterer can use. I have a few things planned first though (true eve volumetric clouds and improvements+fixes to scatterer's atmo).

That's great news!

[Araym]

First of all, I'm very intrigued by this mod...
... but (there should be a "but", if I'm writing ) if I'm not a bother, I would like to ask a technical question:

• Provided that I play with "too much mods", so further problem could arise aside those that I'm going to consider here, how this mod works with modifications of Kerbin itself (mostly Kopernicus based one)???
  I'm asking because, aside using an extended Kerbin system with stock+OPM, I play with a custom made Kerbin atmosphere (based from an xml table I found for modders willing to develope their own planetary pack) with data extrapolated by those present on real Earth, to rise Kerbin atmosphere from 70k altitude to 100km altitude
  It will everything adeguately scaled up by itself, taking in consideration the different "karman line" i have in my install???
   

[Hohmannson]

11 hours ago, Araym said:

modifications of Kerbin itself

It will force stock KWP-Kerbin atmosphere properties, sadly

[charliepryor]

Is there any way to scale this UI up more? It's super small at anything other than 1080p - and a huge portion of people are playing higher than that now, myself included. Would be nice, even if I had to hard-code it, to change the size of text in the interface.

Also, when trying to use Blizzy's toolbar, it's throwing an error (I just have errors display on for testing purposes. You can repro that way). Basically, the icon is too large, and therefore, it shows up as a purple square with Blizzy's bar.

[cmet24]

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).

On 9/23/2021 at 6:05 AM, Araym said:

First of all, I'm very intrigued by this mod...
... but (there should be a "but", if I'm writing ) if I'm not a bother, I would like to ask a technical question:

• Provided that I play with "too much mods", so further problem could arise aside those that I'm going to consider here, how this mod works with modifications of Kerbin itself (mostly Kopernicus based one)???
  I'm asking because, aside using an extended Kerbin system with stock+OPM, I play with a custom made Kerbin atmosphere (based from an xml table I found for modders willing to develope their own planetary pack) with data extrapolated by those present on real Earth, to rise Kerbin atmosphere from 70k altitude to 100km altitude
  It will everything adeguately scaled up by itself, taking in consideration the different "karman line" i have in my install???
   

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. 

Edited October 2, 2021 by cmet24

[cmet24]

On 9/20/2021 at 2:44 AM, blackrack said:

Was thinking about it but the performance hit of this mod was really heavy last time I tried it, and the fact that it's simulation data limits how much artistic control you have over the final result.

Was thinking of adding my own simplified weather system instead that both EVE and Scatterer can use. I have a few things planned first though (true eve volumetric clouds and improvements+fixes to scatterer's atmo).

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. 

. 

On 9/19/2021 at 7:55 PM, theonegalen said:

I feel like this mod could really use a graphics/shader wizard like @blackrackto integrate visible weather using this simulation data. Imagine if the Scatterer oceans used this data for wave intensity, or EVE used it for cloud patterns. It is pretty amazing as it is, of course!

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.  

Edited October 2, 2021 by cmet24

[charliepryor]

Firstly... OH WOW THANK YOU for the scaling. Appreciate that a ton. -- Secondly, I'm noticing something weird, and I'm not sure which mod to blame or whatever, maybe it's nothing... but I just used a balloon from KerBalloons and I noticed the wind direction being listed in the Climate tab was different than the weather tab almost all the time... and I also noticed that my balloon never seemed to drift in the direction the wind stated. Is that showing which way the wind is blowing, or which way the wind is coming from?

[cmet24]

5 hours ago, charliepryor said:

Firstly... OH WOW THANK YOU for the scaling. Appreciate that a ton. -- Secondly, I'm noticing something weird, and I'm not sure which mod to blame or whatever, maybe it's nothing... but I just used a balloon from KerBalloons and I noticed the wind direction being listed in the Climate tab was different than the weather tab almost all the time... and I also noticed that my balloon never seemed to drift in the direction the wind stated. Is that showing which way the wind is blowing, or which way the wind is coming from?

@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.  

 

 

Edited October 3, 2021 by cmet24

[blackrack]

10 hours ago, cmet24 said:

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.

Thank you, I haven't re-tested this mod since release so that sounds very good.

Now that I think about it however, I believe that anything performance intensive shouldn't have anything to do with the calculations you're making, but with adding additional forces to parts and ships, I believe the game's physics engine is where things bottleneck. I assume forces are added to individual parts?

With that said, in your performance test I see you're tracking CPU usage but I don't see any mention of framerate beyond the initial capture, I assume both machines are locked at 60 fps the whole time? In that case it may be better to unlock framerate beyond 60 and to compare max framerates directly instead of comparing CPU usage, as that doesn't tell much when performance is limited by a single-thread speed or a framerate cap.

Also, the Aeris 3A doesn't have a lot of parts, I think ships with a 100+ and 400+ parts would be better for seeing how the performance scales. From memory I tested a 250-ish parts boat on an i7-3770 (so slower cpu than yours) and saw about a 50% reduction in fps when I enable the mod. I haven't tested the new performance improvements yet though.

[cmet24]

@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:

1. A-6E-Intruder
2. A-10A
3. 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

Edited October 3, 2021 by cmet24

[blackrack]

20 hours ago, cmet24 said:

@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

Thanks for the detailed tests. That indeed sounds good performance-wise.

I have a few more questions, relating to possibly using the data for visual mods in the future:

• I checked the api briefly and it seems data for cloud cover can be accessed locally point by point.  I guess it isn't possible for now to access a planet-wide coverage map such as the gif in your first post:
  
  How much of a hassle would it be to expose a dynamic texture or rendertexture that contains the data for the whole planet at once (with a given workable resolution for graphics purposes say 2k or whatever) and that updates every frame with the correct data (or just exposing the next slice and giving the timestamp for it)? How big is the cloud cover data for a whole year for example and how feasible would it be to stream it in this manner? (Not asking you to add it, just wondering how all the bits fit together).
   
• The simulation itself requires a beefy CPU, a significant amount of RAM and significant amount of time to compute. This is fine for the stock planets since we only need to run them once, this would probably block adoption for mods and custom planets though.
  You mention using a cluster, I assume this means the algorithm parallelizes and scales well with more cores, in theory this could mean we can speed it way up by running it on the GPU instead, but it has to fit in video memory which sounds like a stretch. How much of your machine's 128 GB ram was actually used for the simulation and how much can this be reducd by "trimming the fat", lowering number of layers (eg 32 vertical instead of 55), using half-precision instead of full or double precision, discarding some factors etc? Considering a high-end GPU today has 8-16 GB VRAM, wondering if there is any leeway here.

[The_Stinky_Broccoli]

I would love to see an ultra realistic version of this for RSS/RO eventually, but until then im still happy to play stock because of this mod. 

Also, Will Principia mess with the mod?

[RocketRyleigh]

Hi cmet, amazing work on KWP. Just two small questions I might just be missing the answers to:

With the climatology vs. point weather data, is the idea to use one or the other, or just any combination of the two? Totally works for me if the former, I'm playing on a potato, which leads to question #2:

Do I have the right impression that point weather data would be the less resource intensive of the two? I'm just assuming that since then it's not calculating global weather data, but one comment from the thread made me second-guess.

[CraigCottingham]

KWP 1.0.6 is not loading for me in KSP 1.12.3 on macOS 11.6.2. I've opened an issue on GitHub for this: https://github.com/cmac994/KerbalWeatherProject/issues/3

The TL;DR is that the source hard-codes paths to important files (like the bin files for climatology) using backslash as the path separator character, but macOS and Linux use forward slash: https://blog.benhall.me.uk/2008/08/mono-and-file-paths/

I have very little experience coding for KSP mods, but from what I've been able to gather there's a way to build file paths at runtime using the correct path separator character. I can attempt to create a PR, but I've never been able to successfully compile mod code on macOS.

[cmet24]

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. 

On 1/2/2022 at 8:07 PM, CraigCottingham said:

KWP 1.0.6 is not loading for me in KSP 1.12.3 on macOS 11.6.2. I've opened an issue on GitHub for this: https://github.com/cmac994/KerbalWeatherProject/issues/3

The TL;DR is that the source hard-codes paths to important files (like the bin files for climatology) using backslash as the path separator character, but macOS and Linux use forward slash: https://blog.benhall.me.uk/2008/08/mono-and-file-paths/

I have very little experience coding for KSP mods, but from what I've been able to gather there's a way to build file paths at runtime using the correct path separator character. I can attempt to create a PR, but I've never been able to successfully compile mod code on macOS.

Edited January 30, 2022 by cmet24

[cmet24]

On 11/14/2021 at 9:22 PM, RocketRyleigh said:

Hi cmet, amazing work on KWP. Just two small questions I might just be missing the answers to:

With the climatology vs. point weather data, is the idea to use one or the other, or just any combination of the two? Totally works for me if the former, I'm playing on a potato, which leads to question #2:

Do I have the right impression that point weather data would be the less resource intensive of the two? I'm just assuming that since then it's not calculating global weather data, but one comment from the thread made me second-guess.

@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).

1. 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.
2. 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.

Edited January 30, 2022 by cmet24

[cmet24]

On 10/4/2021 at 8:36 AM, blackrack said:

Thanks for the detailed tests. That indeed sounds good performance-wise.

I have a few more questions, relating to possibly using the data for visual mods in the future:

• I checked the api briefly and it seems data for cloud cover can be accessed locally point by point.  I guess it isn't possible for now to access a planet-wide coverage map such as the gif in your first post.
  
  How much of a hassle would it be to expose a dynamic texture or rendertexture that contains the data for the whole planet at once (with a given workable resolution for graphics purposes say 2k or whatever) and that updates every frame with the correct data (or just exposing the next slice and giving the timestamp for it)? How big is the cloud cover data for a whole year for example and how feasible would it be to stream it in this manner? (Not asking you to add it, just wondering how all the bits fit together).
   
• The simulation itself requires a beefy CPU, a significant amount of RAM and significant amount of time to compute. This is fine for the stock planets since we only need to run them once, this would probably block adoption for mods and custom planets though.
  You mention using a cluster, I assume this means the algorithm parallelizes and scales well with more cores, in theory this could mean we can speed it way up by running it on the GPU instead, but it has to fit in video memory which sounds like a stretch. How much of your machine's 128 GB ram was actually used for the simulation and how much can this be reducd by "trimming the fat", lowering number of layers (eg 32 vertical instead of 55), using half-precision instead of full or double precision, discarding some factors etc? Considering a high-end GPU today has 8-16 GB VRAM, wondering if there is any leeway here.

@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! 

Edited January 30, 2022 by cmet24

[Bit Fiddler]

well, yes, I was coming here hoping to get a mod to assist in glider flying.   But I guess this is not there yet.  how hard would it be to check wind direction and add the appropriate vertical wind speed on the windward side of mountains, and then incorporate the city lights texture from (EVE?) and over any spot that has a city texture increase vertical wind speed?  this would cover the most obvious sources of updraft; ridge running and urban sprawl.  

 

I have been on a glider kick recently, and really wish we had the ability to actually fly them.

Spoiler

 

 

Edited February 2, 2022 by Bit Fiddler

[cmet24]

On 2/1/2022 at 9:31 PM, Bit Fiddler said:

well, yes, I was coming here hoping to get a mod to assist in glider flying.   But I guess this is not there yet.  how hard would it be to check wind direction and add the appropriate vertical wind speed on the windward side of mountains, and then incorporate the city lights texture from (EVE?) and over any spot that has a city texture increase vertical wind speed?  this would cover the most obvious sources of updraft; ridge running and urban sprawl.  

I have been on a glider kick recently, and really wish we had the ability to actually fly them.

@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.

Edited February 8, 2022 by cmet24

[blackrack]

On 1/30/2022 at 7:36 PM, cmet24 said:

@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! 

Thank you for the complete reply.

There does appear to be a GPU-enabled MPAS branch here but I haven't read into it much to see how much is actually run on the GPU and what the requirements are: https://mpas-dev.github.io/atmosphere/OpenACC/index.html

Regarding resolution, if 1x1 degree resolution used 1/4 of your server's ram (so 32gb) , then I'm thinking a 2x2 or 3x3 resolution should fit in a modern GPU's memory, the cloud cover data for one year could also go from 633 mb to 150mb or 70mb respectively. Question is how coarse/bad would the simulation be at that resolution(the cloud cover gif already looks quite coarse but not sure if that's because of simulation resolution or how the gif was made)? At least for the purpose of being used in a game like this.

For the nasa model do you have a link? The link above doesn't seem to be working.

Edited February 8, 2022 by blackrack

[Poodmund]

4 hours ago, blackrack said:

Question is how coarse/bad would the simulation be at that resolution(the cloud cover gif already looks quite coarse but not sure if that's because of simulation resolution or how the gif was made)?

If very coarse, could some noise (domain warping) be integrated to lessen any hard edges?

[blackrack]

1 hour ago, Poodmund said:

If very coarse, could some noise (domain warping) be integrated to lessen any hard edges?

For sure