Enabled the inclusion of additional constraints from the input data, the replacement of the objective function and the addition of new terms to the objective function. The basic file structure was also changed to better accommodate these.

Changing the way reserves are treated. An additional penalty variable vq_resMissing can now be used to mitigate lack of reserves after gate closure while the former vq_resDemand is used only for the later time periods. This allows to fix reserves for the time periods between gate closure and reserve update-frequency. In this way problems arising from the forecast errors (VG cannot do what promised) can be mitigated by the vq_resMissing and it is then visible separately from the vq_resDemand (and they can have different penalty values). Released tertiary reserves cannot now be used to mitigate primary and secondary reserves - this could be re-implemented as an option if seen beneficial (and of course in a reserve type agnostic manner).

Fixes and clean ups. Most importantly a term in the q_maxUpward was updated to point to the correct start up time period (hopefully).

Model definition files included in the VCS now only include the GAMS definition (list of included equations), all of which are read by Backbone to allow for easier swapping of models without having to tamper with the "3e_solve.gms" fole. Rest of model parameters are expected to be given as input through the renamed "modelsInit.gms" in the input folder (by default). "periodicLoop.gms" and "periodicInit.gms" now treated as integral parts of the Backbone model.

Example input parameters provided by the "scheduleInit_temp.gms", "buildingInit_temp.gms" and "investInit_temp.gms" included in the defModels folder within the VCS.

Added the ".holdfixed" option to the solve commands, which should make the GAMS compiler convert fixed variables into parameters before feeding the problem to the solver.

NOTE! Regarding the last change concerning the inclusion of flow units into the suft sets: Now conversion equations are generated for flow units, which is required for EV batteries. However, without a defined "fuel" or input energy, traditional flow units (wind, solar, RoR) stop generating energy due to the seemingly nonexistant energy source. This problem can be circumvented by defining free "fuels" for flow units, but is a rather unnecessarily convoluted way of handling things.

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.

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.

A version with commitment of units into reserves plus release of tertiary reserves in the operating hour.

A version with commitment of units into reserves plus release of tertiary reserves in the operating hour.