Flexible outputs are not used

[tsmbland]

The CommOut file, which is used to specify the output commodities for each process, includes the Level field which can be "fixed" or "flexible". Internally, this parameter is used by the read_technologies function to define the fixed_outputs and flexible_outputs dimensions of the xarray object representing the technologies. fixed_outputs is used many times throughout the code, but flexible_outputs isn't used at all (apart from one place where it's just checked to be >0 but the actual value isn't used).

Whatever the intended role of the Level parameter is, it's not being implemented. (@dalonsoa - can you confirm this?)

We have a couple of options:

• Remove the Level field from the CommOut files since it isn't being used and it's confusing to include
• Or, figure out exactly what "flexible" outputs is supposed to mean and implement this

I have a vague idea of what it's supposed to mean, but I'm still not clear on all the details. I can imagine, for example, a refinery that can run multiple different processes - let's say it has two processes it can run: A -> B C -> D "Flexible" would then mean it can choose some mix of these two processes based on some function of commodity prices and demand (in vague terms). Right?

If so, then before implementing this we'd need to go back to the input files because there's no way to actually specify this. You could have A and C as flexible inputs, and B and D as flexible outputs, but you can't specifically map A to B and C to D within one single technology. (If it were A->B and A->D, or A->B and C->B, that would be possible with the current format).

For MUSE2 this seems like a very useful feature to include, but for MUSE1 is anyone actually using this feature in any of their models? @ahawkes

[ahawkes]

I guess if it's not working then no-one is using it! Though I am aware @sharwaridixit was attempting to create a model that had a refinery in it (though not sure was using flexible inputs/outputs).

In the spicy solver I think the correct implementation would be that if a process input/output is flexible, the process-level commodity balance equations would be a bit different. i.e. they would require a balance between all flexible inputs and outputs, as opposed to requiring a balance between each input/output individually. At least that's how I'm thinking to do this for MUSE 2.0.

[tsmbland]

Ok, if nobody's needs flexible outputs now or in the near future then I'm tempted to remove it from the input files/documentation for now and leave this issue open to implement this in the future (or never if MUSE2 comes first), as it's confusing to have it there when it isn't used. Flexible inputs are implemented (whether it's correct is a separate question), so that can stay. @dalonsoa what do you think?

[dalonsoa]

Removing unnecessary things is always useful to bring clarity and simplicity, so it they are really not used, I said we go for it.