You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The UKESM1's ocean spatial grid does not change (and perhaps other models too). It will always be the same for all MIPs, scenarios, experiments and time ranges. With this in mind, there is only one copy of the grid area data, areacello. It can be found with:
fx_cube = iris.load_cube(fx_file)
File "/home/users/ldemora/anaconda3_20190821/envs/esmvaltoolprivate/lib/python3.7/site-packages/iris/__init__.py", line 381, in load_cube
raise iris.exceptions.ConstraintMismatchError('no cubes found')
iris.exceptions.ConstraintMismatchError: no cubes found
@valeriupredoi and I have been discussing this. There are a few suggestions on how to adapt to solve this issue in the short term:
Make _get_correct_fx_file smart enough to look in picontrol if the areacella, areacello is not found.
Allow a more complex fx_file argument to area_statistics:
I personally think that the cell area/volume data is crucial metadata that should be required by iris when loading the cube. However, we're not in a position to make this change.
I've also noticed that some recipes are using area_statistics, operator:mean without the fx_files: areacello/areacella argument. This may result in weird and unphysical results:
recipe_cox18nature.yml
recipe_ecs.yml
recipe_flato13ipcc.yml
recipe_ocean_bgc.yml
recipe_ocean_example.yml
recipe_ocean_Landschuetzer2016.yml
recipe_tcr.yml
recipe_wenzel16jclim.yml
All of these recipes are likely producing incorrect results. In the case of the UKESM data, the difference between the global SST average with and without area-weighting the mean is approximately 4 degrees. This is a non-trivial error!
Also note that in the past, area_statistics used the iris tool iris.analysis.cartography.area_weights to create area_weights, when no fx data were provided. I believe that we should not use this function anymore as it is not as accurate as the areacell datasets.
Finally, just to make things worse, these issues may also apply to volcello in volume_statistics and zonal_statistics preprocessors as well.
The text was updated successfully, but these errors were encountered:
The UKESM1's ocean spatial grid does not change (and perhaps other models too). It will always be the same for all MIPs, scenarios, experiments and time ranges. With this in mind, there is only one copy of the grid area data,
areacello
. It can be found with:(As an aside, I don't understand why we need to provide a time range like
start_year: 1850, end_year: 1850
for a time-independent variable!)If we are looking at data that isn't in the
exp: piControl
experiment,_get_correct_fx_file
is not finding it. For instance, the following recipe:produces the error:
@valeriupredoi and I have been discussing this. There are a few suggestions on how to adapt to solve this issue in the short term:
_get_correct_fx_file
smart enough to look in picontrol if theareacella
,areacello
is not found.area_statistics
:I've also noticed that some recipes are using
area_statistics, operator:mean
without thefx_files: areacello/areacella
argument. This may result in weird and unphysical results:All of these recipes are likely producing incorrect results. In the case of the UKESM data, the difference between the global SST average with and without area-weighting the mean is approximately 4 degrees. This is a non-trivial error!
Also note that in the past,
area_statistics
used the iris tooliris.analysis.cartography.area_weights
to create area_weights, when no fx data were provided. I believe that we should not use this function anymore as it is not as accurate as theareacell
datasets.Finally, just to make things worse, these issues may also apply to
volcello
involume_statistics
andzonal_statistics
preprocessors as well.The text was updated successfully, but these errors were encountered: