This post describes how to use the Kirsch-Nowak synthetic streamflow generator to generate synthetic streamflow ensembles for water systems analysis. As Jon Lamontagne discussed in his introduction to synthetic streamflow generation, generating synthetic hydrology for water systems models allows us to stress-test alternative management plans under stochastic realizations outside of those observed in the historical record. These realizations may be generated assuming stationary or non-stationary models. In a few recent papers from our group applied to the Red River and Lower Susquehanna River Basins (Giuliani et al., 2017; Quinn et al., 2017; Zatarain Salazar et al., In Revision), we’ve generated stationary streamflow ensembles by combining methods from Kirsch et al. (2013) and Nowak et al. (2010). We use the method of Kirsch et al. (2013) to generate flows on a monthly time step and the method of Nowak et al. (2010) to disaggregate these monthly flows to a daily time step. The code for this streamflow generator, written by Matteo Giuliani, Jon Herman and me, is now available on Github. Here I’ll walk through how to use the MATLAB code in the subdirectory /stationary_generator to generate correlated synthetic hydrology at multiple sites, and in Part II I’ll show how to use the Python code in the subdirectory /validation to statistically validate the synthetic hydrology. As an example, I’ll use the Lower Susquehanna River Basin (LSRB).

A schematic of the LSRB, reproduced from Giuliani et al. (2014) is provided below. The system consists of two reservoirs: Conowingo and Muddy Run. For the system model, we generate synthetic hydrology upstream of the Conowingo Dam at the Marietta gauge (USGS station 01576000), as well as lateral inflows between Marietta and Conowingo, inflows to Muddy Run and evaporation rates over Conowingo and Muddy Run dams. The historical hydrology on which the synthetic hydrologic model is based consists of the historical record at the Marietta gauge from 1932-2001 and simulated flows and evaporation rates at all other sites over the same time frame generated by an OASIS system model. The historical data for the system can be found here.

The first step to use the synthetic generator is to format the historical data into an *n _{D}* ×

*n*

_{S}*matrix, where*

*n*is the number of days of historical data with leap days removed and

_{D}*n*is the number of sites, or hydrologic variables. An example of how to format the Susquehanna data is provided in clean_data.m. Once the data has been reformatted, the synthetic generation can be performed by running script_example.m (with modifications for your application). Note that in the LSRB, the evaporation rates over the two reservoirs are identical, so we remove one of those columns from the historical data (line 37) for the synthetic generation. We also transform the historical evaporation with an exponential transformation (line 42) since the code assumes log-normally distributed hydrologic data, while evaporation in this region is more normally distributed. After the synthetic hydrology is generated, the synthetic evaporation rates are back-transformed with a log-transformation on line 60. While such modifications allow for additional hydrologic data beyond streamflows to be generated, for simplicity I will refer to all synthetic variables as “streamflows” for the remainder of this post. In addition to these modifications, you should also specify the number of realizations,

_{S}*n*, you would like to generate (line 52), the number of years,

_{R}*n*, to simulate in each realization (line 53) and a string with the dimensions

_{Y}*n*×

_{R}*n*for naming the output file.

_{Y}The actual synthetic generation is performed on line 58 of script_example.m which calls combined_generator.m. This function first generates monthly streamflows at all sites on line 10 where it calls monthly_main.m, which in turn calls monthly_gen.m to perform the monthly generation for the user-specified number of realizations. To understand the monthly generation, we denote the set of historical streamflows as and the set of synthetic streamflows as , where and are the number of years in the historical and synthetic records, respectively, and *T* is the number of time steps per year. Here *T*=12 for 12 months. For the synthetic generation, the streamflows in are log-transformed to yield the matrix , where *i* and *j* are the year and month of the historical record, respectively. The streamflows in are then standardized to form the matrix according to equation 1:

1)

where and are the sample mean and sample standard deviation of the *j*-th month’s log-transformed streamflows, respectively. These variables follow a standard normal distribution: .

