Add warminglevels

[juliettelavoie]

Pull Request Checklist:

• pre-commit hooks are installed/active in my local clone ($ pre-commit install)
• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes #xyz
• (If applicable) Documentation has been added / updated (for bug fixes / features)
• If a merge request has been made in parallel to this PR in xscen-notebooks, it is merged and the submodules have been updated.
• HISTORY.rst has been updated (with summary of main changes)
  • Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

• See example here: https://gitlab.ouranos.ca/scenario/xscen-notebooks/merge_requests/11
• add produce_warming_level.
• add produce_horizon (produire dataset similaire à warming_level, mais à partir d'une période de référence. utile pour faire le delta ensuite).
• Changement à compute_deltas:
  ** S'il n'y a pas de dimensions 'time', n'essait pas de unstack time.
  ** cast les object à des str, sinon save_to_zarr plante.

Does this PR introduce a breaking change?

yes, compute_deltas use to fail when there was no time dimension.

Other information:

• Si vous pensez qu'il y a un meilleur format pour le output de produce_warming_level, je suis ouverte à le changer. C'est ce qui me semblait faire le plus de sens et qui fonctionnait bien avec mon workflow, mais peut-être que j'ai n'ai pas penser à tous les besoins. Je trouvais que c'était le temps de réunir toutes les fréquences en un dataset, mais on pourrait aussi garder ça en dictionnaire par fréquence. À discuter...

Autres Questions:

• Est-ce qu'on veut que la fonction lance une erreur si la source n'est pas dans le csv?
• Est-ce qu'on veut donner plus d'explication sur le formattage du warming_level_csv ou on veut juste que les gens utilise le fichier par défaut du GIEC et donc pas besoin d'explications qui les mélangeraient?
• @mccrayc a un fichier de moyenne de températures globales pour chaque année. Il y aurait un peu de travail à faire pour le traduire en année de dépassement similaire au fichier de l'IPCC. Il a CanESM5 pour 10 membres alors que l'IPCC n'a qu'un seul membre par modèles. Voulons-nous rajouter ses résultats à ceux de l'IPCC comme le défaut à prendre dans xscen? Sinon, il est toujours possible de passer un csv différent.

[juliettelavoie]

Suite à une discussion avec @mccrayc:

Le csv du giec donne une année centrale d'une période de 20 ans dont la moyenne a atteint un niveau de réchauffement global X. Cependant, je donne le droit à l'utilisateur de faire la moyenne des indicateurs sur n'importe quel window. Est-ce ok de faire ça? Est-ce qu'on veut au moins avertir si window!=20 et qu'on utilise le csv du GIEC?

Les pdfs ici montrent la différence entre 20 et 30 ans: https://github.com/IPCC-WG1/Atlas/tree/main/warming-levels
Pas de grosses différences, mais pas exactement pareil.

Est-ce une mauvais pratique (qu'xscen ne devrait pas permettre) d'utiliser des périodes différentes pour tas global et pour les indicateurs ?

[juliettelavoie]

Autre questionnement:

Le réchauffement global du giec est calculé à partir de la moyenne de 1850-1900. Dans le notebook, lorsque je fais mes deltas sur les indicateurs, ma période de référence est 2001-2020. Est-ce qu'il faudrait que le delta ait la même période référence que "+0C"? En général, on ne post-traite pas 1850-1900. Aussi, 1850-1900 n'est pas une période de 20 ou 30 ans...

[RondeauG]

Autre questionnement:

Le réchauffement global du giec est calculé à partir de la moyenne de 1850-1900. Dans le notebook, lorsque je fais mes deltas sur les indicateurs, ma période de référence est 2001-2020. Est-ce qu'il faudrait que le delta ait la même période référence que "+0C"? En général, on ne post-traite pas 1850-1900. Aussi, 1850-1900 n'est pas une période de 20 ou 30 ans...

Le delta n'a pas à être vs. 1850-1900, il faut utiliser la période de référence qui fait le plus de sens pour l'application donnée. Cela dit, horizon devrait être très clair que c'est +x°C par rapport au climat préindustriel/1850-1900, parce qu'en effet d'autres choix pourraient être pris. Cannon et al. (2020), par exemple, utilise "+x°C vs. 1986-2016" dans son rapport.

EDIT: Si on a un jour les outils pour calculer nous-mêmes les degrés de réchauffement, c'est une raison de plus d'être clairs sur quelle est la période utilisée comme point de départ pour +0°C.

[RondeauG]

Discussion avec @mccrayc:

Le csv du giec donne une année centrale d'une période de 20 ans dont la moyenne a atteint un niveau de réchauffement global X. Cependant, je donne le droit à l'utilisateur de faire la moyenne des indicateurs sur n'importe quel window. Est-ce ok de faire ça? Est-ce qu'on veut au moins avertir si window!=20 et qu'on utilise le csv du GIEC?

Les pdfs ici montrent la différence entre 20 et 30 ans: https://github.com/IPCC-WG1/Atlas/tree/main/warming-levels Pas de grosses différences, mais pas exactement pareil.

Est-ce une mauvais pratique (qu'xscen ne devrait pas permettre) d'utiliser des périodes différentes pour tas global et pour les indicateurs ?

Je ne m'y connais pas assez pour avoir une opinion forte. Pour le moment, je serais d'avis qu'on peut recommander 20 ans, mais laisser l'option d'avoir autre chose ? Et avoir un warning si la période diffère.

[mccrayc]

Suuite à une discussion avec @mccrayc:

Le csv du giec donne une année centrale d'une période de 20 ans dont la moyenne a atteint un niveau de réchauffement global X. Cependant, je donne le droit à l'utilisateur de faire la moyenne des indicateurs sur n'importe quel window. Est-ce ok de faire ça? Est-ce qu'on veut au moins avertir si window!=20 et qu'on utilise le csv du GIEC?

Les pdfs ici montrent la différence entre 20 et 30 ans: https://github.com/IPCC-WG1/Atlas/tree/main/warming-levels Pas de grosses différences, mais pas exactement pareil.

Est-ce une mauvais pratique (qu'xscen ne devrait pas permettre) d'utiliser des périodes différentes pour tas global et pour les indicateurs ?

Je crois qu'une bonne option pas trop lourde serait (au lieu d'inclure un csv avec les années), d'avoir un csv avec tas moyenne annuelle planétaire avec des colonnes 1850, 1851...2100, une ligne par membre GCM - RCP/SSP. Ensuite, xscen peut calculer le GWL avec n'importe quelle période de référence (1850-1900 pourrait être modifié comme dans Cannon) et n'importe quelle fenêtre (20 ans, 30 ans, etc.). Le GIEC utilise les valeurs dans https://github.com/IPCC-WG1/Atlas/tree/main/datasets-aggregated-regionally (fichiers tas_landsea) pour calculer leurs GWL, colonne 'world'. Il faudrait calculer les moyennes annuelles à partir de ces données mensuelles et les mettre ensemble dans un fichier probablement par génération CMIP.

J'ai une fonction qui fait essentiellement ça, non-optimisée mais assez rapide, parce que je voulais calculer les moyennes sur 30 ans pour le projet verglas. get_thresh_years(sim='bby', thresh=3, n_years=30, base_years=[1850,1900]).

Qu'en pensez-vous?

[juliettelavoie]

Suuite à une discussion avec @mccrayc:
Le csv du giec donne une année centrale d'une période de 20 ans dont la moyenne a atteint un niveau de réchauffement global X. Cependant, je donne le droit à l'utilisateur de faire la moyenne des indicateurs sur n'importe quel window. Est-ce ok de faire ça? Est-ce qu'on veut au moins avertir si window!=20 et qu'on utilise le csv du GIEC?
Les pdfs ici montrent la différence entre 20 et 30 ans: https://github.com/IPCC-WG1/Atlas/tree/main/warming-levels Pas de grosses différences, mais pas exactement pareil.
Est-ce une mauvais pratique (qu'xscen ne devrait pas permettre) d'utiliser des périodes différentes pour tas global et pour les indicateurs ?

Je crois qu'une bonne option pas trop lourde serait (au lieu d'inclure un csv avec les années), d'avoir un csv avec tas moyenne annuelle planétaire avec des colonnes 1850, 1851...2100, une ligne par membre GCM - RCP/SSP. Ensuite, xscen peut calculer le GWL avec n'importe quelle période de référence (1850-1900 pourrait être modifié comme dans Cannon) et n'importe quelle fenêtre (20 ans, 30 ans, etc.). Le GIEC utilise les valeurs dans https://github.com/IPCC-WG1/Atlas/tree/main/datasets-aggregated-regionally (fichiers tas_landsea) pour calculer leurs GWL, colonne 'world'. Il faudrait calculer les moyennes annuelles à partir de ces données mensuelles et les mettre ensemble dans un fichier probablement par génération CMIP.

J'ai une fonction qui fait essentiellement ça, non-optimisée mais assez rapide, parce que je voulais calculer les moyennes sur 30 ans pour le projet verglas. get_thresh_years(sim='bby', thresh=3, n_years=30, base_years=[1850,1900]).

Qu'en pensez-vous?

Les csv que tu as trouvés rendent ça relativement facile d'implémenter ton idée d'un csv avec la température par année et par modèle-expérience, je pense! Je trouve que c'est une bonne idée! Ça donne plus de flexibilité à l'utilisateur et ça donne des résultats plus exacts.

[juliettelavoie]

J'ai implémenter la suggestion de Chris. Il y a un nouveau csv. Le nom des colonnes suit le pattern {mip_era}{source}{exp}_{member}. Il y a les données de CMIP5 et CMIP6 venant de l'IPCC. J'ai aussi rajouter ce que Chris avait calculé à la main pour CanESM2 r2 à r5 (pilotes du MRCC5) et CanESM2 rX-rXiXpX (pilotes de ClimEx, la seule façon de les distinguer est leur pattern de membre spécial).

[RondeauG]

I think that everything has been addressed? Since it's a pretty big PR, I'd wait for a 2nd approval before merging though, I think.

Is the Notebook updated to this last version? If so, I'll go see it.

[juliettelavoie]

I think that everything has been addressed? Since it's a pretty big PR, I'd wait for a 2nd approval before merging though, I think.

Is the Notebook updated to this last version? If so, I'll go see it.

The merge request has been updated. You can review it.

@aulemahal, this is ready for review when you have the time !
@mccrayc, if you want, you can also review the PR.

[aulemahal]

Désolé du délai.

Un typo et une question impertinent, c'est tout.

Les tests ne fonctionneront pas tant que xclim 0.39 n'est pas disponible (très bientôt). On pourrait aussi rétrograder pint (<= 0.19) si on est pressé.

[aulemahal]

Que veux dire ce commentaire?

[juliettelavoie]

si freq est annuel, il y a seulement un pas de temps (1e janvier de la première année de l'horizon) comparé à MS qui en a 12. Le infer_freq de unstack_dates échoue sur 1 seul pas de temps parce qu'il ne peut pas inférer. Mais, dans le fond, le commentaire devrait juste dire: pas besoin de stack dates quand c'est annuel.

[juliettelavoie]

Les tests ne fonctionneront pas tant que xclim 0.39 n'est pas disponible (très bientôt). On pourrait aussi rétrograder pint (<= 0.19) si on est pressé.

Je n'ai pas de presse a merger avant que xclim 0.39 soit dispo. @RondeauG qu'est-ce que tu préfères? Je sais que tu attends après cette PR pour merger la tienne.

[RondeauG]

Je crois que 0.39 est sur le point d'être publié, donc pas de problème à attendre 1-2 jours.

Cela dit, il faudrait qu'on change nos requirements pour xclim>=0.39 si nos changements demandent la toute dernière version.

[juliettelavoie]

On n'a pas besoin de 0.39 à cause de nos changements. On a besoin de 0.39 si on prend la toute dernière version de pint. Pint 0.20 brise les anciennes versions de xclim. Donc, je ne pense pas qu'on doive changer nos requis...

Techniquement quelqu'un pourrait rouler xscen avec xclim 0.38 et pint 0.19.