f.cam6_3_095.FWscHIST.ne30_L58.001 - Moving to cam6_3_095

cecilehannay commented 1 year ago

Description of the run

We are getting ready to start a new run moving from our old sandbox based on cam6_3_058 to the head of the development trunk cam6_3_095.

cam6_3_095 contains the version of the CLUBB external that Ben (@bstephens82) had been using for his sumulations presented at the CAM7 meeting last week.
cam6_3_095 uses PUMAS by default instead of MG2.

I created a new case: /glade/p/cesmdata/cseg/runs/cesm2_0/f.cam6_3_095.FWscHIST.ne30_L58.001

I looked at the namelist differences between f.cam6_3_095.FWscHIST.ne30_L58.001 and our last run based on 26c f.cesm3_cam058_mom_e.FWscHIST.ne30_L58.26c_topofix.001

I would like to confirm we want to use the out of the book namelist variables. Please could review the differences and confirm what we want. I tagged a few people but others are welcome to chime in.

Differences in clubb tuning parameters (@bstephens82)

## Old
<  clubb_c14            = 2.2D0
<  clubb_gamma_coef             = 0.28
<  clubb_c8             = 4.8

## New
>  clubb_c14            =  1.6D0   
>  clubb_c8             =  4.2   
>  clubb_gamma_coef             =  0.270

Differences in gravity wave (@JulioTBacmeister)

## Old
<  use_gw_convect_dp            = .false.
<  use_gw_front         = .false.

## New
>  use_gw_front         = .true
>  use_gw_convect_dp            = .true.

Differences in gravity wave (@PeterHjortLauritzen )

## Old
<  se_hypervis_subcycle         = 4
<  se_nsplit            = 2
<  se_rsplit            = 3

## New
>  se_hypervis_subcycle         =  2 
>  se_nsplit            =   5  
>  se_rsplit            =  4

More coming (@cecilehannay ) This the starting point. I might be adding some more differences

Suffix in the casename

None

Namelist modifications

Will use the new topo and output from previous.

Source modifications

None

Sandbox

cam6_3_095

Contact info

@JulioTBacmeister, @adamrher, @PeterHjortLauritzen, @bstephens82, @c

Any other relevant information

Enter relevant info

adamrher commented 1 year ago

This is an L58 run -- why are we cranking down the se time-stepping?

cecilehannay commented 1 year ago

This is a L58 run. Right now, I am just showing what is coming out of the box.

adamrher commented 1 year ago

My apologies. So those time-stepping settings should not be coming out of the box. I would explicitly set it to the "old" values in user_nl_cam, and then @PeterHjortLauritzen can investigate why this is occurring. I suspect we can clean this up once we actually implement the L58/L93 compsets into the code https://github.com/ESCOMP/CAM/issues/692

PeterHjortLauritzen commented 1 year ago

I don't think we need to change default time-stepping for L58 (the smaller time-step is for ~80k top)

PeterHjortLauritzen commented 1 year ago

Please add energy diagnostics to this run:

nhtfrq = 0,0 avgflag_pertape(2) = 'A' fincl1 = 'WV_phBF','WL_phBF','WI_phBF','SE_phBF','KE_phBF', 'WV_phBP','WL_phBP','WI_phBP','SE_phBP','KE_phBP', 'WV_phAP','WL_phAP','WI_phAP','SE_phAP','KE_phAP', 'WV_phAM','WL_phAM','WI_phAM','SE_phAM','KE_phAM', 'WV_dyBF','WL_dyBF','WI_dyBF','SE_dyBF','KE_dyBF', 'WV_dyBP','WL_dyBP','WI_dyBP','SE_dyBP','KE_dyBP', 'WV_dyAP','WL_dyAP','WI_dyAP','SE_dyAP','KE_dyAP', 'WV_dyAM','WL_dyAM','WI_dyAM','SE_dyAM','KE_dyAM', 'WV_dBF','WL_dBF','WI_dBF','SE_dBF','KE_dBF', 'WV_dED','WL_dED','WI_dED','SE_dED','KE_dED', 'WV_dAD','WL_dAD','WI_dAD','SE_dAD','KE_dAD', 'WV_dAF','WL_dAF','WI_dAF','SE_dAF','KE_dAF', 'WV_dBD','WL_dBD','WI_dBD','SE_dBD','KE_dBD', 'WV_dAR','WL_dAR','WI_dAR','SE_dAR','KE_dAR', 'WV_dAH','WL_dAH','WI_dAH','SE_dAH','KE_dAH', 'WV_dBH','WL_dBH','WI_dBH','SE_dBH','KE_dBH', 'WV_dCH','WL_dCH','WI_dCH','SE_dCH','KE_dCH', 'WV_dAS','WL_dAS','WI_dAS','SE_dAS','KE_dAS', 'WV_dBS','WL_dBS','WI_dBS','SE_dBS','KE_dBS'

