New reserve margin

[HauHe]

The changes to OSeMOSYS proposed here change the way how the ReserveMargin is determined.
It introduces the new parameter AnnualPeakHour dependent on r in REGION, y in YEAR, which takes the electricity demand of the hour with the highest electricity demand of the year.
Using this parameter the calculation of the ReserveMargin has been adopted.
The aim of this changes is to have a ReserveMargin that is closer to the ones observed in real power systems. The current formulation of the ReserveMargin relates the ReserveMargin to the time slice with the highest demand. However, time slices do not necessarily represent one hour. Therefore, the ReserveMargin is potentially not accurate.
This PR addresses #48

[vignesh1987]

Hi Hauke,

The following suggestions are (just) to stimulate a discussion around this parameter addition.

1. Probably we can have a different name, which clearly says that this new parameter is the annual-hourly-peak-demand that is expressed in power units (watts etc). The reason I am saying this is because to a normal OSeMOSYS user, demand means specified or accumulated annual demand that is an energy unit.
2. This will also eliminate the association of the fuel/commodity to the reserve margin (reservemargintagfuel). Probably it is not necessary, but it is good to think out loud here. If you have one country model, not associating with fuel will be fine. But, in future, provisions for multiple reserve margins may need an association to fuel/commodity.
3. It may be useful to have a simple implementation of this equation on SIMPLICITY dataset and make it available under the Tests folder for the reviewers to get a better idea.

[HauHe]

Hi Vignesh,

thanks for your comments and considerations!

1. I agree, finding a name for the parameter that is clear would be good. Initially I (or actually Constantinos) had called it YearlyPeak. Perhaps better?
2. You are right these changes eliminate the ReserveMarginTagFuel. It is still in the code I committed, since I didn't think about it that it is not needed anymore. Good to think out loud! And I see the potential issue that arises with multi-country models, if one models like we currently do. One way to avoid that problem would be to use set REGION. I'm not sure if with the latest changes using regions is still increasing the calculation time. I actually thought of running a test to see the difference.
3. Sure an example could be useful. Simplicity is not using the ReserveMargin. But Utopia is. I can give it a go.

[HauHe]

I have now implemented the new RM in the UTOPIA test model.
The AnnualPeakHour was calculated using the electricity demand for lightning and heating the UTOPIA model. The TimeSlice with the maximum per hour demand was identified and the max per hour demand used as the AnnualPeakHour.

[HauHe]

Perhaps you could have a look @vignesh1987 ?

[willu47]

@vignesh1987 - would you be able to review this pull request?

[willu47]

• Please check that the documentation is updated and the parameter definition so it is not specified as a binary parameter

[HauHe]

@NMoksnes and I have been going through this PR.
We have changed the name of the parameter that represents the peak hour of the year to YearlyPeakHour.

NB:This PR should just be merged if #85 is addressed. If #85 is not addressed the proposed change here would need to be adjusted to be able to consider ReserveMargins in different regions.

[willu47]

NB:This PR should just be merged if #85 is addressed. If #85 is not addressed the proposed change here would need to be adjusted to be able to consider ReserveMargins in different regions.

I don't think #85 is going to be resolved soon. Can you develop the same functionality without relying on region functionality, otherwise this PR will just sit here gathering dust!

[HauHe]

I will think about how to do it. And try to implement it next week.

[TomAlfstad]

Just a quick note that by using the user defined constraints functionality you can set up reserve margin constraints a bit more flexibly than with a fixed model implementation.