Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

radiation option for horizontally nonuniform CO2 concentrations?

Hi, I wanted to ask if there is an option implemented to run CAM with horizontally nonuniform CO2 concentrations for the radiation code? If yes, what are the namelist options to consider? Thanks!
 

eaton

CSEG and Liaisons
There is an option to run with a carbon cycle which makes the CO2 field prognostic (thus fully 3D).  This isn't documented.  Look at the module in src/physics/cam/co2_cycle.F90.  CAM's configure has an option, -co2_cycle, which turns the functionality on.  It's meant to be used with the fully coupled system (i.e., B compsets with biogeochemistry), but it is possible to use it in a CAM standalone configuration by providing emission datasets.
 
Dear Eaton, Thank you for the information. My goal is just to specify an anmalous radiative forcing over specific regions in an idealized model setting. I think reading in for instance prescribed CH4 (time,lat,lon,lev) field (CH4_2000-2009_clim_c090605.nc) might also be albe to do the job!? Is it supported to read in the 4d CH4 field under the F compset setting?  
 

eaton

CSEG and Liaisons
No, this isn't a supported functionality.  However implementing this functionality would not be a difficult job for someone familiar with CAM's infrastructure code.  The easiest way to add a prescribed concentration is probably to copy a module like prescribed_ozone.F90 and adjust it as needed.  The new prescribed field needs to be added to the physics buffer, and at that point it could be accessed by the radiation code by modifying the rad_climate namelist variable. 
 
Thanks for the suggestion. From my understanding of the code I would implement the call to the module in the radiation_tend subroutine? And for instance overwriting the colum mean CO2 concentration right after the calc_col_mean routine for CO2 and/or for the solar constant solin right before the radcswmx routine is called!?
call rad_cnst_get_clim_gas
call calc_col_mean

! construct cgs unit reps of pmid and pint and get "eccf" - earthsundistancefactor
call radinp

if (dosw) then

call t_startf('rad_sw')

! Get Oxygen mass mixing ratio.
call rad_cnst_get_clim_gas
call calc_col_mean

! Get aerosol radiative properties.
call t_startf('aero_optics_sw')
call aer_rad_props_get_clim_sw
aer_tau, aer_tau_w, aer_tau_w_g, aer_tau_w_f)
call t_stopf('aero_optics_sw')

call radcswmx
ncol, pnm, pbr, sp_hum, o3, &
o2_col, cld, cicewp, cliqwp, rel, &
rei, eccf, coszrs, solin, &
cam_in%asdir, cam_in%asdif, cam_in%aldir, cam_in%aldif, nmxrgn, &
pmxrgn, qrs, qrsc, fsnt, fsntc, fsdtoa, &
fsntoa, fsutoa, fsntoac, fsnirt, fsnrtc, fsnirtsq, &
fsns, fsnsc, fsdsc, fsds, cam_out%sols, &
cam_out%soll, cam_out%solsd, cam_out%solld, fns, fcns, &
Nday, Nnite, IdxDay, IdxNite, co2_col_mean, &
aer_tau, aer_tau_w, aer_tau_w_g, aer_tau_w_f )

call t_stopf('rad_sw')
 From my understanding, even though solin [W/m2] and co2_col_mean [e.g. 3.550e-4] have global mean values, they are still defined for each grid point (pcols), thus allowing to be overwriiten in the radiation_tend routine by a variable of the same dimension (e.g. from a netcd file)? 
 

eaton

CSEG and Liaisons
My suggestion for providing an alternative prescribed ghg distribution would not involve any changes in the radiation code itself.  However, if you're not familiar with details of CAM's infrastructure then doing the modifications as you've proposed is probably the safest way.Note that solin is an output, not an input.  You need to look inside the shortwave code to see how the incoming solar flux is specified. 
 
