B112 with old fire scheme (b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112oldfire)

[slevis-lmwg]

Description:
Clone of NCAR/cesm_dev#15 (b112) but change to old fire scheme.

Purpose: See if we can grow back reasonable Amazon LAI. Discussion here: NCAR/cesm_dev#26

Under "Extra details" I have listed all the lnd_in diffs between b112 and b111 for reference.

---

Case directory:
Locally:
/glade/u/home/slevis/cases_LMWG_dev/b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112oldfire

---

Sandbox:
Locally:
/glade/work/gmarques/cesm.sandboxes/cesm3_0_alpha03d_cice

---

user_nl_ changes:
user_nl_clm (first line same as b112 and for the li2021 vars I got guidance from Extra details below)

use_init_interp = .true.

fire_method = 'li2021gswpfrc'
boreal_peatfire_c = 0.09d-4
cli_scale = 0.025d00
cropfire_a1 = 1.6d-4
non_boreal_peatfire_c = 0.17d-3
rh_hgh = 80.0d00
ufuel = 1050.d00

---

SourceMods:
Same as b112

---

Diagnostics:
https://webext.cgd.ucar.edu/BLT1850/b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112oldfire/lnd/b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112oldfire.11-20-b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112_11_20/setsIndex.html

---

Output:
Output (if still available):
Initially
/glade/derecho/scratch/slevis/b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112oldfire/run
Later
/glade/derecho/scratch/slevis/archive/b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112oldfire

---

Contacts:
@slevis-lmwg

---

Extra details:
lnd_in diffs between 112 and 111 for reference:

10a11
>  dust_emis_method = 'Zender_2003'
12d12
<  flush_gdd20 = .false.
19c19
<  fsurdat = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/surfdata_esmf/ctsm5.3.0/surfdata_ne30np4.pg3_hist_1850_78pfts_c240908.nc'
---
>  fsurdat = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/surfdata_esmf/ctsm5.2.0/surfdata_ne30np4.pg3_hist_1850_78pfts_c240216.nc'
23c23
<  hillslope_fsat_equals_zero = .false.
---
>  hillslope_fsat_equals_zero = .true.
25d24
<  hist_wrt_matrixcn_diag = .false.
33c32
<  paramfile = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/paramdata/ctsm60_params.c240822.nc'
---
>  paramfile = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/paramdata/ctsm60_params.c240208.nc'
56c55,56
<  use_excess_ice = .true.
---
>  use_dynroot = .false.
>  use_excess_ice = .false.
65d64
<  use_init_interp = .true.
69d67
<  use_matrixcn = .false.
73d70
<  use_soil_matrixcn = .false.
96c93
<  stream_fldfilename_urbantv = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/urbandata/CTSM52_urbantv_Li_2024_0.9x1.25_simyr1849-2106_c20230621.nc'
---
>  stream_fldfilename_urbantv = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/urbandata/CTSM52_tbuildmax_OlesonFeddema_2020_0.9x1.25_simyr1849-2106_c200605.nc'
140,153c137,139
<  cropcals_rx = .false.
<  cropcals_rx_adapt = .true.
<  model_year_align_cropcal_cultivar_gdds = 2000
<  model_year_align_cropcal_swindows = 2000
<  stream_fldfilename_cultivar_gdds = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/cropdata/calendars/processed/gdds_20230829_161011.tweaked_latlons.nc'
<  stream_fldfilename_gdd20_baseline = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/cropdata/calendars/processed/20230714_cropcals_pr2_1deg.actually2deg.1980-2009.from_GDDB20.interpd_halfdeg.tweaked_latlons.nc'
<  stream_fldfilename_swindow_end = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/cropdata/calendars/processed/swindow_ends_ggcmi_crop_calendar_phase3_v1.01.2000-2000.20231005_145103.tweaked_latlons.nc'
<  stream_fldfilename_swindow_start = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/cropdata/calendars/processed/swindow_starts_ggcmi_crop_calendar_phase3_v1.01.2000-2000.20231005_145103.tweaked_latlons.nc'
<  stream_gdd20_seasons = .false.
<  stream_meshfile_cropcal = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/cropdata/calendars/processed/360x720_120830_ESMFmesh_c20210507_cdf5.tweaked_latlons.nc'
<  stream_year_first_cropcal_cultivar_gdds = 2000
<  stream_year_first_cropcal_swindows = 2000
<  stream_year_last_cropcal_cultivar_gdds = 2000
<  stream_year_last_cropcal_swindows = 2000
---
>  model_year_align_cropcal = 1850
>  stream_year_first_cropcal = 1850
>  stream_year_last_cropcal = 2100
168d153
<  init_interp_method = 'general'
216d200
<  urban_explicit_ac = .true.
261,263c245,247
<  glacier_region_behavior = 'single_at_atm_topo','UNSET','virtual','multiple'
<  glacier_region_ice_runoff_behavior = 'melted','UNSET','remains_ice','remains_ice'
<  glacier_region_melt_behavior = 'remains_in_place','UNSET','replaced_by_ice','replaced_by_ice'
---
>  glacier_region_behavior = 'single_at_atm_topo','virtual','virtual','multiple'
>  glacier_region_ice_runoff_behavior = 'melted','melted','remains_ice','remains_ice'
>  glacier_region_melt_behavior = 'remains_in_place','replaced_by_ice','replaced_by_ice','replaced_by_ice'
311c295
<  fire_method = 'li2024crujra'
---
>  fire_method = 'li2021gswpfrc'
319,320c303
<  boreal_peatfire_c = 0.28d-4
<  borpeat_fire_soilmoist_denom =  0.35d00
---
>  boreal_peatfire_c = 0.09d-4
323c306
<  cli_scale = 0.01d00
---
>  cli_scale = 0.025d00
326,328c309
<  cropfire_a1 = 0.3d00
<  defo_fire_precip_thresh_bdt = 0.6d00
<  defo_fire_precip_thresh_bet = 1.8d00
---
>  cropfire_a1 = 1.6d-4
330,332c311
<  max_rh30_affecting_fuel = 95.
<  non_boreal_peatfire_c = 0.71d-4
<  nonborpeat_fire_precip_denom = 6.5d00
---
>  non_boreal_peatfire_c = 0.17d-3
335c314
<  rh_hgh = 85.0d00
---
>  rh_hgh = 80.0d00
337c316
<  ufuel = 825.d00
---
>  ufuel = 1050.d00
344,351d322
<  stream_fldfilename_exice = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/paramdata/exice_init_0.125x0.125_c20220516.nc'
<  stream_mapalgo_exice = 'bilinear'
<  stream_meshfile_exice = '/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/paramdata/exice_init_0.125x0.125_ESMFmesh_cdf5_c20220802.nc'
<  use_excess_ice_streams = .true.
< /
< &clm_temperature_inparm
<  excess_ice_coldstart_depth = 0.5
<  excess_ice_coldstart_temp = -3.15
359,361d329
< &prigentroughness
<  use_prigent_roughness = .false.
< /
362a331
>  zender_soil_erod_source = 'atm'

