compatibility of ERA5 pressure level variable(s) #1136
Comments
fserva
added
bug
|
Could you please post the complete stack trace? Or attach the file run/main_log_debug.txt? |
|
Here it is, thanks. |
|
I tried to reproduce this with hourly zg and it looks like the crash is due to the @jvegasbsc Could you look into this? We would need some way to select the correct variable from the CMOR table, i.e. one that has e.g. Here is an example recipe: datasets:
- {dataset: ERA5, project: native6, tier: 3, type: reanaly, version: 1}
diagnostics:
timeseries:
description: zg
variables:
zg:
mip: E1hr
frequency: 1hrPt
start_year: 1990
end_year: 1990
scripts: null |
|
That looks like a different but related problem. In this case, I realized that this is actually already possible, but it's a bit counter intuitive. The following recipe seems to work for me with ERA5 hourly geopotential height on pressure levels. Could you give it a try @fserva? Make sure to replace the frequency with the frequency that you actually need. datasets:
- {dataset: ERA5, project: native6, tier: 3, type: reanaly, version: 1}
diagnostics:
timeseries:
description: test zg
variables:
zg:
mip: Amon
frequency: 1hrPt
start_year: 1990
end_year: 1990
scripts: null |
|
Thanks @bouweandela, I've tried your recipe and I needed to do a change adding a When using the data I have, I got an error on the time axis Suggestions or other issues I should consider? Thanks |
|
I've tried various |
|
It looks like that happens because we were only aware of hourly and monthly ERA5 data when we wrote the fix file. It sees that the timestep is more than an hour, so it wrongly assumes that it is monthly. How can I download the six hourly data?
Yes, I think so. |
|
Yes, good point. In fact the highest frequency you can get is hourly, but through the CDS API and the web form one can select specific hours. In this case I took 6-hourly to save some space, but of course I can start from the hourly. Maybe not a problem, but I see that above you mentioned |
|
That the pressure levels are different than in the CMOR tables is not a problem, this is almost always the case for non-CMIP data, so long as the coordinate is sufficiently similar it should work. If you are working on some institutional machine (e.g. Jasmin), you might be able to use ERA5 data that is already available instead of downloading it yourself, see also ESMValGroup/ESMValTool#2183. |
|
Thanks Bouwe, sorry for the long time to respond. Now I have access also to the space |
|
Hello @bouweandela from what I can see in |
|
Apparently there is not enough space on the group workspace on Jasmin, but there is ERA5 data available in another directory, see here for some recent discussion on the topic: #1246. |
|
Ok, I see. In the Jasmin disks there are surface variables and some model level variables under I have some hourly data for geopotential on pressure levels and I am planning to use those. |
|
It may also be possible to augment the data available on jasmin by asking the right people there. For that, it will be very useful to consult the ERA5 documentation to specify exactly which data one is interested in. |
|
I made some test with #1136 (comment) The run finished correctly, even if no file was produced (I guess it is normal). There were some warnings related to the fact that units of data downloaded from the CDS are hPa. Maybe they can be changed manually in advance, or there is a better procedure? In the original files I have |
|
Files are produced, but deleted after a successful run. You can set The warning is not about the units, but it tells you that some pressure levels that are mandatory for the zg variable's plev coordinate in the CMOR table are not present, this is only to be expected because this is not CMIP data. |
|
Thanks Bouwe, your tip worked and the file is produced; levels are converted to Pa as for CMOR standard. Update: This worked (note I did not include Note that |
It probably doesn't matter too much what mip you choose, but to signify your intent I think |
|
Yes, I also think so. It's iris complaining about the coordinates (not new likely)... |
|
Ok, yes, I forgot about that. This is the problem from the top post and it can indeed be solved by picking a table that does contain |
|
So the |
Hello all, I would need to process (six) hourly ERA5 data in order to prepare input for the zmnam recipe, which requires daily means geopotential height.
I've tried to process it by using https://github.com/ESMValGroup/ESMValTool/blob/master/esmvaltool/recipes/cmorizers/recipe_era5.yml, however an error is raised when building the cube:
ERROR [15512] Failed to run fix_metadata([<iris 'Cube' of geopotential / (m**2 s**-2) (time: 124; pressure_level: 19; latitude: 721; longitude: 1440)>, <iris 'Cube' of geopotential / (m**2 s**-2) (time: 124; pressure_level: 19; latitude: 721; longitude: 1440)>, [...], <iris 'Cube' of geopotential / (m**2 s**-2) (time: 124; pressure_level: 19; latitude: 721; longitude: 1440)>], {'project': 'native6', 'dataset': 'ERA5', 'short_name': 'zg', 'mip': '6hrPlev', 'frequency': '6hr', 'check_level': <CheckLevels.DEFAULT: 3>}), likely due to iris This seems to be an iris problemiris.exceptions.CoordinateNotFoundError: 'Expected to find exactly 1 coordinate, but found none.'I believe this may be due to the missing
standard_names, see the header of the raw files:Maybe assigning default attributes would be enough? See e.g. https://groups.google.com/g/scitools-iris/c/9IwC2Rr7xm
Please note the discussion started in: ESMValGroup/ESMValTool#1909
If anyone succeeded cmorizing ERA5 pressure level data, any hint would be useful.
FYI @remi-kazeroni @zklaus @bouweandela
The text was updated successfully, but these errors were encountered: