Following continuous monitoring by the ECMWF Reanalysis team, an issue with snow data in summer 2024 in ERA5T for an area in the Alps was identified as needing correction. Subsequent investigation revealed the cause of the problem, enabling the Reanalysis team to correct the data before the final ERA5 release was made available.
As a result of this, for July 2024, the final ERA5 product differs from ERA5T.
ERA5-Land is not affected.
We will post additional details including guidelines on what to do as soon as possible.
We will also fully document this issue as part of the ERA5 Documentation.
Thank you for your patience.
ECMWF Support
on behalf of the Reanalysis team at ECMWF
3 Likes
Just to clarify: The publication of the July 2024 final ERA5 product is delayed but will be published shortly.
We will post an update in this Forum topic to confirm when final ERA5 product for July 2024 is made available from the Climate Data Store (CDS).
Final ERA5 product for July 2024 is now available to download from the Climate Data Store (CDS).
As mentioned previously, July 2024 final ERA5 differs from ERA5T.
Documentation soon coming!
1 Like
Hi Kevin,
Thanks for that - the document on that link says “On the Climate Data Store (CDS), the initial (ERA5T) fields have been/will be overwritten”
Would you be able to post when that overwriting process is complete?
Thanks,
Mark
Hi Mark,
The most recent 3 months of data are ERA5T (expver=5).
At the start of each month, the oldest month of ERA5T data on the CDS are replaced by the ‘validated’ ERA5 data (expver=1). Normally, for a given date ERA5T and ERA5 data are identical, but because of the snow issue, there will be a difference between (say) the data for July-October 2024, with the ‘validated’ ERA5 data being the corrected data. ERA5 data are published at the start of each month, but it’s best to check the value of ‘expver’ for the timesteps you are using to make sure you have ERA5 (expver=1) rather than ERA5T (expver=5).
Hi Kevin,
Thanks, but not quite my question (or more accurately, the questions from my colleagues who use the data -I’m just a dev)
The linked document says (or implies) you are replacing the faulty ERA5-T with a new version of ERA5-T (" the initial (ERA5T) fields have been/will be overwritten") and the faulty data would no longer be available. I was asking when that process would be complete.
If it is the case you’re replacing the faulty ERA5-T, that would mean the ERA5-T (Aug, Sep, Oct) we gathered over the last few weeks would differ from what’s now available, and we would need to re-fetch those ERA5-T.
My colleagues are a little surprised at the suggestion of you replacing ERA5-T, as it seems outside your normal practice but it’s certainly what’s implied in your link. (Some raised the example of agERA5- where a new data version type was introduced when faulty data was corrected).
Your answer just now suggests that the faulty ERA5-T will only be replaced when it becomes ERA5 on the normal schedule, and we live with the faulty ERA5-T as is for now.
Another question was also raised. If most of the ERA5-T for July, August, September, October was faulty and the error then corrected, at what date did the ‘correct’ ERA5-T start?
Apologies for the confusion, I just need to explain to folks what to expect for the few months and what further work we need to do.
Thanks again,
Mark
Dear Mark,
as a temporary product ERA5T will not be overwritten, it will stay there until it is replaced by the final product a few months later. Usually that final product equals ERA5T, which is now not the case any more. So if you redownload ERA5 data for July-October 2024 one year from now, the values have been changed since you are then downloading the final version rather than the preliminary ERA5T version, currently, and they are different.
Reason to replace ERA5T by an improved version is due to a problem over the Alps. Other areas are not affected. Having said that, due to the nature of our (4D-Var) data assimilation system, changing one observation will lead to changes in analysis products over the entire world. These changes are, however, within the uncertainty estimate of ERA5 itself. For these regions outside the Alps you can see ERA5T and its final version as two equally-likely drawings of a distribution. Does that make sense? Our apologies for the inconvenience. At the end of the day the quality of the final product is what will remain for years to come, so with the ERA5T/final ERA5 infra structure we have an additional mechanism to improve the quality of our products.
2 Likes
Hans,
Our confusion was the linked document comment “the initial (ERA5T) fields have been/will be overwritten”
I think we took that to mean that the ERA5-T was being overwritten now - rather than “has been/will be overwritten by the ERA5 as that is produced monthly.”
Thanks for clarifying,
Mark
1 Like
Final ERA5 product for August 2024 is now available to download from the Climate Data Store (CDS).
As mentioned previously, August 2024 final ERA5 differs from ERA5T.
Dear ERA5 team. I have found abnormal temperatura and evaporation data after September 2022, at least in the Peruvian Amazon basin. I worked with 2022-2023 data at the beginning of this year and they were OK, but I downloaded a longer series now and tried to process until 2024 and I found this problem. Please, check from September 2022 on.
Dear ERA5 team,
The netCDF4 reanalysis data is not opening in grads. sdfopen command is not ingesting data in grads. Please look into it.
Final ERA5 product for September 2024 is now available to download from the Climate Data Store (CDS).
As mentioned previously, September 2024 final ERA5 differs from ERA5T.
1 Like
Hi!
How do I make sure, I am only getting the final ERA5 version in a CDS-API request? Adding expver=1 does not seem to have an effect.
Thanks,
Tobias
1 Like
Hi Tobias,
at the moment you need to look inside the files themselves to see what value of expver’ (netCDF) or ‘experiment version number’ (grib) applies to a particular timestep. Values of ‘1’ for ‘expver’/‘experiment version number’ are the ‘final’ ERA5 data.