cecilehannay commented 1 year ago

My apologies. So those time-stepping settings should not be coming out of the box. I would explicitly set it to the "old" values in user_nl_cam, and then @PeterHjortLauritzen can investigate why this is occurring. I suspect we can clean this up once we actually implement the L58/L93 compsets into the code ESCOMP/CAM#692

Hi @adamrher, I looked at the namelist_defaults_cam.xml with @PeterHjortLauritzen. The reason this is happening is that we are running with the Wsc flag. The way the namelist_defaults_cam.xml is working that any compset with a waccm_phys will automatically be assigned some default waccm_phys values whether it is a low top or a high top. So even that we are using a low top L58, we get the the same values as a high top. We would need to change how we set the namelist_defaults_cam.xml.

cecilehannay commented 1 year ago

After talking to @PeterHjortLauritzen and @JulioTBacmeister , I set the following variables new run using the setting from our previous run 26c and not what is coming out of the box. This is for the reason explained above about the namelist_defaults_cam.xml

<  use_gw_convect_dp            = .false.
<  use_gw_front         = .false.
<  se_hypervis_subcycle         = 4
<  se_nsplit            = 2
<  se_rsplit            = 3

cecilehannay commented 1 year ago

I also compared f.cam6_3_095.FWscHIST.ne30_L58.001 with Ben's case directory /glade/u/home/stepheba/cam92/cime/scripts/dflt092/.

There a few more differences in the out of the box configuration because we use different cam_chempkg

<  cam_chempkg          = 'trop_mam4'     (ben)
>  cam_chempkg          = 'waccm_sc_mam4  (our run)

differences in the dust emission factor [@tilmes : do you care?]

<  dust_emis_fact               = 0.70D0   (ben)
>  dust_emis_fact               = 0.80D0   (our run)

se_hypervis_subcycle is still different [@PeterHjortLauritzen: I will use 4]

<  se_hypervis_subcycle         = 3    (ben)
>  se_hypervis_subcycle         = 4     (our run)

a bunch of gravity waves parameters [@JulioTBacmeister: any advice?]

<  gw_apply_tndmax              = .true.  (ben)
>  gw_apply_tndmax              = .false. (our run) 
<  gw_limit_tau_without_eff     = .false. (ben)
>  gw_limit_tau_without_eff     = .true.  (our run) 
<  gw_lndscl_sgh                = .true.  (ben)
>  gw_lndscl_sgh                = .false. (our run) 
<  gw_oro_south_fac             = 1.d0    (ben)
>  gw_oro_south_fac             = 2.d0    (our run) 

>  gw_qbo_hdepth_scaling        = 0.25D0  (our run) 
>  gw_top_taper                 = .false. (our run)

photo_max_zen [I have no clue what that is]

<  photo_max_zen                = 88.85D0
>  photo_max_zen                = 97.01D0

cecilehannay commented 1 year ago

The latest:

I talked to Julio and he thinks the differences in gravity waves parameters won't matter.
I will keep the dust_emis_fact to the value we had in 26c:
dust_emis_fact = 0.80D0
For clubb, I will use the out of the box tuning.

I will submit the run now. We'll see if there is any other issues.

cecilehannay commented 1 year ago

I am hitting a problem with the ubc_specifier

Because the compset uses Wsc, the model sets:
ubc_specifier = 'T->MSIS','Q->2.d-8vmr','CH4->2.d-10vmr' but at runtime, I get the error: ERROR: ubc_init: MSIS is not allowed in this configuration

Any advice? (@tilmes, @fvitt)

fvitt commented 1 year ago

