What Happens In A Climate Cell (Model)

In a prior posting I looked at how to choose a cell gridding or placement method:

https://chiefio.wordpress.com/2020/11/08/there-is-no-good-coordinate-system-for-climate-models/

In this posting, I’m looking at what happens inside a physical cell and ways to properly reflect that inside the model cell.

This likely would work best with a graphic, but my graphics skills are primitive at best and the time it takes not available to me at the moment. So text it is.

Basic Cell vs Sun

In my view, the cell is first defined by the location (latitude, longitude, average altitude) and then what that means in terms of ’tilt’ of that cell toward the sun line. So, for example:

A cell at sea level at the equator would be 0 altitude, 0 tilt, 0 latitude, and {whatever} longitude.

A cell at the north pole would be 0 altitude, 90 tilt, 90 latitude, and {any / all} longitude.

A cell at 45 north in a mountain containing area could be 2000 m altitude, 45 tilt, 45 latitude, and some longitude.

A cell at 45 south could be 100 m altitude, 45 tilt, -45 latitude, and some longitude.

The Lat and Lon can be used to calculate tilt relative to the normal sun line, then tilt can be used in conjunction with season (and procession and wobble and… if desired) to calculate % of solar output that is incident on that cell.

Pretty much all of this can be computed once in advance and stored as parameters for use during a model run. In this way your “Globe” becomes a “disco ball” with tessellations defined allover the surface relative to the sun line. The model run just needs to ‘rotate the ball’ and calculate the change of actual ‘angle to sun’ as the cell/tilt rotates relative to the sun (and nods up and down with the season). FWIW, it would be possible to pre-compute those parameters once and store them also; but it would require some testing to find out if the (very slow) read-in process took more time than just recomputing it with each turn of a time period.

A 10,000 cell “globe” would need 240,000 parameters if the time step is one hour, then x 365 to cover the annual changes of axial tilt. That’s 87.6 Meg parameters that would need to be stored / read in, for each year of run time. Even at several parameters and long words, the number of MB is very manageable. Even at 10x it would be under 1 GB of data. Many larger memory SBCs have 4 to 8 GB of memory, so caching is possible. Even if not cached, a 1 year model time run would require reading all of 1 GB of data. If a year of model time is completed in 1 minute, that’s 1 GB / minute. Very easy on a 640 MB/second (38 GB/min) USB 3.0 channel.

I’m pretty sure that calculating the sunlight incident on any single cell is easily handled with just these values, and that it is easily handled in a modest SBC (likely with computes and memory left over).

I’d start with a model that used a TSI Solar Constant, but later I’d change that to a variable sun where the spectrum shift (that we saw happen) of up to 10% is incorporated.

Layers Of Layers

But sunlight does not just fall on a cell and be done. Different things happen in different layers of the path.

The path has parts.

Atmosphere, surface {water, dirt, vegetation, snow / ice}, subsurface {ocean, earth}.

Here IMHO we need to layer the air at least into the gross layers of Mesosphere, Stratosphere, Troposphere. I think we can ignore the thermosphere (where the space station and many satellites orbit) until proven otherwise. The Mesosphere matters as that’s where the Ozone Layer absorbs a lot of UV and solar shifts in amount of UV will matter. But perhaps it can be left out of a ‘first cut’. The Stratosphere is where actual IR radiance can happen. The Stratosphere can actually reach the Earth surface at high polar altitudes when in the middle of a dark winter. A complication that really matters, but will be difficult to get right in a model. Then the Troposphere is where IR is ineffective at moving heat, so turbulent convection is the dominant method of heat transport. It is also where most all of the weather happens.

As there is a hurricane Cat 2 wind going sideways at the Tropopause, I think it matters a very great deal too, but I’m not sure how to handle that. Have a specific layer? Average the mass flow into the stratosphere and not worry about it? Somehow one must get that wind taking huge tonnages of air from the equatorial rise to the polar vortex descending. It ought to show up as an emergent phenomenon, but then you need very thin layers… So that’s an open issue. I suppose as an initial kludge one could just program in that air from the Troposphere top gets moved sideways in a layer toward the poles, with some leakage to the stratosphere. Hack it in as a “if air gets here, it goes there”… Then come back later to make it emergent? Hmmm….

I think that is enough layering to handle the major differences in absorption, weather events, chemistry, and IR path length (at least for a first cut). Eventually it would be helpful ( as my best guess) to have layers as thick as the typical tropopause thickness for all layers and then model each one with the known physics of them; but that’s definitely a ‘way later’ enhancement.

Then you have the Surface Layer:

This is a (roughly) 100 M thick layer of air that is strongly influenced by the dirt or water below it. I think this layer must be considered along with that physical floor surface.

This is where the sunshine hits the road (or forest or ocean or…) and turns into heat, either as temperature or evaporated water, with some turned into chemical energy in plants. The physical heat portion can be transferred from the surface into the boundary layer of air. This causes it to warm during the day, destabilize, and rise. As water on the surface evaporates, it also makes the boundary layer air less dense ( Nitrogen 32 mass, water vapor 18 mass, so lighter) and enhances rising.

