CAM
CAM copied to clipboard
ESCOMP
Create testing compsets based on FLT,FMT,FW and FX
Issue Type
Other (please describe below)
Issue Description
We need compsets set up for testing purposes. These compsets will lead to final compsets for the next release. Several features need to be implemented:
-
FLTHIST, FMTHIST and FWHIST and FXHIST are proposed compsets based on the naming conventions described in #692 . Until the actual details of the settings are finalized, they will have _v0a, _v0b, etc appended to them (i.e.
FLTHIST_v0a) -
FLT/FMT/FW/FX will set a keyword
model_topwhich will replace the current use ofnlevandwaccmin the namelist_defaults_cam.xml. The values will be: -- FLT*=> model_top = 'low' --FMT* => model_top = 'mid' --FW* => model_top = 'high' --FX* => model_top = 'xhigh' -
These compsets will use the
-chem GHG_MAM4setting
Original description (for reference with conversations below):
We need compsets set up for testing purposes. These compsets will lead to final compsets for the next release. Several features need to be implemented:
-
FLTHIST, FMTHIST and FHTFIST are three currently proposed compsets based on the naming conventions described in #692 . Until the actual details of the settings are finalized, they will have _v0a, _v0b, etc appended to them (i.e.
FLTHIST_v0a) -
LT/MT/HT need to set a keyword
model_topwhich will replace the current use ofnlevandwaccmin the namelist_defaults_cam.xml -
These compsets will use the
-chem GHG_MAM4setting
@cecilehannay @dan800 @fvitt @JulioTBacmeister
Will this change answers?
No
Will you be implementing this yourself?
Any CAM SE can do this
Thanks for starting this! One thing to note while WACCM is HT we would stick with FWHIST rather than FHTHIST.
If we keep the FWHIST, what will be the flag for model_top for the FWHIST compset.
Would it still be: FLTHIST => model_top = 'low' FMTHIST => model_top = 'mid' FWHIST => model_top = 'high'
I think that would work but not sure how FX fits in... @fvitt should comment. I think the idea here is to avoid keying off the number of levels to set boundary conditions and physics packages. They really depend on where in the atmosphere you set the upper boundary --
LT ~40 km MT ~80 km HT/W -~140 km WX ~700 km
"xhigh" for waccmx?
FLT*=> model_top = 'low' FMT* => model_top = 'mid' FW* => model_top = 'high' FX* => model_top = 'xhigh'
I am happy with @fvitt 's latest suggestion. Then for B compsets we would just replace the 'F' with 'B', i.e., BLT*=> model_top = 'low' BMT* => model_top = 'mid' BW* => model_top = 'high' BX* => model_top = 'xhigh'
@fvitt, @JulioTBacmeister, @cecilehannay and @dan800
I have revised the description with I believe is our current thinking.
I am still unsure how exactly -chem GHG_MAM4 is being set? @fvitt and @dan800 - is this what specifying --chem trop_mam4 does, or is the "prognostic greenhouse gas using mam4" designated in the description as --chem GHG_MAM4 , something that still needs to be implemented?
@cacraigucar -- @fvitt is certainly the expert for this, but I think it should be as simple as copying the directory src/chemistry/pp_waccm_sc_mam4 to src/chemistry/pp_ghg_mam4 and adding CO2 to the chem_mech.in file in the Solution and Explicit sections. Then I hope ensuring CAM_CONFIG_OPTS has a "-chem ghg_mam4" instead of waccm_sc should call the appropriate pre-processor input file. Not sure if you also need to modify bld/cofig_files/definition.xml to get this to work.
@cacraigucar I will need to create the chemistry mechanism file and preprocess the pp_ code. I will provide a branch for the ghg_mam4 chemistry.
The setting I use for model_top = 'low' (L58) is in:
/glade/p/cesmdata/cseg/runs/cesm2_0/f.cam6_3_095.FWscHIST.ne30_L58.001
ncdata = '/glade/p/cesm/amwg_dev/juliob/FWsc_ne30pg3_58L_GRID_48_taperstart10km_lowtop_BL10_v3_beta1p75_Top_43km.nc'
se_rsplit = 3
se_nsplit = 2
se_hypervis_subcycle = 4
bnd_topo = '/glade/p/cgd/amp/juliob/bndtopo/latest/ne30pg3_gmted2010_modis_bedmachine_nc3000_Laplace0100_20230105.nc'
use_gw_convect_dp = .false.
use_gw_front = .false.
ubc_specifier = 'Q:H2O->UBC_FILE'
ubc_file_path = '/glade/p/cesmdata/inputdata/atm/cam/chem/ubc/f.e21.FWHISTBgcCrop.f09_f09_mg17.CMIP6-AMIP-WACCM.ensAvg123.cam.h0zm.UBC.195001-201412_c220322.nc'
ubc_file_input_type = 'SERIAL'
co2_flag = .false.
The setting I use for model_top = 'mid' (L93) is in:
/glade/p/cesmdata/cseg/runs/cesm2_0/f.cesm3_cam058_mom_e.FWscHIST.ne30_L93.26c_topofix.001/ (although this is an older case and the MT might need other setting that are not here)
ncdata = '/glade/p/cgd/amp/pel/inic/L93_ne30pg3_ne30pg3_mg17_450_short.cam.i.1979-01-07-00000.nc'
se_nsplit = 3
se_qsplit = 1
se_rsplit = 6
se_hypervis_subcycle = 3
bnd_topo = '/glade/p/cgd/amp/juliob/bndtopo/latest/ne30pg3_gmted2010_modis_bedmachine_nc3000_Laplace0100_20230105.nc'
use_gw_convect_dp = .true.
use_gw_front = .true.
tau_0_ubc = .true.
co2_flag = .false.
@fvitt - Do you want to open a PR with the ghg_mam4 chemistry code when it is ready? Will you also be creating the FLT/FMT compsets changing the namelist_defaults_cam.xml settings that @cecilehannay specified? I think you had mentioned making the compsets, but if not, please let us know.
@cecilehannay - Do these new files all have the mandatory metadata (i.e are they ready to be imported into the svn inputdata repo?)
@dan800 @fvitt are the lbc's for CO2 latitudinally and seasonally varying, as Dan had suggested?
@adamrher what are the current atm_in settings used in the FHIST compset for the section &chem_surfvals_nl I hope it's a simple as adding 'CO2' to the flbc_list and pulling from the same file as the CFCs
e.g., if it like the file for SD it is glade/p/cesmdata/cseg/inputdata/atm/waccm/lb/LBC_17500116-20150116_CMIP6_0p5degLat_c180905.nc
variables:
float CO2_LBC(time, lat) ;
CO2_LBC:long_name = "CO2 (carbon dioxide) lower boundary condition" ;
CO2_LBC:units = "mol/mol" ;
Which you can see is only time & lat
I posted this in the wrong thread and so am moving the discussion here: https://github.com/ESCOMP/CAM/issues/762
@cecilehannay and @JulioTBacmeister (and anyone else who can answer the question) - Does the new topo file replace the topo file used for all runs of hgrid=ne30np4, npg=3 or just for these new compets?
@cacraigucar We should use (or create if not available) new topo files for all grids and compsets used for CAM6++, CAM7 . However the topo files used for earlier releases of the model should not be replaced. I don't know off the top of my head what grids we will be incorporating into the new model ne30pg3, ne30np4 and fv grids?
@JulioTBacmeister could what you're proposing be rephrased this way: "replace all bnd_topo files in namelist_defaults.xml on cam_development with new topo files ... do not touch change the topo files in prior releases, e.g., cesm2.1 release branch."
To add to this discussion, I should also point out that once a file is in the inputdata repo, it remains there forever, whether the current namelist_defaults_cam.xml points to it or not. A user can always specify a previous topo file via user_nl_cam if they want to override the defaults.
@JulioTBacmeister could what you're proposing be rephrased this way: "replace all bnd_topo files in namelist_defaults.xml on cam_development with new topo files ... do not touch change the topo files in prior releases, e.g., cesm2.1 release branch."
Adam, Your rephrasing is correct. What I am uncertain about is whether we have new topography files for all the grids we need.
We have an open issue to update all topo files in namelist_defaults.xml: https://github.com/ESCOMP/CAM/issues/523. That should maybe get a cesm2.3 priority label. Peter is working on python scripts to generate all topo files in namelist_defaults, but I don't think he's ready yet.
I think for the new compset PR discussed here, at the bare minimum we only need to update the ne30pg3 file --- our workhorse grid. And I think the rest can come in when Peter's ready.
@JulioTBacmeister: how do we want to set gw parameters for LT?
Here are the parameters in FWscHIST
gw_apply_tndmax = .false.
gw_limit_tau_without_eff = .true.
gw_lndscl_sgh = .false.
gw_oro_south_fac = 2.d0
What currently come out of the box in the LT compset is:
gw_apply_tndmax = .true.
gw_limit_tau_without_eff = .false.
gw_lndscl_sgh = .true.
gw_oro_south_fac = 1.d0
The gw_* vars are due to the chemistry difference. The values for waccm_sc_mam4 are different than those for ghg_mam4. The default values of these variables currently depend only on the chemistry package and not on model top.
Question for Julio, are these variables really just a function of chemistry, or are they more appropriately a function of model top and the chemistry package has been used as a proxy for model top? Maybe they depend on both?
This really needs to get cleaned up. Two of these parameters are not used unless the old orographic scheme is used:
gw_lndscl_sgh gw_oro_south_fac
One is never used at all (but is still passed around in the namelist)
gw_limit_tau_without_eff
The remaining parameter gw_apply_tndmax
should be .false. when non orographic GW are used, or if the old orographic scheme is used.
I have tested the last version of Cheryl's sandbox. I think we need a few more changes.
ext_frc_type = 'CYCLICAL' => 'INTERP_MISSING_MONTHS'
srf_emis_type = 'CYCLICAL' => 'INTERP_MISSING_MONTHS'
tracer_cnst_type = 'CYCLICAL' => 'INTERP_MISSING_MONTHS'
flbc_type = 'CYCLICAL' => 'SERIAL'
csw_time_type = 'CYCLICAL' => 'SERIAL'
prescribed_ozone_type = 'CYCLICAL' => 'SERIAL'
prescribed_strataero_type = 'CYCLICAL => 'SERIAL'
I have tested the last version of Cheryl's sandbox. I think we need a few more changes.
ext_frc_type = 'CYCLICAL' => 'INTERP_MISSING_MONTHS' srf_emis_type = 'CYCLICAL' => 'INTERP_MISSING_MONTHS' tracer_cnst_type = 'CYCLICAL' => 'INTERP_MISSING_MONTHS' flbc_type = 'CYCLICAL' => 'SERIAL' csw_time_type = 'CYCLICAL' => 'SERIAL' prescribed_ozone_type = 'CYCLICAL' => 'SERIAL' prescribed_strataero_type = 'CYCLICAL => 'SERIAL'
These changes are due to using an FHIST setup as the base instead of FWscHIST. I will add these settings to the FLTHIST_v0a use case. Should they be added to the FMTHIST_V0a as well, or should we defer on making any additional changes to the FMTHIST_V0a until the next tag?
I think it is picking up the wrong ozone file. It is using a cyclical ozone. Last week, the ozone coming out of the box was:
prescribed_ozone_file = 'ozone_strataero_WACCM_L70_zm5day_18500101-20150103_CMIP6ensAvg_c180923.nc'
I don't know if it is the one we want but at least, that one was not cyclical
Cheryl - to reply your questions above: The non CYCLICAL changes can be added to the FMTHIST compset too. There is no reason a FHIST compset would use CYCLICAL for these variables if we have the non cyclical datasets.