Curious changes in climt output due to code structure

[HaynesStephens]

• CliMT version: 0.16.3
• Python version: 3.5.2
• Operating System: MacOS (Unix)

Description

For context, I was running test simulations with the same initial conditions. The initial conditions were of a one-column model with a CO2 concentration of 270 ppm and solar insolation of 290 Wm^-2. The differences come from changes that I made in the code, particularly with updating the state['time'] values, ordering between the time_stepper and sympl_physics diagnostics, and ordering between updating the diagnostics and the state values. The simulations were named according to the list below. So the simulation 'test_a1_b1_c1' means that the state['time'] is updated, time_stepper is called before sympl_physics, and the resulting diagnostics are updated before the state values. I hope this all makes sense.

a1 = state[‘time’] DOES get updated
a2 = state[‘time’] DOES NOT get updated
b1 = time_stepper is called BEFORE sympl_physics
b2 = time_stepper AFTER sympl_physics
c1 = for each call, diagnostics are updated BEFORE state is updated
c1 = diagnostics updated AFTER state

Along with the plots, I've attached the respective python scripts, and the jupyter notebook plotting script, in case you wanted to look into them.

My main questions at the moment are:

1. In the python scripts, I've prescribed the solar insolation to be 290 Wm^-2. However, in all of my simulations, the incoming TOA radiation never exceeds about 95 Wm^-2.

2. The precipitation spikes in the beginning, but then falls toward zero as the simulation reaches equilibrium. This is probably tied to the tiny insolation value, but I was surprised to see it nonetheless.

3. In the simulations where the state['time'] is NOT updated, the fluxes shown are relatively flat and smooth with time. But where the state['time] IS updated, the radiative fluxes wiggle significantly (~ 5 Wm^-2). I know that a single-column model has issues with advection, which could maybe result in something like this, but I'm not sure how updating the state['time'] value causes this behavior.

4. I did a rough calculation and wasn't able to match the convective precipitation values with the latent heat flux. I can see in the plots that their trends match, but when I compare the respective peak values (during the spike), I get that the latent heat flux is significantly lower than what the resulting precipitation rate is. My method for switching was just to multiply the precipitation rate, latent heat of vaporization, and density of water (P * Lv * rho_water) to get a rough estimate.

Hope these questions make sense and aren't too much at one time. I would really appreciate some help, and please don't hesitate to ask further questions.

test_plots.zip
test_scripts.zip
plots.ipynb.zip

[JoyMonteiro]

I'm in the middle of something right now, will get to this asap.

However, I must note that the order of calling components does matter (it is a known "feature" of larger models as well). As long as the equilibrium state of the model makes sense scientifically, there is not much else to be asked for.

The issue about updating time is worrisome. I will first take a look at that before others.

[JoyMonteiro]

Thanks for this very detailed analysis. It is great to see such an analysis, since it helps
improve my own understanding of climt :)

Overall, I think the behaviour you are seeing is nothing out of the ordinary.

In the python scripts, I've prescribed the solar insolation to be 290 Wm^-2. However, in all of my simulations, the incoming TOA radiation never exceeds about 95 Wm^-2.

I guess we figured this out offline. This was because the zenith angle was nonzero.

The precipitation spikes in the beginning, but then falls toward zero as the simulation reaches equilibrium. This is probably tied to the tiny insolation value, but I was surprised to see it nonetheless.

Once the temperature profile is moist adiabatic, the convection scheme is mostly
inactive since there is no more CAPE in the column. The sensible and latent heat fluxes
are also tending to zero, meaning there is very little energy input to the column (in the form
of moisture and heat from the surface).

Given these facts, it is not surprising the precipitation is close to zero. I expect the column to
produce rain intermittently when the small LHF adds sufficient moisture, but I would not expect
it to produce rain proportional to the insolation.

In the simulations where the state['time'] is NOT updated, the fluxes shown are relatively flat and smooth with time. But where the state['time] IS updated, the radiative fluxes wiggle significantly (~ 5 Wm^-2). I know that a single-column model has issues with advection, which could maybe result in something like this, but I'm not sure how updating the state['time'] value causes this behavior.

OK, the variation of fluxes with time is expected. I keep forgetting about this, but
RRTMG calculates the seasonal cycle internally based on state['time']. See also
#21. The way to keep it flat is to set the
ignore_day_of_year option. See the documentation here.

I did a rough calculation and wasn't able to match the convective precipitation values with the latent heat flux. I can see in the plots that their trends match, but when I compare the respective peak values (during the spike), I get that the latent heat flux is significantly lower than what the resulting precipitation rate is. My method for switching was just to multiply the precipitation rate, latent heat of vaporization, and density of water (P * Lv * rho_water) to get a rough estimate.

It is not necessary that these values are equal at every time step. One can only expect that
their long-term averages are equal when the model is in equilibrium. In the initial periods, the
model is not in equilibrium (as seen by the fact that the column integrated moist enthalpy is not
constant over time), and the sources and sinks of energy to the column won't balance.

[JoyMonteiro]

Another issue that you don't seem to have raised, but I find the temperature profiles
a bit off. Can you verify that they are moist adiabatic?

I have found that SimplePhysics alone is insufficient to keep the near-surface temperature
profile close to dry adiabatic. I would recommend using the dry convective adjustment scheme in addition to the
components you are already using.

it has been used in this example:

climt/examples/column_code_with_slab.py

Lines 106 to 120 in 5aa011f

	for i in range(60000):
	diagnostics, state = time_stepper(state, timestep)
	state.update(diagnostics)
	diagnostics, new_state = simple_physics(state, timestep)
	state.update(diagnostics)
	# state.update(new_state)
	# diagnostics, new_state = dry_convection(state, timestep)
	# state.update(diagnostics)
	if (i+1) % 100 == 0:
	print('Surface Temperature: ', state['surface_temperature'].values.item())
	monitor.store(state)
	state.update(new_state)
	state['eastward_wind'].values[:] = 3.

but has been commented out (lines 114-115). I find that the resulting temperature
profile is more realistic when using this component.