future scenario ssp585

[PengyangSong]

Dear developers,
I tried a future scenario but it does not work.
What I changed in yaml file is this:
echam: scenario: "ssp585"

The error log is this:

ERROR: Missing Configuration

The input file variable LU_HIST of forcing_sources can not be fully resolved:

/work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/hist_harvest/LUH_harvest_T63_1850.nc:
to: 1850
/work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/hist_harvest/LUH_harvest_T63_@YEAR@.nc:
from: 1851

Thanks for any comments.

[denizural]

Hi @PengyangSong,
we have a branch feat/ssp585_awicm-recom_v6_WITH_RELEASE which will be merged soon. Could you please checkout that branch and give it a try?
We developed that mainly for Mistral, so it may not work right away. If you can provide me with a runscript, I can also have a look.

[PengyangSong]

Hi @denizural
I mainly work on ollie, so if you would kindly try the runscript on ollie also, I would be very grateful.
The location is in /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585_ini.yaml
Thanks.

[denizural]

Hi @PengyangSong, I think I discovered a bug while try to setup your simulation. I will solve it first very quickly.

[denizural]

Hi @PengyangSong, I finished the bugfix. I have a question for you? Which branch of ESM-Tools are you using? Are you on release or a special one that supports ssp585 scenario? You are having this issue because the forcing files for ssp585 are not defined.

Another issue is you need to fix the line in your runscript res: "CORE2" to resolution: "CORE2". In the future, I will implement a mechanism that will detect such issues.

[PengyangSong]

1. release version. esm_tools, version 6.0.2.
2. Thanks. I will fix that.

[denizural]

Thanks for the feedback. As I mentioned previously there is a branch where you can find ssp585 forcing files:
https://github.com/esm-tools/esm_tools/tree/feat/ssp585_awicm-recom_v6_WITH_RELEASE/configs
You can use these options in your runscript. The esm_runscripts terminate because land use forcing data is not defined.

[PengyangSong]

Problem solved.
To simulate ssp585 scenario, one needs to add below to the yaml file:

jsbach:
      scenario_type: "cmip6"
      namelist_dir: "${general.esm_namelist_dir}/jsbach/${version}/HIST/dynveg"
      add_forcing_files:
          Ndepo: Ndepo_1850

echam:
      greenhouse_dir: "${echam.input_dir}"

[mandresm]

As far as I understand, you'll be using the wrong file for Ndepo, the one for 1850. Instead, you need to use the one for the ssp585 scenario. @chrisdane, can you confirm that what I am saying is correct?

[PengyangSong]

If we do not make these changes, we will get:

WARNING: File not found: /work/ollie/pool/ECHAM6/input/r0007/T63/greenhouse_historical.nc
2022-09-07 10:16:37.602879
WARNING: File not found: /work/ollie/pool/JSBACH/input/r0010/T63/ndepo/Ndepo.2001.nc
2022-09-07 10:16:37.613256
WARNING: File not found: /work/ollie/pool/JSBACH/input/r0010/T63/ndepo/Ndepo.2000.nc
2022-09-07 10:16:37.613424
WARNING: File not found: /work/ollie/pool/JSBACH/input/r0010/T63/ndepo/Ndepo.2002.nc
2022-09-07 10:16:37.613606
WARNING: File not found: /home/ollie/psong/esm_tools/namelists/jsbach/3.20/ssp585/dynveg/namelist.jsbach

I found that these files are in:

/work/ollie/pool/ECHAM6/greenhouse_rcp85.nc
/work/ollie/pool/JSBACH/input/r0010/T63/Ndepo/ssp585/T63_ndepo.input4MIPs_surfaceFluxes_ScenarioMIP-NCAR-CCMI-ssp585_@YEAR@.nc
/home/ollie/psong/esm_tools/namelists/jsbach/3.20/PI-CTRL/dynveg/namelist.jsbach

1. In jsbach.yaml, when we use 3.20, there is no entry for ssp* scenario, which finally directs to scenario "cmip6", thus the Land Use files are missing.
2. esm_tools does not have an ssp585 namelist for JSBACH-3.20. Since in 3.10 the PI-CTRL namelist does not have difference with ssp585 namelist. I guess for 3.20 the namelist is more or less like PI-CTRL or HIST.
3. echam greenhouse file should use greenhouse_rcp85.nc but I do not know how to add lines in my yaml file instead of modifying echam.datasets.yaml.
4. The same reason for Ndepo that if it is not corrected in jsbach.datasets.yaml, I do not know how to give a filename from my template.