[slevis-lmwg]

2 and 1/4 years left to go in this one before I start the diagnostics.

UPDATE: Just submitted diagnostics (2024/12/11 1712 PT)

[slevis-lmwg]

I posted b112oldfire versus b112 above (diagnostics). The old fire scheme seems to have helped Amazonian LAI, though it may not be the whole story. @olyson pointed out to me that paramfiles also changed between b111 and b112. I have not looked at the paramfile differences.

[wwieder]

Yeah, looks like fire alone won't save the amazon.

There are pft changes to tropical trees that came in with 5.3. Is another b run worth considering, based on what we saw in the F-cases or are we better waiting for changes in MOM that warm SSTs?

[dlawrenncar]

It doesn’t look like it helped much at all (?) which is a bit surprising to me. I think it would be a good idea to revert all the land changes back to 111. We should confirm that the Amazon degradation is not due to land changes. I still feel that it is more likely land changes than ocean changes because the climate forcing is not that different between 111 and 112 (at least for P).

…

On Thu, Dec 12, 2024 at 3:10 PM will wieder ***@***.***> wrote: Yeah, looks like fire alone won't save the amazon <https://webext.cgd.ucar.edu/BLT1850/b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112oldfire/lnd/b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112oldfire.11-20-b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112_11_20/set6/set6_turbf_Amazonia.gif> . There are pft changes to tropical trees that came in with 5.3. Is another b run worth considering, based on what we saw in the F-cases or are we better waiting for changes in MOM that warm SSTs? — Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVDTPUOJ722DQBQGQ2L2FHUU7AVCNFSM6AAAAABTJQKGVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZZHEYTSNJXGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[slevis-lmwg]

I will try to get that started this afternoon.

[slevis-lmwg]

This far, a new case that I'm calling b112_but_111land has not worked.

