CAM 4.0 Relaxation scheme

[jls106@columbia_edu]

I'm trying to implement a relaxation scheme in CAM 4.0 in which a portion of the field, e.g. a band stretching from pole to pole from 100-120E and through all levels, is restored to climatology. The idea is to dampen any wave activity/communication across the 'sponge' layer. I've done this with CAM 3.0, but am having trouble getting it to work for CAM 4.0. Basically, I run the model with an imposed perpetual setting (e.g. January), and also diabatic forcing. These changes work fine; however, the relaxation appears to produce a global solution--that is, it seems to produce a similar response no matter where it is imposed--a sponge band in the NH only affects the SH in a fashion that is unrealistic. The scheme I'm trying is one in which the zonal and meridional winds and the dry static energy are relaxed toward perpetual climatology. This is affected by loading in the climatology and adding a new subroutine in ‘physics_types.F90’.The relaxation is effected using:
State%u + (dt/gamma)(urelax – state%u)
Where state%u is the field (here zonal wind), gamma is the relaxation time scale, dt is time increment, and urelax is the climatology of zonal wind.
It worked in CAM 3.0, but for CAM 4.0 it doesn’t seem to work here. Problems could include a need to include moisture variables in the relaxation, a need for an alternate or additional scheme, or incorrect matching of the climatology and state fields (I don’t think the latter is the problem).
Any suggestions or help you could offer would be great.

 

[eaton]

1) What code base are you using to run CAM4?

2) How are you configuring CAM to run in perpetual mode?  This is
   not an "out of the box" configuration and requires some
   non-obvious namelist settings to have all the boundary
   datasets using fixed dates.

3) Have you added the relaxed fields to the history output to be
   sure that they are being modified exactly as you expect?

General comment: Doing this experiment in a recent code
base (cesm1_0_6 or cesm1_2_2) would provide a clean comparison of
cam3 vs cam4.  This wasn't possible in the original CAM4
release (which was part of CCSM4) because the backwards
compatibility with the CAM3 physics package was not implemented
in CCSM4.  But we fixed this starting in the CESM1_0_3 release.

 

[eaton]

1) What code base are you using to run CAM4?

2) How are you configuring CAM to run in perpetual mode?  This is
   not an "out of the box" configuration and requires some
   non-obvious namelist settings to have all the boundary
   datasets using fixed dates.

3) Have you added the relaxed fields to the history output to be
   sure that they are being modified exactly as you expect?

General comment: Doing this experiment in a recent code
base (cesm1_0_6 or cesm1_2_2) would provide a clean comparison of
cam3 vs cam4.  This wasn't possible in the original CAM4
release (which was part of CCSM4) because the backwards
compatibility with the CAM3 physics package was not implemented
in CCSM4.  But we fixed this starting in the CESM1_0_3 release.

 

[jls106@columbia_edu]

I set up this version of CAM originally in August 2010 prior to release of CESM 1I've implemented the perpetual by setting sstcyc=.true. and inputing boundary files (i.e. namelist variables bndtvg, prescribed_aero_file, prescribed_ozone_file, tropopause_climo_file and faerdep) with the same desired month (e.g. August) for all 12 values in the seasonal cycle.  I also override the calendar day so that it is fixed day (213 in the case of August) plus a diurnal cycle.  This is effected in 'aerdepMod.F90, boundarydata.F90, cam3_aero_data.F90, chem_surfvals.F90, clm_time_manager.F90, co2_data_flux.F90, ocn_time_manager.F90, qbo.F90, radiation.F90, sst_data.F90, time_manager.F90, tropopause.F90 and zenith.F90.  I set it up a while ago, so I may be forgetting something, but it produces a stable seasonally appropriate perpetual climatology for whichever month I set up.I output climatologies produced by the perpetual runs and add these as inputs to the runs in which I'm trying to implement the relaxation scheme.  I add the relaxation fields to the initialization file (i.e. a modified version of cami_0000-01-01_1.9_2.5_L26_c070408.nc).  These relaxation fields are added in cam_diagnostics.F90 (through call addfld) read in physpkg.F90.  The actual relaxation subroutine is attempted in physics_types.F90.The output of the relaxation scheme is the same as a non-relaxed run.  I'm looking to see disruption of wave activity specific to the location where the relaxation sponge is applied, but instead the solution is fairly insensitive to where the relaxation is performed.Your last comment may be very telling, though I'm not quite sure what you mean by 'clean comparison' nor what 'backwards compatibility' means specifically--could you explain?  Thanks,Jeff 

 

[jls106@columbia_edu]

