Operational Constraints Suppress Forecast Value within State-Aware Reservoir Policies in Highly Regulated Water Resources Systems
Bibliographic record
Abstract
Background Outflows from Lake Ontario are regulated at the Moses-Saunders Dam, which is located downstream on the St. Lawrence River near Cornwall, Ontario and Massena, New York. The Moses-Saunders Dam spans the border of the United States and Canada and is jointly managed by the two countries by the International Lake Ontario - St. Lawrence River Board, at the direction of the International Joint Commission. The current flow regulation plan of the LOSLR system is Plan 2014, which is the first control policy in the system to use forecasts to guide release decisions. This Zenodo repository contains a framework to identify alternative reservoir operating policies using a simulation and optimization approach, particularly through the use of global approximators (e.g.., neural networks) as the release function for the system. Repository Overview There are two major components to the workflow in this repository: the simulation and optimization of alternative outflow control policies and the visualization and data analysis on optimized alternatives. This repository contains code to: Perform an offline artificial neural network (ANN) hyperparameter search Optimize control policies Simulate plan prescribed outflows and water levels Assess policy performance for system objectives Explore results in an interactive dashboard Offline ANN Architecture Selection Procedure Before running simulation-optimization experiments, it is necessary to determine the hyperparameters (e.g., number of neurons, hidden layer activation functions, number of hidden layers, et cetera) to configure the ANN policy. There are four key steps required to perform the offline ANN architecture selection procedure: Obtain Training Data Train ANNs Compute Testing Error Select the Best ANN Architecture To obtain the training data, releases associated with optimized, satisficing rule curve policies for the LOSLR system are used. Then, a large suite of ANNs using different architectures are trained, defined by varying number of neurons, activation functions, and number of hidden layers. Then, model performance is evaluated by computing the mean squared error (MSE) for each policy and architecture. The best ANN architecture is selected based on rankings of mean and standard deviation MSE by architecture. To implement the offline ANN architecture procedure, please see the script offline_ANN_approach_HPC_scaling_revised_train_test_split_updated_mpi. We conduct the offline ANN approach on an HPC environment. You can run the shell script runOfflineANN_HPC_batch_mpi.sh to implement the ANN offline hyperparameter search procedure on HPC. Simulation-Optimization There are two scripts that drive the policy simulation and optimization: optimizationWrapper_MWBorg_noisy_opt_combined.py and optimizationSimulation_historic_stochastic_combined.py. The optimizationWrapper_MWBorg_noisy_opt_combined.py script calls and interacts with the Borg MOEA. The wrapper script reads the user-generated configuration file and sets up the optimization experiment. optimizationWrapper_MWBorg_noisy_opt_combined.py then calls optimizationSimulation_historic_stochastic_combined.py to simulate the time series of outflows, water levels, and system performance that result from the decision variables returned by Borg in each function evaluation. To ensure convergence on the Pareto Frontier and avoid falling into local minima/maxima, it is advisable to run multiple seeds per experiment. The runOptimization_Local.sh and runOptimization_HPC_batch_stochastic.sh shell scripts are setup to take in the number of seeds to run per experiment rather than the random seed. Configuration File The optimization requires several hyperparameters, decision variables, and simulation modules. These fields are specified in a user-generated configuration file. Configuration files are written using the toml file format. Optimization Algorithm A many-objective evolutionary algorithm (MOEA) is used to optimize control policies for flow regulation. The optimization algorithm used in this repository is the parallelized Master-Worker Borg MOEA MW-Borg MOEA. Before any runs, you will need to download and compile MW-Borg. A two-part tutorial on setup (with an example) is available here by the Reed Lab at Cornell University. Once you have compiled MW-Borg, you can introduce new simulation and evaluation problems. You will need to move the borg.c, borg.py, and libborgms.so to the directory with your wrapper script. Input Data Input hydrologic files are provided for the historic supply data from 1900 - 2020 (input/historic/1900_2020), as well as for 500 stochastic centuries (input/stochastic/century_xxx). Objective Functions Objective functions are simulated over the user-specified time period. Each objective is aggregated by the net annual average value, and that metric is returned to Borg to drive the optimization.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.013 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.003 | 0.002 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.009 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".