1. 12 Sep, 2017 1 commit
  2. 11 Sep, 2017 1 commit
  3. 08 Sep, 2017 1 commit
  4. 07 Sep, 2017 2 commits
  5. 06 Sep, 2017 2 commits
  6. 31 Aug, 2017 2 commits
  7. 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
  8. 16 Aug, 2017 1 commit
  9. 14 Aug, 2017 1 commit
    • Topi Rasku's avatar
      The reserve variables for the to-be-committed period are now "realized",... · 8a79d29a
      Topi Rasku authored
      The reserve variables for the to-be-committed period are now "realized", meaning that the fRealization forecast is used for all the different forecasts. The commitments are locked using the solution previous to the update. Reimplemented the requirement for the reserve transfer to have reserve requirements for both nodes.
      8a79d29a
  10. 11 Aug, 2017 3 commits
  11. 09 Aug, 2017 1 commit
  12. 04 Aug, 2017 1 commit
  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. 21 Jul, 2017 1 commit
  15. 22 Jun, 2017 1 commit
  16. 19 Jun, 2017 2 commits
  17. 16 Jun, 2017 1 commit