Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assignment of capacity_factor is not properly working for subannual time slices #409

Closed
behnam-zakeri opened this issue Sep 30, 2020 · 7 comments · Fixed by #705
Closed
Assignees
Labels
bug Doesn't work as advertised/unintended effects timeslice
Milestone

Comments

@behnam-zakeri
Copy link
Contributor

behnam-zakeri commented Sep 30, 2020

In message_ix\model\MESSAGE\data_load.gms, there are two equations (see the links below) related to the assignment of capacity_factor:

  1. The first equation assigns capacity_factor = 1 to the missing entries for capacity_factor in any time slice.

    * set the default capacity factor for technologies where no parameter value is provided in the input data

  2. The second equation calculates an average yearly value for capacity_factor:

    * assign the yearly average capacity factor (used in equation OPERATION_CONSTRAINT)

The problem is that, in a scenario with sub-annual time slices, e.g., two seasons of winter and summer; when a technology is active only in sub-annual time slices, it has no capacity_factor defined for time year. As such, Eq. No. 1 above adds a capacity_factor with the value of 1 for year. Then, Eq. No 2 above makes an average yearly capacity factor by considering all time slices, including winter, summer, and year. This results in an average capacity_factor higher than 1, which is not correct.

To tackle this issue, it seems the solution is to reverse the order that these two equations appear in the formulation, i.e.,:

  • first caculating the average yearly capacity_factor, and then,
  • if there is no capacity_factor for year, assiging the value of 1 to that.
@khaeru
Copy link
Member

khaeru commented Apr 26, 2022

@behnam-zakeri could you please help us interpret here:

@khaeru khaeru changed the title Assignment of capacity_factor is not properly working for subannual time slices Assignment of capacity_factor is not properly working for subannual time slices Apr 28, 2022
@behnam-zakeri
Copy link
Contributor Author

behnam-zakeri commented May 4, 2022

@khaeru thanks for picking this. No, this is a separate issue. Indeed, this will remain an issue even after the improvements in #561. So, it should remain open.

@behnam-zakeri
Copy link
Contributor Author

However, now that we have tests for capacity_factor, it should be possible to resolve this and test it. I will give it a try, but perhaps after the release.

@khaeru khaeru modified the milestones: 3.5, 3.6 May 4, 2022
@khaeru
Copy link
Member

khaeru commented May 4, 2022

Thanks! Adjusted the milestone accordingly.

@khaeru khaeru modified the milestones: 3.6, 3.7 Aug 17, 2022
@glatterf42
Copy link
Member

glatterf42 commented Apr 13, 2023

When I tried to understand the problem here, I found the following: basically, the existing test_capacity_factor_time(request) seems to set exactly the conditions that we want: a scenario, where we only have values for capacity_factor in the subannual time slices for winter and summer, but not for year. So, according to the description, I'd expect a value of 1 to be added for year, which would then go on to disturb the calculation of the average yearly value. However, when I introduce

    cf = scen.par("capacity_factor")
    print(cf)

in the test (and look at pytest's output for this test by running with the -rP option), I find

  node_loc technology  year_vtg  year_act    time  value unit
0     node    gas_ppl      2020      2020  summer    0.8    -
1     node    gas_ppl      2020      2020  winter    0.6    -

So I don't see any addition beyond the two specified season. Is this issue obsolete, then, @behnam-zakeri ? Because if no arbitrary value for year is added, the yearly average should also be fine, shouldn't it?

@behnam-zakeri
Copy link
Contributor Author

behnam-zakeri commented Apr 14, 2023

@glatterf42 thanks, for checking this. Indeed, as you noted, there is no problem in the input data of capacity_factor. That is what we can see when calling Scenario.par("capacity_factor"). However, when the input data is passed to GAMS, there will be further modifications in capacity_factor before using that in the mathematical model. You can see the final capacity_factor in the output GDX file. That would look like this:
image
In this case, the results are correct.

@behnam-zakeri
Copy link
Contributor Author

The workaround for resolving this issue is proposed in this commit. But we need to extend test_feature_capacity_factor to test that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Doesn't work as advertised/unintended effects timeslice
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants