Fixing an isse of the online variables were not being recorded correctly, resulting in infeasibilities between solves.

Merge with "trtopi_develop" after first successful full-year simulation of the Northern European Power System.

Removed the "periodicLoopDispatch.gms" as unnecessary, as the optimization is no longer carried out in two separate stages.

Moved the initialization from "modelsLoop.gms" to "periodicLoop.gms" to get it in the repository. Various tweaks to make the code more readable.

Minor fixes to thew stored results, as well as only requiring upwards tertiary reserves to cover for the wind power fluctuations.

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.

Fixed an issue where the reserve variables common between the forecasts were not bound properly. Also removed an unnecessary index for q_resDemand.

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.

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.

Removed the requirement for both nodes to have reserve requirements in order to permit reserve transfer. Now reserve transfer is permitted as long as either of the nodes has reserve requirements.

This change was made to cope with the North Sea wind farm nodes in the eHighway data, as I don't see a reason to impose rigorous reserve requirements for the wind farm, but it should still be able to provide reserves.

Master didn't solve. Removed ts_reserveDemand (uses only static reserves for now) and removed building model solve statement (would require the definition for the building model which is not currently available in the repository). Solves now.

Clarifying the description of the "selfDischargeLoss" parameter to match the way it functions in the "q_balance" equation.

NOTE! This is a rather unconvetional way to impelement self-discharge, as typically these values are given as percentage of state lost over some time interval. However, the way it had been (accidentally) implemented in the code is actually more robust for possible changes in the length of the timestep.

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.

Fixing an issue with replacing missing time series data using the ct(t). Needs defining in e.g. periodicInit.gms to function properly.