1. 22 Jun, 2017 1 commit
  2. 19 Jun, 2017 3 commits
  3. 16 Jun, 2017 1 commit
  4. 09 Jun, 2017 1 commit
  5. 05 Jun, 2017 1 commit
  6. 02 Jun, 2017 2 commits
  7. 17 May, 2017 1 commit
  8. 16 May, 2017 1 commit
  9. 11 May, 2017 5 commits
  10. 26 Apr, 2017 1 commit
  11. 13 Apr, 2017 1 commit
  12. 10 Apr, 2017 1 commit
    • Topi Rasku's avatar
      Making it possible for "maxGen" to be negative, which is a special case... · 456369bf
      Topi Rasku authored
      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.
      456369bf
  13. 07 Apr, 2017 1 commit
  14. 04 Apr, 2017 1 commit
  15. 03 Apr, 2017 1 commit
    • Topi Rasku's avatar
      Created 3 new variables and 2 new equations to permit imposing ramp... · b01011a3
      Topi Rasku authored
      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".
      b01011a3
  16. 31 Mar, 2017 3 commits
  17. 30 Mar, 2017 3 commits
  18. 29 Mar, 2017 1 commit
    • Topi Rasku's avatar
      Renamed the "q_transferLimit" to "q_resTransfer", and added conditionals to... · d8244ea8
      Topi Rasku authored
      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.
      d8244ea8
  19. 28 Mar, 2017 1 commit
    • Topi Rasku's avatar
      Major rewriting and cleanup of the efficiency approximations (directOff,... · 5c5c68b2
      Topi Rasku authored
      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.
      5c5c68b2
  20. 24 Mar, 2017 1 commit
  21. 23 Mar, 2017 2 commits
  22. 22 Mar, 2017 2 commits
  23. 21 Mar, 2017 3 commits
    • Topi Rasku's avatar
      Re-implemented the "section" of the "directOn" approximation, and further... · 1d127ff2
      Topi Rasku authored
      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.
      1d127ff2
    • Topi Rasku's avatar
      Fixed an issue where the "vq_resDemand" dummy variables were generated for... · f0157fd9
      Topi Rasku authored
      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.
      f0157fd9
    • Topi Rasku's avatar
      Fixing an issue where the objective function would generate online variables... · a5e19c0c
      Topi Rasku authored
      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.
      a5e19c0c
  24. 20 Mar, 2017 2 commits