Large scale `thl` tendencies not applied with radiation on.

[julietbravo]

The time varying thl tendencies (modtimedep.f90) are read into thlpcart, which is averaged in time into thlpcar, which is applied as a radiative tendency in modradiation.f90, but only when rad_ls=.true.. But with radiation on, e.g. for iradiation=4, rad_ls is set to .false.:

  case (4)
    iradiation = 2
    rad_ls     = .false.
    rad_longw  = .true.
    rad_shortw = .true.
    rad_smoke  = .false.

I see two possible solutions: (1) read the thl tendencies in modtimedep.f90 into dthldtlst (like is done with ltestbed=.true.), which is applied as a tendency in modforces.f90, or always set rad_ls to .true.. I think I would prefer (1); then the thl tendency can be seen as a large scale advective tendency, a radiative tendency, or both.

[jchylik]

But with radiation on, e.g. for iradiation=4, rad_ls is set to .false.

I think that this is the desired behaviour: prescribing the heating tendencies due to radiation makes sense when we use prescribed radiation or simple large scale parametrisation. If we use rapid radiation scheme (iradiation=4), then radiation is calculated interactively, and adding extra tendencies would be quite un-physical.

[julietbravo]

@jchylik Yes, but there is no option to prescribe other thl tendencies, like large-scale advection, so this column in ls_flux.inp is typically also used for that. And if you want to use iradiation=4 without prescribed radiative heating/cooling, you can always set this variable/column to zero.

I know that this implicit rad_ls switch has "bitten" a lot of people (including myself) who didn't know that these tendencies were not applied when interactive radiation was on, so in the very least case, I think that a big warning should be printed :-)

[jchylik]

I know that this implicit rad_ls switch has "bitten" a lot of people (including myself) who didn't know that these tendencies were not applied when interactive radiation was on, so in the very least case, I think that a big warning should be printed :-)

Definitely, there should be a warning. As for potential temperature tendencies, I think there is another column that covers the advective tendency, isn't it?

[julietbravo]

I think only with ltestbed=.true. (which uses the NetCDF input). From the ascii files, only one thl tendency variable is read:

read (ifinput,*) &
     height  (k)  , &
     ugt     (k,t), &
     vgt     (k,t), &
     wflst   (k,t), &
     dqtdxlst(k,t), &
     dqtdylst(k,t), &
     dqtdtlst(k,t), &
     thlpcart(k,t), &
     dudtlst (k,t), &
     dvdtlst (k,t)

[fjansson]

For the ascii files, I propose we read the temperature tendency into dthldtlst(k,t) instead of thlpcart(k,t). Then existing cases continue to work, and the temperature tendency is always applied.

We need a mechanism to provide a large-scale temperature tendency regardless of the radiation setting. Is there a need for a separate radiative tendency? Then I think we have to introduce a new column in the ascii file, and either make it optional with a flag or break existing cases.

cc @AlessandroSav

[fjansson]

One more note: the case (4) mentioned at the top (which turns rad_ls off) is in a select case (irad). irad is different from iradiation and is marked as deprecated. If you set iradiation directly, rad_ls stays on, as far as I can see.

I find this confusing, and one more reason to view the temperature tendency columns in lscale.inp and timedep.inp as general temperature tendencies that are always applied, and not as radiative tendencies.

[huugouwersloot]

Sorry for my late reply. Fredrik is right that 'iradiation' does not affect 'rad_ls'. Only 'irad' does and you're not supposed to use that for a long time. Since it is deprecated for over a decade (I'm sure it was already the case in 2009, but probably a bit langer), maybe the best thing to do is to just remove the 'irad' variable and the corresponding case-structure and entry in the namelist. Other than that, no code changes should be applied.