For each site, we generate standard normal synthetic streamflows that reproduce the statistics of by first creating a matrix of randomly sampled standard normal streamflows from . This is done by formulating a random matrix whose elements are independently sampled integers from . Each element of is then assigned the value , i.e. the elements in each column of are randomly sampled standard normal streamflows from the same column (month) of . In order to preserve the historical cross-site correlation, the same matrix is used to generate for each site.

Because of the random sampling used to populate , an additional step is needed to generate auto-correlated standard normal synthetic streamflows, . Denoting the historical autocorrelation =corr(), where corr() is the historical correlation between standardized streamflows in months *i* and *j* (columns of ), an upper right triangular matrix, , can be found using Cholesky decomposition (chol_corr.m) such that . is then generated as . Finally, for each site, the auto-correlated synthetic standard normal streamflows are converted back to log-space streamflows according to . These are then transformed back to real-space streamflows according to =exp().

While this method reproduces the within-year log-space autocorrelation, it does not preserve year to-year correlation, i.e. concatenating rows of to yield a vector of length will yield discontinuities in the autocorrelation from month 12 of one year to month 1 of the next. To resolve this issue, Kirsch et al. (2013) repeat the method described above with a historical matrix , where each row *i* of contains historical data from month 7 of year *i* to month 6 of year *i*+1, removing the first and last 6 months of streamflows from the historical record. is then generated from in the same way as is generated from , while is generated from in the same way as is generated from . As before, is then calculated as . Concatenating the last 6 columns of (months 1-6) beginning from row 1 and the last 6 columns of (months 7-12) beginning from row 2 yields a set of synthetic standard normal streamflows that preserve correlation between the last month of the year and the first month of the following year. As before, these are then de-standardized and back-transformed to real space.

Once synthetic monthly flows have been generated, combined_generator.m then finds all historical total monthly flows to be used for disaggregation. When calculating all historical total monthly flows a window of +/- 7 days of the month being disaggregated is considered. That is, for January, combined_generator.m finds the total flow volumes in all consecutive 31-day periods within the window from 7 days before Jan 1st to 7 days after Jan 31st. For each month, all of the corresponding historical monthly totals are then passed to KNN_identification.m (line 76) along with the synthetic monthly total generated by monthly_main.m. KNN_identification.m identifies the *k* nearest historical monthly totals to the synthetic monthly total based on Euclidean distance (equation 2):

2)

where is the real-space synthetic monthly flow generated at site *m* and is the real-space historical monthly flow at site *m*. The *k*-nearest neighbors are then sorted from *i*=1 for the closest to *i*=*k* for the furthest, and probabilistically selected for proportionally scaling streamflows in disaggregation. KNN_identification.m uses the Kernel estimator given by Lall and Sharma (1996) to assign the probability of selecting neighbor *n* (equation 3):

3)

Following Lall and Sharma (1996) and Nowak et al. (2010), we use . After a neighbor is selected, the final step in disaggregation is to proportionally scale all of the historical daily streamflows at site *m* from the selected neighbor so that they sum to the synthetically generated monthly total at site *m*. For example, if the first day of the month of the selected historical neighbor represented 5% of that month’s historical flow, the first day of the month of the synthetic series would represent 5% of that month’s synthetically-generated flow. The random neighbor selection is performed by KNN_sampling.m (called on line 80 of combined_generator.m), which also calculates the proportion matrix used to rescale the daily values at each site on line 83 of combined_generator.m. Finally, script_example.m writes the output of the synthetic streamflow generation to files in the subdirectory /validation. Part II shows how to use the Python code in this directory to statistically validate the synthetically generated hydrology, meaning ensure that it preserves the historical monthly and daily statistics, such as the mean, standard deviation, autocorrelation and spatial correlation.

Pingback: Open Source Streamflow Generator Part II: Validation – Water Programming: A Collaborative Research Blog