1. 04 Aug, 2017 1 commit
  2. 31 Jul, 2017 1 commit
    • Topi Rasku's avatar
      Various changes required for running both the building model, the dispatch... · 1daa625b
      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.
      1daa625b
  3. 19 Jul, 2017 1 commit
  4. 25 Jun, 2017 1 commit
  5. 22 Jun, 2017 1 commit
  6. 19 Jun, 2017 2 commits
  7. 26 Apr, 2017 1 commit
  8. 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
  9. 31 Mar, 2017 1 commit
  10. 30 Mar, 2017 2 commits
    • Topi Rasku's avatar
      Renamed the 'unitCapacity' parameter as 'outputCapacityTotal', and hopefully... · e55fedb1
      Topi Rasku authored
      Renamed the 'unitCapacity' parameter as 'outputCapacityTotal', and hopefully made the description a little more helpful as well.
      e55fedb1
    • Topi Rasku's avatar
      Implemented a new 'param_gnn' called 'transferCapBidirectional', and the... · da0ced85
      Topi Rasku authored
      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.
      da0ced85
  11. 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
  12. 24 Mar, 2017 1 commit
  13. 23 Mar, 2017 2 commits
  14. 22 Mar, 2017 1 commit
  15. 16 Mar, 2017 2 commits
  16. 14 Mar, 2017 1 commit
    • Topi Rasku's avatar
      Minor cleanup. · e5f32adb
      Topi Rasku authored
      Renamed the "param_nu" to "param_unit" as it is currently used in "p_unit", which is not dependent on the node. Also commented out some unused/redundant assets in the "1a_definitions.gms", and made appropriate changes to "1e_inputs.gms" (since "p_gnu" efficiency and conversion related parameters don't affect anything anymore).
      e5f32adb
  17. 22 Feb, 2017 1 commit
  18. 06 Feb, 2017 1 commit
    • Topi Rasku's avatar
      Intermediate commit for implementing time series form unit parameters. HAS NOT... · 2b52ab69
      Topi Rasku authored
      Intermediate commit for implementing time series form unit parameters. HAS NOT BEEN TESTED WITH ACTUAL TIME SERIES DATA  AS OF YET!
      
      First steps for implementing the possibility of time series form input data for units, required for e.g. heat pumps. The idea is to use a flag "useTimeseries" in p_unit to easily disable the use of time series when necessary. However, the flag is not parameter dependent, meaning that if the flag is set all available time series data for each unit will be used. The code should use time series data only when able, and supplement missing values with constant parameter data, which should make it possible (if not advised) to feed incomplete time series as input.
      2b52ab69
  19. 14 Dec, 2016 1 commit
  20. 13 Dec, 2016 1 commit
  21. 05 Dec, 2016 1 commit
  22. 30 Nov, 2016 1 commit
  23. 29 Nov, 2016 1 commit
  24. 17 Nov, 2016 1 commit
  25. 11 Oct, 2016 1 commit
  26. 04 Oct, 2016 2 commits
  27. 27 Sep, 2016 1 commit
    • Juha Kiviluoma's avatar
      Big changes. · 0913d330
      Juha Kiviluoma authored
      1) Units and nodes can be aggregated in later time steps
      2) Piecewise linear implementations (SOS1 and SOS2) for part-load conversion efficiency
      3) Piecewise linear implementation can change in later time periods
      0913d330
  28. 02 Sep, 2016 1 commit
  29. 31 Aug, 2016 1 commit
  30. 30 Aug, 2016 2 commits
  31. 29 Aug, 2016 1 commit
  32. 23 Aug, 2016 1 commit
    • Topi Rasku's avatar
      Added a "v_stateSlack" slack variable, which allows for penalizing deviations... · fafa7114
      Topi Rasku authored
      Added a "v_stateSlack" slack variable, which allows for penalizing deviations in state variables in the objective function.
      
      This also required changing the way "v_state" variables were bounded, and they now require separate constraints called "q_minState" and "q_maxState". A new set called "gnBoundState" was also added to simplify the process of generating the new constraints only when necessary. NOTE! The possibility of "ts_nodeState" to impose bounds only on select timesteps still causes BackBone to create "v_stateSlack" variables for all "ft(f, t)". The way the "v_stateSlack" is implemented in the objective function is also only a simple penalty, which will probably require some customizing later.
      fafa7114
  33. 30 Jun, 2016 1 commit
    • Topi Rasku's avatar
      "gnData" parameter "fixState" now acts as a sort of flag that tells which... · 1852aa50
      Topi Rasku authored
      "gnData" parameter "fixState" now acts as a sort of flag that tells which states are necessary to account for in the energy dynamics and with dummy variables. (Avoid formulating unnecessary equations and variables)
      
      NOTE! gnData "fixState" must be input in order to avoid calculating "q_balance" for the node! Even in the case of ts_nodeState "fixState" covering the whole timespan (and thus overwriting dnData "fixState" imposed boundaries) the "q_balance" and "vq_gen" variables are formulated unless a value for dnData "fixState" is provided. This permits fixing node states according to time-series data, and calculating the necessary control resulting in the fixed node state imposed energy dynamics.
      1852aa50
  34. 29 Jun, 2016 1 commit