- 12 Sep, 2017 1 commit
-
-
Topi Rasku authored
-
- 11 Sep, 2017 1 commit
-
-
Topi Rasku authored
-
- 08 Sep, 2017 1 commit
-
-
Topi Rasku authored
-
- 07 Sep, 2017 2 commits
-
-
Topi Rasku authored
-
Topi Rasku authored
Minor correction to the online variable .up bounds, now imposed for the last realized state as well for safety.
-
- 06 Sep, 2017 2 commits
-
-
Topi Rasku authored
Fixing the "v_spill" variable limits still being calculated as if the variable was in energy instead of power.
-
Topi Rasku authored
Added a new displacement set "cf_Central" that binds the v_state variables of the shorter forecasts to the central forecast at the end of the forecast length to avoid issues with hydro reservoirs being overutilized in the shorter forecasts.
-
- 31 Aug, 2017 2 commits
-
-
Topi Rasku authored
Fixed the variable limits properly, as the issue was with the $onOrder $offOrder commands when determining interval averaging while data is being circulated.
-
Topi Rasku authored
Fixed an issue where the variable boundaries would not work correctly for long horizons where data needs to be circularly displaced.
-
- 17 Aug, 2017 1 commit
-
-
Topi Rasku authored
Variable values are wiped clean after each solve in order to conserve memory. References to previous variable values are now handled through the results parameters, e.g. "r_state". Additionally, initializing of the various sets, parameters etc. is now handled through the "Option clear" command, as I suspect it to be faster than the old method of resetting the values over the defined sets. Before these changes, GAMS would occupy more and more memory the longer the model was set to run. This resulted in significant reduction of performance during simulations spanning e.g. a whole year with a large system, as every single variable value for each forecast time-step would be kept in memory, regardless of whether it was necessary for the current solve. In order to avoid this, temporary timeseries and variable values are now wiped clean between solves, and the desired results are committed to the results parameter arrays. The results arrays will also bloat the memory requirements of each solve, but not as much as the unaltered variable values (and bounds). I imagine it would be possible to write these into some external file during the solve loop for safekeeping, and periodically wipe the results arrays as well in order to conserve memory for the calculations proper. However, this writing could slow the loop by itself, and might not be necessary for the current project work. It seems that the equation values are still left in the debug file, and are presumably still carried along with the solves. Have to see if further changes are required to avoid unnecessary memory use.
-
- 16 Aug, 2017 1 commit
-
-
Topi Rasku authored
Fixed an issue where the reserve variables common between the forecasts were not bound properly. Also removed an unnecessary index for q_resDemand.
-
- 14 Aug, 2017 1 commit
-
-
Topi Rasku authored
The reserve variables for the to-be-committed period are now "realized", meaning that the fRealization forecast is used for all the different forecasts. The commitments are locked using the solution previous to the update. Reimplemented the requirement for the reserve transfer to have reserve requirements for both nodes.
-
- 11 Aug, 2017 3 commits
-
-
Topi Rasku authored
Sort of implementing the locking of reserves from the "update_frequency" for "gate_closure" horizon. Currently, the locking is only done to the forecasts, and the to-be-realized ft-steps are unlocked.
-
Topi Rasku authored
-
Topi Rasku authored
-
- 09 Aug, 2017 1 commit
-
-
Topi Rasku authored
-
- 04 Aug, 2017 1 commit
-
-
Erkka Rinne authored
-
- 31 Jul, 2017 1 commit
-
-
Topi Rasku authored
Various changes required for running both the building model, the dispatch model, and the combined model. IMPORTANT! The modelsInit.gms is key, when defining multiple models. Because some of the parameters in the model definition file don't have the "mType" dimension, multiple model declarations result in overwriting previous model settings by the newer ones. For this reason, it becomes necessary to define the models in a certain order to avoid errors. This issue will probably need to be fixed at some point.
-
- 21 Jul, 2017 1 commit
-
-
Topi Rasku authored
-
- 22 Jun, 2017 1 commit
-
-
Juha Kiviluoma authored
-
- 19 Jun, 2017 2 commits
-
-
Juha Kiviluoma authored
A version with commitment of units into reserves plus release of tertiary reserves in the operating hour.
-
Juha Kiviluoma authored
A version with commitment of units into reserves plus release of tertiary reserves in the operating hour.
-
- 16 Jun, 2017 1 commit
-
-
Juha Kiviluoma authored
-