v2.LR.AUFIRE

README.SSP370

@@ -0,0 +1,69 @@
+------------
+# fix EAM settings for v2
+------------
+cd /global/project/projectdirs/ccsm1/people/nanr/e3sm_tags/E3SMv2/E3SM/components/eam/bld/namelist_files/use_cases
+cp /global/cfs/cdirs/e3sm/wlin/share/fix_ssp370_ssp585_use_case_files/SSP370_eam_CMIP6.xml .
+cp /global/cfs/cdirs/e3sm/wlin/share/fix_ssp370_ssp585_use_case_files/SSP585_eam_CMIP6.xml .
+
+------------
+May 30 2022
+------------
+The v2 SSP370 is supposed to have the same atm physics parameter settings as for the historical simulations. The only differences should be inputdata files related. 
+
+With the current master, I created a historical (WCYCL20TR) and a SSP370 (WCYCLSSP370) cases. Due to the wrong use_case setting,  the atm physics parameters is a mixture of EAMv1 and EAMv2. The atm_in files for the two test cases, as follows, differ in more than just the input files.
+WCYCL20TR: /global/cscratch1/sd/wlin/E3SM_testings/E3SMv2/20220527.WCYCL20TR.ne30pg2_EC30to60E2r2/run/atm_in
+WCYCLSSP370old : /global/cscratch1/sd/wlin/E3SM_testings/E3SMv2/20220527.WCYCLSSP370old.ne30pg2_EC30to60E2r2/run/atm_in
+I think atm_in in your SSP370 run is the same as in WCYCLSSP370old.
+
+A PR to fix the use_cases for the E3SM master is in. atm_in for a new WCYCLSSP370 test case created off it is
+/global/cscratch1/sd/wlin/E3SM_testings/E3SMv2/20220527.WCYCLSSP370new.ne30pg2_EC30to60E2r2/run/atm_in
+The use_case file was created using a template from V1. The forcing files were correctly updated. All the settings for the tuning parameters should have been removed but were not. I am terribly sorry for this negligence.
+
+To rerun with the same code base but with the correct atm settings, need to replace the following file
+components/eam/bld/namelist_files/use_cases/SSP370_eam_CMIP6.xml
+with the one in the above bug-fix PR. I also copied the new use_case files to the following directory on NERSC 
+/global/cfs/cdirs/e3sm/wlin/share/fix_ssp370_ssp585_use_case_files
+
+-----------
+ELM settings:
+I'm curious about the changes to the ELM settings.  Do I also need to make these changes or will the previous settings I used be ok, since they were validated in the original SSP370 PR for ELM.
+
+
+< <fsurdat>lnd/clm2/surfdata_map/surfdata_ne30np4.pg2_simyr1850_2015_c211105.nc </fsurdat>
+> <fsurdat>lnd/clm2/surfdata_map/surfdata_ne30np4.pg2_SSP3_RCP70_simyr2015_c220420.nc </fsurdat>
+
+> <!-- Add following for hybrid run of SSP370 continuing from a historical simulation -->
+> <check_finidat_fsurdat_consistency>.false.</check_finidat_fsurdat_consistency>
+> <check_finidat_year_consistency>.true.</check_finidat_year_consistency>
+> <check_finidat_pct_consistency>.true.</check_finidat_pct_consistency>
+
+---------------------
+Wuyin Lin:
+Thanks for bringing up the ELM settings. The previous settings you used are ok.
+
+In general, it looks somewhat more consistent in terms of simyr starting time if using surfdata_ne30np4.pg2_SSP3_RCP70_simyr2015_c220420.nc.
+
+The two files are essentially the same and either one is ok for the currently SSP runs, as long as the same file is used for all ensemble members. They are different in five variables, four of which -- PCT_NATVEG, PCT_LAKE, PCT_GLACIER, and PCT_URBAN at 1e-7 level. The other one, PCT_NAT_PFT, has large differences, but during run time, the same variable from landuse.timeseries will be used. 
+
+Please note that, for hybrid runs as for the SSP370 simulations, the surface data recorded in the restart file (elm.r) are supposed to take precedence over what are in fsurdat. But the elm initialization code does have an issue and it is not implemented exactly that way. As a result, simulation results would be non-BFB using one vs the other.  Alan Di Vittorio is working on the fix. 
+
+---------------------
+Jim Benedict:
+All,
+
+A summary of the ELM bug and its implications for v2 SSP* runs can be found here:
+https://acme-climate.atlassian.net/wiki/spaces/DOC/pages/3417112603/Statement+on+ELM+land+use+behavior+for+future+projection+simulations
+
+The bug impacts were found to be negligible (but not zero) for v2 SSP* runs, as Wuyin mentioned.  Use of the "2015" fsurdat file in the updated ELM use case file should eliminate any issues.
+
+Jim
+
+-------------------
+Jim Benedict:
+Hi Nan,
+
+
+Many (many!) apologies for the error in the SSP370 EAM config!  When I started putting together the SSP370 configuration last year, I asked about the EAM parameter settings and the guidance then was that the values would not change, so I put it aside.  I should have brought it up again once the other aerosol/GHG/etc inputs were finalized.  The problem, I believe, was that the EAM parameter settings had not yet been updated to be consistent with the v2 DECK at the time I started and those changes never made it into my workflow.
+
+
+The small silver lining is that your new runs will use the "2015" ELM fsurdat file that is more consistent with a (2015-2100) SSP simulation, based on our discovery of the small ELM bug that Wuyin noted.

