You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the ScenarioMIP/SSP project, @OFR-IIASA and @macflo8 reported the following issue using:
Scenario.clone(…, shift_first_model_year=…).
message_ix.report output.
message_data.tools.post_processing (~message_ix_models.report.legacy) with the merge_ts/merge_hist options.
In essence what happens:
After (1), for the set of “newly historical” periods—that is, those that were originally within the model horizon but become historical periods due to the shift—the Scenario is left with (a) zeros in ACT, (b) non-zero values in historical_activity, and (c) non-zero values in output. For example, if y₀=2020 initially but shift_first_model_year=2030 is given, then the affected periods might be 2020 and 2025.
In (2), the calculation of out:* = ACT:* × output:* thus yields zeros for those periods.
In (3), those zeros overwrite existing/historical values for those periods.
Users will almost never want to be using this quantity with usable values for the new y₀ and later combined with zeros for the newly-historical periods.
Instead, the expected behaviour is that the user can make a deliberate and informed choice to use either of the following:
out:* = ACT:* × output:*, but only for the periods y₀ and later. This would omit the zeros produced for the newly-historical periods.
out:*:hist = (ACT:* + historical_activity:*) × output:*. This would add the historical_activity values for those newly-historical periods to the ACT zeros, leading to a non-zero values in the result. This mirrors the way the variable ACT and parameter historical_activity are used in the GAMS code.
The tag :hist is tentative, perhaps there is a more intuitive and informative way to make the distinction.
The text was updated successfully, but these errors were encountered:
During the ScenarioMIP/SSP project, @OFR-IIASA and @macflo8 reported the following issue using:
Scenario.clone(…, shift_first_model_year=…)
.message_ix.report
output.message_data.tools.post_processing
(~message_ix_models.report.legacy
) with themerge_ts
/merge_hist
options.In essence what happens:
ACT
, (b) non-zero values inhistorical_activity
, and (c) non-zero values inoutput
. For example, if y₀=2020 initially butshift_first_model_year=2030
is given, then the affected periods might be 2020 and 2025.out:* = ACT:* × output:*
thus yields zeros for those periods.Users will almost never want to be using this quantity with usable values for the new y₀ and later combined with zeros for the newly-historical periods.
Instead, the expected behaviour is that the user can make a deliberate and informed choice to use either of the following:
out:* = ACT:* × output:*
, but only for the periods y₀ and later. This would omit the zeros produced for the newly-historical periods.out:*:hist = (ACT:* + historical_activity:*) × output:*
. This would add thehistorical_activity
values for those newly-historical periods to theACT
zeros, leading to a non-zero values in the result. This mirrors the way the variableACT
and parameterhistorical_activity
are used in the GAMS code.The tag
:hist
is tentative, perhaps there is a more intuitive and informative way to make the distinction.The text was updated successfully, but these errors were encountered: