Decreasing the number of representative days in US_9R_8D

[Aaron Belman Martínez]

Hello temoa developers!

I was wondering if it would be possible to decrease the number of representative days from 8 to 4 in the US_9R_8D from the Open Energy Outlook.

The reason why I am interested in doing this is because I am running into computational limitations, and I cannot complete a full simulation of the US_9R_8D in a reasonable amount of time. I used to work with the older US_9R_4D database without trouble before.

Considering that the US_9R_8D is the most updated version of the OEO, is there any chance you have the same updated version but with 4 representative days? And if not, what would be your recommendation to manually decrease the number of representative days?

Kind regards,

Aaron

[Cameron Wade]

Hi Aaron,

I would generally caution against using much fewer representative days than ~8. A lot of research has shown that it is just not possible to capture the variability of and correlations between important time series (e.g., wind, solar PV, load, etc..) using only a few RDs resulting in heavily biased results.

Given that, I would recommend looking for some other levers where you can decrease the size of the model. Some ideas:

1. The number of years being modelled. Do you need to go out to 2050?
   
2. The number of regions. Do you need the entire US? Can you merge some regions you're not all that interested in?
3. The number of hours per day. Consider agglomerating some hours within each day. Try not to average out peak load & peak net-load events.
   
4. Storage technologies. These technologies require inter-temporal constraints that can really add to the computational burden.
5. Transmission technologies. Often times, generation and transmission expansion are done separately. Consider removing the option to build new intra-regional transmission.
   

With all that said, if you are keen on reducing the number of RDs, I can't speak for the OEO/Temoa team but I and most others using RDs have a clustering &\or optimization framework that is used to select the days and their corresponding weights. Perhaps they can tell you more.

Finally, it's possible to peruse through older versions of git repos. You can browse through the commit history, select a specific commit, then click on the "Browse files" option. I've done that for commit bb785fb85ad66381667719825a793cfadd91a9cb made on Nov 3, 2021. Here is the commit and here is the archived oeo repo from that time, which includes a 4 RD database. Again, since I'm affiliated with the OEO, I have no idea whether this particular version is stable or compatible w/ newer releases. At minimum, though, you should be able to take the data you need from it (SegFrac, DSD, capacity factors, etc...)

I hope this helps!

Cam

--
You received this message because you are subscribed to the Google Groups "Temoa Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to temoa-projec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/temoa-project/965b045d-b526-40bc-a370-400852d18ef5n%40googlegroups.com.

--

Cameron Wade

Principal, Sutubra Research

p: 902-292-4478

[Cameron Wade]

Woops, typo: I am not affiliated with the OEO.

And in item 5., I meant inter-regional transmission.

[Aaron Belman Martínez]

Hello Cameron, 

Thanks a lot for your well-described answer, I really appreciate your assistance in this matter. While waiting for feedback, I proceeded with decreasing the number of representative days to 4 days. For this, I followed this methodology:

1. Remove H49 to H96 in the "time_of_day" table

2. Remove H49 to H96 in the "CapacityFactorTech" table

3. Remove H49 to H96 in the "SegFrac" table and redistribute the remaining units in H1 to H48 so they still sum up 1

4. Remove H49 to H96 in the "DemandSpecificDistribution" table and redistribute the remaining units in H1 to H48 so they still sum up 1

It is important to remark that meticulous data handling was taken in steps 3 and 4 to keep the same distribution as in the 8 days database. The total simulation time was 34 hrs and the results were consistent. I attach a figure of the hourly electricity generation by source for the year 2020 for the 4 representative days.

For the SegFrac, DemandSpecificDistribution, and CapacityFactorTech data I did not try to gather the data from the older US_9R_4D database as you recommended because this one works with 4 seasons and one representative day by season. In contrast, the newer version US_9R_8D works with only 2 seasons and 4 representative days in each one. Therefore, reusing the data could bring more implementation challenges. Moreover, as the US_9R_8D is more updated, it can have more technologies than the US_9R_4D, therefore the 4D database could lack plenty of information in CapacityFactorTech data.

