EarthIn the config file example15.cfg, combined with materials_earth.cfg and material_map_earth_hires.cfg a simple model for Earth with an atmosphere and oceans is defined. The actual configuration reads as follows:
Most sections should be famililar by now. The materials map contains a 10 deg by 10 deg resolution version of Earth's surface with a coarse mapping of surface properties. The atmosphere_basic block reaffirms that the parameters estimated by processing the atmosphere block should indeed be use. The hydrosphere_basic block defines that oceans contribute to heat transport as much as Earth oceans (oceanic heat transport is only calculated between materials declared as water) - potentially a world could have much shallower water-covered surfaces which do not contribute much to heat transport. The ice_buildup_factor can be declared for a similar purpose - if there is a reason oceans would not freeze quite as much or even more, it should differ from unity. The random_seed keyword allows to generate a reproducible simulation - this is relevant since the weather code introduces a lot of randomness. If left out, each run of the simulation will be different.
SeasonsExtracting the temperature distribution from the simulation works as discussed in the previous tutorials, i.e. by evolving the simulation for 1-2 years to remove initialization artifacts and then requesting a surface plot. The result may look as follows:
While the year-averaged average temperature is about 288 K as in the real case, the seasons in the simulation appear rather harsh - winters tend to be really chilly and summers rather hot. Extracting sea ice via
reveals that fairly large parts of the ocean freeze in winter (surprisingly, this affects overall Earth albedo very little - in Winter, water surfaces without ice cover are hit by the light under shallow angles, and that means that the albedo is fairly high also in the liquid state).
WeatherUsing a recording, the weather on a specific location can be investigated as a time series. The following request generates a fairly comprehensive weather analysis:
This can result in the temperature and precipitation evolution
The simulation gets the presence of a rainy, hot and a dry, colder season as realized in some tropical environments - Hanoi/Vietnam shows this (albeit shifted because it is on the northern hemisphere) Manaus/Brazil has a more constant temperature. Day/night temperature variations are generally low, so the results are not completely crazy.
The reason for the seasonal variation seen is the movement of the Intertropical Convergence Zone (ITCZ) with the sun angle. This movement happens all over the globe in the simulation, but in reality it is basically absent in South America, so the simulation does not account for the climate in Brazil properly. Looking toward higher latitudes finds again very harsh winters and hot summers. One might suspect that this is an issue of transport - perhaps increasing the transport coefficient leads to a more realistic result with excess summer heat transported to the winter hemisphere and increasing the temperatures there. However, it is more likely that what is seen here is the effect of a missing simulation of latent heat.
Latent heat (and why it is difficult)When the Sun warms moist terrain, only part of the energy goes into increasing temperature, another part ends up evaporating water. For any given terrain, the Bowen ratio determines the relative amounts. That however means that if the latent heat needed for evaporation is considered, a summer day ends up being less hot than when this is neglected.The reverse situation is realized in cold temperatures. When moisture condenses or water freezes into ice, latent heat is released, corresponding to an additional heat source which increases the temperature relative to the situation where no latent heat is considered. Both effects would clearly go into the right direction to mitigate the harsh seasons on simulated Earth. Why then does the simulation not simply consider latent heat? The reason is that in order to do so, the simulation would have to track the transport of moisture. This however is very different from the transport of heat - heat flows on average from hot to cold regions, but moisture does not flow on average from wet to dry. When in liquid state, water flows downward, so the simulation would need to include elevation profiles. Part of the water might evaporate on the way, part might end up underground, so other properties of the local terrain matter. When frozen into ice, water is essentially static, but when evaporated, it can be carried by the winds over large distances. Again, mountain ranges can act as barriers leading to copious precipitation on the windward side and dry conditions leeward. The local temperature of the air crucially matters for how much moisture it can hold however. All this requires another order of magnitude of detail as well as a much higher spatial resolution to capture a meaningful elevation profile of the simulated planet, which is why it is simpler at this point to accept the overly harsh conditions in the simulation and make a correction outside the code if desired.
Continue with Ice ages. Back to main index Back to science Back to worldbuilder Created by Thorsten Renk 2023 - see the disclaimer, privacy statement and contact information. |
