2010.11.25 Bias corrected CNRM data (from Tanya Warnaars/Stefan Hagemann)
Following the discussions that took place in Amsterdam regarding bias correction of CNRM data, Stefan and Claudio have prepared the following explanations:
We (mainly Claudio, Cui, Jens and me) have looked at the bias corrected CNRM data. Our conclusion is that due to large errors in the daily statistics of the CNRM data in some regions, a complete matching of the means with the WATCH forcing data (WFD) is not possibe without destroying the validity of the bias correction method, so that we have to live with the discrepancy of the bias corrected CNRM data. Thus, all bias corrected CNRM data are are valid data. A more thorough explanation given by Claudio is:
While in Amsterdam, I looked at the offset between mean precipitation in WFD and bias-corrected CNRM. I saw peaks in two locations of around 2 mm/day. Though I expected this when different time intervals are used derive the correction and to apply it, I did not expect it in the case when the same interval is used to both derive and apply the Bias correction. Cui independently conducted the Bias Correction of CNRM precipitation for the decade 1960 to 1969 using the WDF for the same decade and found the same discrepancies. Although we have stated that the mean of the corrected simulated data should be exactly the same as the observation, this is not always the case (figure 1). After analyzing two regions where the differences were largest we have come to the conclusion that it is the prior removal of outliers from the precipitation data that causes the mismatch. (In the case over the monsoon region in July the the 2 mm/day difference was very small relative tot he mean precipitation. In the case over Saudi Arabia,the maximum observed precip was of the order of 0.1-0.2 mm/day while the model was reporting 40-60 mm/day). Removal of outliers is done according to a statistical criterion common to all grid points and models. The criterion should not be changed to improve the match between the bias corrected control period and the WFD. Indeed if matching the control period with the WFD is what is needed all one has to do is substitute simulated values with WFD. What is in fact required of the BC methodology is that corrected simulations match, as closely as possible, the WFD where the corrections are obtained using WFD from another period (this is how it would be used for simulated projections of future climate). Including outliers in the analysis increases the error when bias correction is done on different time periods, since these are the most likely to change from one decade to another. Also the BC methodology should not be tailored to each grid point and time segment case, least it lose all generality.
After a discussion with Ingjerd, it can be stated that there are areas of the globe were the difference between WFD and Bias corrected CNRM mean precipitation reaches 10%. We think the bias correction was carried out correctly and these differences can be explained via the outlier removal as explained above. In this respect it would not be methodologically correct to 'tune' the bias correction algorithm to different grids points, months or models.
2010.11.10 Replaced ECHAM5 file pr_PRSN_BCed_1960_1999_1996.nc.gz (from Doug Clark)
There was a problem with another daily ECHAM5 A2 file for WATCH: pr_PRSN_BCed_1960_1999_1996.nc.gz. In part of Nov 1996 and Dec 1996 the grid changed, so some of the land points were suddenly replaced with the missing data value (1e+20)....meaning your model would get a lot of snowfall. Cui Chen has uploaded a revised file to the IIASA ftp site and the new version seems OK (as far as I have seen).
2010.09.21 Replaced MPEH5_20C3M_3_DM_rlds_1964_0.5deg_land.nc (from Doug Clark)
I discovered a problem with another WATCH ECHAM5 daily file, namely MPEH5_20C3M_3_DM_rlds_1964_0.5deg_land.nc (which is for LWdown). There was a problem with the grid in 1964, which would cause the temporal disaggregator code to fail. Jan Haerter has uploaded the file again and the revised version appears to be fine. If you need this file you should download this revised version.
2010.09.15 A corrupted ECHAM5 file (from Fulco Ludwig)
Doug informed me that one of the snowfall files was corrupted. For your information, one of the ECHAM5 A2 daily snowfall files was corrupted on the IIASA server, as noticed by someone at the Met Office. Yesterday afternoon I told Jan Haerter at MPI and the file has now been replaced by a good version. I assume the problem occurred when the file as initially uploaded, so anyone who downloaded it before yesterday evening will have a bad version. It is pretty obvious if one has a bad version - it is small and won't uncompress. The file is A2_pr_PRSN_BCed_1960_1999_2074.nc.gz from directory /watch/WorkBlock3/echam_bc_data_yearly. Please update your files were appropriate
2010.08.09: CNRM-CM3 climate data (from Jens Heinke)
You may have noticed that for each climate variable of CNRM-CM3 there are two versions of year 2000 files available on the website: One in the 20C3M folder and one in each of the scenario folders (SRESA2, SRESB1). According to the CNRM-CM3 simulation protocol the SRES A2 and B1 simulations start from year 1999 of the 20C3M simulation. Hence, year 2000 from 20c3m should be used when conjoining 20c3m and scenario runs. Despite this fact we (Ingjerd, Stefan, Jens) have decided to use year 2000 of the 20C3M simulation which should then be followed by year 2001 of the scenario simulations. This has been done in order to be cosistent with the WaterMIP simulation protocol and the other GCMs where year 2000 is considered as belonging to the control run. The README file has been updated accordingly and all year 2000 files of the scenario runs have been deleted from the ftp site. By the way, for those of you who require LWnet I have uploaded this variable for WFD for the 1901 - 1957 period to the FTP site. The values have been derived in the same way as for the 1958 - 2001 period.
2010.08.09: Bias corrected data, Tmax/Tmin (from Jan Haerter)
For those of you using the daily maximum and minimum temperatures of the bias corrected model data I would like to point out a possible obstacle when feeding the data into hydrological or other impact models: Due to the interpolation routine (that makes smooth transitions between the monthly correction factors) there is a small number of cases where the corrected T_max<T_mean, where T_max is the daily maximum of the corrected data, and T_mean is the daily mean. In these cases, the value of T_max can become slightly less than T_mean (on the order of <1K). This is not noticeable in all practical cases, including those that we tested before releasing the bias correction algorithm or the data. However, if your hydrological model makes the assumption T_max>=T_mean>=T_min, then this could lead to confusion or crashes. If this has occurred, please let me know! To fix any such problems, it is suitable to just include a statement in your code saying if Tmax < Tmean then Tmax = Tmean. If Tmin > Tmean then Tmin = Tmean. For those of you that don't use Tmax or Tmin or whose hydrological models aren't sensitive to this condition, this is not important of course.
2010.07.30: WATCH daily disaggregator (from Graham Weedon)
The WATCH daily disaggregator code has been released. This allows creation of realistic subdaily data from the daily averages of the forcing variables from the 1960-2100 GCM runs. The code is available from the IIASA ftp server from the WFD_code directory within the WATCH_Forcing_Data section.
2010.06.03: WATCH forcing data on ftp site (from WATCH Programme Office)
The WATCH forcing data has been separated out from the rest of the WATCH material on the FTP site at IIASA. This should make it more straightforward for those needing to only download the forcing data. The folder this is located in has its own password (sorry for the extra password, but the aim is to make it clearer).
2010.02.05: FTP server
The ftp server at IIASA is now available, and should be used when uploading files. The forcing files can also be found on the IIASA ftp server. Note that data is stored in separate places, and hence you may need to use several login names and passwords.
2009.07.30: WaterMIP: WATCH forcing data available (from Graham Weedon)
In her absence I have been asked by Ingjerd to let you know that the final variables (Rainf & Snowf) have been updated by Workblock 1 members and are now available for 1980-1999 on the WATCH Workblock1 ftp site. Thank you for your patience while we tackled a variety of important issues.
Please note that the README text file has been corrected and updated: the flux forcing variable values (precipitation and radiation) indicate average flux over the time interval FOLLOWING the timestamp (e.g. for 3-hour Rainf the 06:00:00 values cover 06:00:00 to 08:59:59).
WaterMIP will be concerned with GPCC version of the precipitation data rather than the CRU version. For those running models requiring sub-daily forcing data the "Interpolator" code will be made available shortly and we will contact the relevant groups when this happens.
Good luck with your model runs.