Define scenario specification workflow

[abelsiqueira]

How do we expect scenarios to work.

Discussing with @gnawin some use cases.

---

Example: sensitivity study

• many singular changes that are compared to a reference solve
  • E.g., double capacity, or half the cost, or double the profile of the demand for one asset
• active or deactivate constraints
  • Based on a true/false parameter
• Change a parameter

---

(migrated from #289)

Capabilities/Usability requirements

• Scenario building
  • change (enable/disable/limit) capacities
  • easily specify scenario parameters for multiple scenarios
    • need examples
    • probably needs some kind of filter-and-apply API
    • should be code, not config

[abelsiqueira]

Thinking about the scenario variants specification, slightly based on the diagram in #415.
The main features that I see are:

• Specify using a file what variants will be applied
• Apply these variants in multiple places in the workflow
• Don't allocate memory (don't copy everything) for each one of them
  • This assumes running one variant at a time, so maybe that is the opposite of what we want?

Suggestion using configuration file:

• Create a scenario-variants.abc configuration file
• Use a hierarchical definition in the file:
  • Variants - a name for them, then a list of
  • Stages - the red bubbles on the diagram, then a list of
  • Changes, defined with a limited set of options

Example in yaml:

variant:
  - name: Double cap for ocgt->demand
    pre-graph:
      scale-capacity-flow:
        from: ocgt
        to: demand
        factor: 2
  - name: Variant with double demand
    pre-cluster:
      scale-asset-time-series:
        asset: demand
        factor: 2

or in TOML:

[[variant]]
name = "Double cap for ocgt->demand"
[variant.pre-graph.scale-capacity-flow]
from = "ocgt"
to = "demand"
factor = 2.0

[[variant]]
name = "Variant with double demand"
[variant.pre-cluster.scale-asset-time-series]
asset = "demand"
factor = 2.0

Suggestion using julia file:

• Create a scenario-variants.jl file
• Use functions or macros to define variants
• work directly with the structures

Example:

@variant "Double cap for ocgt->demand" begin
    @create_graph begin
        graph["ocgt", "demand"].capacity *= 2
    end
end

@variant "Double demand" begin
    @cluster begin
        asset_profile["demand"] *= 2
    end
end

---

The file-based is probably easier to implement for a small number of options, but harder to extend.
The code-based needs more thought.

[gnawin]

This already looks great to me.

Don't allocate memory (don't copy everything) for each one of them
This assumes running one variant at a time, so maybe that is the opposite of what we want?

Currently with COMPETES, we only do one at a time. So that would be our user case unless we would want to support parallel runs?

The file-based is probably easier to implement for a small number of options, but harder to extend.

For our user case, we only do a small number (<30, mostly around 10). Unless we support parallel runs, I can hardly imagine we will do more.

[suvayu]

These are more higher-level points about how a user might want to specify scenarios, not relevant for lower-level implementation of scenarios

---

These are what I can think of at the moment, but I have no idea how common/important they might be.

• Replace a dataset entirely, asset data, profiles, etc.
• Replace parts of a dataset, specific column(s)
• Transform a dataset, or parts thereof; e.g.
  • Maybe need filtering capability before applying. Something like, scale capacity for all wind energy nodes.
  • factor/scaling (also needed for harmonising units)
  • offset?
  • applying any mathematical function
• Make some input specific transformations like:
  • combine/split partitions (can this be inferred? does this require validation based on the profiles?)
• Include/exclude assets/flows/constraints
  • How is this done internally? How to specify this will depend on the implementation.
• Group transforms/settings into scenarios
  • Is there need for generating scenarios based on some pattern or rules?

[clizbe]

It sounds like @suvayu is focusing on how to create a database for a single run, whereas @abelsiqueira is maybe thinking of specifying multiple runs simultaneously.

I see a few options:

1. Create data for each scenario, then have a way of running them all at once (or in series)
2. Also have an option to run multiple scenarios that only differ by 1 or 2 factors
   Such as a "wind production" set, which are the same as the base case, but with varying levels of wind production
3. Have a "scenario settings" file that can adjust certain common features and those are applied across multiple runs
   Such as "wind scalar" or "constraint X active"
   If we work out the ability then the file could start small and be expanded as people do analyses.
   This one is a bit tricky because it adds another level of abstraction that could be abused. Do you specify it in database or the scenario settings?

[datejada]

Blocked by #289 and #547

[clizbe]

Let's have a discussion about this soon.

[clizbe]

Related #56

[clizbe]

This already looks great to me.

Don't allocate memory (don't copy everything) for each one of them
This assumes running one variant at a time, so maybe that is the opposite of what we want?

Currently with COMPETES, we only do one at a time. So that would be our user case unless we would want to support parallel runs?

The file-based is probably easier to implement for a small number of options, but harder to extend.

For our user case, we only do a small number (<30, mostly around 10). Unless we support parallel runs, I can hardly imagine we will do more.

I agree that our current use-case is a limited number of hand-crafted scenarios, but that's a limitation. I think enabling batch runs (whether parallel or series) will be an important new feature for better analyses. Sebastiaan is also pushing the idea of "having the model run constantly, exploring the scenario space," but we'll see what that turns into.

[clizbe]

Another thing to consider: how aggregation happens from core data to scenario. As in, the core data is probably in as high resolution as possible, then the user needs to specify a level of detail and then some kind of aggregation processing happens.