a diagnostic to evaluate the turnover times of land ecosystem carbon

[dr-ko]

…stock

Before you start, read CONTRIBUTING.md and the guide for diagnostic developers.

Please discuss your idea with the development team before getting started, to avoid disappointment later. The way to do this is to open a new issue on GitHub. If you are planning to modify existing functionality, please discuss it with the original author(s) by tagging them in the issue.

---

Tasks

• Create an issue to discuss what you are going to do, if you haven't done so already (and add the link at the bottom)
• Give this pull request a descriptive title that can be used as a one-line summary in a changelog
• Make sure your code is composed of functions of no more than 50 lines and uses meaningful names for variables
• Circle/CI tests pass. Status can be seen below your pull request. If the tests are failing, click the link to find out why.
• Preferably Codacy code quality checks pass, however, a few remaining hard to solve Codacy issues are still acceptable. Status can be seen below your pull request. If there is an error, click the link to find out why. If you suspect Codacy may be wrong, please ask by commenting.
• Please use yamllint to check that your YAML files do not contain mistakes

New recipe/diagnostic

• Add documentation for the recipe to the doc/sphinx/source/recipes folder and add a new entry to index.rst

If you need help with any of the tasks above, please do not hesitate to ask by commenting in the issue or pull request.

---

Closes #1393

[zklaus]

I put some comments with regards to the documentation. Will take a look at the code now.

[mattiarighi]

In this case the cmorizer script should be provided, so that everyone is able to generate the observational data for the recipe after retrieving the original data from the respective source.

See here.

[mattiarighi]

This PR should also be in the final release, since it's part of one of the already accepted ESMValTool papers.

There are however two issues to be solved:

• the cmorizer for the observation is apparently missing
• the recipe name does not follow the standard filenaming convention of the tool (easy fix)

@koir-su any chance you can solve these issues before the final release (end of July)?

[dr-ko]

Hi Mattia, we have had several discussions on the observation. The cmorization of observation is not a straightforward one here, as the variable compared is not a standard observation but rather a derived variable that is very specific. On top of that, every figure needs a derivation of the observation at the spatial and regional scale. For example, the uncertainty ranges cannot be aggregated, as has been discussed elsewhere within ESMValTool. So, the scripts to prepare observation is not a cmorization script but a rather complicated collection of derivations that produces the data up to the standard needed in the ESMValTool. Moreover, the derived observation-based data are provided in 11 different resolutions so that the evaluators have enough flexibility.

I have pushed the changes to the filenames, as you suggested.

[bouweandela]

Regarding previous discussion on the observations, it took place here #1395 (comment) and here #1395 (comment)

[mattiarighi]

matplotlib is complaining...

