☁️ Clouds?

[Datseris]

Hey there,

it is difficult to think of "weather" without clouds :P Currently there isn't any support for simulating clouds even with the most crude of approximations. I am opening this thread to first collect resources for simulating clouds and perhaps get some directions in case I want to implement some.

(I am from a far away field and I don't even know where to start, but I would like to have a fast spatiotemporal idealized climate model that has basic clouds support)

[Datseris]

I guess one would add a parameterization for clouds from here: https://speedyweather.github.io/SpeedyWeather.jl/dev/parameterizations/ (once this is completed)

[milankl]

Well, actually we have clouds

clouds.mp4

Here visualised as the cloud height [m] with a transparent to white colour map. While this simulation ran at 100km resolution, it only used 8 vertical levels and of which each either has a cloud, diagnosed by humidity > 100% or convection (dry/shallow or deep) active, or not. The geopotential determining the height of a grid box changes but that's why it's still rather patchy because it's overly coarse in the vertical.

At the moment cloud liquid water is

• not a prognostic variable, meaning it's not advected and purely diagnostic from specific humidity
• not interfering with any radiation (it's a passive diagnostic)

So question back George, what basic support are you looking for? I'm hesitant to make cloud water a prognostic variable right now as it makes the model more computationally expensive, and I'm not sure we desperately need this. But I am open and indeed working towards a simple cloud-radiation scheme. Fortran SPEEDY has it, but I'm not sure we want to implement exactly the same scheme.

[Datseris]

Well, actually we have clouds

I couldn't find anything about this in the documentation, sorry. Can you point me to where in the source the clouds are? Or what is supported right now in terms of clouds and precipitation?

But, then again, given:

At the moment cloud liquid water is

* not a prognostic variable, meaning it's not advected and purely diagnostic from specific humidity

* not interfering with any radiation (it's a passive diagnostic)

This doesn't sound like "has clouds" to me. At the very least I would expect clouds to reflect sunlight, as they have such a strong cooling effect on the planet. Next more advanced steps would be cloud formation being physics based instead of RH = 100%, and cloud aggregation and finally precipitation. But the just the reflection is what I'd take honestly.

I'm hesitant to make cloud water a prognostic variable right now as it makes the model more computationally expensive, and I'm not sure we desperately need this.

Okay, this confused me. By reading the README, I got the impression that Ι could add clouds as per:

physics parameterizations for precipitation, boundary layer, etc; new ones are passed as argument to the model constructor

and in fact that's exactly the the way I envision using any kind of "fast"/idealized climate simulator: I can "plug-in" my own components, via e.g., keyword arguments.

But your comment gives me the impression that this is not the vision of SpeedyWeather.jl? Otherwise why would you be reluctant to "add" something as an option? Just hoping to clarify here, I am not challenging your view.

in my ideal world, there would be such an option with a basic cloud scheme that interacts with radiation that I could turn on or off at will.

[milankl]

I couldn't find anything about this in the documentation, sorry. Can you point me to where in the source the clouds are? Or what is supported right now in terms of clouds and precipitation?

Because clouds are currently just passive & diagnostic, it's not documented yet, sorry. Because as you say, our vision would mean that if describe how the clouds work, users would expect to interact with them, which at the moment you can't because you can diagnose where clouds form but not how they interact with the climate. Cloud top height is currently set in src/large_scale_condensation.jl and convection.jl but it's really as simple as conditionally setting it to the vertical index k

SpeedyWeather.jl/src/physics/large_scale_condensation.jl

Lines 91 to 93 in ca898de

	# If there is large-scale condensation at a level higher (i.e. smaller k) than
	# the cloud-top previously diagnosed due to convection, then increase the cloud-top
	column.cloud_top = min(column.cloud_top, k) # Page 7 (last sentence)

SpeedyWeather.jl/src/physics/convection.jl

Line 145 in ca898de

column.cloud_top = min(column.cloud_top,level_zero_buoyancy) # clouds reach to top of convection

But as you can see that's more a part within the large-scale condensation scheme which we discussed in #439, #447, #445. And the simplified Betts-Miller convection scheme #442 and #436

This doesn't sound like "has clouds" to me. At the very least I would expect clouds to reflect sunlight, as they have such a strong cooling effect on the planet.

Yes, I agree with that, but that's not yet part of the radiation scheme. Think of clouds currently being invisible.

Next more advanced steps would be cloud formation being physics based instead of RH = 100%, and cloud aggregation and finally precipitation. But the just the reflection is what I'd take honestly.

That's not how many precipitation parameterization work. Maybe that's a poorly communicated misunderstanding: In most climate models you can have precipitation without having clouds. From a microphysics perspective you need the droplet formation, then the growth till the droplets become so heavy that they fall down and you have precipitation. Macroscopically, however, the actual cloud formation is never resolved and so RH > 100% (or some lower value sometimes) is just considered condensation which is vertically integrated to give you precipitation. So while clouds are only diagnosed, we have precipitation from both large-scale condensation and convection. Sorry that is not yet documented yet. I've only changed the convection scheme in #442 and didn't want to document before this part of the parameterizations is more stable.

Okay, this confused me. By reading the README, I got the impression that Ι could add clouds

No climate model actually has clouds. Droplet formation occurs on scales you can never resolve and so the question is how you mimic the occurence, their properties etc. At the moment we diagnose clouds where condensation and convection occurs and you could define your own scheme that uses that information to do something else, e.g. reduce shortwave radiation where there's a cloud or calculate outgoing longwave radiation from the brightness temperature at the top of clouds etc.

You are right that we should allow users to add as many tracers as they like, e.g. ECMWF's model uses next to specific humidity four other water species, cloud liquid water, cloud ice, rain and snow. Their interaction gets enormously complicated and probably defeats the idea of a "simple" model. So for now, I feel the best balance between too complex to be simple and good enough to simulate a realistic climate would be to move around specific humidity, diagnose clouds and their properties like optical thickness and let that influence radiation. And nothing currently stops you from doing that, a respective radiation scheme is just no there yet.

But your comment gives me the impression that this is not the vision of SpeedyWeather.jl? Otherwise why would you be reluctant to "add" something as an option? Just hoping to clarify here, I am not challenging your view. In my ideal world, there would be such an option with a basic cloud scheme that interacts with radiation that I could turn on or off at will.

Yep, that's exactly the idea, one should absolutely be able to do things like

PrimitiveWetModel(;spectral_grid, clouds = NoClouds())

such that any clouds would be invisible to the radiation scheme that calculates radiative fluxes based on optical thicknesses. Maybe intuitively that should also disable large-scale precipitation and deep convection, I see your point, but as I said above most of these schemes can produce precipitation just by assessing whether humidity has reached saturation. There should als be options to switch on clouds only for long or shortwave radation, and whatever people think is a sensible simulation. That's why I asked you: What would you like clouds to do? Reflecting incoming solar radiation is on my todo list, but you don't need cloud liquid water to be a prognostic variable for that.

Thanks for your inputs!!!

[Datseris]

perfect thanks, this clarifies a lot. I know very little about simulating clouds; all of my scientific work so far has been about the impact of clouds on climate (albedo and greenhouse), so I never thought of it this way. Of course, it makes perfect sense now that you say it that it isn't clouds that one is tracking, but cloud liquid water or ice. And I can see how this would be too complicated for the package scope.

Your suggestion makes the most sense to me for tracking specific humidity and inferring clouds based on simple parameterizations. If one can infer (or even track) optical depth then you have everything you need for albedo or greenhouse effect depending on the wavelength the optical depth corresponds to.

My own research shows that the greenhouse effect of clouds and their abledo seem to be almost entirely proportional to each other (like, longwave CRE is 0.5 times shortwave CRE) so in essence if one tracks shortwave optical depth that seems to be the perfect amount of information for "having clouds" in an intermediate complexity climate model like this one.

plot that shows that one needs only shortwave CRE at a first approximation:

shortwave and longwave CRE (from CERES) versus surface temperature (from ERA5) stratified into 3 characteristic types of cloudiness regimes. It isn't too bad of an approximation to say that LCRE is 0.3-0.4 times the SCRE.

[Datseris]

There should als be options to switch on clouds only for long or shortwave radation, and whatever people think is a sensible simulation. That's why I asked you: What would you like clouds to do?

The incremental levels of usage would look like:

Level 1: just shortwave interaction; level 2: also longwave interaction, allowing to turn on or of either; level 3: beign able to directly access and alter the parameterization parameters; level 4: allowing for different parameterizations for "making clouds" that don't follow the traditional logic of microphysics -> cloud droplet formation -> radiation scheme. So that I can prescribe a "cloud albedo" field that reads in temperature, humidity, and whatever else I need, and outputs Top of the atmoshere cooling or warming, or per-pressure level cooling or warming. Does this level 4 make sense? In my work i am testing cloud "hypothesis" in conceptual models and I am still struggling to see how I would bring them into a "normal" spatiotemporal climate model.

[milankl]

Your suggestion makes the most sense to me for tracking specific humidity and inferring clouds based on simple parameterizations. If one can infer (or even track) optical depth then you have everything you need for albedo or greenhouse effect depending on the wavelength the optical depth corresponds to.

Awesome, thanks for all the input! I believe from a modular perspective it makes most sense to introduce a model.clouds component <:AbstractClouds that (somehow) calculates the optical thickness (single visible spectral band for shortwave, maybe on several longwave) which can then be used by a radiation scheme that computes the radiative fluxes from layer to layer. I'd be happy to have any input here what you think makes sense in terms of a good balance between general enough to be modular but not too complicated enough for simplicity and speed. As always we want to find a good balance on the good enough for a somewhat realistic climate versus unnecessarily complicated spectrum.

For example, model.clouds could be set to NoClouds() which sets the optical thickness to some constant default (what does the thickness all depend on?) but one can then define their own MyClouds <: AbstractClouds to make this more complicated, e.g. being a function of specific humidity, or also whether condensation or convection occured. The interface between large-scale condensation or the convection scheme might not be easy for modularity, but I'm sure we can figure this out.

If you have any good resources on simple cloud schemes, please post them in here?

[Datseris]

I don't, but I'll try to find some...

[sit23]

Just in case it's useful, this is the cloud scheme that we introduced within our Isca idealised modelling framework:
https://gmd.copernicus.org/articles/14/2801/2021/

[milankl]

Hellooo the Isca team is here! Welcome welcome. Thanks for that input, this looks great and I will give it a shot. You mind me asking you here for clarifications if I end up having questions? George, I don't know how much capacity you have, but happy to work on this together!

[Datseris]

I have ultra low capacity, but I am willing to help. I am happy to code the simpler aspects of any scheme you need. For example the first ten equations of this paper I could easily code up. I've also worked extensively with cloud diagnostics, especially for low clouds, so happy to code these up as well. Already got the code online actually: https://github.com/Datseris/MinimallyFittingCloudiness/blob/master/src/thermodynamics.jl

Happy to code in tests as well. Happy to provide feedback to ensure the API is simple and well usable and extendeble, like I have ensured for DynamicalSystems.jl and Agents.jl. Happy to write docs. Happy to update the parameters of any cloud schemes to better fit currently observed CERES data; I anyways do this for my job currently.

These are all things I could do. I think when it comes to e.g., dynamic core or coupling to the radiation scheme I can't help. Generally speaking if I have to obtain a significant amount of new knowledge I'll probably not be able to do it.

[milankl]

Ultra-low capacity still you are willing to do a lot, much appreciated! With #502 I've also included a transparent shortwave radiation that currently just fluxes straight into the lower-most atmospheric layer. I want to change this to a simple optical-thickness-based shortwave radiation so that we can plug in clouds by modulating that optical thickness and the fully transparent atmosphere should then be just the optical thickness = 0 case again. We could then define a cloud parameterization as a function of (relative) humidity, condensation and convection to give us optical thickness in shortwave (or also longwave). I could ping you here once we're at that stage?

[Datseris]

Sounds perfect to me. Optical thinckess seems a good approach. You would also have a "longwave optical thickness" as well I guess? So that clouds also modulate the greenhouse efffect?

[milankl]

#606 introduces optical depth as a diagnostic variable in the column. My idea is to first run the condensation/convection schemes so that information from there can be used to determine the optical depth. This can be then used by the radiation schemes.