Implementing "scopes" feature

[alexdewar]

Overview

Scopes are defined in the model specification. Some information about them is included in the online documentation, but some sections were deliberately omitted for now, though there is more info in the private Overleaf document.

The model specification defines scopes as:

Purpose: This module provides a mechanism to implement aggregate policies, such as emission limits
for a country, renewable energy quotas for a region, or specific consumption quotas for certain fuels, by
defining ”scopes” over which these policies apply. It also handles associated financial instruments like
carbon taxes or production subsidies.

It also says that scopes constitute sets of region and time slice pairs to which particular policies apply.

From the Overleaf document, it seems the following is needed to include scopes in the objective function and add the relevant constraints:

Questions

I think there are two main questions here:

1. What extra functionality needs to be added so that users could use MUSE2 do add constraints to the system along these lines?
2. What should the external interface be for that functionality (i.e. what should the input file format look like)?

There are probably some subtleties that are eluding me, but the general idea is a relatively simple one. The motivation is a bit less clear to me though. Maybe you could give a simple, real-world example @ahawkes?

I think the part that seems less obvious to me is what role time plays in all this. With a little more detail, we can hopefully come up with a nice interface for this (I once heard someone say that interfaces should be "easy to use correctly and difficult or impossible to use incorrectly", which I like). Grouping regions seems like a more obvious idea (and would be dead simple to implement -- we could even add an option so users could group regions as a first step towards this), but my first thought is that having entities which encompass both regions and time slices will potentially be a bit confusing or error prone, so it's worth thinking about this carefully so that we can come up with something that's convenient to use and maintainable on the code side.

(NB: This isn't urgent as we're a way off from tackling it, but I thought I'd open a new discussion for it so that we have somewhere to talk about this.)