That says, to me, that key functions of the surface interaction are absorption vs reflection (albedo) and for ocean, transmission into the depths, then propensity to evaporate water into the air, and any vegetation effects. This is where we must handle the varying wetness of surfaces, changing snow / ice coatings, vegetation transpiration (and the tendency to self regulate to about 86 F leaf temperature via transpiration). IMHO, this is likely to be the hardest bit to get right.

So we’ll need parameters for Albedo by season / weather events, surface type (dirt, water, vegetation where vegetation will change by season as can dirt vs vegetation) and a way to figure out how much water will move from the surface (at whatever the present wetness might be) into the boundary layer.

Initially this can be simplified to just average albedo and surface type, but expanding the detail handling of the surface and boundary layer is where a lot of the work will need to go.

Think we’re done?

Nope.

A cold surface has a huge heat sink below it. You can think of the dirt of about 10 cm thick having a significant change of temperature during the day, but with a very slow heat transfer to / from the larger block of dirt and rock below it. This can be modeled as a large capacitor with a resistor to a smaller block of surface. Overall, the Earth has net heat flow OUT from the several thousand degrees core temperature to the air, then space. So overall, the net heat flow is out of this sub-surface rock into the boundary layer.

BUT, the heat flow is extraordinarily slow as rock is high R (resistance to heat flow) value. In general, I think we can ignore this essentially net heat flow out. Yes, it matters. But IMHO it matters a whole lot more at the various plate boundaries where boiling hot water and / or magma come flowing out. We have no real data on heat flow at the ocean bottom, but it is vastly more than on the continental land away from volcanoes.

Yet on a yearly basis, the heat flows into the top couple of meters of dirt / rock in summer, and out in winter. It takes a couple of months to make the surface rocks cold enough for snow to stick. It takes a few months for the spring warmth to soak in. I suspect it is a significant part of why our seasons lag the insolation angle by a couple of months. How much, how fast, how big? All need a bit of investigation. Initially, I’d set it to a Fudge Factor. Just something like “soak in surface temp delayed by a month”. Eventually it needs decent modeling on it’s own. Any depth over about 2 meters can be set to the constant 56 F which is about the average air temperature of the planet.

So initially it’s a plug number wobbler, but eventually needs to be done better / right.

Ocean is more complex.

For the ocean, we again need a ‘surface layer’ were IR at the surface all causes prompt evaporation, but red and blue and remaining UV soak in. I’d include about a 10 m mixed layer that over the length of the day mixes in any surface delta-T. Then you have the water down to about 100 M where red and blue light are all absorbed. UV can go to the bottom of that, or even below to some amount. Exact depths need to be worked out as those are ‘guesses’ based on what I know from scuba diving.

Initially, I’d model it as a surface that absorbs all IR and turns it into water vapor, then the Red through Blue absorbed as heating into the next 100 feet / 30 m. Yes, at 100 feet in the tropics there’s still a lot of light. Yes, it ought to have a ‘turbidity’ factor and ’tilt matters’ too as depth is directly toward the core of the gravity well while solar light path is directly along line to the sun, so at the poles you get a near infinite path length at near zero depth as the sun sits on the horizon in fall. I’d put that off for later, as I’m pretty sure there’s bigger fish to fry first. At the pole in fall you have near zero light / heat incident anyway, so handling it perfectly isn’t so important. At the equator, having all the heat in 30 m instead of 50 m is likely not that important. That we don’t have enough granularity to handle major ocean currents and gyres is likely a bigger issue.

So I’d have a surface layer, visible absorption layer, then below that any residual UV. At about 1000 M you can assume it is 4 C and constant. Again, exact numbers need a “dig here” to set. Currents need to be added “someday” to get heat flow correct. In a ‘first cut’ one might need to add them as mass flow average plug values between cells.

That, I think covers the question of layers and layering for the first cut at a cell model “well enough” for now. When (if?) I ever get that much programmed and running, I’ll be thrilled…

Order Of Processing

The model MUST converge, or it is trash. For that reason, I’d not be too hung up on starting values. Most anything reasonable ought to converge toward more reasonable, or you need to fix something in the model. Set starting values to approximate averages from some year and “move on” (to debugging, fixing, and tuning to reality… but note when your “tuning” is really patching over a missing bit of reality, like those ocean currents and their heat flows…)

I’d have an initial TSI Solar Constant, then in Version 2.0, change that to a variable solar spectrum with solar cycle (as has been observed). Why? Because I believe that is a major driver of the system, the spectrum shifts, and I’d like to see how the model runs both ways and compare.

Then that solar power arrives at the “top of cell” proportional to tilt / season. Each atmospheric layer absorbs the portion of that light which it normally captures, or reflects. For the tropospheric layer, that includes the initial %Clouds and their thickness. When it reaches the surface, the albedo and surface type determine absorption. Light gets turned to surface heat, or water evaporation, or goes into ocean depths. This is where a lot of the Real Work gets done on “getting it right”. Then that heat and water vapor gets moved into the boundary layer of air. Reflected light goes back toward the relevant layers (but I suspect this can be ignored… if you already absorbed the UVC incoming does the blue outgoing matter to the stratosphere? Some noodling needed here…)

