Create testing compsets based on FLT,FMT,FW and FX

cacraigucar commented 1 year ago

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_top which will replace the current use of nlevand waccm in 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_MAM4 setting

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_top which will replace the current use of nlevand waccm in the namelist_defaults_cam.xml
These compsets will use the -chem GHG_MAM4 setting

@cecilehannay @dan800 @fvitt @JulioTBacmeister

Will this change answers?

No

Will you be implementing this yourself?

Any CAM SE can do this

dan800 commented 1 year ago

Thanks for starting this! One thing to note while WACCM is HT we would stick with FWHIST rather than FHTHIST.

cecilehannay commented 1 year ago

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'

dan800 commented 1 year ago

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

fvitt commented 1 year ago

"xhigh" for waccmx?

FLT=> model_top = 'low' FMT => model_top = 'mid' FW => model_top = 'high' FX => model_top = 'xhigh'

JulioTBacmeister commented 1 year ago

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'

cacraigucar commented 1 year ago

@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?

dan800 commented 1 year ago

@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.

fvitt commented 1 year ago

@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.

cecilehannay commented 1 year ago

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.

cacraigucar commented 1 year ago

@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.

cacraigucar commented 1 year ago

@cecilehannay - Do these new files all have the mandatory metadata (i.e are they ready to be imported into the svn inputdata repo?)

adamrher commented 1 year ago

@dan800 @fvitt are the lbc's for CO2 latitudinally and seasonally varying, as Dan had suggested?

dan800 commented 1 year ago

@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

adamrher commented 1 year ago

I posted this in the wrong thread and so am moving the discussion here: https://github.com/ESCOMP/CAM/issues/762

cacraigucar commented 1 year ago

@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?

adamrher commented 1 year ago

all instances of hgrid=ne30np4, npg=3 should use this new topo file.

JulioTBacmeister commented 1 year ago

@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?

adamrher commented 1 year ago

@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."

cacraigucar commented 1 year ago

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 commented 1 year ago

@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.

adamrher commented 1 year ago

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.

cecilehannay commented 1 year ago

@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?

JulioTBacmeister commented 1 year ago

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.

cecilehannay commented 1 year ago

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'

cacraigucar commented 1 year ago

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?

cecilehannay commented 1 year ago

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

cecilehannay commented 1 year ago

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.

ESCOMP / CAM