Forcing PORT with CMIP6 output?

Hi all!

I am new to using the Parallel Offline Radiative Transfer configuration of CAM, so please excuse me if this is a simple question. From what I understand, PORT is an offline radiative transfer model that uses the CAM radiation code. I am currently using the CAM6 version, built from CESM2.1.5 on a linux based HPC cluster.

So far everything I have read about PORT leads me to believe that I need to force PORT with output created by a full CESM or CAM run. To do this I would need to set rad_data_output = .true. in the CAM namelist to get all of the necessary radiation forcing fields. My question is this: is it not possible to take CMIP6 output of atmospheric profiles of T/Q/cloud fields etc. from piControl and 4xCO2 runs to force PORT?

Additionally, if I want to perform sensitivity testing, can I change individual fields (like surface albedo) manually?

Basically, getting and setting the input data for PORT seems to be an involved and not manual process, but I'm wondering if I'm misunderstanding. So far I've read the paper introducing PORT (https://gmd.copernicus.org/articles/6/469/2013/gmd-6-469-2013.pdf), the section in the CAM7 documentation on PORT (4. Atmospheric configurations (compsets) — camdoc documentation) and the NCAR wiki page (PORT - PORT - Parallel Offline Radiative Transfer Tool for CAM - wiki.ucar.edu). Are there other documentation resources I should know about?

Thanks in advance for any responses/discussion! I appreciate it a lot.
Calvin

Hi CalvinC, thanks for writing.

I agree that PORT needs to be forced with output from a full CESM/CAM run by setting rad_data_output = .true. - looking at the code (src/physics/cam/radiation_data.F90) rad_data_output = .true. will enable a series of output fields to be written into the CAM history file, e.g., rad_asdir (radiation input: short wave direct albedo), rad_asdif (radiation input: short wave difuse albedo), rad_aldir (radiation input: long wave direct albedo), ... which are then read by the PORT simulation in the rad_data_read subroutine in the same radiation_data.F90. These fields are not output by default, so it might not be possible to use the CMIP6 outputs directly, but you may be able to reproduce the runs then enable rad_data_output = .true. to get the necessary inputs.

As mentioned above there appears to be albedo fields in the history file written by rad_data_output = .true. so you may be able to change them for sensitivity simulations.

Hope this is helpful!

Hi Haipeng!

This is super helpful! Thanks so much for your input. I have built PORT and am currently trying to generate the necessary forcing output data from a B1850 CESM 2.1.5 run. However, when I run my realization of CESM 2.1.5, I get the following error:

ERROR: radiation_readnl:: ERROR reading namelist

I have set up by user_nl_cam file as described in the PORT wiki (PORT - PORT - Parallel Offline Radiative Transfer Tool for CAM - wiki.ucar.edu) to include the following lines:
iradsw = 1
iradlw = 1
iradae = 1
ndens=1,1
nhtfrq = 0,73
mfilt = 1,1
avgflag_pertape = 'A','I'
rad_data_output = .true.

However, I am now seeing that in the CAM6 PORT guide the namelist seems to be slightly different, including the lines:
rad_data_output=.true.
rad_data_histfile_num=2
rad_data_avgflag = 'I'
avgflag_pertape = 'A','I'
iradlw = 1
iradsw = 1
fincl2 = 'FLNT', 'FLNR','FLNS', 'FSNT','FSNR', 'FSNS'
nhtfrq = 0,73
mfilt = 1,5
ndens = 1,1

Is this why I am getting that error? Is the NCAR PORT wiki from an older version of PORT/CESM? I'll try this updated version and see if it fixes things.

Thanks so much!

Hi CalvinC, I'm not sure why there is a namelist read error, these variables seem to be accepted in the CESM2.1.5 code. Maybe the log files (atm.log and/or cesm.log) have more context about this error?

Hi Haipeng!

The issue seems to have been iradae. Removing that variable from the radiation_readnl section of the atm_in file has allowed the model to initialize successfully. It is currently running right now. I guess that iradae is no longer accepted in 2.1.5? Although if you say that iradae should work with 2.1.5 then I am not sure what the error was about.

Thanks! Calvin

Thanks for the update CalvinC! I only checked that iradae was defined in the namelist definition but wasn't sure if there's extra logic in the radiation code to handle it that could report an error. It's great to hear that it is running now.