Redefine transformer behavior (fix assignment to in- and output flows)

[SabineHaas]

This is part of #333 to finish testing D1. I'd like to give you the chance of giving your opinion on my plans @smartie2076 as implementation can change drastically depending on the decisions.

@smartie2076 will this interfere with your PR #379?

Planned changes:

• [ ] Redefine type_oemof to fix assignment of parameters variable_costs, efficiencies, nominal_value (fixed capacity), existing and investment (for optimization) to input/output flows of transformers. Valid options: 'heat_pump', 'chp_pp', for more see document attached below. Option 'transformer' is kept for transformers that are not of one of these options (default behavior: see section Decisions below)
• [ ] Adapt and add tests for transformer function in D1.

Fixes:

• [ ] Fix assingment of variable_costs, efficiencies, nominal_value (fixed capacity), existing and investment (for optimization) to input/output flows of transformers.

Deprecations:

• [ ] type_oemof 'transformer' behavior will be changed to xxx whatever we decide

Decisions to be made:

• [ ] Define default behavior for option 'transformer' (if yes, which?) AND/OR give user possibility to define behavior. Default behavior could be the one for 'condensing_pp' and 'chp_pp' (see document attached). My preference: add default behavior and wait whether the need for user's input arises.
• [ ] Now the functions are named transformer_constant_efficiency_XY() but I think they might just work with both, constant and time dependent efficiency. I would just test that for both, but give me a notice in case you think it cannot work!
• [ ] Look at the attached document please: green cells are planned to be implemented, red is for the future. Check if you agree :)

Update: I updated the file including solar_inverter and transformer_station, which were missing before: 2020-07-02_transformer_planning_mvs.xlsx

[smartie2076]

@smartie2076 will this interfere with your PR #379?

No, that PR only changes stuff in C-modules afaik.

Planned changes:

* [ ]  Redefine `type_oemof` to fix assignment of parameters `variable_costs`, `efficiencies`, `nominal_value` (fixed capacity), `existing` and `investment` (for optimization) to input/output flows of transformers. Valid options: 'heat_pump', 'chp_pp', for more see document attached below. Option 'transformer' is kept for transformers that are not of one of these options (default behavior: see section Decisions below)

That means that you do not plan to change type_oemof but add other types to it, correct? This is something you can do here which is then something you would have to implement here.

* [ ]  Fix assingment of `variable_costs`, `efficiencies`, `nominal_value` (fixed capacity), `existing` and `investment` (for optimization) to input/output flows of transformers.

I am not sure what you mean by this.

* [ ]  `type_oemof` 'transformer' behavior will be changed to xxx whatever we decide

Or could it be the one that you can define most freely? I think I need to check the table before I can answer this.

Decisions to be made:

* [ ]  Define default behavior for option 'transformer' (if yes, which?) AND/OR give user possibility to define behavior.
  Default behavior could be the one for 'condensing_pp' and 'chp_pp' (see document attached).
  My preference: add default behavior and wait whether the need for user's input arises.

Will need to check the table before I can answer this.

* [ ]  Now the functions are named `transformer_constant_efficiency_XY()` but I think they might just work with both, constant and time dependent efficiency. I would just test that for both, but give me a notice in case you think it cannot work!

Ah, constant here refers to the fact that it is not an OffsetTransformer, ie. it does not have an efficiency curve. Currently it will work for a scalar efficiency and one that is time-dependent, but not for one that is load-dependent.

* [ ]  Look at the attached document please: green cells are planned to be implemented, red is for the future. Check if you agree :)

Do you need feedback to this plan urgently, ie. did you plan to work on this before your vacation? I will work in the afternoon/evening/tomorrow again and only then can promise you a reply.

A quick check makes me wonder how you want to implement this in the input csvs. Do you want to split them up into the transformer type? Are no changes necessary?

[SabineHaas]

@smartie2076 will this interfere with your PR #379?

No, that PR only changes stuff in C-modules afaik.

Planned changes:

* [ ]  Redefine `type_oemof` to fix assignment of parameters `variable_costs`, `efficiencies`, `nominal_value` (fixed capacity), `existing` and `investment` (for optimization) to input/output flows of transformers. Valid options: 'heat_pump', 'chp_pp', for more see document attached below. Option 'transformer' is kept for transformers that are not of one of these options (default behavior: see section Decisions below)

That means that you do not plan to change type_oemof but add other types to it, correct? This is something you can do here which is then something you would have to implement here.

Right! Thanks for the hints!

* [ ]  Fix assingment of `variable_costs`, `efficiencies`, `nominal_value` (fixed capacity), `existing` and `investment` (for optimization) to input/output flows of transformers.

