Conversation
|
I think like this it is more flexible, because you can vary everything (e.g. also component But one should decide for either one of the definitions and also clean up the settings in the config before merging and move them to |
|
In my humble opinion I think it would a little confusing to have both |
|
Thanks a lot for your suggestions @koen-vg and @fneum . I still think it is useful to be able to more flexibly modify the components and attributes. For example, with the current implementation in the master branch the load cannot be modified and only specific attributes. Also it is not possible to have a modification depending on the investment period, which can be very useful. I have adapted now the existing function |
|
I definitely see the appeal of being able to adjust any attribute, also depending on the investment horizon (and choosing relative or absolute adjustments)! I think it made a lot of sense to build this into the If you ask me, I would at this point just get rid of the |
.## Changes proposed in this Pull Request
Add option to modify any parameter by a setting in the config called
varyfollowing the syntax
componentcarrierparameterone can modify any static values of a component. This is helpful for creating different scenarios and also would allow to remove all quite a few settings in the config (e.g.co2_network_cost_factor,aviation_demand_factor,gas_distribution_grid_cost_factor,...)Checklist
envs/environment.yaml.config.default.yaml.doc/configtables/*.csv.doc/release_notes.rstis added.