Thanks for pointing out the limitation of using fewer representative days and its consequence of having biased results. That is something I am aware of, however, as my research is not especially focused on developing very realistic future scenarios, but rather is about understanding the interlinkages of different parameters and their difference to a base case. I believe that is a limitation I can afford to take. 

Thanks a lot for all the other recommendations for decreasing the size of the model, I might pursue 2nd, 4th or 5th recommendation. As I am mostly interested to model long-term scenarios and having an hourly resolution in the representative days (therefore discarding your 1st and 3rd recommendations). I will let you know if I manage to decrease the computational times!

I have one last question, based on your experience what is the best way to increase the computational performance of solving TEMOA's optimization problems? I am currently using gurobi optimization software and my virtual machine has a very significant computational power (128GB of RAM, 16 virtual processors, and a CPU speed of 2.59 GHz). However, as I mentioned before this last simulation took more than 30 hrs to complete. I am almost certain that there might be a different computational bottleneck different than RAM and CPU, perhaps the memory bandwidth? Your expertise will be very much appreciated!

Thanks again!

Aaron Belman Martínez, B.Eng.
M.A.Sc. Student, University of Toronto
Dept. of Civil & Mineral Engineering
Email: aaron....@mail.utoronto.ca 

[Cameron Wade]

Hi Aaron,

Without going into too much detail, here are three areas where I've found it possible to speed up the model runs. I'll first caveat this with a few things:

• I haven't run any of the OEO databases. This is based off my own work.
  
• Without looking at your machine, I'm not sure where the bottlenecks are. But I'm guessing it's simply a matter of the solver finding the optimal solution.
  

Some ideas:

1. Temoa can spend a lot of time instantiating the model. I've done some work to speed the model build time up by a factor of 5-10x. Here are the two relevant commits (please note: 1- This is on a different repo where there have been significant changes made to the core Temoa code. 2- There are a couple assumptions baked in there (like if a DSD is defined for a single timestep, then we assume it is supplied for all timesteps)).
   
   
2. Change the solver settings. By tuning the solver parameters I've achieved 2-5x speed-ups in solve times. I've borrowed the solver parameters from the PyPSA settings -- essentially, we're using the barrier algorithm with no crossover and are relaxing some tolerances. These are all reasonable changes given that you're not looking for extreme accuracy.
   
   I haven't uploaded these to a remote repo yet, but I've attached a screenshot that should give you the idea (taken from the temoa_run.py file). You'll have to determine the appropriate keywords for gurobi, though.
   
   
   
   It's best practice to include these parameters in the config file to more easily allow users to edit them etc... I'll get around to that at some point.
   
   
3. Look for and remove numerical instabilities. You'll want to inspect the problem matrix and ensure the condition number is of a reasonable magnitude (< 1e10^9 or so). This is a pretty meticulous task... I would suggest trying the first two options and only attack this one if large problems persist. For your reference, I've included an attachment that talks about numerical instabilities in some detail.
   

I hope this helps. Sorry I can't provide more details right now... busy week!

And finally, Aranya, Katie, Joe or other members of the Temoa & OEO teams might have much better ideas...

Cheers,

Cam

To view this discussion on the web visit https://groups.google.com/d/msgid/temoa-project/8dff46f9-6df1-4626-b655-2702a3917ce6n%40googlegroups.com.

[Temoa Project]

Aaron, Cam: this is a great discussion! 

Cam: We'll be looking at your repository to see how we can make some improvements on our end; thanks for sharing. 

Aaron: I don't have much to add to Cam's feedback except to ask if you are solving the model myopically? How long does each time step take? For the 8D versions, we've seen total runtimes (when solved myopically) of 24-36 hours. 

The steps you described to test a 4D version sound appropriate to me. The older 4D version had a lot less detail in some of the sectors, so it likely has faster solution times than the current 4D version you tested. If you are interested in such a reduced-form (4D) version of our current database, reach out to us separately, and we can try to create a new one (we'd have to re-implement the clustering algorithm that gets us from 8760 hours to fewer representative days). But I would generally agree with Cam that reducing the number of days further could lead to biased results, and it makes more sense to look at some other levers to reduce model size. 

Happy to discuss further if helpful.

Best,

Aranya