1. 15 Oct, 2021 1 commit
  2. 14 Apr, 2021 1 commit
  3. 07 Dec, 2020 1 commit
    • Erkka Rinne's avatar
      Add set for realized time steps · 21cbd5f6
      Erkka Rinne authored
      Set `t_realized(t)` has the realized time steps in the simulation (excluding the starting point and any extra horizon).
      This is included in file *results.gdx* as symbol `t`.
      
      Closes #81
      21cbd5f6
  4. 11 Nov, 2020 1 commit
  5. 25 Oct, 2020 1 commit
  6. 28 Aug, 2020 1 commit
  7. 03 Oct, 2019 1 commit
  8. 26 Feb, 2019 1 commit
  9. 01 Feb, 2019 1 commit
  10. 22 Jan, 2019 1 commit
  11. 21 Jan, 2019 1 commit
  12. 11 Jan, 2019 1 commit
  13. 05 Dec, 2018 1 commit
  14. 05 Oct, 2018 1 commit
  15. 14 Sep, 2018 1 commit
  16. 24 Jul, 2018 1 commit
    • Niina Helistö's avatar
      Several updates · d90cd515
      Niina Helistö authored
      * taking investment costs into account in cost results calculation
      * adding transfer link investment possibility sets
      * moving run-up and shutdown trajectories into their own 'blocks' to speed up the model
      * commenting out some forecast related sets that are not used anymore
      * updating info file writing
      d90cd515
  17. 26 Mar, 2018 1 commit
    • Niina Helistö's avatar
      Several fixes to make the investment model work: · 6b70441c
      Niina Helistö authored
      Added fixed operation and maintenance costs for investment options
      Adding a new parameter unitOutputCapacityTotal to avoid division by zero
      Added unit investment result parameter
      Removed equation q_fixedGenCap1U
      Added default value calculation for reserves update frequency
      Moved tCounter update outside ms loop in 3c_periodicLoop.gms
      Updated the limits of v_invest_LP and v_invest_MIP (no more maxGenCap, minGenCap)
      Updated investInit_temp.gms
      And some smaller updates
      6b70441c
  18. 16 Mar, 2018 1 commit
  19. 11 Dec, 2017 1 commit
  20. 04 Dec, 2017 1 commit
  21. 01 Dec, 2017 2 commits
  22. 29 Nov, 2017 2 commits
  23. 23 Nov, 2017 1 commit
  24. 16 Nov, 2017 2 commits
  25. 15 Nov, 2017 1 commit
  26. 07 Nov, 2017 1 commit
  27. 23 Oct, 2017 1 commit
  28. 19 Oct, 2017 1 commit
  29. 18 Oct, 2017 1 commit
  30. 22 Sep, 2017 1 commit
  31. 19 Sep, 2017 1 commit
  32. 12 Sep, 2017 1 commit
  33. 23 Aug, 2017 1 commit
  34. 18 Aug, 2017 2 commits
  35. 17 Aug, 2017 2 commits
    • Topi Rasku's avatar
      Minor fixes to thew stored results, as well as only requiring upwards tertiary... · 1ce1a834
      Topi Rasku authored
      Minor fixes to thew stored results, as well as only requiring upwards tertiary reserves to cover for the wind power fluctuations.
      1ce1a834
    • Topi Rasku's avatar
      Variable values are wiped clean after each solve in order to conserve memory.... · 1e094745
      Topi Rasku authored
      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.
      1e094745