Conflicts:
	inc/2b_equations.gms

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.

Possible problem here - when forecast branches were combined (with mft_bind and mt_bind) then online units were forced to equal 0 if the unit did not have online variable in the time period to be bound to.

# Conflicts:
#	Backbone.json

Reimplemented the "boundAll" conditional for the "q_balance" constraint to avoid unnecessary "vq_gen" variables for nodes with fully bound nodes.

Also added diagnostic result vectors "d_cop" and "d_eff" that calculate the realized COP of energy conversion units and the efficiency of fuel units. These are mainly used for testing and debug purposes, as the COP and efficiency time series for norman operation aren't all that interesting.

Now considers the "ts_nodeState" as well as "ts_influx" when finding the maximum length of time series.

Lambdas are now calculated using v_online variable for fuel use section (no load fuel use). If lowest operating point is zero, the user can define the section or the operating point where the first cross between p_unit efficiency curve and approximated efficiency curve takes place. Section takes precedence.

This avoids the issue, where the efficiency stayed constant until the first non-zero 'rb' defined in the efficiency data.

Making it possible for "maxGen" to be negative, which is a special case currently required by cooling equipment.

Cooling equipment are quite irregular when it comes to Backbone's node-unit-structure, as they consume energy in order to get rid of energy elsewhere. In this commit, the desired behavior is achieved by defining both the "maxGen" and "slope" of the cooling units as negative, which results in the input "v_gen" still being drawn as normal, but the output "v_gen" is converted into "negative energy" with the negative "slope".

Another possible approach would have been to define cooling equipment as sort of heat pumps (which they sort of are in reality), defining both the electrican grid and the cooled heat node as input nodes and constraining their input ratios. However, this would have required creating a heat sink node where the heat is transported, and giving that node the "v_spill" variable. All in all, this method was simpler for the time being.

Fixing an issue, where the "v_online" simulation starting boundaries were overwritten by later definitions in "3c_setVariableLimits.gms".

Also some fine tuning to the indexing of the ramp variables, as well as the way "uft_online" is defined.

Created 3 new variables and 2 new equations to permit imposing ramp constraints and costs on units. Also generalized the "resdirection" set as an "up_down" set, also used for ramp related variables.

IMPORTANT! The dummy data in "3a_modelsInit.gms" regarding the reserve requirements needs to be changed in order for these changes to function!

The new "v_genRamp" records the change in the "v_gen" over an interval, as required in the "q_genRamp" equality constraint. The "v_genRamp" variable is generated for units with ramp restrictions, and is used for enforcing those in the model. However, in order to apply larger costs to steeper ramps, another variable called "v_genRampChange" is required, that essentially tracks the changes in the ramp speed of the units according to the "q_genRampChange" equality constraint. Since this variable is used to apply the costs, it requires the "up_down" dimension to keep track of positive and negative changes separately.

In order to make the ramping constraints as general and specific as possible, they can be imposed for each unit output separately. The old ramp related parameters were thus moved from "param_unit" under "param_gnu".

Adding a new model parameter called "intervalInHours", that defines the length of a single time step (index) in hours.

Modifications to include linearized power flow equations. Variable v_state denotes the voltage angle of a node in the electrical grid.

Renamed the 'unitCapacity' parameter as 'outputCapacityTotal', and hopefully made the description a little more helpful as well.

Implemented a new 'param_gnn' called 'transferCapBidirectional', and the associated 'q_bidirectionalTransfer'.

The new parameter allows for defining upper limits for bidirectional transfer, meaning that the sum of the individual (directional) transfers doesn't exceed a set maximum. If provided by data, the new parameter assumes that transfer in both directions is permitted, and fills in any required transfer parameters possibly lacking from data. Data integrity checks are also included to abort model execution and warn user of incompatible parameter values.

Renamed the "q_transferLimit" to "q_resTransfer", and added conditionals to only feature it when necessary.

The old "q_transferLimit" was redundant with "v_transfer.up" without reserve transfer, so added conditionals to make it appear only when necessary. Also renamed it to better capture its intended purpose.

Major rewriting and cleanup of the efficiency approximations (directOff, directOn, lambda), and some of the related sets.

Previously, the efficiency approximations required specific efficiency data, and no more than 2 points of data were used. Now the approximations use all the relevant input data they can find (up to the defined maximum indeces) when determining the parameters, and tests have been implemented in "1e_inputs.gms" to abort Backbone execution and warn the user of incompatible input data with the desired approximations.

However, without minimum load, there are still issues with the "directOn" and "lambda" approximations that could perhaps be solved.

Previously "ts_absolute" and "ts_energyDemand" were kind of redundant, and the name "ts_absolute" wasn't all that intuitive. The two time series are now replaced by a single time series called "ts_influx", that hopefully gets its point accross even slightly better.

Some of the input data might have some requirements that need to be met for the model to work correctly, e.g. the right borders.

The SOS1 based efficiency approximation would require further variables in order to correctly restrain its behavior. This would most likely render it just as computationally demanding as the SOS2 based "lambda" approximation, but less accurate.

Re-implemented the "section" of the "directOn" approximation, and further tweaked the penalty values.

I am still a little worried that the "section" should be a data-based parameter in on itself, and not dependent on the efficiencies and borders.

Fixed an issue where the "vq_resDemand" dummy variables were generated for nodes without reserve requirements. Also tweaked the penalty terms to improve solution viability.

CAUTION! The reserve penalty seems to cause some issues, if it is of the same order of magnitude as the energy penalty. This is probably due to the multiple categories of reserves accumulating penalties faster than the energy balances at the nodes. This could result in the model purposefully violating the energy balance, if reserve requirements would need to be compromised, which is not intended behavior.

Fixing an issue where the objective function would generate online variables for the last timestep even though the online approximation is not in use. Also resetting the penalty term.

Realized that the "q_onlineGeneration" was redundant with "q_maxDownward" and "q_maxUpwards" and removing it. Minor tweaks to "q_maxDownward" and "q_maxUpwards".

Removing unnecessary sets from the equations.