Create switches that explicitly enable/disable features

[clizbe]

These configuration switches will tell Tulipa what constraints to turn on/off and determine required data (for validation feedback).

THIS SHOULD NOT BE A FILE.
Defining this as a file makes it a required input in the data that Tulipa will check for. Which means if the user wants to change settings on the fly, they now have to open the file (or alter the file with code) to change the configuration.

These should be arguments that Tulipa expects and uses for conditional switches, but not a required file. If the user wants to have their configuration saved in a file and then load that file in their workflow, they have that choice. But it's not required - they could just set UC = true in their workflow code.

I hope this makes sense!

@suvayu Did I get it?

[clizbe]

What should be the options the user needs to define in their model/scenario?
Maybe:

• FlexTemp? - Should they be able to turn it off and default to Hourly? Or they define the temp res in their data all the time?
• Year(s) horizon - Probably multiple types of Year they can define
• UnitCommitment
• RollingHorizon
• Clustering yes/no? Or is that just a part of their worklfow that we don't need to account for?
• Group Constraints?

Thinking of these things, it's hard for me to understand where their "data" ends and where the scenario begins. Say they have data for 2030, 2040, 2050 - and they want to run just 2040. Does that mean they should select for 2040 in their data, or they can send all three years and set 2040 in the scenario and it'll check for that data?

[suvayu]

they can send all three years and set 2040 in the scenario and it'll check for that data?

This. Data is static. The point of a workflow is pick the relevant data, make the required transforms, then run the model.

So a scenario is essentially parameters to a bunch of data transforms.