README.e3sm-setup

@@ -0,0 +1,25 @@
+Running E3SM on NERSC Cori
+
+directions: https://e3sm.org/model/running-e3sm/e3sm-quick-start/
+monitoring jobs: https://docs.nersc.gov/jobs/monitoring/
+
+squeue -u sglanvil
+
+get source code
+	mkdir /global/homes/s/sglanvil/sourceCode/
+	git clone -b maint-1.0 --recursive https://github.com/E3SM-Project/E3SM.git
+
+create new case
+cd /global/homes/s/sglanvil/sourceCode/E3SM/cime/scripts
+
+./create_newcase --case MCSP_CMT_5_coupled --compset A_WCYCL20TRS_CMIP6 --res ne30_oECv3_ICG --pecount L --handle-preexisting-dirs u --mach cori-knl --output-root /global/cscratch1/sd/sglanvil/ --script-root /global/homes/s/sglanvil/cases/MCSP_CMT_5_coupled -project mp9
+
+
+cd /global/homes/s/sglanvil/cases/MCSP_CMT_5_coupled
+./case.setup
+./case.build
+./case.submit
+
+Compsets:
+cd E3SM/cime/scripts/
+./query_config --compsets

README.samStevenson

@@ -0,0 +1,12 @@
+https://docs.google.com/document/d/1t7j5xXWrbGzSSWb0HXSksQxpKQM7FpKfpYKnqPErz_0/edit
+https://docs.google.com/document/d/1mgTeLXYe2niMRloIW9cXG3GvoZmcVkKn0pVNZSO4FC8/edit
+
+
+=======
+PI control start years:
+REF_CASE:20180129.DECKv1b_piControl.ne30_oEC.edison
+	210
+	320
+	365
+	410
+	480

README.user_nl_cam

