Separate top-level config and parameters
brynpickering opened this issue · comments
Problem description
run
and model
configs mix up configuration and parameters. We want to be able to pipe these parameters to the Calliope model dataset and then onto the backend. We handle that at the moment with hardcoding which are parameters in the core code, which isn't ideal. An idea on how to change these YAML structures:
config:
init:
name: null
calliope_version: null
random_seed: null
subset_time: null
time: {}
timeseries_data_path: null
timeseries_data: null
timeseries_dateformat: "%Y-%m-%d %H:%M:%S"
build:
custom_math: []
backend: pyomo
cyclic_storage: true
ensure_feasibility: false
mode: plan
solve:
operate_window: null
operate_horizon: null
operate_use_cap_results: false
spores_number: 3
spores_score_cost_class: spores_score
spores_slack_cost_group: null
spores_save_per_spore: false
spores_save_per_spore_path: null
spores_skip_cost_op: false
save_logs: null
solver_io: null
solver_options: null
solver: cbc
zero_threshold: 1e-10
parameters:
reserve_margin: {electricity: 0.1}
bigM: 1e9
objective_cost_class: {"costs": {"monetary": 1, "emissions": 0.1}}
my_param: {("costs", "carriers"): {("monetary", "electricity"): 1, ("monetary", "heat"): 0.1}}
spores_slack: 0.1
spores_objective_cost_class: {"costs": {spores_score: 1, monetary: 0} }
Other things:
file_allowed
is deprecated.- All config items could become arguments in the relevant methods (
init
incalliope.Model
)/(build
incalliope.Model.build
)/(solve
incalliope.Model.solve
). - ^ config items then have to be flattened so they can be used by args.
- parameters can be dimensionless or have dimensions in a dict form (for non-tech/node/tech+node dims). This is very simplified and wouldn't work well for large parameters. That's ok because we would solve it in the long (hopefully medium) term with #92.
- Users can then add their own top-level parameters to 'parameters' for use in their custom constraints.
Calliope version
v0.7.0-dev
Completed in #497