Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Bias-correct CESM2 LENS temperature data

Bias-correct CESM2 LENS temperature data using ERA5 reanalysis

Input Data Access

  • This notebook illustrates how to bias-correct daily temperature data from CESM2 Large Ensemble Dataset (https://www.cesm.ucar.edu/community-projects/lens2) hosted on AWS.

  • This data is open access (https://aws.amazon.com/marketplace/pp/prodview-xilranwbl2ep2#resources)

  • We will access the data using OSDF’s AWS open data origin.

  • The OSDF zarr paths are obtained from an intake catalog which lives on NCAR’s Geoscience Data Exchange (GDEX) and is publicly accessible via https.

  • We will use NCAR’s origin to access the publicly available ERA5 reanalysis.

  • In summary, this notebook illustrates how we can access data from two different OSDF origins using PelicanFS and perform an interesting computation.

Computational resources and Output data
  • If you don’t have access to NCAR’s HPC system, please select the appropriate cluster

  • All the intermediate results and the final result will be written to NCAR’s GLADE storage system, which doesn’t have public write access.

  • You are welcome to modify this to suit your needs.

Import package, define parameters and functions

Create a Dask cluster

Dask Introduction

Dask is a solution that enables the scaling of Python libraries. It mimics popular scientific libraries such as numpy, pandas, and xarray that enables an easier path to parallel processing without having to refactor code.

There are 3 components to parallel processing with Dask: the client, the scheduler, and the workers.

The Client is best envisioned as the application that sends information to the Dask cluster. In Python applications this is handled when the client is defined with client = Client(CLUSTER_TYPE). A Dask cluster comprises of a single scheduler that manages the execution of tasks on workers. The CLUSTER_TYPE can be defined in a number of different ways.

  • There is LocalCluster, a cluster running on the same hardware as the application and sharing the available resources, directly in Python with dask.distributed.

  • In certain JupyterHubs Dask Gateway may be available and a dedicated dask cluster with its own resources can be created dynamically with dask.gateway.

  • On HPC systems dask_jobqueue is used to connect to the HPC Slurm, PBS or HTCondor job schedulers to provision resources.

The dask.distributed client python module can also be used to connect to existing clusters. A Dask Scheduler and Workers can be deployed in containers, or on Kubernetes, without using a Python function to create a dask cluster. The dask.distributed Client is configured to connect to the scheduler either by container name, or by the Kubernetes service name.

Select the Dask cluster type

The default will be LocalCluster as that can run on any system.

If running on a HPC computer with a PBS Scheduler, set to True. Otherwise, set to False.

If running on Jupyter server with Dask Gateway configured, set to True. Otherwise, set to False.

Python function for a PBS cluster
Python function for a Gateway Cluster
Python function for a Local Cluster
Python logic to select the Dask Cluster type
  • This uses True/False boolean logic based on the variables set in the previous cells

/glade/u/home/harshah/venvs/osdf/lib/python3.10/site-packages/distributed/node.py:187: UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 42145 instead
  warnings.warn(
Loading...

Load CESM LENS2 temperature data from AWS using an intake catalog

Loading...
Loading...
array(['https://stratus.gdex.ucar.edu/d010092/atm/daily/cesm2LE-historical-cmip6-TREFHTMX.zarr', 'https://stratus.gdex.ucar.edu/d010092/atm/daily/cesm2LE-historical-smbb-TREFHTMX.zarr', 'https://stratus.gdex.ucar.edu/d010092/atm/daily/cesm2LE-ssp370-cmip6-TREFHTMX.zarr', 'https://stratus.gdex.ucar.edu/d010092/atm/daily/cesm2LE-ssp370-smbb-TREFHTMX.zarr'], dtype=object)

--> The keys in the returned dictionary of datasets are constructed as follows:
	'component.experiment.frequency.forcing_variant'
Loading...
Loading...
CPU times: user 4.38 s, sys: 264 ms, total: 4.65 s
Wall time: 1min 36s
Loading...
CPU times: user 141 ms, sys: 15.4 ms, total: 156 ms
Wall time: 1.01 s
<Figure size 640x480 with 2 Axes>

Save means and standard deviations

  • Save the overall means, standard devaitions and the ensemble means

  • We will regrid the ‘final/EOC’ ensemble means onto the ERA5 grid.

  • We will then compare it with the bias-corrected future predictions obtained from ERA5

Access ERA5 data and regrid CESM2 LENS data on the finer, ERA5 grid

  • In this section, we will load pre-processed ERA5 data from the NCAR origin

  • We will not use an intake catalog

ncar/gdex/special_projects/harshah/era5_tas/zarr/e5_tas2m_daily_1940_2023.zarr
osdf:///ncar/gdex/special_projects/harshah/era5_tas/zarr/e5_tas2m_daily_1940_2023.zarr
CPU times: user 534 ms, sys: 24.7 ms, total: 559 ms
Wall time: 781 ms
Loading...

Perform Bias Correction

Loading...
Loading...

Re-grid the model data onto the ERA5 grid

Using xesmf
Using xarray-regridder
Loading...
CPU times: user 863 ms, sys: 37 ms, total: 900 ms
Wall time: 986 ms
CPU times: user 12.3 ms, sys: 109 μs, total: 12.4 ms
Wall time: 12.6 ms

Now, perform bias correction by only adjusting the first moment, i.e, mean and plot

Loading...

Plot bias corrected temperature and CESM model’s predictions for the End of the 21st century (2100)

  • Since tas_bc are predictions for the years 2070-2100, we need to change the year coordinated

  • We will then save the bias-corrected surface air temperatures (tas) to a zarr store.

  • Finally, we will read from this zarr store and plot

Loading...
Loading...
Loading...
CPU times: user 226 ms, sys: 24 ms, total: 249 ms
Wall time: 880 ms
<Figure size 640x480 with 2 Axes>
<Figure size 640x480 with 2 Axes>
<Figure size 1000x500 with 3 Axes>
CPU times: user 1.01 s, sys: 68.6 ms, total: 1.08 s
Wall time: 1.5 s