1. 12 Sep, 2017 1 commit
  2. 11 Sep, 2017 3 commits
  3. 08 Sep, 2017 4 commits
  4. 07 Sep, 2017 2 commits
  5. 06 Sep, 2017 5 commits
  6. 05 Sep, 2017 3 commits
    • Topi Rasku's avatar
      Minor cosmetic changes to the code. · d09f6ac3
      Topi Rasku authored
      d09f6ac3
    • Topi Rasku's avatar
      Reimplemented the value of online units, but now using a set "uft_online_last"... · 89b4cf98
      Topi Rasku authored
      Reimplemented the value of online units, but now using a set "uft_online_last" instead of the previous "p_uft_online_last" parameter.
      89b4cf98
    • Topi Rasku's avatar
      Fixing an issue where the "v_reserve" variable for input units was being... · 20c88c64
      Topi Rasku authored
      Fixing an issue where the "v_reserve" variable for input units was being counted twice in the "q_resDemand" equation. Also limited the averaging of the "ts_reserveDemand_" time series to "t_reserveLength", as it is unnecessary to average the time series over the reserve horizon.
      
      I'm unsure why the input units were handled separately in the "q_resDemand" equation, but it seems to me that this is a relic from versions past. No (node, unit) should be able to influence the properties of other nodes directly, as these types of interactions are handled either by the "v_transfer" or conversion units, which have separate (grid, node, unit) entities on each of the nodes concerned. These are included in the (node, unit, f, t) of their respective nodes, so there should be no need to include other reserve variables to the nodes.
      20c88c64
  7. 04 Sep, 2017 2 commits
  8. 01 Sep, 2017 1 commit
  9. 31 Aug, 2017 2 commits
  10. 28 Aug, 2017 1 commit
    • Topi Rasku's avatar
      Removed "p_uft_online_last" from use, as it is not currently working properly... · ce40bea6
      Topi Rasku authored
      Removed "p_uft_online_last" from use, as it is not currently working properly and possibly confuses the objective function.
      
      At the moment, online variables are generated only for the time steps when they actually affect the v_gen variables. Thus, having this sort of incentive term to keep the units online at the end of the simulation is perhaps not necessary. The horizon extends over the t_end anyways, and the units keep on working as if they still had to keep on keeping on.
      ce40bea6
  11. 24 Aug, 2017 1 commit
  12. 23 Aug, 2017 3 commits
  13. 18 Aug, 2017 9 commits
  14. 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
  15. 16 Aug, 2017 1 commit