Access the cloud albedo output field.

[pybl]

Dear experts,

I am using WACCM6 with the atmosphere component cam6 for climate analysis.

For a pre-industrial case or in any other case in general, I want to know how to access the mean cloud albedo output field.

I have checked the Masterfield list, and it is not included.

Using the clearsky radiation, i.e., difference between the planetary albedo with and without the cloud can give the cloud radiative effect on albedo:

FSNT / (FSNT + FSUTOA) - FSNTC/(FSNTC +FSUTOAC)

However, the cloud effect can affect the surface temperature and change the surface albedo as well, so if we use the definition, the `cloud albedo' becomes essentially a combined effect rather than cloud reflectivity itself. The same problem would also apply for using FUS and FUSC.

I also noticed a software/subroutine called isccp-simulator see (ISCCP Simulator) from the Source code, and it can output `meanalbedocld' which is a grid box mean cloud albedo. This, in the first place, aims to be used to compare with the isccp observation data.

I found the information In /nobackup/CESM/cesm_2.1.3, nano ./components/cam/src/physics/cosp2/src/simulator/icarus/README

Could anyone let me know what is the right approach to get the mean cloud albedo?

All the best,
Binghan

 

[pybl]

I just noticed that FSUTOAC or FSUTC does not exist in the Masterfield list in CAM6
See CAM History Fields

 

[CaliFornia]

I just met the same issue. I am trying to calculate the cloud feedback using the F2010climo compset. After 60 yrs simulation only to find that FSUTOAC is not in the output. Did you solve this issue?

 

[CaliFornia]

Hi Bingham, just FYI, you can do FSUTOAC = FSNTOA + FSUTOA - FSNTOAC.
This is because : NET= Down - Up,
which means at top of atmosphere, FSNTOA = SolarDown - FSUTOA
when no cloud at top of atmosphere, FSNTOAC = SolarDownC - FSUTOAC. C means clear sky no clouds.
Given that at top of atmosphere, downward solar radiation is not depending on clouds, it's just the incoming solar radiation. Therefore, SolarDown = SolarDownC.
So, SolarDown = FSNTOAC + FSUTOA =SolarDownC= FSNTOAC + FSUTOAC.
Therefore, FSUTOAC = FSNTOA + FSUTOA - FSNTOAC.

 

[pybl]

Hi Bingham, just FYI, you can do FSUTOAC = FSNTOA + FSUTOA - FSNTOAC.
This is because : NET= Down - Up,
which means at top of atmosphere, FSNTOA = SolarDown - FSUTOA
when no cloud at top of atmosphere, FSNTOAC = SolarDownC - FSUTOAC. C means clear sky no clouds.
Given that at top of atmosphere, downward solar radiation is not depending on clouds, it's just the incoming solar radiation. Therefore, SolarDown = SolarDownC.
So, SolarDown = FSNTOAC + FSUTOA =SolarDownC= FSNTOAC + FSUTOAC.
Therefore, FSUTOAC = FSNTOA + FSUTOA - FSNTOAC.

Hi, Thanks for your reply!

This should work to find the cloud effect on the planetary albedo.

I tried to look at FDS and FDSC-downwelling shortwave at each layer with and without a cloud; this should be helpful in finding out which layer is more responsible for reflection.

These are instantaneous files - h1 files with a vertical dimension `ilev'.

But I got zeros everywhere for FDS and FDSC, which I don't understand.

 

[brianpm]

The zeros you are seeing in h1 are likely just because the radiation time step (1 hour) is longer than the model time step. Many of the radiation fields are written as zeros if they are written during time steps when the radiation is not active. Please let us know if you think this is not what you are seeing, as instantaneous radiation fields should be valid in general.

 

[pybl]

Hi Brian,

Thanks for the reply.

I found dtime = 1800 in the CAM6 namelist which I use.

I suppose dtime indicates radiation time step ~ 30 min which equals to the model time step.

Am I looking in the right place to find radiation timestep?

Best regards,
Binghan

 

[pybl]

Hi Brian,

Thanks for the reply.

I found dtime = 1800 in the CAM6 namelist which I use.

I suppose dtime indicates radiation time step ~ 30 min which equals to the model time step.

Am I looking in the right place to find radiation timestep?

Best regards,
Binghan

I realize dtime should be model timestep

In radiation.F90, I find:

integer :: iradsw = -1 ! freq. of shortwave radiation calc in time steps (positive)
! or hours (negative).
integer :: iradlw = -1 ! frequency of longwave rad. calc. in time steps (positive)
! or hours (negative).

so Indeed the radiation time step > model time step.

 

[brianpm]

Binghan, yes, that is correct. The dtime=1800s is the model physics time step; the default is 1800s. The parameters called iradlw and iradsw control the frequency of the radiation calculations. They both default to 1 hour (3600s; see CESM2 CAM6.3 Namelist Definitions). So the default behavior is for the radiation to run every 2 physics time steps. When writing instantaneous output, you could be writing the times when radiation is not run, and so get a bunch of zeros. If you do a short test run writing out every time step, you will see this behavior. Writing averages works correctly, but when writing instantaneous output and then doing your own averaging you'll have to take care to only select the times when radiation is actually run.

 

[pybl]

I realize dtime should be model timestep

In radiation.F90, I find:

integer :: iradsw = -1 ! freq. of shortwave radiation calc in time steps (positive)
! or hours (negative).
integer :: iradlw = -1 ! frequency of longwave rad. calc. in time steps (positive)
! or hours (negative).

so Indeed the radiation time step > model time step.

To output these instantaneous files, I am wondering if simply changing iradsw = 1 and iradlw =1 in user defined namelist does the work.

 

[pybl]

Thanks a lot for the informative reply.

Binghan, yes, that is correct. The dtime=1800s is the model physics time step; the default is 1800s. The parameters called iradlw and iradsw control the frequency of the radiation calculations. They both default to 1 hour (3600s; see CESM2 CAM6.3 Namelist Definitions). So the default behavior is for the radiation to run every 2 physics time steps. When writing instantaneous output, you could be writing the times when radiation is not run, and so get a bunch of zeros. If you do a short test run writing out every time step, you will see this behavior. Writing averages works correctly, but when writing instantaneous output and then doing your own averaging you'll have to take care to only select the times when radiation is actually run.

 

[brianpm]

Changing iradsw = 1 and iradlw =1 will have the radiation scheme run every physics time step. This is valid, but will change the solution, and it will be more computationally expensive and slower.

For a case writing instantaneous fields for every time step, I would set:
nhtfrq = 0, 1

That makes the h0 file continue to be monthly, and the h1 file be every time step. Combined with FINCL2 to specify the variables to be written to h1, this should produce all the output, including the zeros in the radiation fields. Since the output will be every time step, the "A" and "I" flags don't really mean anything in this case, as all the fields would be instantaneous.

 

[pybl]

Changing iradsw = 1 and iradlw =1 will have the radiation scheme run every physics time step. This is valid, but will change the solution, and it will be more computationally expensive and slower.

For a case writing instantaneous fields for every time step, I would set:
nhtfrq = 0, 1

That makes the h0 file continue to be monthly, and the h1 file be every time step. Combined with FINCL2 to specify the variables to be written to h1, this should produce all the output, including the zeros in the radiation fields. Since the output will be every time step, the "A" and "I" flags don't really mean anything in this case, as all the fields would be instantaneous.

Thank you!