Skip to content

cam6_4_098: CAM updates to bring in CCPP-ized RRTMGP longwave modules #1290

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 37 commits into
base: cam_development
Choose a base branch
from

Conversation

peverwhee
Copy link
Collaborator

@peverwhee peverwhee commented Apr 4, 2025

Summary

Brings in (via atmospheric_physics) new CCPP-ized longwave routines. Modifies CAM side to use new CCPP interfaces, while maintaining RRTMG functionality.

Addresses #1192

Main modules updated:

  • src/physics/rrtmgp/radiation.F90
    • Use new ccpp interfaces
  • src/physics/rrtmgp/rrtmgp_inputs.F90 (now rrtmgp_inputs_cam.F90)
    • Remove longwave gas and cloud optics (now ccppized)
    • Will get smaller when SW is CCPPized
  • src/physics/rrtmgp/radconstants.F90
    • Move set_wavenumber_bounds to CCPP/utils
  • src/physics/cam/cloud_rad_props.F90
    • pass out data read in from ice and liquid optics files to be used by CCPPized interfaces

Updates configure as well to include new rrtmgp paths (always build utils because RRTMG requires access to radiation_utils.F90)

Testing

Tests are b4b.

@peverwhee peverwhee requested a review from nusbaume April 4, 2025 16:21
@peverwhee peverwhee self-assigned this Apr 4, 2025
Copy link
Collaborator

@cacraigucar cacraigucar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First section of review - have not reviewed the big sections yet

@peverwhee peverwhee requested a review from cacraigucar June 9, 2025 04:46
@cacraigucar cacraigucar changed the title CAM updates to bring in CCPP-ized RRTMGP longwave modules cam6_4_098: CAM updates to bring in CCPP-ized RRTMGP longwave modules Jun 16, 2025
Copy link
Collaborator

@nusbaume nusbaume left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @peverwhee! I had a few requests related to code style and comments, but nothing that requires a re-review.

Comment on lines 299 to 313
allocate(abs_lw_liq_out(nmu,nlambda,nlwbands), stat=ierr, errmsg=errmsg)
call handle_allocate_error(ierr, sub, 'abs_lw_liq_out')
abs_lw_liq_out = abs_lw_liq
allocate(abs_lw_ice_out(n_g_d,nlwbands), stat=ierr, errmsg=errmsg)
call handle_allocate_error(ierr, sub, 'abs_lw_ice_out')
abs_lw_ice_out = abs_lw_ice
allocate(g_mu_out(nmu), stat=ierr, errmsg=errmsg)
call handle_allocate_error(ierr, sub, 'g_mu_out')
g_mu_out = g_mu
allocate(g_lambda_out(nmu,nlambda), stat=ierr, errmsg=errmsg)
call handle_allocate_error(ierr, sub, 'g_lambda_out')
g_lambda_out = g_lambda
allocate(g_d_eff_out(n_g_d), stat=ierr, errmsg=errmsg)
call handle_allocate_error(ierr, sub, 'g_d_eff_out')
g_d_eff_out = g_d_eff
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need the errmsg output here as it isn't actually being used anywhere.

!=========================================================================================

subroutine get_sw_spectral_boundaries(low_boundaries, high_boundaries, units)
subroutine get_sw_spectral_boundaries(low_boundaries, high_boundaries, units)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the indent here? It looked like it was already lined-up correctly (but maybe that is just Github fooling me)?

Comment on lines 8 to 9
use radiation_utils, only: get_sw_spectral_boundaries_ccpp
use radiation_utils, only: get_lw_spectral_boundaries_ccpp
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To better match the (newer) CAM coding standards, should we move these two use statements down into their respective CAM subroutines (i.e. lessen their scope)?

@@ -319,7 +170,7 @@ subroutine rad_gas_get_vmr(icall, gas_name, state, pbuf, nlay, numactivecols, ga
integer, intent(in) :: nlay ! number of layers in radiation calculation
integer, intent(in) :: numactivecols ! number of columns, ncol for LW, nday for SW

type(ty_gas_concs), intent(inout) :: gas_concs ! the result is VRM inside gas_concs
type(ty_gas_concs_ccpp), intent(inout) :: gas_concs ! the result is VRM inside gas_concs
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure the comment here is referring to "Volume Mixing Ratios":

Suggested change
type(ty_gas_concs_ccpp), intent(inout) :: gas_concs ! the result is VRM inside gas_concs
type(ty_gas_concs_ccpp), intent(inout) :: gas_concs ! the result is VMR inside gas_concs

@@ -625,6 +338,7 @@ subroutine rrtmgp_set_cloud_sw( &
integer, intent(in) :: nlay ! number of layers in radiation calculation (may include "extra layer")
integer, intent(in) :: nday ! number of daylight columns
integer, intent(in) :: idxday(pcols) ! indices of daylight columns in the chunk
integer, intent(in) :: nswgpts
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment here? for example:

Suggested change
integer, intent(in) :: nswgpts
integer, intent(in) :: nswgpts ! number of shortwave g-points

@@ -1173,17 +1179,17 @@ subroutine radiation_tend( &

! Compute the gas optics (stored in atm_optics_sw).
! toa_flux is the reference solar source from RRTMGP data.
!$acc data copyin(kdist_sw,pmid_day,pint_day,t_day,gas_concs_sw) &
!$acc copy(atm_optics_sw) &
!$acc data copyin(kdist_sw%gas_props,pmid_day,pint_day,t_day,gas_concs_sw%gas_concs) &
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just adding a note here that we should double-check with CISL that this is the correct way to handle the OpenACC calls.

@cacraigucar cacraigucar changed the title cam6_4_098: CAM updates to bring in CCPP-ized RRTMGP longwave modules CAM updates to bring in CCPP-ized RRTMGP longwave modules Jun 17, 2025
@cacraigucar cacraigucar changed the title CAM updates to bring in CCPP-ized RRTMGP longwave modules cam6_4_098: CAM updates to bring in CCPP-ized RRTMGP longwave modules Jun 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

3 participants