1. 23 Aug, 2017 1 commit
  2. 21 Aug, 2017 1 commit
  3. 18 Aug, 2017 10 commits
  4. 17 Aug, 2017 4 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
    • Niina Helistö's avatar
      45ca8026
    • Niina Helistö's avatar
      9df3532d
  5. 16 Aug, 2017 1 commit
  6. 14 Aug, 2017 2 commits
  7. 11 Aug, 2017 5 commits
  8. 10 Aug, 2017 1 commit
  9. 09 Aug, 2017 1 commit
  10. 08 Aug, 2017 2 commits
  11. 04 Aug, 2017 6 commits
  12. 03 Aug, 2017 1 commit
    • Topi Rasku's avatar
      Clarifying the description of the "selfDischargeLoss" parameter to match the... · 38ff1613
      Topi Rasku authored
      Clarifying the description of the "selfDischargeLoss" parameter to match the way it functions in the "q_balance" equation.
      
      NOTE! This is a rather unconvetional way to impelement self-discharge, as typically these values are given as percentage of state lost over some time interval. However, the way it had been (accidentally) implemented in the code is actually more robust for possible changes in the length of the timestep.
      38ff1613
  13. 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
  14. 25 Jul, 2017 2 commits
  15. 21 Jul, 2017 1 commit
  16. 19 Jul, 2017 1 commit