Minor differences when solving TIMES-NZ cases

[olejandro]

There is a small difference in the objective function value when solving TIMES-NZ Kea using the outputs from the tool compared to the benchmark. I believe I've managed to narrow down the cause to the issues discussed here: https://forum.kanors-emr.org/showthread.php?tid=1254&page=1. More specifically, as mentioned by @Antti-L, when the PCG is a genuine group, the process will no longer contribute to the peak by capacity.

[olejandro]

@Antti-L, are there any other differences between PCG being a commodity vs an actual group with a single member?

[Antti-L]

In terms of functionality, I don't think so, there is nothing else that I can recall. It might additionally just cause a bit confusion to some users that access the model data and results from the full GDX files.

[olejandro]

Ok, super, thanks!

[Antti-L]

There is a small difference in the objective function value when solving TIMES-NZ Kea using the outputs from the tool compared to the benchmark.

Hmm..., but I see GDX diff reporting 3877 differences for Kea (under v0.2.1), unless I am misinterpreting it. I would be surprised if all those differences are about this PCG issue. So, I am curious whether you consider all those differences otherwise cosmetic?

[olejandro]

Surprising, right? The PCG issue alone is responsible for 1000+. Another big one is BOTIME which we currently don't adjust. I am planning to open a PR in the benchmark repository with manual adjustments, so we can reach 100% and lock in the progress. I hope you'd be up for giving your opinion on the adjustments.

[olejandro]

Just verified that the objective function for the other NZ case is reproduced, as well, once the PCG issue is corrected and HYD_DAM_BAN constraint is disabled. Regarding the latter, Veda drops it because UC_Sets on the sheet are disabled. @Antti-L, you mentioned in #291 that TIMES has defaults for it. I guess, it is okay for the tool not to drop the constraint then?

[Antti-L]

HYD_DAM_BAN constraint is disabled

I assume you refer now to the TUI scenario, and not KEA? Sure, if the tool defines the UC_RHSRTS(r,'0') and UC_CAP for all regions even when no UC_Sets: R_E: is defined, then it would be okay. TIMES would set UC_R_EACH by default for all regions having UC_RHSR* defined, and the constraint would thus be correctly defined.

[olejandro]

I assume you refer now to the TUI scenario, and not KEA?

Yes, here is what it looks like.

No, regions are specified for UC_CAP, so currently it is filled in with all internal regions.