Provide option to average similar clustered periods during time domain reduction

[wrgunther]

GenX runtimes typically limit the number of representative days in a simulation to ~50 per year. The current time domain reduction (TDR) methodology does a good job of picking and weighting a subset of the full 8760 input but given the limited number of representative days the TDR weighted periods can have non-trivially different annual averages vs the full 8760 h input. Consistency in some of the offsets makes me worry about the economic selection between renewable types and between zones. I was intrigued by NYISO’s simple approach in their System and Resource Outlook of averaging clustered periods together to generate (synthetic) representative period shapes. Putting aside the potential volatility dampening effects of averaging, at least the annual average capacity factors would be correct. I may test this manually by modifying the input 8760 but figured it would be straightforward to add an option and have the TDR code average clustered periods rather than select one. Perhaps the code could also stretch/shift the average representative period shape to match the cluster average and peak.

[JesseJenkins]

I dont think we will be implementing the NYISO averaging approach in native GenX. Every time domain reduction approach has limitations, and the NYISO averaging approach is not likely to be any more accurate than the statistical clustering approach we use. The challenge is to select sufficient number of representative periods.

Can you tell me what kind of computing resources you are running on, what your solver and solver settings are, and if you are trying to run (a) single stage expansion; (b) multi-stage myopic, or (3) multi-stage with foresight? We may be able to advise on how to improve setup.

If you want to use NYSIO practice in order to align with their approach, you can implement this manually by adjusting the input data and choosing not to use the native time-domain reduction within GenX.

[wrgunther]

Sure, no problem about not implementing the approach – I will try it by manually editing the TDR input files. In terms of your other question, our current GenX setup is:

Computing resource Current: Desktop with 24 GB of memory and 6 cores running only GenX Potential: Server with 40 GB of memory and 20 cores that also runs GE MAPS/MARS

Solver and solver settings HIGHs solver using “choose” method without crossover and with 1E-5 optimality tolerance I have also tried specifying the ipm method and use the most recent Julia/package version every time I update GenX.

Problem setup Multistage myopic with 5 periods, w/o LDS and w/o integer commitment 123 resources and 14 zones Runtime using prior GenX version on desktop: 12x96 h TDR = 2 days, 12x168 h TDR = 13 days A 2–3 day run-time is fine but 13 days is a bit long, especially if the run may need to be restarted.

[JesseJenkins]

Thanks for that info. And just to clarify, the 2-13 day runtime is to complete all 5 stages of the multistage expansion, correct? (So each individual stage is taking ~1/5th that time).

I think the real issue here is just that HiGHS is not yet up to the task of running large-scale cases in a reasonable runtime. Have you explored Gurobi licensing options? It would provide a roughly 10x speed-up in performance.