Thanks Eaton. I am trying to follow your explanations and the following instructions. Could you please point out if I am assuming something wrong. I am not that familar with the atmospheric moodule. Thank you very much in advance!  Example 5.1. Modify a radiatively active gasSuppose that we wish to modify the distribution of water vapor that is seen by the radiation calculations. More specifically, consider modifying just the stratospheric part of the water vapor distribution while leaving the troposheric distribution unchanged. To modify a radiatively active gas two things must be done.Change the name (and possibly the type) of the constituent which is providing the mass mixing ratios to the radiation code. This is a simple modification to the rad_climate value.Make the necessary modifications to CAM to provide the new constituent mixing ratios. A likely scenario for this example would be to create a new module which is responsible for adding the modified water vapor field to the physics buffer. This module could leverage the existing tropopause module to determine the vertical levels where changes need to be made. It could also leverage existing modules for reading and interpolating prescribed constituents, for example the prescribed_ozone module. Details of how to make this type of source code modification won't be covered here.[/list] Now suppose the source code modifications have been made and the new water vapor constituent is in the physics buffer with the name Q_fixstrat. The best way to modify the rad_climate variable is to start from a value that was generated by build-namelist for the configuration of interest but with the default water vapor, and then to modify that version of rad_climateand add the modified version to the build-namelist command in our run script. Note that the entire value of rad_climate must be specified. There is no way to just modify one individual string in the array of string values. If we are running with a default cam5 configuration then the customized namelist would be generated by the following command.$camcfg/build-namelist ...
-namelist "&cam ...
rad_climate =
'N:Q_fixstrat:H2O', 'N:O2:O2', 'N:CO2:CO2', 'N:ozone:O3',
'N:N2O:N2O', 'N:CH4:CH4', 'N:CFC11:CFC11', 'N:CFC12:CFC12',
'M:mam3_mode1:/CSMDATA/atm/cam/physprops/mam3_mode1_rrtmg_c110318.nc',
'M:mam3_mode2:/CSMDATA/atm/cam/physprops/mam3_mode2_rrtmg_c110318.nc',
'M:mam3_mode3:/CSMDATA/atm/cam/physprops/mam3_mode3_rrtmg_c110318.nc' /"
The only difference between this version of rad_climate and the default is that the string for water vapor:'A:Q:H2O'
has been replaced by'N:Q_fixstrat:H2O'
In addition to specifying the new name for the constituent (Q_fixstrat), it was necessary to replace the A by an N since the new constituent is not advected, even though it is derived in part for the constituent Q which is advected.  To make a new dummy variable (e.g., different column mean CO2 concentrations) in the physics routines I first need to create a prescribed_dummy.f90 module based on the prescribed_ozone.f90 module. Also I have a netcdf file with the new concentrations. Then adding the following dummy namelist and adding the new dummy variable to rad_climate namelist:  &prescribed_dummy_nl prescribed_dummy_cycle_yr              = 1850 prescribed_dummy_datapath              = '/path/' prescribed_dummy_file          = 'dummyfile.nc' prescribed_dummy_name          = 'DUMMY' prescribed_dummy_type          = 'CYCLICAL'/&rad_cnst_nl rad_climate            = 'P_Q:H2O', 'D_O2:O2', 'D_CO2:CO2', 'D_ozone:O3', 'D_N2O:N2O', 'D_CH4:CH4', 'D_CFC11:CFC11',  'D_CFC12:CFC12', 'D_DUMMY:DUMMY' 'D_sulf:$DIN_LOC_ROOT/atm/cam/physprops/sulfate_camrt_c080918.nc',  'D_dust1:$DIN_LOC_ROOT/atm/cam/physprops/dust1_camrt_c080918.nc',  'D_dust2:$DIN_LOC_ROOT/atm/cam/physprops/dust2_camrt_c080918.nc',  'D_dust3:$DIN_LOC_ROOT/atm/cam/physprops/dust3_camrt_c080918.nc',  'D_dust4:$DIN_LOC_ROOT/atm/cam/physprops/dust4_camrt_c080918.nc',  'D_bcar1:$DIN_LOC_ROOT/atm/cam/physprops/bcpho_camrt_c080918.nc',  'D_bcar2:$DIN_LOC_ROOT/atm/cam/physprops/bcphi_camrt_c080918.nc',  'D_ocar1:$DIN_LOC_ROOT/atm/cam/physprops/ocpho_camrt_c080918.nc',  'D_ocar2:$DIN_LOC_ROOT/atm/cam/physprops/ocphi_camrt_c080918.nc',  'D_SSLTA:$DIN_LOC_ROOT/atm/cam/physprops/ssam_camrt_c080918.nc',  'D_SSLTC:$DIN_LOC_ROOT/atm/cam/physprops/sscm_camrt_c080918.nc' /
To make the new variable avaiable in the physics buffer, do I need to add a call to the new dummy module from all the following 7 routines (as for the ozone module)?  7 calls to
PRESCRIBED_OZONE
 ADVNCE
