Adding atlantic_meridional_overturning_circulation (AMOC) derived variable.

[ledm]

Hi,

I've added a new derived variable. It is a very simple scalar metric, known as the Atlantic meridional overturning circulation at 26N. This variable is an indication of the strength of the North bound circulation in the Atlantic. It is widely used to evaluate marine circulations models, and is included in several places in the IPCC reports on climate change.

The value at 26 degree north is used because that is the location of the RAPID array. The rapid array is an array of instruments in the Atlantic along the 26th parallel which measures circulation and heat transport. If you need a better description, I'd encourage you to talk to @tillku, who is an expert on this.

In ESMValTool, the AMOC variable is calculated by:

1. Loading the msftmyz field as a cube.
2. Find the relevant region (the msftmyz field contain Global, Indian and Atlantic regions, we're looking for the Atlantic stream function here.)
3. Find the latitude closest to 26.5 N
4. Find the maximum over the water column of the stream function at 26.5N, for each time step.

Alongside the new amoc variable, I've added a recipe (recipe_amoc.yml). This recipe produces the following images for every CMIP5 model with a msftmyz field:

• Time series figures of the AMOC at 26 N:

• Stream functions transect figure for the Atlantic, Indian and Global zonal means.

• Stream functions transect contours figures for the Atlantic, Indian and Global zonal means.

And also produces the following multi model comparisons:

• Time series figures comparing all the AMOC at 26 N.

• Multi model contours for -20, -10, 0, 10, & 20 Tg s-1 :

Please let me know if we are happy to make a PR to move this into the main branch. (Please note that this work is mostly independent of the work I've been doing with regards to issue #737 and doesn't require the extensive code described there.)

[ledm]

The more I look at this, the more I wonder about my suggestion to create a preprocessor to extract a specific named region (originally discussed in #673). It would also make more sense in the scalar function tools. It would be very simple to extract the Atlantic region in a preprocessor, instead of plotting all three regions, as done in this recipe.

[ledm]

I've now added a preprocessor, extract_named_regions in _area_pp.py, and associated units tests.

While @mattiarighi originally said "We should just avoid having to many preprocessor functions." when I suggested this preprocessor before, the extract_named_regions preprocessor is simple, important & useful.

It is used for extracting both the AMOC and Drake passage current data, two crucial global currents that underlie a significant part of the evaluation of the marine components of ESMs in CMIP6. Those two metrics are the first things we check in the ocean circulation models.

The PR containing this new code is #740.

[mattiarighi]

Agree. At the beginning I was a bit hesitant to implement too many functionalities that would be hard to maintain. But the community of active v2 users has grown since them and now I am more positive :smiley:

Just one comment about the variable derivation: given the discussion in #733, are you sure you want to implement amoc as a derived variable, rather than having a diagnostic script which calculates it?

[ledm]

Glad to hear you're onboard!

I'm not entirely sure that I follow the full discussion in #733. However, I think there's a case to be made for the AMOC at 26N to be a derived variable. Are there any scientific or technical requirements that need to met for a derived variable to be included in ESMValTol?

Either way, the AMOC at 26N is such a crucial metric, telling a lot about one of the most significant ocean circulations, and about the flux of heat from the tropics into the North Atlantic. In addition, there is an well studied high quality observational dataset available (although the observational data are not included in this recipe, yet).

[mattiarighi]

Variable derivation has been originally implemented with 2 use cases in mind:

1. When an observational dataset contains a variable which is not directly available in the model data.

The prototype for this case is total column ozone (toz): this is given in many satellite datasets, but the CMIP5 models only provide the 3D ozone field (tro3). The derivation routine simply calculates the vertical integral of the 3D field to get the total column and allow the comparison with observations.

2. When you want to use an existing diagnostic designed for single variables with complex variables.

An example here are the cloud radiative effects (lwcre and swcre) in the recipe_perfmetrics_CMIP5.yml. These variables are calculated as the difference of two standard variables and this is applied to both model and observations. One could implement this simple calculation directly in the perfmetrics diagnostic, but this would require hard coding an exception (if variable == lwcre then...) which on the long term may be hard to maintain.

So, back to amoc. If this variable is available in the observations, then it's use case 1 and derivation is definitely the solution.

Use case 2 depends a bit on which kind of diagnostics you want to apply to your variable.

[ledm]

For the case of the AMOC, the data is indeed available, here. You can see in this figure from that page, the red line (MOC) and it's corresponding monthly average is directly comparable to the AMOC derived variable:

In addition, producing the AMOC as a derived variable means that it can be treated by the same diagnostic tools (ocean/diagnostic_timeseries.py) as all the other scalar fields. This saves me having to create a new diagnostic script for a single field.

[mattiarighi]

Then it makes perfectly sense to have it derived. :+1:

[ledm]

The associated PR was merged, so I'm closing this issue.