Integrate ‘new’ and ‘legacy’ reporting

[khaeru]

There are (as of 2021-07) two ways of doing reporting/and postprocessing for MESSAGEix-GLOBIOM–family models:

1. message_data.reporting, based on message_ix.reporting, ixmp.reporting, and genno—a.k.a. ‘genno-based’ (or ‘new’) reporting, developed through this project.
2. ‘Legacy’ reporting, mainly contained in message_data.tools.post_processing.iamc_report_hackathon.py

(1) was developed to supersede (2) but—for operational reasons—(2) remains in parallel use. This issue is to:

• Discuss how to integrate these (short-/medium- term) and eventually retire (2) (long-term).
• Organize various efforts via other issues/PRs to carry out this work.

Top-level tasks

Edit this list to link to individual issues or PRs.

1. Migrate message_data.reporting to message_ix_models.report. Migrate message_data.reporting #116
2. Add ‘glue’ code. This should/can be implemented in genno-based reporting, however see (4) below. This code should:
   • Run both the new and legacy reporting on a scenario.
   • Combine their results.
3. Expand message_ix_models.report and its dependencies to provide any additional features.
   1. “Upload” —i.e. store time-series data computed by reporting back into the same scenarios (?). This was not identified as one of the requirements of the 2019–2020 reporting project, so was not handled then. Add store_ts reporting computation ixmp#444
4. Adjust the legacy reporting as necessary to integrate with the workflow of (2).
   1. Allow a flexible selection of which quantities to include. iiasa/message_data#239
   2. Aggregation. @OFR-IIASA mentions that certain aggregates are computed in complex ways on higher-resolution/sub-quantities. This has the effect of making the legacy reporting “must-run” when any of these sub-quantities are computed, and stands in the way of implementing them individually in the new reporting.
5. Compare results. The 2019–2020 project did this to some extent, but it needs to be repeated/done differently to satisfy everyone that the results are numerically the same.
6. Identify, deprecate, and remove parts of the legacy reporting that are fully implemented in message_ix_models.
7. Improve documentation, including:
   1. Provide a basic.yaml global.yaml and generic instructions for people working with models (e.g. single-country models) based on the MESSAGEix-GLOBIOM RES, but not containing all the quirks of current global models (e.g. for ENGAGE). Mentioned by @behnam-zakeri.

[khaeru]

Today (2021-07-21) we had a 30-minute meeting with @volker-krey @OFR-IIASA @behnam-zakeri @adrivinca @francescolovat @LauWien to discuss.

[khaeru]

As part of the NAVIGATE project, in message_data, some of this glue code (2) has been worked out for the {B,M,T} model variants. This is not yet documented.

[khaeru]

#134 is a partial/experimental effort to replicate one of the trickier parts of the legacy reporting that prevented us moving away from it in the NAVIGATE project for calculation of CO₂ emissions from transportation. It runs on the snapshot model and solution data.

Similar code could be written to replicate other parts of the legacy reporting output.

[khaeru]

@Jihoon notes that, even though we now have message_ix_models.report.legacy here, users may in some cases want to use this with certain branches of message_data:

• With a project- or variant-specific files:
  • Configuration files.
  • "Tables" from a Python module.
• With changes to the core legacy reporting files.

It would be good to, at least, document a suggested approach for this.