[mandresm]

There has being recent updates (and not so recent, since May) that solve some of the problems that you are mentioning for ssp simulations. The missing Ndepo specific to ssp585 simulations is still an ongoing problem but it should be solved by the end of this week by the merge of tPR #747

[PengyangSong]

That's strange, I did "git pull" recently (maybe one month ago). But the problems are not solved, maybe they are solved in some branch but not merged yet.

[mandresm]

The problems are not solved yet indeed, #747 should solve the problems. If you click in that PR, you can keep track of our work. I will ask you for help to test if that PR works for you, later today, or early tomorrow, after I make the final changes.

[PengyangSong]

Hi all @denizural @mandresm @pgierz,
I tested the fix/ssp_generalization_jsbach branch. Some errors remain, and I hope these can be fixed before the merging of this branch.

1. aero_coarse, aero_farir and aero_fine are always renamed as year 1849, 1850, 1851, regardless of actual model year.

file aero_coarse_1852.nc does not exist.

2. esm_master clean-awiesm-2.1-wiso does not work.

Traceback (most recent call last):
  File "/home/ollie/psong/esm_tools/src/esm_parser/esm_parser.py", line 1850, in recursive_get
    result = config_to_search[this_config]
KeyError: 'scenario_type'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ollie/psong/esm_tools/src/esm_parser/esm_parser.py", line 1406, in resolve_basic_choose
    choice = recursive_get(config, path_to_key)
  File "/home/ollie/psong/esm_tools/src/esm_parser/esm_parser.py", line 1857, in recursive_get
    return recursive_get(result, my_config_elements)
  File "/home/ollie/psong/esm_tools/src/esm_parser/esm_parser.py", line 1853, in recursive_get
    "Exactly None! Couldn't find an answer for:", my_config_elements
ValueError: ("Exactly None! Couldn't find an answer for:", [])

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ollie/psong/.local/bin/esm_master", line 11, in <module>
    load_entry_point('esm-tools', 'console_scripts', 'esm_master')()
  File "/home/ollie/psong/esm_tools/src/esm_master/cli.py", line 103, in main
    main_flow(parsed_args, target)
  File "/home/ollie/psong/esm_tools/src/esm_master/esm_master.py", line 55, in main_flow
    complete_setup = SimulationSetup(user_config=user_config)
  File "/home/ollie/psong/esm_tools/src/esm_runscripts/sim_objects.py", line 42, in __init__
    self.config = prepare.run_job(self.config)
  File "/home/ollie/psong/esm_tools/src/esm_runscripts/prepare.py", line 17, in run_job
    helpers.evaluate(config, "prepare", "prepare_recipe")
  File "/home/ollie/psong/esm_tools/src/esm_runscripts/helpers.py", line 70, in evaluate
    framework_recipe, framework_plugins, config
  File "/home/ollie/psong/esm_tools/src/esm_plugin_manager/esm_plugin_manager.py", line 141, in work_through_recipe
    config = getattr(submodule, workitem)(config)
  File "/home/ollie/psong/esm_tools/src/esm_runscripts/prepare.py", line 126, in resolve_some_choose_blocks
    esm_parser.choose_blocks(config, blackdict=config._blackdict)
  File "/home/ollie/psong/esm_tools/src/esm_parser/esm_parser.py", line 2591, in choose_blocks
    blackdict[model_with_choose],
  File "/home/ollie/psong/esm_tools/src/esm_parser/esm_parser.py", line 1409, in resolve_basic_choose
    raise KeyError("Key %s was not defined" % ".".join(path_to_key))
KeyError: 'Key jsbach.scenario_type was not defined'

3. From ECHAM filelist. Should we find some greenhouse_ssp585.nc instead of greenhouse_historical.nc?

Source: /work/ollie/pool/ECHAM6//input/r0007/greenhouse_historical.nc
Exp Tree: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/forcing/echam/greenhouse_gases.nc
Target: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/work/greenhouse_gases.nc

4. From JSBACH filelist. Should we use /work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/ssp585_dynveg and ssp585_harvest instead of hist_dynveg and hist_harvest?

Source: /work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/hist_harvest/LUH_harvest_T63_2001.nc
Exp Tree: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/forcing/jsbach/landuseHarvest.2001.nc
Target: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/work/landuseHarvest.2001.nc