Now you get to figure out how to do inter-layer mass transport and weather computing. Sigh. Don’t have a good grip on this yet. So {wave hands} a density change needs to result in a velocity upward. This becomes a “mass / unit time” into the next layer. Some of this turns into lateral air flow (wind) proportional to volume change. Then, the really hard bit:

Send in The Clouds

As air rises into the Troposphere, it cools. At some point water vapor condenses. This can be fog in the surface boundary layer (model with RH vs T ?) and clouds at some level. In reality, you can have ‘cloud decks’ at 1000 ft levels from zero to 40,000 feet. Call it 40 to 50 layers are really needed. Then there’s a few dozen kinds of clouds, infinitely variable opacity from 0 to 100%, layers that can be a few feet thick up to a thunderhead from ground level to 50,000 feet.

Clouds are CRITICALLY important, as in ‘cycle 2’, they determine how much of the sunshine makes it to the surface to drive all the rest. They also happen at far finer granularity than the size of a cell. So “what to do?”

Initially, I’d use a table of “average cloud by month” for each cell. Likely fairly easy to get the data and not that much data entry. For 10k cells, that’s 120k values. This is “good enough” to let you work on getting the rest of the model right. What is BREAKS, is the feedback loop from surface heating a wet surface to more cloud to more shade and more rain. It is a big crowbar setting things to AVERAGE. I’d do the same thing with precipitation by month, initially.

Longer term, you must find a way to get clouds and precipitation right (and is that precip rain or snow or ice or ???). Shorter term, just saying “on average it snows 8 inches in November” and put 8 inches of snow on the ground along with the appropriate temperature is “good enough” to start debugging the rest of the model (the air and land).

This is where the bulk of the work in “Version 2.0” or maybe even “Version 3.0” will be. IMHO, it is likely why the present “Climate Models” are so concentrated on radiative physics. Clouds and precipitation and convection feedbacks are hard. Radiation is a formula.

Time Step

AFTER all that stuff is done and calculated, you take a Time Step. Mass flows to other cells along with heat amounts and water and such are all moved to those cells input buffer. Cloud values (eventually…) set and new insolation % figured. Surface changes set (i.e.is your ‘dirt’ now ‘snow’ as the weather model says snow happened?). Mass and water flows into this cell are integrated. Basically, you move all the surface and mass flow stuff around, taking their heat and water changes with them.

Then you do all your calculations again.

So I see the general flow as:

Read in parameters / values by season / date / time. Start.
Calculate Light In (solar values, cell parms, time).
Distribute light energy by layer absorption and reflectance values.
Calculate temperature changes, water vapor / ice melting changes (phase changes), mass changes (air density, pressure, etc.)
Calculate ocean energy / temperature changes (eventually).
Figure cycle mass flows out (air / water to next cell, clouds to next layer, etc.)
Calculate any radiative model leftovers.
Set any changes to initial parameters (such as snow on dirt, etc.)
Next Time Step.

That’s all just a ‘first cut prototyping’ spitball subject to massive changes as desired. Just sayin’… it isn’t considered significantly valid and will change.

In Conclusion

That’s where I’ve got to. A solar centric, water moderated, tropospheric weather modulated, convective first, radiative at the end; model. IR Radiation out from the Stratospher (where it happens and where it is driven by CO2 et. al. as a cooling gas) and CO2 ignored in the troposphere where it can’t do anything as the radiative window is closed (which is WHY we have a Troposphere…)

With a whole lot of details to be worked out over time.

I’d start with One Cell with fixed parameters. Once coded, move parameters to a ‘read file’ in. Then add a few more cells around it, test flow between cells and data in from “plug number files”. Once any insanity behaviour is stamped out of it, use a globe of about 100 cells and ‘reasonable’ estimates of values running on one computer and ‘see where it goes’. IFF that has any crazy behaviours, polish on that until no longer insane. (Things like snow in the Sahara or a desert at the north pole.. or 200 inches of rain in Los Angeles…) Then try to expand the number of cells and move to distributed processing. (That’s a big lump ‘o work just for the data entry. Figure a reasonable 10k cell model will take about 20 data items input so 200k items to type. At, say, 10 char per item, that’s 2 Meg keystrokes… or one works out a data loading script… but it’s days+ in any case.)

I figure I can get one cell running, and even expand it to a dozen cells, all by myself. Perhaps even I can get the 100 Cell Globe to run. At the point that I’m trying to get a 10K to 100K planet running with added clouds and ocean currents: It will take several people and a lot of hardware (i.e. money) IMHO. So we’ll see how far I get, and it won’t be happening fast as this happens in my “left over time” that is not much.

So there you have my best guesses on it all.

Start throwing rocks and ideas at it. Polish time welcome.

Subscribe to feed