Skip to content
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

CCPP scheme simulator #996

Merged
merged 26 commits into from
Aug 1, 2023
Merged

CCPP scheme simulator #996

merged 26 commits into from
Aug 1, 2023

Conversation

dustinswales
Copy link
Collaborator

@dustinswales dustinswales commented Jan 30, 2023

This PR adds a new functionality, a physics process scheme simulator, to the CCPP-physics.

Data-driven tendencies can be used to drive process schemes (e.g. PBL, Deep-Convection, etc..). The control over which schemes are used are set in a new physics namelist, scm_data_nml. These data tendencies are read in during the CCPP initialization stage, and applied during the _run stage, if requested by the nml. There are new interstitial variables for the data tendencies.

To use this feature on the host-model side the Suite Definition File (SDF) needs to be modified to include the ccpp_scheme_simulator scheme, and GFS_ccpp_scheme_sim_pre.

Caveats worth mentioning.

  • This tool relies on using the GFS diagnostic physics tendencies from the "active" physics scheme. These are "bucket variables", Interstitial fields that are accumulated over the diagnostic interval. To avoid introducing new interstitials I decided to just use these, with the downside of having to run the host-model with a diagnostic interval that matches the physics timestep. The scheme simulator is intended to be agnostic to the host, so the coupling to the host is handled in an Interstitial module GFS_ccpp_scheme_sim_pre.F90. If a host had the instantaneous tendencies for the "active" scheme, they could bypass this interstitial step and pass directly into ccpp_scheme_simulator.F90.
  • There are only four prognostic fields: heat, moisture and momentum. This could be extended to handle tracers, clouds, etc...
  • Secondary coupling is not accounted for. The scheme simulator is dropped into a full SDF, just augmenting the prognostic state variables, and not any other scheme-to-scheme coupling (e.g. surface fluxes from radiation->surface scheme).

@yangfanglin
Copy link
Collaborator

Dustin, this is a great tool to have. Does this only work for SCM or for both SCM and full dimension models ?

@dustinswales
Copy link
Collaborator Author

Dustin, this is a great tool to have. Does this only work for SCM or for both SCM and full dimension models ?

@yangfanglin I plan on testing this in the full model in the coming days. Technically it shouldn't be a problem, the real "gotcha" is creating useful data tendencies to drive the model. For testing I've been using SCM output to create the temporal data tendencies to drive the simulators, but one could easily do the same with the UFS, creating temporal/spatially varying data tendencies.

@dustinswales dustinswales marked this pull request as ready for review April 14, 2023 22:03
@dustinswales dustinswales marked this pull request as draft April 14, 2023 22:04
@dustinswales dustinswales marked this pull request as ready for review April 17, 2023 21:55
@grantfirl
Copy link
Collaborator

@dustinswales Don't we need to check for flag_for_diagnostics_3D and flag_for_tracer_diagnostics_3D both being true if we're relying on the existing diagnostic variables? The SCM sets these to T by default and in the physics namelists, but it would probably be good to have a check for these somewhere since the functionality relies on them being T.

@grantfirl
Copy link
Collaborator

Also, the same comment applies by adding a check for fhzero = dt_phys.

! (Suites where active scheme is last physical process)
!
iprc = minval([iprc,proc_end])
if (.not. physics_process(iprc)%time_split) then
Copy link
Collaborator

Choose a reason for hiding this comment

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

So, when using this, one needs to remove the state_update scheme from the SDF and put this scheme as the last process-split scheme, right?

if (status == nf90_noerr) then
status = nf90_get_var( ncid, varID, physics_process(iprc)%tend2d%time)
else
errmsg = 'SCM data tendency file: '//trim(scheme_sim_file)//' does not contain times variable'
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could one interpret the data as constant for all time if a time dimension is missing rather than error?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not at the moment, but that's a good idea.

@dustinswales
Copy link
Collaborator Author

@dustinswales Don't we need to check for flag_for_diagnostics_3D and flag_for_tracer_diagnostics_3D both being true if we're relying on the existing diagnostic variables? The SCM sets these to T by default and in the physics namelists, but it would probably be good to have a check for these somewhere since the functionality relies on them being T.

Good idea. Will do.

if (prc_SWRAD_cfg(1) == 1) then
physics_process(iprc)%use_sim = .true.
else
physics_process(1)%nprg_active = 1
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could you help me understand why this is setting physics_process(1) instead of physics_process(iprc)?

type(phys_tend_2d) :: tend2d ! 2-dimensional data
type(phys_tend_3d) :: tend3d ! Not used. Placeholder for 3-dimensional spatial data.
type(phys_tend_4d) :: tend4d ! Not used. Placeholder for 4-dimensional spatio-tempo data.
character(len=16) :: active_name ! "Active" scheme: Physics process name
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@grantfirl In response to your comment above regarding physics_process(1) vs. physics_process(iprc).
I added the metadata related to the active scheme to this type, which gets allocated by the number of physics process set in the namelist, but I only need to use the (1) index for the active metadata, since there is only one active scheme.
Two questions:

  1. Do we want to be able to have multiple "active" schemes? (I think so)
  2. Should I create a second DDT here with the metadata, and data, for the active scheme(s)? This would clean up the interface to the simulator a bit.

Copy link
Collaborator

Choose a reason for hiding this comment

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

OK, now I think I'm confused. You're using "active" as opposed to "simulated", right? They're mutually exclusive? If so, ya, I thought that we would be able to have any combination of "active" and "simulated" schemes, not one active and the rest simulated.

Copy link
Collaborator

@grantfirl grantfirl left a comment

Choose a reason for hiding this comment

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

Nice job on implementing this. It's probably a good idea to go ahead and merge this and if there are additional "features" that need to be added, we can add an issue to address them later.

@dustinswales dustinswales merged commit 215ba6d into NCAR:main Aug 1, 2023
3 checks passed
@dustinswales dustinswales deleted the ccpp_scheme_sim branch August 1, 2023 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants