Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Climate Model Research #9
Found this while trying to find support for my k1 + k2cos(6lat) + k3(1-lat/90) - k4dist_to_cont_edge*sin(lat) model.
Evaporation and precipitation vs. latitude.
This might prove useful…
We should be able to easily work that into the shader code - relevant code is in "scripts/view/fragment/template.glsl.c" and "scripts/view/fragment/FragmentShaders.js"
Something relevant to mention: for the last year or so I've been working on a experimental branch to overhaul the crust model to address problems while working on issue #8 and #1 (it's the "tests/field" branch if you want to try it out on your machine, if so let me know what you think). If I can get it working, it throws the door wide open for proper climate modeling. So now is a good time to think about pie-in-the-sky climate models, because they just might be feasible soon.
There's maybe just one issue I need to work out before I'm comfortable merging that branch with master. It needs to handle plate collision a bit more sensibly: continental docking, accretion, etc. It already generates sensible looking planets, but it doesn't have code in place to accrete continental crust, and I'm unsatisfied with that
useful or interesting links:
Rules of Thumb:
also bought a super cheap book on amazon: https://books.google.com/books?id=3lcnDwAAQBAJ&printsec=frontcover#v=onepage&q=GCM&f=false. The 2nd edition is just $8
I can finally see how 2d fluid simulation could be done with our model. The only problem: most fluids on a real planet require 3d fluid simulation.
OK, really excited now.
I'm prototyping a climate model based on what I see here: https://imgur.com/a/UNvLF#vrrcARn. Nowhere near scientifically valid (at least not yet), and probably has lots of bugs.
We start with a simple model for air pressure based on latitude. It's just a few bands of alternating high and low pressure, represented by cosine of latitude:
Offset the latitude to simulate winter (I think this is the right thing to do):
Result looks boring because there's no land. So let's find out where the land is:
Smooth it out with binary morphology and the diffusion equation. This part is costly, performance-wise.
Land has different pressure effects depending on hemisphere. IIRC land in winter gets higher pressure:
Turn this into a function in the AtmosphericModeling namespace, and add a "season" parameter (season==1 for winter in the northern hemisphere and season==-1 for summer in the northern hemisphere)
OK, now we add the two effects together:
Density times the gradient of pressure is acceleration, but we pretend it's velocity.
Now just add the coriolis effect:
You can see how air gets deflected around landmass:
BTW, you should be able to run all this code in the Developer Tools console. I've also got a "atmo-model" branch out with this stuff added.
I have these features implemented in prod.
The models aren't strictly rigorous, not scientifically. Pressure and velocity are scaled to the right units, but the pressure model is hand wavey (kind of like existing models for precip and temp), and using gradients to find velocity is not strictly correct. Strictly, density times the gradient of pressure ought to be acceleration, not velocity, but it is suggestive of velocity and it's much more performant than actual fluid simulation.
I need a model that can be run in less than a single frame. It needs to return the average climate over millions of years, not years or decades. There's not a lot of GCMs that meet that criteria. I expect the correct model I'm looking for either relies on statistical mechanics or a steady state assumption. I need to do some more reading.
The next thing I'm going to work on is probably temperature. I have a branch out there to model orbital mechanics, specifically distance and orientation relative to the sun. I'd sample over several points in the day and several points in the year, find equilibrium temperature for a black body at each point, then average them out to get summer/winter temperature.
I'm going to have to look at this more closely later, but the pressure doesn't seem to take landmasses into account currently. I'm also just guessing here, but it looks like you're still using "my" handwavey precip model. Looking forward to a flow-based model. In the longer run, it looks like that flow-based model may be applicable to overland water flow and thus considerably prettier erosion, and sediment deposition effects. If you get to that point, exporting high dynamic-range elevations will become a lot more urgent……
On Nov 11, 2017, at 4:04 PM, Carl Davidson ***@***.***> wrote: I have these features implemented in prod. The models aren't strictly rigorous, not scientifically. Pressure and velocity are scaled to the right units, but the pressure model is hand wavey (kind of like existing models for precip and temp), and using gradients to find velocity is not strictly correct. Strictly, the gradient of pressure ought to be acceleration, not velocity, but it is suggestive of velocity and it's much more performant than actual fluid simulation. I need a model that can be run in less than a single frame. It needs to return the average climate over millions of years, not years or decades. There's not a lot of GCMs that meet that criteria. I expect the correct model I'm looking for either relies on statistical mechanics or a steady state assumption. I need to do some more reading. The next thing I'm going to work on is probably temperature. I have a branch out there to model orbital mechanics, specifically distance and orientation relative to the sun. I'd sample over several points in the day and several points in the year, find equilibrium temperature for a black body, then average them out to get summer/winter temperature. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Pressure does take landmass into account, but the effect only exists during the solstices. Try moving the season slider.
Precip is still your model. I'm unsure how to continue on that front. I know high pressure regions like the "horse" latitudes should be drier. We could also advect wind velocity to determine where water evaporates from the ocean or where rain shadows exist. I don't have a good mechanistic model for evaporation or precipitation, but that's what I want as well.
Erosion is already flow based, in a way. It's sort of related to the gradient of elevation. I spent a lot of time thinking about ways to simulate river valleys this year though and it will take a different approach to do so. A problem I foresee will be grid resolution. It's already working close to the limits to what we can do in a single frame. We can speed up diffused pressure fields for the mantle and atmosphere by switching to a coarser grid, but we can't take that approach for river valleys.
EDIT: I misunderstood what you meant by flow based erosion. Yeah, any improvements we make to precipitation can be fed immediately into our erosion model.
Okay. I see the season slider now. As a preliminary model, it's very cool. It doesn't look like you have an arctic/antarctic high pressure zone. It's going to be strong, because the flow geometry and the really cold temperatures are going to collaborate to pile up low altitude air. My precip model is actually probably a better model for surface pressure(lows for high precip, highs for low precip, so an inverse model. It needs more research than I bothered with. It was definitely a bit of educated handwavery. For a precip model. I think I might look into a "fetch"-based model. Trace winds back to the nearest patch of ocean and base precipitation on inverse distance traversed. The farther water is along the wind path, the less rain you get. Give bonuses for orographic uplift and penalties for falling terrain. Should work better than decreasing rainfall with distance from shoreline… I also think the weaknesses in the temperature model start to make themselves apparent with that season slider. What it really is is an insolation model pretending to be a temperature model, much as pressure gradient is acceleration masquerading as velocity. Unfortunately, the downsides of that pretense show up a lot more clearly with the temperature model. If you are familiar with octave/matlab code, I can send you a decent-ish 1d+time insolation model and try to work up from that. May or may not be helpful. As to eroding river valleys, that's a tough one. Even on an 8192x4096 equirectangular grid(I call that 8k), each pixel near the equator is going to represent something like 5km on the planetary surface. Also, to work decently, those river valleys are going to need to be at least 3 pixels wide minimum. Maybe 2 at the outside. Even a 16 or 32k equi grid is going to have a hell of a time with that, and realistically you don't want to mess with a grid that big. Regretfully, I think that should sleep on the back burner.
Yeah, how should I fix that? Right now it's
I think there's two things that can help with that in the not-too-distant future: 1.) black body equilibrium temperature (mentioned earlier, this is what I'm working on today), and 2.) advection.
Go for it.
Sounds like advection in essence. For each parcel of air, back-calculate previous position at some timestep. Sample winds from that position and use it to back-calculate further. Repeat as many times as you can afford in a single frame (it might only be once). However many times you choose, it traces a path. Follow that path forward and calculate evaporation and precipitation along the way in some time sensitive manner that's consistent with your back-calculation timestep (you could possibly do this going backward, but it's probably easier to think about if it goes forward). The back-calculation timestep is completely decoupled from the tectonics timestep that occurs every frame. It's shorter by many orders of magnitude, and it should be proportionate to the time it takes for global average windspeed to traverse one grid cell.
yeah, totally agree
I've been looking at potential evapotranspiration models.
Priestly-Taylor sounds like it's the simplest but requires an empirical factor that varies by location, so that's probably out for the long run.
Penman-Monteith is pretty well regarded and we may be able to supply it with all the parameters we need, but it's probably most complex and it involves things like stomatal conductance that would require assumptions about the planet's plant life.
Penman is simple and only seems to require parameters that we either already have or could potentially represent in the model.
Penman sounds preferable for the long run, but we might get away with Priestly-Taylor for a first pass.
My first pass at a mechanistic temperature model was to calculate black body equilibrium temp for each grid cell given that cell's insolation:
Obviously, this doesn't work because the poles reach absolute zero, but I figure it could be a starting point.
Next, I took black body equilibrium and tried to simulate some advection/diffusion.
This resulted in an unrealistic graph with jagged peaks and valleys. This is because I started with black body equilibrium, which features a very sharp drop off where the poles reach absolute zero. The jagged drop off propogrates from advection/diffusion. Advection and diffusion need to operate on temperature fields where advection and diffusion have already been taken into consideration, so its sort of a a chicken-egg problem.
The best solution I found was to take a moving average of black body equilibrium.
Except now it's hand waving. I don't have any way to tie the parameters of the moving average model to the parameters for a sensible advection/diffusion model. I have no idea what the size of the moving average window ought to be. I can try to match it to fit observed max/min temp for earth, but what's to say that would apply to other planets?
More to come...
Next I tried a simpler model. It couldn't get any simpler: two parcels of air, one at the poles, the other at the equator. It looks a lot like two black bodies in equilibrium, except now there's an additional energy flux that represents how convection moves heat away from the equator and towards poles.
I played with it for a while. I found I could predict temperature given wind velocity, but then I'm still left with finding velocity. I found I couldn't get anywhere without introducing additional constraints.
The diagram above was so simple it reminded me of one of those diagrams for a heat engine, and it turned out the analogy is pretty common knowledge. The atmosphere is a kind of heat engine that transforms heat into mechanical work in the form of wind. You could use this fact to predict the maximum theoretical efficiency of the heat engine, and that would give you an upper bound for how strong the wind blows, but that's not quite what I want.
At some point while researching heat engines, I stumbled on this paper:
Wouldn't you know, that's the same diagram I drew!
So here's what the paper is saying: just like any other heat engine, the atmosphere produces entropy. Entropy is the ratio between output energy and temperature. In this case, "output energy" is convective energy flux, and temperature is whatever occurs in a given parcel of air. The difference in entropy between the two air parcels should be a good indicator for the entropy produced.
Now here's the kicker: for a complex system like an atmosphere, there's a lot of degrees of freedom, and whenever you have a lot of degrees of freedom, its postulated that the system tends to maximize the entropy produced.
So if you find a W that maximizes entropy production, then that's probably the W you see in real life. If you know what W is, then you also know what max/min temp is. If max/min temp is known, you can scale your temperature model to the correct values. You could either start with black body equilibrium temp and scale it to correct values (might still have jaggies), or better yet, you can parameterize a moving average diffusion/advection model given known min/max temp.
It's still a form of hand waving, but now the hand waving is peer reviewed!
MEP models are freaky accurate. The paper cited above accurately predicts temperature ranges for Titan and Mars. By comparison, the next best model we have for Titan is off by several orders of magnitude. It's also been used to predict temperatures for Earth
Why does MEP work? The best explanation found so far uses statistical mechanics. A highly unconstrained system simply has a higher probability of assuming a state where entropy production is maximized. Dewar (2005) explains why this must necessarily be the case, but I haven't read it yet.
Here's what I implemented using an MEP model:
The vertical line indicates the convective energy flux at which MEP occurs. The intercept between it and the other lines indicate the max and min temp of earth. Curiously, it only gives sensible max/min values for earth when insolation is doubled. I'm not sure why, but I think its a problem with my implementation. It might have something to do with representing only a single hemisphere. I think this was brought up at some point during my reading. I'll have to go back and check.
As you have already observed, the poles experience zero insolation at least some time during the year leading to absolute zero black body temperatures. This problem was disguised in the original script by hardwiring a 23º axial obliquity into the model and only returning the annual average temperatures. As soon as you access the daily temperatures or set the obliquity to zero, the problem becomes obvious. I've had a good deal of trouble figuring out how to do anything like a diffusion in Matlab. To start with, at least, I'd go with something relatively simple, like a convolution kernel.
For best results, I'd do some kind of diffusion both in time and in space. The spatial diffusion, of course would represent movement of warm air over the globe, whereas, the much small temporal diffusion would represent storage effects. Making it two way in time would be a bit odd…
The next step would be to increase the grid to three dimensions(latitude, longitude and day). I'm pretty sure Matlab can handle this, but again my ignorance is showing badly. Or very well…
Your last post started out pretty understandable to me and bounded straight over my head from there. I've been pretty much incapable of figuring out temperatures from your MEP model.
Your moving average model had the best results, so I think you're onto something there. While it's not rigorous as is, I wonder if you've tried using that moving average model as an initial input to a more rigorous advection/diffusion model. You might at least avoid the jagged chicken-egg problem. While not precisely rigorous, the blended model is almost certainly closer to a valid solution than the straight up black body solution. At least near the poles.
One problem I have with sanity checking your moving average is that it displaces the minimum temperature to the right of the pole. Part of the solution, I think is to force the output of all latitudes outside of the range -90<=latitude<=90 to zero. The other, and more important part will be to make sure that the point of interest is at the center of the window. I have the feeling that at present it's simply averaging with the four cells to the right(perhaps weighted, I'm not sure). If the moving average is centered on the cell of interest(average of itself, the two cells to the right and the two cells to the left), the result should have a minimum centered on the pole, even with the repeat.
I figure if you repeated the advection/diffusion procedure several times, the jagged artifacts would work themselves out, but the procedure would be slow or unsatisfactory. I think starting with a reasonably massaged initial state would give best results. Although there is no way that storage(even in water) would damp changes over million year time steps, it would probably pay off, for our purposes, to use final temperatures from the previous time step to initialize the model. That might however fail the sanity check if there are large differences between land and sea temperatures being propagated. Perhaps re-initializing from a moving average black body temperature with each time step might be preferable.
Finally, in response to your question about precipitation and pressures…
One very nice thing, once we can generate winter and summer extremes for temperature and precipitation, we can create better biome maps. Still better if we can model the flow of water over the land surface. If you have even a simple model of upland moisture concentrations for erosion already, then you can probably adapt that to generating something like that. It'd be awesome to have Egyptian or Mesopotamian areas of increased fertility winding through drier areas fed by moister uplands.
Good point. I started out modeling air as a particle moving through the atmosphere before switching to modeling a stationary air parcel. The min temp displacement made a lot more sense in the original model, where the x axis was time.
actually, that's also an artifact of the earlier model. I really didn't do a good job transitioning that!
This is the approach I'd like to start with. If performance becomes a concern we can always rely on temperatures from the last time step to give a better initial guess.
I do think the proper solution going forward is to initialize with black body temp and then run some sort of space/time averaging using parameters from the MEP model. Bonus points if the space/time averaging also happens to be some sort of rigorous physics simulation.
So we want to do two types of averaging: "spatial" and "temporal". I'm pretty sure the "spatial" part can be made rigorous. I'm thinking about using the convection/diffusion equation, but we might only need the diffusion equation. From the MEP model, we can derive max temp, min temp, wind velocity, and what's known as the "meridional diffusion coefficient", D. Taking W from the diagram above, the Lorenz paper says that W=2DΔT. I think the "D" coefficient from the Lorenz paper could be the same "D" coefficient from the wiki article above. I think it's kind of like you're modeling convection as if it were conduction. Even if it isn't, we can simply run the diffusion equation a few times with some arbitrary parameters until max and min temp start to resemble the values predicted by MEP. The thought also occurred to me that the diffusion equation uses the laplacian, and the laplacian operator is sort of analogous to a "moving average" or "convolutional kernel", so that could explain why those methods worked well.
As for the temporal averaging... the only way I see it being made rigorous is to run a simulation over many time steps, but I can guarantee that's going to be too slow.
I know for certain we'll need temporal averaging, because from my own experiments I know summer time black body equilibrium temp is higher at the poles than it is at the equator. I don't think the temperatures in Antarctica ever get hotter than the temperatures at the equator, at least not on average at the same time of the year. The MEP model doesn't solve this problem, either, because it only tells what the max/min temps are, not where they're located.
You mention that temperature model worked around its problem by averaging summer and winter temps. I think something similar could be done for this model, but instead of just sampling two points across time, you could sample from many points and then have some sort of weighted average between them. Let's say you sample black body temperature T from times t=1,2,3. Your weighted average for t=3 could be (3T(3) + 2T(2) + 1T(1)) / 6, or something similar. I'd just like to see if something like this could have some more physical justification. That way, I could put more faith in the results and spend less time parameterizing. I could also potentially generalize a physically justified model to examine a planet across other cycles: day/night cycles, annual cycles, binary star system cycles, milankovitch cycles, etc.
It's probably going to wind up being equivalent to precip during the equinoxes.
I read the explanation by Dewar. It feels like one of those ideas you could explain in a sentence, but every time I try it winds up being a paragraph. Here goes:
Let's say I want to guess the position of every molecule in some random parcel of air. What's more likely: the molecules are all scrunched up in one corner, or the molecules are evenly distributed? You're probably going to say they're more likely to be evenly distributed, but why? Its because there are way more states that describe molecules being equally distributed than there are states that describe molecules being scrunched in one corner. We can phrase this several different ways:
OK, now let's say I drop some creamer into coffee. What's more likely: the creamer stays scrunched up, or the molecules diffuse in the usual way? Obviously the latter, but why? It's because the latter scenario describes more possible outcomes. The statement has more possible interpretations. It contains less "information." It produces more "entropy". You can see this and start to understand how any scenario that produces more entropy is inherently going to be more likely. Once you're comfortable with this, it follows that the most likely scenario of all is the one maximizes the production of entropy.
This statement has nothing to do with physics. It rests solely on statistics, and it's been proven rigorously. If your MEP model doesn't produce the most likely outcome, it's not because the MEP principle is false. Rather, the problem lies with your implementation: what constraints do you use, how did you define entropy, etc.
If I could cut it down to a sentence, it's this: entropy is a measure for how vague a prediction is, and the most likely prediction is the vaguest one
The Planetary Climate Sim here(http://rocketpunk-observatory.com/home.htm) may also be helpful in a broad sense. Turning it into a map would require a lot of work, though. I still need to wrap my noodle around the statistical physics stuff. It seems reasonable from a first reading.
Next step will be to partition out functionality within the World class. There's going to be separate classes for each submodel: lithosphere, hydrosphere, atmosphere, biosphere. The World class is going to be way too convoluted if I properly implement atmospheres without any separation of concern.
As of commit b09df17, the model is producing temperature estimates in keeping with the Maximum Entropy Production (MEP) principle.
This is big: temperature is now being calculated in a scientifically defensible manner. It's not just some trickery like it was in the past when we rescaled mean annual insolation to earth-like temperature values.
I'm solidly pleased with the results:
For a model like ours, which requires really fast temperature approximations every timestep on a world that's constantly evolving, this model is definitely the way to go.
I've been reading more on the MEP principle and stumbled on what could be a solution to modeling seasonal temperatures. Crooks 1999 mentions that a macroscopic system doesn't just tend to maximize entropy production during a steady-state. It maximizes entropy produced across an arbitrary time interval.
seasonal temperature demo:
The dots indicate the temperature at two latitudes, 90° and 45°. Temperature is reported in degrees Celcius.
The arrow indicates the heat flux due to entropy. The heat flux is reported in Watts per square meter.
Note I say the heat flux is due to entropy, not wind. Wind is just one of several processes that contribute to entropy. I would say it's generated by wind, but that would invite confusion as to what's being simulated.
All temperatures are generated strictly from physics simulation using real world parameters. The only parameters fed to the model are heat capacities, insolations, and the greenhouse gas factor.