[Question] Modifications of SW and LW flux at certain layers

[starrystarrynighttt]

Dear CESM community,

My colleague and I are trying to perform some simulations using CESM1.2.2 that modify SW and LW at different layers. For example, we want to modify the model to reflect more SW upward or reduce the outgoing longwave at the atmospheric layer near the tropopause.

I checked the model code for CAM4 and here is what I found:

(a) For shortwave, it seems that I should scale up the reflectivity at the target layer, which basically involves four parameters in radsw.F90: rdir, rdif, rdirc, and rdifc;

(d) For longwave, it seems that I should scale up the total emissivity (emstot) in radlw.F90.

I have done some quick fixed-SST simulations and the model works fine at this point (though I haven’t checked all the details). But before running more simulations, I am wondering if these approaches sound reasonable? If not, is there any suggestion?

Any comments would be very appreciated. Thanks very much.

Best regards,

Lei

 

[brianpm]

I haven't looked at CAMRT (the radiation scheme for CAM4) in a long time, but this seems like an okay way to go. The layer reflectivities are determined in the subroutine `raddedmx` in radsw.F90. You have probably already looked at that, but it is worth double checking that your modifications are consistent with whatever is going on in there. By that I'm really just thinking about details like whether you want to only change the clear sky optical properties or if you actually want to change the cloud albedo too. The other detail you might want to check is whether aerosol optical properties are okay for your experiment; they are set in radiation.F90 ahead of the call to the radiation scheme, and are passed as input into the radiation.

I suppose that a more crude method would be to directly change the fluxes that come out of the radiation. This seems worse because it would very likely mess up energy conservation. Altering the optical properties that are used for the radiative transfer is the better solution, as you have suggested.

 

[starrystarrynighttt]

I haven't looked at CAMRT (the radiation scheme for CAM4) in a long time, but this seems like an okay way to go. The layer reflectivities are determined in the subroutine `raddedmx` in radsw.F90. You have probably already looked at that, but it is worth double checking that your modifications are consistent with whatever is going on in there. By that I'm really just thinking about details like whether you want to only change the clear sky optical properties or if you actually want to change the cloud albedo too. The other detail you might want to check is whether aerosol optical properties are okay for your experiment; they are set in radiation.F90 ahead of the call to the radiation scheme, and are passed as input into the radiation.

I suppose that a more crude method would be to directly change the fluxes that come out of the radiation. This seems worse because it would very likely mess up energy conservation. Altering the optical properties that are used for the radiative transfer is the better solution, as you have suggested.

Thanks very much for your quick response.

“I haven't looked at CAMRT (the radiation scheme for CAM4) in a long time, but this seems like an okay way to go. The layer reflectivities are determined in the subroutine `raddedmx` in radsw.F90. You have probably already looked at that, but it is worth double checking that your modifications are consistent with whatever is going on in there. By that I'm really just thinking about details like whether you want to only change the clear sky optical properties or if you actually want to change the cloud albedo too.”

Here we want some super idealized simulations. Take the shortwave case as an example, we just want to change the partition between downward and upward shortwaves, and it doesn’t matter if it’s clear-sky or cloudy-sky radiation.

Yes, I noticed that these parameters (ridr, rdif, rdirc, and rdifc) are calculated in the subroutine “raddedmx”. But for the idealized case, I am not sure we want to (and how to reasonably) change this process. So in my test runs after these four parameters are calculated, I changed them in the specific layer i as:

ridr_layer_i = ridr_layer_i * scale_factor
rdif_layer_i = rdif_layer_i * scale_factor
rdirc_layer_i = rdirc_layer_i * scale_factor
rdifc_layer_i = rdifc_layer_i * scale_factor

“The other detail you might want to check is whether aerosol optical properties are okay for your experiment; they are set in radiation.F90 ahead of the call to the radiation scheme, and are passed as input into the radiation.”

Thanks for mentioning this. I checked the codes and it seems that aerosol optical properties (e.g., the parameter aer_tau, aer_tau_w, aer_tau_w_g, and aer_tau_w_f) are all included in the calculation of the reflectivity in “raddedmx”.

This makes me think that maybe the approach I used above is easier because I don’t need to deal with different components separately.

Any comments here?

"I suppose that a more crude method would be to directly change the fluxes that come out of the radiation. This seems worse because it would very likely mess up energy conservation. Altering the optical properties that are used for the radiative transfer is the better solution, as you have suggested.”

Do you mean variables like fluxup and fluxdn?

Yes, as you mentioned it would mess up the energy conservation. If I changed these two directly in layer n, it won’t affect fluxes at other layers (but maybe indirectly through changes in layer divergence).
++++

I do have another question here. Do you have any idea what’s the unit of the reflectivity (i.e., ridr, rdif, rdirc, and rdifc) here? I tried to output them but I am not sure I understand the units here.

Thanks again.

 

[brianpm]

I think this approach makes sense. As far as I can tell from looking at CAMRT, this should work like you are proposing. So I don't see any obvious changes that are needed. One potential complication that could come up is if your intention is to change, for example, the near-tropopause reflectivity since that will be at a different model vertical level in the tropics vs high latitudes.

I would guess that reflectivity is unitless and bound to be within [0,1] (i.e., it's just like albedo).

 

[starrystarrynighttt]

I think this approach makes sense. As far as I can tell from looking at CAMRT, this should work like you are proposing. So I don't see any obvious changes that are needed. One potential complication that could come up is if your intention is to change, for example, the near-tropopause reflectivity since that will be at a different model vertical level in the tropics vs high latitudes.

I would guess that reflectivity is unitless and bound to be within [0,1] (i.e., it's just like albedo).

Thanks. Any suggestion on the longwave?

I found three variables to consider in radlw.F90:

abstot => abstot_3d(:,:,:,lchnk) !! Total absorptivity
absnxt => absnxt_3d(:,:,:,lchnk) !! Total nearest layer absorptivity
emstot => emstot_3d(:,:,lchnk) !! Total emissivity

Is that fine to change just one of them? For example, total emissivity -- emstot.

 

[starrystarrynighttt]

Hi,

Sorry for throwing too many questions here.

I tried to implement the changes I mentioned above to the code with a fixed SST configuration (F1850).

if (k == 15) then
rdir(ns,i,k) = min(rdir(ns,i,k)*1.5,1._r8)
rdif(ns,i,k) = min(rdif(ns,i,k)*1.5,1._r8)
rdirc(ns,i,k) = min(rdirc(ns,i,k)*1.5,1._r8)
rdifc(ns,i,k) = min(rdifc(ns,i,k)*1.5,1._r8)
end if

However, I keep seeing this error message after running for a few months:

(shr_sys_abort) ERROR: MAPZ_MODULE
(shr_sys_abort) WARNING: calling shr_mpi_abort() and stopping
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 68 in communicator MPI_COMM_WORLD
with errorcode 1001.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
forrtl: error (78): process killed (SIGTERM)

Do you happen to know why this error occurred? The log file is attached below.

Best wishes,