Source: /work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/hist_harvest/LUH_harvest_T63_2000.nc
Exp Tree: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/forcing/jsbach/landuseHarvest.2000.nc
Target: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/work/landuseHarvest.2000.nc

Source: /work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/hist_harvest/LUH_harvest_T63_2002.nc
Exp Tree: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/forcing/jsbach/landuseHarvest.2002.nc
Target: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/work/landuseHarvest.2002.nc

Source: /work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/hist_dynveg/LUH_scaled_transitions_T63_2001.nc
Exp Tree: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/forcing/jsbach/landuseTransitions.2001.nc
Target: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/work/landuseTransitions.2001.nc

Source: /work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/hist_dynveg/LUH_scaled_transitions_T63_2000.nc
Exp Tree: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/forcing/jsbach/landuseTransitions.2000.nc
Target: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/work/landuseTransitions.2000.nc

Source: /work/ollie/pool/JSBACH/input/r0010/T63/New_Hampshire_LCC/hist_dynveg/LUH_scaled_transitions_T63_2002.nc
Exp Tree: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/forcing/jsbach/landuseTransitions.2002.nc
Target: /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585/run_20010101-20011231/work/landuseTransitions.2002.nc

Regards.

[denizural]

Hi @PengyangSong,
could you please provide your runscript? It seems that /work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585_ini.yaml does not exist any more but there is another yaml file. You are working in that experiment directory, right? (PI_CTRL_585.yaml)

[PengyangSong]

That's right.
/work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585
/work/ollie/psong/AWIESM-2.1-wiso/PI_CTRL_585.yaml

[mandresm]

One comment about your runscript: the way AWIESM is configured in the latest versions of ESM-Tools (I think from 6.13.0) is that you only need to define the scenario under the general section of the coupled setups (if you run a standalone simulation you should place the scenario under echam). So my recommendation is that you move scenario to general once you start to use a more recent version of ESM-Tools, it won't fix anything but it would be just a better practice in the context on what has been decided in the big AWIESM meetings, where we discussed with the users how to better configure ECHAM.