B112 uses clm53 code and, therefore, expects glacier region stuff that appears in 5.3 fsurdat files. It fails when I point to the 5.2 fsurdat. This does not worry me because the clm53 versus clm52 diagnostics in #60 show little change in Amazon LAI. I have a hard time seeing this explaining anything.

But b112 also expects new parameters in the paramfile and fails when I point to the 5.2 paramfile. So I will try making the 5.2 paramfile more like a 5.3 paramfile.

[olyson]

@slevis-lmwg , I was wondering if it would be possible to just switch the CLM external to the tag that was used in B111?

[slevis-lmwg]

Keith, that's a reasonable suggestion. This far I have created my cases using the sandboxes of the people who created the original cases (b112 was Gustavo's). I would need to determine the exact cesm tag that he used, checkout my own, and then do what you're suggesting. I can give that a shot tomorrow.

[slevis-lmwg]

This far I have tried this without success:

• I checked out cesm3_0_alpha03d (the cesm tag used for b112) and ran a 2-day clone of my b112oldfire as a sanity test, which worked (b112_but_111lnd). Then I changed the clm in .gitmodules to ctsm5.2.009 (as was used in b111), and the case built and ran, but the namelist looks like ctsm5.3, suggesting that this still used ctsm5.3. The env_case.xml shows that I'm still pointing to Gustavo's code.
• Then with ctsm5.2.009 in .gitmodules, I created a new case and got a build failure in cice (b112but111lnd).
• Turns out a create_newcase even without the .gitmodules change gives me the same build failure (b112but111ln).
• In the last case and in a new case intended to be the same, I changed cice in .gitmodules to what Gustavo seems to have used, but I get the same build failure (b112new). Puzzling...
• Even if I got the above to work, we don't know whether changing to the ctsm5.2 tag would play nice with the other components of this cesm tag. So instead I will go back to yesterday's plan and try changing the paramfile.

[dlawrenncar]

This might require a quick message to Jim Edwards to help understand where the pitfalls are. I'll leave it to you, though, to decide if that is actually the right approach or not. The alternative, of course, is to try to zero in on the changes that would have any real chance of causing this and just revert those. Surface dataset changes, you would think, would not be a source of the problem, but parameter changes and ??? might be. But I guess the parameter file changes are actually a bit difficult to implement due to changes in the parameters that are on the param file from CLM5.2 to CLM5.3?

…

On Fri, Dec 13, 2024 at 1:51 PM Samuel Levis ***@***.***> wrote: This far I have tried this without success: I checked out cesm3_0_alpha03d (the cesm tag used for b112) and ran a 2-day sanity test, which worked. Then I changed the clm in .gitmodules to ctsm5.2.009 (as was used in b111) and I got a build failure. My next thought is to try the latest ctsm5.2 tag in case it's compatible with the rest of cesm3_0_alpha03d. — Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVGA55ZRPLSOVAGBL7T2FMUCJAVCNFSM6AAAAABTJQKGVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBSGA2TIMJUHA> . You are receiving this because you commented.Message ID: ***@***.***>

[slevis-lmwg]

I ended up working a bit with Bill Sacks (earlier in the day) and with Erik (at the end of the day) and despite reasonable suggestions from both, I continue to get the same cice errors during the build phase:

/glade/work/slevis/git_cesm/cesm3/components/cice/src/cicecore/cicedyn/dynamics/ice_dyn_vp.F90(389): error #6784: The number of actual arguments cannot be greater than the number of dummy arguments.   [ICEPACK_ICE_STRENGTH]

/glade/work/slevis/git_cesm/cesm3/components/cice/src/cicecore/cicedyn/dynamics/ice_dyn_vp.F90(389): error #6633: The type of the actual argument differs from the type of the dummy argument.   [NCAT]

/glade/work/slevis/git_cesm/cesm3/components/cice/src/cicecore/cicedyn/dynamics/ice_dyn_vp.F90(392): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [AICE0]

/glade/work/slevis/git_cesm/cesm3/components/cice/src/cicecore/cicedyn/dynamics/ice_dyn_vp.F90(394): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [VICEN]

Component ice build complete with 78 warnings
cice built in 381.311938 seconds
ERROR: BUILD FAIL: cice.buildlib failed, cat /glade/derecho/scratch/slevis/b.e30_alpha03d.BLT1850.ne30_t232_wgx3.112new/bld/ice.bldlog.241213-185058

Meanwhile, though I the alternate attempt that we discussed (#85) is in progress.