Correct GAMS for the assignment of "capacity_factor" at "year"

[behnam-zakeri]

This PR resolves issue #409. The GAMS formulation is corrected not to assign a capacity factor of 1 at "year" if the value is missing in a scenario with sub-annual time slices. The weighted average of capacity factors defined for sub-annual time slices can be used to calculate the capacity factor for "year". This is tested by extending the existing tests in test_capacity_factor_feature, i.e., adding data for parameter "operation_factor", which uses capacity factor at "year".

How to review

The test test_capacity_factor_feature should pass with the GAMS formulation in this PR. However, this test must fail if using GAMS formulation of the main branch of message_ix. So, first, copy this test to your main branch and ensure it fails. Then, switch to this branch and run the tests again and make sure they pass.

PR checklist

• Add or expand tests; coverage checks both ✅
• [Not needed ] Add, expand, or update documentation.
• Update release notes.

[codecov]

Codecov Report

Merging #705 (55abd89) into main (a824be9) will increase coverage by 0.0%.
The diff coverage is 100.0%.

@@          Coverage Diff          @@
##            main    #705   +/-   ##
=====================================
  Coverage   94.4%   94.4%           
=====================================
  Files         43      43           
  Lines       3432    3449   +17     
=====================================
+ Hits        3241    3258   +17     
  Misses       191     191           

Impacted Files	Coverage Δ
message_ix/testing/__init__.py	99.6% <100.0%> (+<0.1%)	⬆️
message_ix/tests/test_feature_capacity_factor.py	100.0% <100.0%> (ø)

[glatterf42]

Can confirm: on my main branch, the new test fails with the following error message: FAILED message_ix/tests/test_feature_capacity_factor.py::test_capacity_factor_average - assert 3.0 == 2.8
At the same time, the test succeeds on the new branch.

While this looks good, I'm also receiving a new RuntimeWarning:

message_ix/tests/test_feature_capacity_factor.py::test_capacity_factor_zero_two
home/glatterf42/message_ix/message_ix/tests/test_feature_capacity_factor.py:27: RuntimeWarning: invalid value encountered in double_scalars
    act.loc[i, "cf-corrected"] = act.loc[i, "lvl"] / float(

I will try to understand where that comes from.

[glatterf42]

Looks good to me, but I'd like to understand this RuntimeWarning before approving.

[glatterf42]

This seems to cause the RuntimeWarning. I'm wondering about i and the hardcoded index 1: is that always correct or does it assume a certain structure of i? If so, can we change to using no assumption?

[glatterf42]

The problem arises in the test_capacity_factor_zero_two, where the solar_pv_ppl has a capacity_factor of 0 in the time slice night. In

if i[1] != "year":
            cf.loc[i, "duration-corrected"] = cf.loc[i, "value"] * duration
            act.loc[i, "cf-corrected"] = act.loc[i, "lvl"] / float(
                cf.loc[i, "duration-corrected"]
            )

this gives us a division by 0 since cf.loc[i, "value"] is 0. So we have to provide some condition/prescription on how to deal with cases like this.

[glatterf42]

I've now added a condition that checks if either duration or cf.loc[i, "value"] are 0. In that case, we now set act.loc[i, "cf-corrected"] to act.loc[i, "lvl"], so we don't change it. This relies on the assumption that in this case, act.loc[i, "lvl"] will also be 0, which is implied (and asserted) by the test in line 19.
All the tests are still passing for me, but there's no RuntimeWarning anymore.

[behnam-zakeri]

Thanks @glatterf42 for reviewing this and suggesting improvements. Indeed, as you noted, zero capacity factors are tested and they can be excluded from the follow-up calculations. The index i in that loop is a tuple with two members, the first one being the technology name and the second time slices. So, the index 1 is always related to time.