I am not sure what you mean by this.

Some of the parameters are assigned to both, input and output flows, or maybe just to the wrong flow. This is connected to #246. Need to check whether #248 is connected, as well (reminder for me).

* [ ]  `type_oemof` 'transformer' behavior will be changed to xxx whatever we decide

Or could it be the one that you can define most freely? I think I need to check the table before I can answer this.

Decisions to be made:

* [ ]  Define default behavior for option 'transformer' (if yes, which?) AND/OR give user possibility to define behavior.
  Default behavior could be the one for 'condensing_pp' and 'chp_pp' (see document attached).
  My preference: add default behavior and wait whether the need for user's input arises.

Will need to check the table before I can answer this.

* [ ]  Now the functions are named `transformer_constant_efficiency_XY()` but I think they might just work with both, constant and time dependent efficiency. I would just test that for both, but give me a notice in case you think it cannot work!

Ah, constant here refers to the fact that it is not an OffsetTransformer, ie. it does not have an efficiency curve. Currently it will work for a scalar efficiency and one that is time-dependent, but not for one that is load-dependent.

Oh, I see! Thanks for clarifying. So constant means non-load-dependent but possibly time-dependent?

* [ ]  Look at the attached document please: green cells are planned to be implemented, red is for the future. Check if you agree :)

Do you need feedback to this plan urgently, ie. did you plan to work on this before your vacation? I will work in the afternoon/evening/tomorrow again and only then can promise you a reply.

It's also okay if you reply after your vacation! There's always other things to do :P

A quick check makes me wonder how you want to implement this in the input csvs. Do you want to split them up into the transformer type? Are no changes necessary?

No changes are necessary as long as the user is not allowed to define the assignment of parameters to either in- or outflows (or both). Then type_oemof can be 'transformer', 'heat_pump', 'chp_pp', etc. To allow users to define the assignments themselves other parameters would be necessary. But then it could even be easier to adapt the code and add a new 'type_oemof'.

[SabineHaas]

@smartie2076 I could probably work on Monday on this topic if you manage to give feedback until then? Otherwise don't worry - there are always other things to work on!

[smartie2076]

I will start reviewing your proposal now - lets see if we need a call for this. Today is coding day!

[SabineHaas]

nice :+1:

[smartie2076]

* [ ]  Fix assingment of `variable_costs`, `efficiencies`, `nominal_value` (fixed capacity), `existing` and `investment` (for optimization) to input/output flows of transformers.

I am not sure what you mean by this.

Some of the parameters are assigned to both, input and output flows, or maybe just to the wrong flow. This is connected to #246. Need to check whether #248 is connected, as well (reminder for me).

Got it now. OK!

• [ ] Define default behavior for option 'transformer' (if yes, which?) AND/OR give user possibility to define behavior.

Ah, constant here refers to the fact that it is not an OffsetTransformer, ie. it does not have an efficiency curve. Currently it will work for a scalar efficiency and one that is time-dependent, but not for one that is load-dependent.

Oh, I see! Thanks for clarifying. So constant means non-load-dependent but possibly time-dependent?

Yes

A quick check makes me wonder how you want to implement this in the input csvs. Do you want to split them up into the transformer type? Are no changes necessary?

No changes are necessary as long as the user is not allowed to define the assignment of parameters to either in- or outflows (or both). Then type_oemof can be 'transformer', 'heat_pump', 'chp_pp', etc. To allow users to define the assignments themselves other parameters would be necessary. But then it could even be easier to adapt the code and add a new 'type_oemof'.

I do not think that the user should define the assignment of var_cost etc. to the in/output bus themselves.

To be commented:

• [ ] type_oemof 'transformer' behavior will be changed to xxx whatever we decide

...

• [ ] Look at the attached document please: green cells are planned to be implemented, red is for the future. Check if you agree :)

... checking, but I think there is need for a call

[smartie2076]

The variable costs of transformer dispatch should be on the output flow as they should represent the om costs, not fuel costs. This is connceted to #186, which we probably have to fix by requiring an explicit (fuel) source definition. Those sources can then also include their fuel prices. The transformers´ variable costs should not be fixed until #186 is fixed.

[SabineHaas]

Also nominal values and efficiencies should be on the output flow. There might be exceptions for efficiencies (heat pump). In order not make the post-processing not too complicated we will stay with as few oemof_types as possible. There's still the question whether we want different transformer types but we will first wait for #186, then change the code so that variable costs, nominal value and efficiency is assigned to the output flow(s) of the transformer and then see, how to handle special cases.