Fix input/output_parameters for BEV and Reservoir

[unndreay]

This fixes BEV's and Reservoir's parametrization to have input and output parameters.

Details: BEV: output_parameters exists as an argument but is not applied to a subnode. BEV: variable_cost as (numerically) auxilliary cost is hard-coded in the input Flow Reservoir: input_parameters exists as an argument but is not applied to a subnode. Reservoir: still needs variable_cost as auxilliary cost for input Flow

With this,...

• [x] input parameters in BEV can be used to apply variable costs instead of being hard-coded
• [x] variable costs can be applied to Reservoir's pump to avoid curtailment by the solver using the 'pump-and-spillover trick'.

[unndreay]

We use the pass-through parameter input_parameters the first time here. To be consistent with what was done so far, we decided that input and output will be applied to Flow objects, not to any of the other sub-nodes (would require a new pass-through parameter name!)

First usage here, but there is a reverted commit I have used as a template: https://github.com/modex-flexmex/oemo-flex/commit/04b903551a8e6589b6d338c60f129ffec1c16759 The additional lines are not necessary as long as there is only one input parameter (more than one parameter results in a comma which is more complicated).

[unndreay]

Tested this with Use case 3. As expected, Shortage VarOM only differ in a few hundred Euro per Region (the amount of auxiliary cost). Curtailment increased by 2% (BE) and ~25% (AT, DK, IT) -- seems OK because curtailment formerly performed via pump must be compensated via proper curtailment now. Pump energy decreases and the amounts are equal with the respective curtailment amount. This is not true for IT. Also turbine energy is identical (+–0%), except for IT (–2%). Actually, the balance for each region should hold and turbine flows should not be affected, but it both happens to IT probably as an indirect cause (changes in reservoir storage level or similar).

[jnnr]

Looks good!

One question: The auxiliary costs are hard-coded in the update function - maybe it would be more transparent to set it as default parameter?

I will check the changes against my default results and then merge.

[unndreay]

Moved variable_costs setting to the default value. The first solution works as long as there is only one key-value pair. If more, there would be a comma making it necessary to replace the separator in the CSV file by a semicolon. This affects all csv component files and needs adaptations in all read_csv() calls (every single update function). An alternative (last commits) is using double quotes as qualifier and escaping the dict key name with two double quotes: "{""variable_costs"": 0.00001}" which allows to include commas within the field. I suggest to stick with that solution although it has less readable csv files. As soon as the read_csv() calls are centralized we can think about the other way again.

[unndreay]

Dealing with the dict in output/input parameters has another implication: If one wants to add an input parameter via the update function (different values across the regions), the former (default) dict must be read in and updated with the new key-value pair: Say, variable_costs is the default (set via the csv file) and a specific summed_max value has to be applied to every region (via update fcn). Currently, the default value of input_/output_parameter would be overwritten if an update function re-writes the dict in the csv file. variable_costs would be lost. So, updating input/output parameter with a default value would be more complex. To do it right, the update function should not need to know if a default value exists. Instead get_parameter_values() should overtake that.

[jnnr]

Looks good! I checked the postprocessed results. For 7b, nothing changed which is good because apart from the implementation, the model has not changed. For 3, this change leads to more curtailment and less energy pumped into the reservoir.