too fast QBO in EAMv2

[wenyuz]

Hi,

I ran the EAMv2 with an F2000 setup and found that the QBO is too fast (with a period of half-year).

I notice that EAMv2 has already incorporated the parameter tuning for better QBO, as suggested by Richter et al. 2019.

In Richter et al. 2019 (based on EAMv1), they reduces the values of the following two parameters: effgw_beres = 0.35 (default 0..4 in EAMv1) and gw_convect_hcf=10 (default 20 in EAMv1). This reduces the magnitude of the gravity momentum source and consequently makes the QBO less fast in EAMv1.

I tried to further reduce the values of these two parameters (effgw_beres = 0.1 and gw_convect_hcf=4) but the QBO period does not change much and is still at about half year.

I wonder if there is any explanation for this behavior of EAMv2.

Thanks,

Richter et al. 2019: Improved Simulation of the QBO in E3SMv1. JAMES.

Wenyu Zhou

[whannah1]

@wenyuz my only thought on this is that the DCAPE trigger modification in the Zhang-McFarlane (ZM) deep convection scheme that was added for v2 will effectively reduce the amount of convective heating that is used for gravity wave generation, which might explain why you're seeing a different sensitivity to changing those parameters.

Coincidently, I just made this figure the other day directly comparing the precipitation in v1 and v2:

This is a 2 year average of 3 precip variables - total, convective, and "large-scale" - of some coupled runs I'm doing that branch from the 500-year pre-industrial control simulations for v1 and v2. I was just making this plot as a sanity check that things were looking reasonable, but it's quite striking how the convective precipitation reduces in v2. I think "convective" precip includes precip from ZM and CLUBB, but I suspect the majority of this difference is due to the DCAPE change in ZM.

One way you might be able to directly test this is to artificially enhance the convective heating that is used for gravity waves.
The way I would try to do this is to take the "TTEND_DP" variable that is set here:
components/eam/src/physics/cam/convect_deep.F90
and just multiply it by some positive constant greater than 1, maybe 2.
This data is the heating tendency that is used to estimate the convective gravity wave source, so if the reduction of heating from ZM is the problem, then artificially enhancing this tendency we should see stronger gravity wave tendencies in the tropics, and perhaps a noticeable change in the QBO phase speed.

[wenyuz]

Thanks for your suggestion. I will run a case with conventional CAPE closure and see how it affects the QBO.

[whannah1]

Just so you know, the DCAPE option affects the "trigger" and not the "closure".

[wenyuz]

Oh! So the DCAPE_trigger option only controls when will the deep convection trigger, and the cloud base mass flux is still computed in the conventional way of (CAPE-CAPE0)/tau?

[whannah1]

Exactly. There is also the "unrestricted launch level" (ULL) modification that changes "where" the cloud base occurs. I'm not sure how that might play a role here. The ULL change probably doesn't have much affect over tropical oceans, it was moreso motivated by the elevated convection that is sometimes observed over land at night. But this also shouldn't fundamentally change the basic behavior of the closure.

[wenyuz]

I see. Thank you so much for your explanation. Good to know that DCAPE only affects the trigger.

[wenyuz]

Here are some results with tuned parameters. What I saw in the control EAMv2 may not be QBO but semi-annual oscillation. In other words, the QBO is absent in the control EAMv2 simulation.

I further tuned the parameters related to the convective gravity drag but still could not get a reasonable QBO. Here are my results. The closest case is with effgw_beres = 0.4; gw_convect_hcf = 20, which produces an ~annual oscillation.

[whannah1]

Thanks for posting this analysis. It seems my inclination to blame DCAPE was wrong, which is good to know.
Any other ideas to explain the lack of QBO in v2?

[wenyuz]

I only tested trigger_dcape_ull = false with effgw_beres=0.35 and convect_hcf=10. It is possible that trigger_dcape_ull = false may play a larger role when applied with other values of effgw_beres and convect_hcf. I will test that further.

But, on the other hand, I do not want to change the basic setup of EAMv2 (i.e., set trigger_dcape_ull = false) when I tune the QBO.

[whannah1]

@wenyuz Have you tried disabling use_gw_energy_fix in your v2 experiments?

[wenyuz]

Yes, I actually tried one case with use_gw_energy_fix = .false. but It did not help much.

[wenyuz]

I had some discussions with Yaga Richter. She told me that, in the historical simulation when they tuned effgw_beres=0.35 and convect_hcf=10, EAMv2 was able to simulate a QBO with a ~2 year period but with a very weak amplitude.

https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/wlin/E3SMv2/v2.LR.HIST_ENS/e3sm_diags/180x360_aave/model_vs_obs_1985-2014/viewer/qbo/variable/qbo-era-interim/plot.html

What I ran is the AMIP F2000. I use the newest code on this GitHub page and the default run does not change any parameter.

It will be surprising if the difference between AMIP and coupled simulations is so large. So I wonder if there may be some code differences between them. Thanks.