Forecast System Revisions History
Version 3.0 now includes the ESP forecast using all the historical dataset
Version 3.1 Major bug found on the forecast date, March 19,2004
GSM forecast available on 200403 (march 08,2004) are actually forecing for 200404,05,06,07,08,and 09. hence, we can only start this forecast system at the end of March 2004, when all realtime NLDAS forcing are available to end of March.
Version 4.0 The GSM and NSIPP forecast are now suspended.
The ESP is the default forecast method. A workdir is now used to run the forecast system in one scratch disk. This allows running the system in parallel mode.
Version 4.2 CFS based forecast is added to the system with new forcing generation method.
Version 4.3 VIC version has been updated, the global control file needs to be changed so that we can write the regular output as well as the binary output in GrADS format.
Version 4.4 previous pp_vic is removed, and VIC output is now directly in image mode. (May 18, 2005)
Version 4.5 enable doing CFS and conditional ESP in one run. (May 26, 2005)
Version 4.6 change config CFS_ensemble to EnsembleSize, so it is also used in ESP
Version 4.7 pp_vic is re-added to the, but this is a different program than before. It does the post-processing and plotting.
Version 5.0 include ECMWF hindcast for evaluation. So we can run CFS, ESP and CFS+ECMWF in one script.
Version 5.1 update and correct the search_years.f90, all the 6 months use different years new search_year_withclimindex.f90 is added to the system. a 1-deg mask is needed and created in the beginning of each run. remove search_years, we now use random selection.
Version 5.2 changed the location of routing models
Version 5.3 distributed_routing is rewritten.
Version 6.0 changed the way CFS and ECMWF data were used. spatial smoothing is done. This is based on the results from CFS predictability study. There is no change to this script. The change was reflected in process_cfs.pl and process_cfs_clim.pl. The grads scripts generated by these two perl script are different.
These grads scripts produce ASCII data file in exactly the same format as before, but the values are now
spatially averaged values. For the first month, a 9-point smoothing is done, the second month, a 25 point smoothing
is done... the nine month, a 19x19 point smoothing is done.
A new search_years subroutine is added. There is also changes in merge_withecmwf.f90 that now also calculates the 6 month total precipitation at each grid using the posterior distribution. This field is then compared with all observations to select the most similar years.
Add pp_forcing.f90 to the package, so that we can make plots similar as in pp_vic.
Version 6.1 clean up bugs, some changes in merging_withecmwf.f90 and search_years.f90.
Version 7.0 major change in directories. copied all files to climate disk /home/raid8. A few links are changed, There is no change in methodology.
Version 7.1 Allow skipping ensembles that have been generated by checking the size of the outputfile. This is bacuase climate crashes all the time, and we need to save computer time and do not want to start from the very beginning. also add an input variable FensE, to enable running only part of the entire ensemble set from FensI to FensE. Modifed to use 2-year spinup before the realtime forecast. This allowes rivers to fill up before the forecast of streamflow.
Version 7.2 Add streamflow plots for the three model case.
Version 7.3 plot probabilistic streamflow prediction as maps using General Mapping Tool (GMT) March 6, 2006
Forecast System Bug Report
Several bugs were found in pp_vic.f90 related to leap years and year turnover. These bugs did NOT affect any of the previous results since it was never encoutered in the program. We found the bug because the program crashed due to insufficient number of records during reading or writing for leap years, and we only meet this for forecast starting from Nov and Feb.
A bug related to extractfrom uwmonthly.f90 was found. This causes additional information available at the time of forecast, which shouldn't be available at all. This increases the forecast skill of the hindcast at least for the first month of the forecast. Instead of searching the most similar years using the monthly precipitation before the forecast, the bug causes the forecast system to use the actual forecast during the first month of the forecast to calculate the most similar years. Obviously, the first will always use the most similar years in history.
A bug in the recycle_forcing.f90 was found. The bug resides in the getrec subroutine that calculates the position in the binary observation file given the month and year information. Once the record position is identified, a 6-month time series is read to form the baseline of the forecast during the forecast period. The monthly total precipitation is adjusted to match the monthly total precipitation produced by the merging. The bug is that each eary is considered as 366 days while the leap years are considered as 367 days. As the first record is for 1949-01-01, 1950-01-01 should be the 356th record. But instead of getting 366, the program got 367. The shift is one day per year. So if 1994 is selected as the baseline, the shift is 45 days. Although the monthly total precipitation is still correct in CFS and CFS+ECMWF based forecasts, the rainfall statistics could be wrong. Furthermore, the original temperature and wind fields are used during the forecast period without any correction. Once the shift is large, these two fields could be wrong, too. This bug has been fixed and the hindcasts and forecasts will be rerun.
A bug was found in the program taht creates the quantile map of the 50 year UW forcing. This program is not part of the forecast system, but its output is used by the forecast system. This bug affects the results from search_years.f90 as it uses the quantile map as input to calculate the most similar years. The changes in results are not significant, particularly for equal combining since only the order of a few years are changed WITHIN the top 20 years. In some cases, there are years dropping out of the top 20 while some other years moving up to the top 20. If we need to rerun the forecast, the new data set will be used autmoatically.
Nowcast System Revision History
Version 0.1 This script runs the nowcast system over the entire us (or selected region) on a daily basis.
Version 0.2 Including forcing preparation
Version 0.4 Post-processing scripts are ready, analysis and plotting are now automated.
Version 0.6 Including an recovery estiamte using historical recharge data
Version 0.7 A suite of variables related to water state is included in the nowcast, while the recovery estimate needs to be re-evaluated.