@cecilehannay First you need to remove 'T->MSIS' from the list which is for high-top configurations. The vmrs for Q and CH4 are probably not appropriate for the low-top model. It might be best to read the upper boundary conditions from a WACCM output file rather than fixed scalar values. I don't know what tracers should have specified mixing ratios at the upper boundary in a low top configuration, other than water vapor. @dan800 might have some recommendations.

cecilehannay commented 1 year ago

Hi @fvitt and @dan800,

Peter told me that in the past, he used:

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 = 'CYCLICALubc_file_cycle_yr  = 2000

I don't know if a similar setting (but for HIST instead of 2000) would be appropriate.

fvitt commented 1 year ago

Yes similar ubc setting are probably appropriate with ubc_file_input_type = 'SERIAL'. You would need a ubc input file that starts in 1979 and spans the period you plan to run through. @drmikemills might be able to provide such a file from the WACCM CMIP6 output.

dan800 commented 1 year ago

In the future we really should be taking middle stratosphere upper boundary conditions for LT from MT CAM-CHEM runs. The sooner we can get into that work flow the better. But in the meantime HT (waccm) data should be fine if no suitable runs are available. Simone should comment.

For MT runs of CAM, once you have a configuration for testing let's do some test with various UBC conditions to see how many can be set as zero flux rather than coming from a file.

dan800 commented 1 year ago

Can we please adopt the updated naming conventions and never again use FWSC for a LT or MT case name.

cecilehannay commented 1 year ago

Hi @dan800 I was planning to switch for the new naming as soon as the new compsets are avsilable. The casename just reflects the compsets I am using not some random convention that I came up with. This allows to easily identify from the casename what is used in a specific run. I will check with Cheryl what else she needs from us to create the new compsets.

cecilehannay commented 1 year ago

In the future we really should be taking middle stratosphere upper boundary conditions for LT from MT CAM-CHEM runs. The sooner we can get into that work flow the better.

I agree with that. We should also change cam_namelist_default to be based on LT and MT and not waccmsc. Do we get the appropriate value for rsplit, nsplit, ... out of the box.

tilmes commented 1 year ago

@cecilehannay In this run, that I tested with the new aerosol setting in the development code: https://github.com/NCAR/amwg_dev/issues/215 I would recommend these settings for now:

dust_emis_fact = 0.9D0 seasalt_emis_scale = 1.10D0 lght_no_prd_factor = 2.50D0

Also, I would strongly recommend to set the aerosol history setting to true so we can look at the budgets. Regarding Upper boundary conditions from CAMchem, I agree to produce them, however, with the problem in aerosol and chemistry we have currently, I would agree to use WACCM upper boundary conditions.

cecilehannay commented 1 year ago

One more question (maybe for @klindsay28 or @islasimpson).

In previous runs, we had:

co2_flag=.false.

In this run, we get out of the box:

co2_flag=.true.

If my recollection is correct: co2_flag=.true. turns on the BGC tracer advection. But you don't want this when using a Wsc compset because of the way WACCM treats CO2. I don't remember the details. Should I add to my namelist:

co2_flag=.false.

adamrher commented 1 year ago

Is the -co2_cycle CONFIG_OPT flag on? I believe we forced that off in the 26 series runs.

islasimpson commented 1 year ago

@klindsay28 will know better than me, but I think co2_flag and using SC-WACCM physics might be incompatible. I think there's a high chance it could crash. Maybe you can try it and this will tell us the answer.

klindsay28 commented 1 year ago

It looks like it runs with co2_flag, but ... I'm not sure that anyone will be looking at simulated CO2 in these experiments, and there is some computational cost in running co2_flag=.true. So I think you can safely continue setting co2_flag=.false.

On Mon, Feb 27, 2023 at 3:10 PM islasimpson @.***> wrote:

@klindsay28 https://github.com/klindsay28 will know better than me, but I think co2_flag and using SC-WACCM physics might be incompatible. I think there's a high chance it could crash. Maybe you can try it and this will tell us the answer.

— Reply to this email directly, view it on GitHub https://github.com/NCAR/amwg_dev/issues/217#issuecomment-1447190564, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADWZPO2P7K2QX5DVHIF642DWZUQ37ANCNFSM6AAAAAAVHEPFMM . You are receiving this because you were mentioned.Message ID: @.***>

cecilehannay commented 1 year ago

See run #219

NCAR / amwg_dev