Traceback (most recent call last):
  File "/mnt/lustre01/pf/b/b309057/ESMValTool/public/esmvaltool/diag_scripts/land_carbon_cycle/diag_global_turnover.py", line 824, in <module>
    main(config)
  File "/mnt/lustre01/pf/b/b309057/ESMValTool/public/esmvaltool/diag_scripts/land_carbon_cycle/diag_global_turnover.py", line 788, in main
    _plot_multimodel_agreement(plot_path_multimodel, global_tau_mod,
  File "/mnt/lustre01/pf/b/b309057/ESMValTool/public/esmvaltool/diag_scripts/land_carbon_cycle/diag_global_turnover.py", line 614, in _plot_multimodel_agreem
ent
    col_bar = plut.mk_colo_cont(_axcol_rat,
  File "/mnt/lustre01/pf/b/b309057/ESMValTool/public/esmvaltool/diag_scripts/land_carbon_cycle/plot_utils.py", line 169, in mk_colo_cont
    norm=mpl.colors.BoundaryNorm(
  File "/work/bd0080/b309057/SOFTWARE/miniconda3/envs/esmvaltool/lib/python3.8/site-packages/matplotlib/colors.py", line 1486, in __init__
    raise ValueError(f"There are {self._N} color bins including "
ValueError: There are 287 color bins including extensions, but ncolors = 256; ncolors must equal or exceed the number of bins

[bouweandela]

the scripts to prepare observation is not a cmorization script but a rather complicated collection of derivations that produces the data

Are these scripts available somewhere publicly? In the interest of transparency and reproducibility, it would be really good if these could be made available somewhere, along with instructions on how to obtain the original input data and how to use the scripts.

[dr-ko]

Damn! I use 2.2.4, and it does not complain. Can you please send me the yml for your esmvaltool environment so that I can try to fix it within that...

[dr-ko]

Are these scripts available somewhere publicly? In the interest of transparency and reproducibility, it would be really good if these could be made available somewhere, along with instructions on how to obtain the original input data and how to use the scripts.

No, but I can add the programs as is to a git repo. The full data will not be available publicly for the reasons mentioned before. The uncertainty bounds are based on the full cube of all realizations from Carvalhais, which is not available for public use (outside my hands).
For the zonal means and correlations, the processing script is exactly the same as implemented in ESMValTool for models.

[mattiarighi]

Can you please send me the yml for your esmvaltool environment so that I can try to fix it within that...

https://github.com/ESMValGroup/ESMValTool/blob/master/environment.yml

and I'm using

matplotlib-base           3.3.0            py38hb801037_0    conda-forge

[dr-ko]

@mattiarighi, I have fixed the issue with the matplotlib version. Can you give it another go?

[mattiarighi]

There is something wrong with the provenance:

"""
Traceback (most recent call last):
  File "/work/bd0080/b309057/SOFTWARE/miniconda3/envs/esmvaltool/lib/python3.8/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "/work/bd0080/b309057/SOFTWARE/miniconda3/envs/esmvaltool/lib/python3.8/site-packages/esmvalcore/_task.py", line 730, in _run_task
    output_files = task.run()
  File "/work/bd0080/b309057/SOFTWARE/miniconda3/envs/esmvaltool/lib/python3.8/site-packages/esmvalcore/_task.py", line 242, in run
    self.output_files = self._run(input_files)
  File "/work/bd0080/b309057/SOFTWARE/miniconda3/envs/esmvaltool/lib/python3.8/site-packages/esmvalcore/_task.py", line 520, in _run
    self._collect_provenance()
  File "/work/bd0080/b309057/SOFTWARE/miniconda3/envs/esmvaltool/lib/python3.8/site-packages/esmvalcore/_task.py", line 590, in _collect_provenance
    if ancestor_file in ancestor_products:
TypeError: unhashable type: 'list'
"""

[bouweandela]

@mattiarighi Can you attach the log so we can see which diagnostic it is? This happens when ancestors is a list of list of strings instead of a list of strings.

[mattiarighi]

main_log.txt
main_log_debug.txt

[bouweandela]

Could you also attach /mnt/lustre02/work/bd0854/b309057/ESMValTool/v2_output/recipe_carvalhais14nat_20200727_153204/run/diag_land_carbon_turnover/global_turnover_time/diagnostic_provenance.yml? It looks like the problem is in diag_land_carbon_turnover/global_turnover_time.

[mattiarighi]

diagnostic_provenance.txt

[bouweandela]

Ok, so the problem is in the files related to the figure with caption "Map of global distribution of turnover time of carbon". @koir-su Can you have look?

[dr-ko]

Thanks, both. Apparently, the problem was due to having a list as ancestor_files. Needed dictionary. Strangely, was not a problem with the older version of ESMValTool.

[mattiarighi]

Thank you, it works now.

@bouweandela please cherry-pick.

[dr-ko]

Thank you all for such a thorough review. I can say that I learned a lot from this. 🍻

[bouweandela]

please cherry-pick.

@mattiarighi Done

No, but I can add the programs as is to a git repo. The full data will not be available publicly for the reasons mentioned before. The uncertainty bounds are based on the full cube of all realizations from Carvalhais, which is not available for public use (outside my hands).

@koir-su It would be great if you could do this and add a link in the recipe documentation. Make sure to add Zenodo integration to the repository and then make a release, so they have a DOI. If you have no intention of changing the scripts, you could also directly upload them to Zenodo.