1. 07 Jun, 2018 1 commit
  2. 11 May, 2018 1 commit
  3. 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
  4. 28 Feb, 2018 1 commit
  5. 01 Dec, 2017 1 commit
  6. 29 Nov, 2017 1 commit
  7. 21 Nov, 2017 1 commit
  8. 16 Nov, 2017 1 commit
  9. 14 Nov, 2017 3 commits
  10. 13 Nov, 2017 1 commit
  11. 07 Nov, 2017 1 commit
  12. 23 Oct, 2017 1 commit
  13. 20 Oct, 2017 1 commit
  14. 18 Oct, 2017 1 commit
  15. 17 Oct, 2017 1 commit
  16. 12 Oct, 2017 1 commit
    • Topi Rasku's avatar
      Rewrote 4a_outputVariant to match the new forecast-time structure. Model... · 41cf5695
      Topi Rasku authored
      Rewrote 4a_outputVariant to match the new forecast-time structure. Model should be able to run now, but the structure still has to be excessively debugged in order to make the outputs make sense.
      
      Also moved ft_nReserves definition inside the interval loop in order to possibly save an insignificant amount of execution time.
      41cf5695
  17. 22 Sep, 2017 1 commit
  18. 19 Sep, 2017 1 commit
  19. 13 Sep, 2017 1 commit
  20. 12 Sep, 2017 1 commit
  21. 08 Sep, 2017 1 commit
  22. 23 Aug, 2017 1 commit
  23. 18 Aug, 2017 2 commits
  24. 17 Aug, 2017 1 commit
    • 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
  25. 14 Aug, 2017 1 commit
  26. 04 Aug, 2017 1 commit
  27. 26 Jun, 2017 1 commit
  28. 25 Jun, 2017 1 commit
  29. 11 May, 2017 1 commit
  30. 24 Mar, 2017 1 commit
  31. 09 Mar, 2017 1 commit
    • Topi Rasku's avatar
      Added the final state and transfer variables to the results, as well as a... · 35d02677
      Topi Rasku authored
      Added the final state and transfer variables to the results, as well as a cautionary reminder regarding the way the length of the time series form data is determined in the model. This issue will need to be addressed at some point.
      
      The length of the time series data is currently determined as the maximum length of any provided "ts_energyDemand" input. However, this time series is not required for all modelling purposes, as it can be substituted by the "ts_absolute" in most (if not all) cases. If "ts_energyDemand" is not included in the input, the set "ct(t)" will not function properly, causing (at the very least) the looping of the timeseries data to fail. Then again, I'm fairly certain the loop also fails if the time series don't have compatible lengths, e.g. some time series input is shorter than the maximum length of "ts_energyDemand".
      35d02677
  32. 04 Oct, 2016 2 commits
  33. 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
  34. 31 Aug, 2016 1 commit
  35. 30 Aug, 2016 1 commit
  36. 29 Aug, 2016 1 commit