INITINDX
PHYS_INIT
INIT_RESTART_PHYSICS
WRITE_RESTART_PHYSICS
READ_RESTART_PHYSICS
READ_NAMELIST Finally, to have the variable availabe in radiation_tend, I would call it there via: 
! Get dummy variable.
call rad_cnst_get_clim_gas('DUMMY', state, pbuf, dummy) Or is there a step that I am missing?   
 

eaton

CSEG and Liaisons
The syntax for the rad_climate namelist variable changed between
cesm1_0_5 and cesm1_2_2.  Your post contains both versions, so
it's not clear which cesm version you're using.  Please provide that information.
 
Dear Eaton, sorry I forgot to mention, I am using version 1.0.5.I was able to implement everything so far and read in the dummy variable (lon,lat,time). I call it in the radiation.F90 routine and write it out to the history files there as well. This is when I am seeing the constant factor (~1.5190) the output that differes from the input, which I thought is the mwco2/mwdry ratio. I wanted to confirm if it is correct that the CO2 units will be in the [mol/mol]*1.5190?Snippet from modified radiation.F90: call addfld ('DUMMY   ','mol/mol ',1,    'I','dummy variable',phys_decomp)call add_default ('DUMMY   ', 1, ' ')call outfld('DUMMY   ',dummy,pcols,lchnk)real(r8), pointer, dimension(:,:) :: dummy  call rad_cnst_get_gas(0,'DUMMY',  state, pbuf, dummy)
Snippet from modified prescribed_dummy.F90:
       molmass = mwco2        amass   = mwdry call pbuf_add(dummy_name,'physpkg',1,1,1,oz_idx) to_mmr(:ncol,:) = molmass/amass pbuf(fields(1)%pbuf_ndx)%fld_ptr(1,:ncol,:,c,1) = to_mmr(:ncol,:) * pbuf(fields(1)%pbuf_ndx)%fld_ptr(1,:ncol,:,c,1)
 
 

eaton

CSEG and Liaisons
Yes, the concentrations returned by the rad_cnst_get_gas
subroutine should be mass mixing ratios.  The ratio of molecular
weights is converting from vmr to mmr.

The thing that doesn't make sense in the code in your post is
the actual argument 'DUMMY' being passed to rad_cnst_get_gas.
This argument should be 'CO2' and the string 'D_DUMMY:CO2' should
be part of the rad_climate namelist setting to tell rad_cnst_get_gas
that the data for CO2 is found in the physics buffer variable
DUMMY.
 
Hi Eaton, thanks for the clarification! Instead of your method I am just passing on the dummy variable as the CO2 variable to the SW and LW calculations respectively, e.g.: call radcswmx(lchnk, &               ncol,       pnm,        pbr,        sp_hum,     o3,         &               o2_col,     cld,        cicewp,     cliqwp,     rel,        &               rei,        eccf,       coszrs,     solin,      &               cam_in%asdir, cam_in%asdif, cam_in%aldir, cam_in%aldif, nmxrgn, &               pmxrgn,     qrs,        qrsc,       fsnt,       fsntc,      fsdtoa, &               fsntoa,     fsutoa,     fsntoac,    fsnirt,     fsnrtc,     fsnirtsq,   &               fsns,       fsnsc,      fsdsc,      fsds,       cam_out%sols, &               cam_out%soll, cam_out%solsd, cam_out%solld, fns, fcns,      &               Nday,       Nnite,      IdxDay,     IdxNite,    dummy, &                aer_tau,    aer_tau_w,  aer_tau_w_g, aer_tau_w_f , liq_icld_vistau, ice_icld_vistau  )
 
Top