I set up this version of CAM originally in August 2010 prior to release of CESM 1I've implemented the perpetual by setting sstcyc=.true. and inputing boundary files (i.e. namelist variables bndtvg, prescribed_aero_file, prescribed_ozone_file, tropopause_climo_file and faerdep) with the same desired month (e.g. August) for all 12 values in the seasonal cycle.  I also override the calendar day so that it is fixed day (213 in the case of August) plus a diurnal cycle.  This is effected in 'aerdepMod.F90, boundarydata.F90, cam3_aero_data.F90, chem_surfvals.F90, clm_time_manager.F90, co2_data_flux.F90, ocn_time_manager.F90, qbo.F90, radiation.F90, sst_data.F90, time_manager.F90, tropopause.F90 and zenith.F90.  I set it up a while ago, so I may be forgetting something, but it produces a stable seasonally appropriate perpetual climatology for whichever month I set up.I output climatologies produced by the perpetual runs and add these as inputs to the runs in which I'm trying to implement the relaxation scheme.  I add the relaxation fields to the initialization file (i.e. a modified version of cami_0000-01-01_1.9_2.5_L26_c070408.nc).  These relaxation fields are added in cam_diagnostics.F90 (through call addfld) read in physpkg.F90.  The actual relaxation subroutine is attempted in physics_types.F90.The output of the relaxation scheme is the same as a non-relaxed run.  I'm looking to see disruption of wave activity specific to the location where the relaxation sponge is applied, but instead the solution is fairly insensitive to where the relaxation is performed.Your last comment may be very telling, though I'm not quite sure what you mean by 'clean comparison' nor what 'backwards compatibility' means specifically--could you explain?  Thanks,Jeff 

 

[eaton]

Looks like you've dealt with many perpetual mode issues.
Unfortunately there is no central control for this, especially
when it comes to issues with the surface models which are not
part of CAM.  So the key here is testing to be sure the model is
behaving as expected.

What I had in mind with respect to output of relaxed fields was
adding new output fields for u, v, and T (or dry static energy)
before and after the relaxation is applied (instantaneous output)
so that you can verify that the relaxation has been applied
exactly as expected (e.g., no problems with identifying the
correct columns in the chunks to apply the change to).

By "clean comparison" I just meant that if the relaxation code is
in just one framework which has the ability to run either cam3 or
cam4 physics packages by flipping a switch then it's much less
likely to run into the situation where it seems to be working in
cam3 but not in cam4.  And being in one
framework (e.g. cesm1_0_6) all the surface models will be the
same for both cam3 and cam4 physics.  That's not the case, for
example, when comparing CAM3.1 vs CCSM4.0.

By backwards compatible I mean a framework in which old physics
packages are supported along with the current one.  CCSM4.0 was
not backwards compatible with the cam3 physics package even
though the configure command did allow specifying "-phys cam3".
The problem was that the changes between the cam3 and cam4
physics were not implemented in a way that allowed them to be
turned off.  For example the dilute plumes and momentum
convection changes in the ZM scheme did not have switches to turn
them off and revert the scheme to the cam3 configuration.  This
was done subsequently and works correctly in the cesm1_0_3 and
later releases.

 

[eaton]

Looks like you've dealt with many perpetual mode issues.
Unfortunately there is no central control for this, especially
when it comes to issues with the surface models which are not
part of CAM.  So the key here is testing to be sure the model is
behaving as expected.

What I had in mind with respect to output of relaxed fields was
adding new output fields for u, v, and T (or dry static energy)
before and after the relaxation is applied (instantaneous output)
so that you can verify that the relaxation has been applied
exactly as expected (e.g., no problems with identifying the
correct columns in the chunks to apply the change to).

By "clean comparison" I just meant that if the relaxation code is
in just one framework which has the ability to run either cam3 or
cam4 physics packages by flipping a switch then it's much less
likely to run into the situation where it seems to be working in
cam3 but not in cam4.  And being in one
framework (e.g. cesm1_0_6) all the surface models will be the
same for both cam3 and cam4 physics.  That's not the case, for
example, when comparing CAM3.1 vs CCSM4.0.

By backwards compatible I mean a framework in which old physics
packages are supported along with the current one.  CCSM4.0 was
not backwards compatible with the cam3 physics package even
though the configure command did allow specifying "-phys cam3".
The problem was that the changes between the cam3 and cam4
physics were not implemented in a way that allowed them to be
turned off.  For example the dilute plumes and momentum
convection changes in the ZM scheme did not have switches to turn
them off and revert the scheme to the cam3 configuration.  This
was done subsequently and works correctly in the cesm1_0_3 and
later releases.

 

[jls106@columbia_edu]

Thanks again for these responses--they are very helpful.  I will try instantaneous output, as I've wondered if there are problems in the way parsing of columns/chunks.  I don't want to revert to CAM 3.1 physics, as I would like to included the plume and momentum convection changes brought about with CAM 4.0 and beyond.  I will post what happens with the instantaneous output test.  Thanks, Jeff

 

[jls106@columbia_edu]

Thanks again for these responses--they are very helpful.  I will try instantaneous output, as I've wondered if there are problems in the way parsing of columns/chunks.  I don't want to revert to CAM 3.1 physics, as I would like to included the plume and momentum convection changes brought about with CAM 4.0 and beyond.  I will post what happens with the instantaneous output test.  Thanks, Jeff