Another thing to notice, by default ESM-Tools defines the echam.dataset: r0007, however the r0007 folder (/work/ollie/pool/ECHAM6/input/r0007) does not contain the files for ssp simulations. Instead the r0008 do. I have added a warning in the fix/ssp_generalization_jsbach that detects this problem and tells the user (you'll need to pull my changes). @PengyangSong, with your current runscrip, could you please resubmit a test and see if the warning pops up for you? Let me know if you are happy with the content of that warning.

With the exception of point 1, the problems here had been solved/clarified. For the record, here are the answers:
2. Fixed by @denizural , comment below.
3. You are running a simulation from 1850. That means the beginning is historical even if you define the echam.scenario: ssp585. In 2015 it should stop using the greenhouse_historical.nc and start using greenhouse_ssp585.nc, and that's how it's configured here:

esm_tools/configs/components/echam/echam.datasets.yaml

Lines 86 to 90 in 0a0e010

	"greenhouse_hist_scenario":
	"${greenhouse_dir}/greenhouse_historical.nc":
	to: 2014
	"${greenhouse_dir}/greenhouse_${scenario}.nc":
	from: 2015

4. Same goes for ssp585_harvest:

esm_tools/configs/components/jsbach/jsbach.datasets.yaml

Lines 25 to 33 in 0a0e010

	"LU_HIST":
	"${input_dir}/${echam.resolution}/New_Hampshire_LCC/${hist_fold}/LUH_harvest_${echam.resolution}_1850.nc":
	to: 1850
	"${input_dir}/${echam.resolution}/New_Hampshire_LCC/${hist_fold}/LUH_harvest_${echam.resolution}_@YEAR@.nc":
	from: 1851
	to: 2014
	# HIST scenario will use this data beyond year 2014
	"${input_dir}/${echam.resolution}/New_Hampshire_LCC/${hist_extend_scenario}_harvest/LUH_harvest_${echam.resolution}_@YEAR@.nc":
	from: 2015

Where hist_extend_scenario is defined here:

esm_tools/configs/components/jsbach/jsbach.datasets.yaml

Lines 3 to 8 in 0a0e010

	# CD: Only for LU_hist definition is for years larger than 2014 (needed only to load
	# forcing data of the current year + 1 to do an interpolation). The historical
	# simulation in CMIP6 ends in 2014, the only data that is needed by echam is data from
	# 2015 and we agreed to choose the one from the ssp370 scenario (it does not really
	# matter which is chosen)
	hist_extend_scenario: ssp370

(@chrisdane , is it okay in all the cases to always use the hist_extend_scenario: ssp370? It's very easy to change to whatever ssp one is using)

and for ssp585_dynveg:

esm_tools/configs/components/jsbach/jsbach.datasets.yaml

Lines 103 to 107 in 0a0e010

	"LU_trans_hist_scenario":
	"${input_dir}/${echam.resolution}/New_Hampshire_LCC/hist${dynveg}/LUH_scaled_transitions_${echam.resolution}_@YEAR@.nc":
	to: 2014
	"${input_dir}/${echam.resolution}/New_Hampshire_LCC/${echam.scenario}${dynveg}/LUH_scaled_transitions_${echam.resolution}_@YEAR@.nc":
	from: 2015

If you want to test that ESM-Tools does the correct thing for the ssp scenario files you can choose to run in check mode a test simulation changing the starting date of your runscript to 2015. Then it shoulds start using the ssp files.

[chrisdane]

Ok with me!

[denizural]

Hi @PengyangSong,
could you please pull the latest changes in the fix/ssp_generalization_jsbach branch. We made a fix that solves the parser error you are getting when you try to clean/install AWIESM

[PengyangSong]

Hi @PengyangSong, could you please pull the latest changes in the fix/ssp_generalization_jsbach branch. We made a fix that solves the parser error you are getting when you try to clean/install AWIESM

Hi @denizural , clean- and comp- now seems good.

[PengyangSong]

Hi all, the problem is now solved as below.

1. @christian-stepanek showed me some changes in namelist.echam (&radctl). iaero is set to 3, 8 and 9 in CTRL, HIST and SSP scenarios, respectively. More information of iaero settings, go to ECHAM source code stepon.f90 and mo_radiation.f90.
2. If the model year is larger equal than 2015, echam.dataset should switch from r0007 (default) to r0008.

An example of modifying the yaml file looks like below, now it works with the fix/ssp_generalization_jsbach branch.

echam:
    scenario: "ssp585"
    dataset: r0008
    add_namelist_changes:
        namelist.echam:
            radctl:
                iaero: 9

Thank you all for the kind help.

[mandresm]

Thanks for your input, this is now addressed in this PR: #747

[christian-stepanek]

Dear all, sorry for my late reply due to CoVid/traveling. Jule Schrepfer has successfully run some future simulations based on SSP with AWI-ESM2 based on the esm-tools. So if something still does not work one could check whether the settings must be updated to be in agreement with Jule's. For reference I attach the namelists (all of them - I guess only namelist.jsbach and namelist.echam should be of relevance for SSP).

In case you would like to look into more details, the simulation is stored here:
/work/ab0246/from_Mistral/ab0246/a270188/awiesm-2.1-wiso_future/pico-fesom/experiments/ssp5_104/

namelist.config.txt
namelist.echam.txt
namelist.forcing.txt
namelist.ice.txt
namelist.io.txt
namelist.jsbach.txt
namelist.oce.txt

[mandresm]

thanks for your reply!

[mandresm]

I have checked all the namelists agains a default ssp experiment with AWIESM-2.1 with the current ESM-Tools branch ssp_generalization and they all look as the ones from Jule, with some minor changes that are handled automatically (with_pico/without_pico). The only one presenting differences I don't understand is the one mentioned here: #840 (comment)

Once those are clarified we should be on the safe side of things with our defaults in ESM-Tools for AWIESM-2.1 + SSP

[PengyangSong]

The below parts should also be treated carefully, which comes from namelist.echam. Otherwise no future warming is simulated because greenhouse gases do not work.
I would suggest creating a new ECHAM namelist in ESM-tools just for SSP scenario.

&radctl
    iaero = 8
    io3 = 4
    isolrad = 1
    ighg = 1
    ico2 = 4
    icfc = 4
    ich4 = 4
    in2o = 4
    yr_perp = 1850
    lrad_async = .false.
    lrestart_from_old = .false.
/

&co2ctl
    lco2_scenario = .true.
/

Pengyang

[mandresm]

That is a very good point. I suggest that we actually use the one from Jule, reported by @christian-stepanek which have the same values as you are requesting