@@ -0,0 +1,140 @@
+Below is a namelist that Nan has put together for the E3SMv1 simulations with additional output - could you please have a look through and make sure that it has all the needed MJO and MJO-QBO interactions output? (In particular, Jack: can you run all your diags from this? & Julie: are all the variables here that you used for the QBO-MJO plots?)
+
+!!                   h0, h1,  h2,  h3,  h4
+
+ nhtfrq =            0, -24, -24,  -6,  -6
+
+
+
+! monthly (h0)
+
+ fincl1 = 'IEFLX:A'
+
+
+
+! daily 2D (h1) - Averaged
+
+ fincl2 = 'FLUT:A','TREFHT:A','TREFHTMN:M','TREFHTMX:X','LHFLX:A', 'SHFLX:A', 'PRECT:A', 'PRECTMX:X','PRECC:A', 
+
+'FLNT:A','FSNS:A','FSNT:A','FLNSC:A', 'FLNS:A','PS:A', 'PSL:A','OLR:A', 'RHREFHT:A',
+
+'UBOT:A', 'VBOT:A', 'U10:A', 'Z200:A', 'Z500:A', 'U200:A', 'V200:A', 'U850:A', 'V850:A' 
+
+
+
+! daily Full-column (h2) - Averaged
+
+ fincl3 = 'U:A', 'V:A', 'OMEGA:A', 'T:A', 'Q:A','Z3:A'
+
+
+
+! 6hrly 2D (h3) 
+
+ fincl4 = 'PSL:I','TREFHT:I', 'FLDS:I', 'FSDS:I', 'PRECT:A', 'PS:I', 'QREFHT:I', 'TS:I',
+
+          'TMQ:I','U10:I','U850:I','V850:I','UBOT:I','VBOT:I','Z200:I','Z500:I',
+
+ 'IVT:I','uIVT:I','vIVT:I'
+
+
+
+MAYBE: if this would be useful to you please let us know as this is very space intensive!
+
+! 6 hrly Full-column (h4)
+
+ fincl5 = 'Q:I', 'T:I', 'U:I', 'V:I', 'Z3:I'
+
+
+Thanks,
+Yaga
+
+
+Chih-Chieh-Jack Chen
+Oct 28, 2021, 3:41 PM (4 days ago)
+to Jadwiga, Julie, Richard, Brian, me
+
+Hi Yaga,
+
+Yes, the MJO diagnostics I have been running require daily FLUT, PRECT, U850, V850, U200, and V200.
+
+They are all in fincl2.
+
+Jack
+
+
+Julie Caron
+Oct 28, 2021, 3:51 PM (4 days ago)
+to Jadwiga, Richard, Brian, Chih-Chieh-Jack, me
+
+yes, this looks like it has the mjo fields i need too ( same list as jack mentioned). i also have some code that grabs U at 50mb for the qbo i believe. but i think yaga can speak to what frequency is needed and if we want to include some standard plots of qbo in general do we have all the upper level winds at the right frequency?
+thanks,
+julie
+
+
+Jadwiga (Yaga) Richter
+Oct 28, 2021, 3:55 PM (4 days ago)
+to Julie, Richard, Brian, Chih-Chieh-Jack, me
+
+Thanks Jack & Julie.
+
+For the QBO we mostly need monthly  mean wind. For the MJO-QBO paper we used daily wind at U(50 hPa) which we could get out of the 3D daily U in h2.
+
+Nan: if we could add daily U(at 50 hPa) without much overhead, that would make things easier for the analysis,
+
+Yaga
+
+
+Richard Neale
+Oct 28, 2021, 3:57 PM (4 days ago)
+to Jadwiga, Julie, Brian, Chih-Chieh-Jack, me
+
+A few of the tendency fields on the h0 files would be useful: ZMDT, ZMDQ, STEND_CLUBB, RVMTEND_CLUBB, MPDT, MPDQ, DCQ and DTCOND.
+
+I know there are already lots of fincls, but 3 hourly PRECT and maybe PRECC are always useful.
+
+Rich
+--
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+ Rich Neale - [email protected] - http://www.cgd.ucar.edu/cms/rneale -
+ Section Head - Atmospheric Modeling & Predictability, CGD, NCAR  
+ P.O. Box 3000, Boulder, CO 80307-3000 
+ Tel (303) 497-1380 Fax (303) 497-1324 
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
+
+Brian Medeiros
+Oct 28, 2021, 4:05 PM (4 days ago)
+to Jadwiga, Julie, Richard, Chih-Chieh-Jack, me
+
+This looks reasonable for standard MJO diagnostics. 
+
+I was just replying similarly to Rich… the question for the QBO-MJO analysis is what kind of process-level diagnostics will be needed? I’m wondering about heating rates and measures of stability. The tendencies Rich mentioned take care of heating…. stability might be hard. The daily fields might be enough, I guess… though QRS and QRL might be needed too.
+
+.brian
+
+
+Jadwiga (Yaga) Richter
+Oct 28, 2021, 4:07 PM (4 days ago)
+to Brian, Julie, Richard, Chih-Chieh-Jack, me
+
+Daily fields should be enough for the QBO-MJO. If we can add QRS and QRL to the daily's that would be great,
+Yaga
+
+
+Richard Neale
+Oct 28, 2021, 4:10 PM (4 days ago)
+to Brian, Jadwiga, Julie, Chih-Chieh-Jack, me
+
+Good point Brian, we'll need daily convective heating, moistening; copies of my h0 additions. I think daily measures of tropopause height/pressure would be good also if we don't have them.
+Rich
+
+Not sure what you need answers for?
+I say yes to the h0 variables and 3 hourly variables.
+Do you need the actual tropopause variables? How about these 3 daily to capture the tropopause.
+
+tropopause.F90:    call addfld('TROPF_P',         horiz_only,  'A',  'Pa',         'Tropopause Pressure (cold point)',    flag_xyfill=.True.)
+tropopause.F90:    call addfld('TROPF_T',         horiz_only,  'A',  'K',          'Tropopause Temperature (cold point)', flag_xyfill=.True.)
+tropopause.F90:    call addfld('TROPF_Z',         horiz_only,  'A',  'm',          'Tropopause Height (cold point)',      flag_xyfill=.True.)
+
+All good?
+Rich