GEOGloWS uses the RAPID software to perform river routing and custom scripts which perform other tasks such as the geospatial computations to map gridded runoff to vector basins. More information about RAPID can be found here. The code for running model simulations is open source and available at https://github.com/geoglows. The following files are necessary for running GEOGloWS simulations. They were derived from the TDX-Hydro data using open source Python scripts, found here. Each files is described below. The names of these files is important for compatibility with the RAPID software and the other model scripts. All files except the weight tables are CSV files with 1 row per stream. The order of those rows/streams must be identical in all files and the order of the rows is set with a topological sort.
This CSV has four columns and as many rows as there are unique streams in the VPU. The first column contains the TDXHydroLinkNo of each stream. The second column contains the latitude of the centroid of the stream, the third the longitude of the centroid of the stream, and the fourth is the elevation. All elevation values are set to zero and are only included for compatibility with other software.
k and x CSVs
These four CSVs are very similar. K and X are the values used in Muskingum Routing. These files are formatted for use in the RAPID software. Kfac and Xfac which are the initial guess for these parameters when performing parameter estimation with RAPID. The values in kfac and xfac are identical to k and x.
This CSV does not have a header row. It has as many rows as there are streams in a VPU. The first column is the TDXHydroLinkNo of a stream. The second column contains the DSLINKNO, or the downstream TDXHydroLinkNo. The following columns contain the TDXHydroLinkNo for each upstream stream of the stream identified in column one. There are at least 2 of these columns indicating the confluence of 2 rivers. Given the resolution the TDXHydro data, there are some places where 3 or more rivers join and the number of additional columns is equal to the maximum number of rivers that join together. Zero (0) is a fill value. The number zero means that there are no more upstream streams. In the image, each stream has no upstream segments indicating they are all headwater stream segments.
This CSV does not have a header row. It has a row for every river in the vpu. There is only one column which contains the TDXHydroLinkNo of a stream. The order of the IDs in this file is the same as the order they appear in all other csvs. The IDs are topologically sorted so rivers higher on this list are headwater streams and rivers lower on the list are outlet streams.
This CSV's name should start with weight, followed by zero or more characters, then an underscore, then a number, than an x, than a number. For example, weight_example_123x456.csv is valid, but weight_x456.csv is not. This csv is generated using runoff data and the VPU catchment areas. The first number in the weight table name represents the number on latitude breaks were used in the creation of the weight table, corresponding to the number of latitude cells in the inflow netCDF dataset. The second number in the weight table name represents the number of longitude breaks.
This CSV has a header, with the following titles: streamID, area_sqm, lon_index, lat_index, npoints, lon, lat. This is the order that RAPID expects them to appear. The first column, streamID, contains the TDXHydroLinkNo ids for rivers in the VPU. The second column, area_sqm, contains the area of the catchment of that associated river that intersects with a grid cell of runoff data. The third and fourth columns, lon_index and lat_index respectively, contain the index of the of longitude and latitude of the grid cell in the runoff data. The sixth and seventh columns, lon and lat respectively, contain the longitude and latitude of the centroid of the grid cell in the runoff data. The fifth column, npoints, contains the number of grid cells in the runoff data that a given catchment intersects.
The order and number of streams in this CSV do not match the other CSVs. Generally, they are sorted from smallest to largest numerically, and each river segment in the VPU appears at least once.