[RTD] Describe assumtions for energy assets

[smartie2076]

In the RTD assumptions we started to describe the assumptions for component models. This is to explain how they are modelled in the MVS, and maybe give a hint on the limitations of the approach. This should in the end include all assets that are to be modelled with the MVS:

• [x] Electrical storage (BESS) - as per requirements
• [x] Stratified thermal storage - add-on for GRECO
• [x] thermal storage - as per requirements
• [x] Generic storage - eg. for H2 storage (Walqua)
• [x] Energy providers - as per requirements with peak demand pricing and energy price timeseries
• [x] Electrical transformers (inverters, rectifiers) - "transformers" see FUN-MVS-06, used for transformer stations which are focal point of E-Land bottlenecks
• [x] Charge controllers - for completeness, ie. used managing storage assets (used to add costs)
• [x] CHP - as per requirements
• [x] Undispatchable sources (renewable sources) - as per requirements (PV)
• [x] Dispatchable sources (fuel sources) - not in requirements, complementary to uni-lateral energy providers?
• [x] Excess sinks (automatically added) - not in requirements, necessary from energy modelling perspective
• [x] Electrolyzer - Needed in Walqua
• [x] Heat pump (geothermal) - as per requirements
• [x] Solar thermal collectors - Needed in UVtgV
• [x] Heat pump (HVAC) - Needed in UVTgV
• [x] Biogas power plant - Optional description, needed for Auroville
• [x] other power plants?

Following are the todos:

• [x] Someone needs to read the descriptions and tick the checkboxes for the assets already described
• [x] Check with the requirements whether any assets were forgotten in above list
• [x] Check with pilot sites whether any assets were forgotten in above list (add info in which pilot site the asset is needed) @smartie2076 ?
• [x] Propose in the structure of that section (eg. we could use the common sections energyProvider, energyConsumperion, energyProduction, energyStorage, energyConversion to mirror both EPA and MVS input data).

[smartie2076]

@SabineHaas are you interested in this issue? I have heard you like working on the RTD :D

[mahendrark]

@smartie2076

I found descriptions for some of the components in your list in the docs, but like only two lines for each one already described. They should be further expanded I suppose.

[SabineHaas]

@SabineHaas are you interested in this issue? I have heard you like working on the RTD :D

hehe that's True ;) coding and docs are my favourites! Is @mahendrark going to work on this, too? how do we split?

[mahendrark]

@SabineHaas

You can go ahead with it. I just read the component models section for a bit. Did not do any work on the other to-dos.

[SabineHaas]

Propose in the structure of that section (eg. we could use the common sections energyProvider, energyConsumperion, energyProduction, energyStorage, energyConversion to mirror both EPA and MVS input data).

Could you clarify this point, please @smartie2076 ? "Propose in the structure of that section"?

[smartie2076]

Propose in the structure of that section (eg. we could use the common sections energyProvider, energyConsumperion, energyProduction, energyStorage, energyConversion to mirror both EPA and MVS input data).

Could you clarify this point, please @smartie2076 ? "Propose in the structure of that section"?

Sure. So currently, the structure is like the screenshot below - which descriptive component model names. I wonder, though, if this is the right structure to make it easy for the user to understand: After all, both in MVS and in EPA, the user chooses assets from the categories energyConsumption, energyConversion... Maybe we should have an identical structure there as well?

It could be that it is easier to split this issue in two PRs, though: One dealing with the structure and one with the content. Or do very nice commit messages ;)

[SabineHaas]

Sure. So currently, the structure is like the screenshot below - which descriptive component model names. I wonder, though, if this is the right structure to make it easy for the user to understand: After all, both in MVS and in EPA, the user chooses assets from the categories energyConsumption, energyConversion... Maybe we should have an identical structure there as well?

Thank you, this is clear now. I will propose a structure in this issue.

It could be that it is easier to split this issue in two PRs, though: One dealing with the structure and one with the content. Or do very nice commit messages ;)

I would propose a structure we agree on before implementing it and then do all in one PR (with nice commit messages ;)).

[SabineHaas]

In the requirements I did not even find all the assets you have listed. In FUN-MVS-05, FUN-MVS-06: PV, BESS, CHP, Thermal Storage, geothermal conversion (heat pump). But not much more information. Did I miss anything @smartie2076 ?

[SabineHaas]

What do you think about the following structure @smartie2076 ? We could also skip the third level section in energy production, but I find it helpful.

• Component models
  • Energy Production
    • Non-dispatchable sources of production
    • Dispatchable sources of production
  • Energy Conversion
  • Energy Providers (DSOs) (include here instead of of first level)
  • Energy Storage
  • Energy consumption (do we need this section? --> it's only about demand, DSOs consumption in providers section)
  • Energy excess

[smartie2076]

In the requirements I did not even find all the assets you have listed. In FUN-MVS-05, FUN-MVS-06: PV, BESS, CHP, Thermal Storage, geothermal conversion (heat pump). But not much more information. Did I miss anything @smartie2076 ?

No, you are right: The functional requirements name quite few assets. However, in the end, we should (also) be able to simulate all of the assets at our pilot sites. Those need to be added. Maybe add a comment to the assets individually, so that I can comment again if I think the asset should be mentioned?

What do you think about the following structure @smartie2076 ? We could also skip the third level section in energy production, but I find it helpful.

* Component models

  * Energy Production

    * Non-dispatchable sources of production
    * Dispatchable sources of production
  * Energy Conversion
  * Energy Providers (DSOs) **_(include here instead of of first level)_**
  * Energy Storage
  * Energy consumption **_(do we need this section? --> it's only about demand, DSOs consumption in providers section)_**
  * Energy excess

Yeah, I like it. This would be identival to the csv structure and the EPA structure! The Excess sinks are somewhat an assumption, as they are not intentionally added to the energy system, but automatically.

[SabineHaas]

In the requirements I did not even find all the assets you have listed. In FUN-MVS-05, FUN-MVS-06: PV, BESS, CHP, Thermal Storage, geothermal conversion (heat pump). But not much more information. Did I miss anything @smartie2076 ?

No, you are right: The functional requirements name quite few assets. However, in the end, we should (also) be able to simulate all of the assets at our pilot sites. Those need to be added. Maybe add a comment to the assets individually, so that I can comment again if I think the asset should be mentioned?

Do you mean to add a comment to the list in this issue in case the asset is not named in the requirements?

What do you think about the following structure @smartie2076 ? We could also skip the third level section in energy production, but I find it helpful.

* Component models

  * Energy Production

    * Non-dispatchable sources of production
    * Dispatchable sources of production
  * Energy Conversion
  * Energy Providers (DSOs) **_(include here instead of of first level)_**
  * Energy Storage
  * Energy consumption **_(do we need this section? --> it's only about demand, DSOs consumption in providers section)_**
  * Energy excess

Yeah, I like it. This would be identival to the csv structure and the EPA structure! The Excess sinks are somewhat an assumption, as they are not intentionally added to the energy system, but automatically.

True.. so, would you prefer to move them one layer up to not confuse the users? I would be fine with having them in Component models - I would then add as first line a statement saying that they are added automatically.

[smartie2076]

Do you mean to add a comment to the list in this issue in case the asset is not named in the requirements?

Like this:

• [ ] Electrical storage - required at projet site
• [ ] Stratified thermal storage - add-on
• [ ] Excess sinks - automatically added
• [ ] Electrolyzer - needed for pilot site Walqua
• [ ] Heat pump (geothermal) - as per requirements
• [ ] Heat pump (HVAC) - needed for UVTgV

True.. so, would you prefer to move them one layer up to not confuse the users? I would be fine with having them in Component models - I would then add as first line a statement saying that they are added automatically.

Hmhm, if there is a large warning, I guess they could stay in the component models. I have some other ideas, but we have until May to figure out if this leads to confusion.

[SabineHaas]

Do you mean to add a comment to the list in this issue in case the asset is not named in the requirements?

Like this:

* [ ]  **Electrical storage** - required at projet site

* [ ]  **Stratified thermal storage** - add-on

* [ ]  **Excess sinks** - automatically added

* [ ]  **Electrolyzer** - needed for pilot site Walqua

* [ ]  **Heat pump (geothermal)** - as per requirements

* [ ]  **Heat pump (HVAC)** - needed for UVTgV

Ahh okay, I cannot see that from the requirements. I think it would be faster if you add the information you know about the pilot sites - I've added the info from the requirements. Could you do that @smartie2076 ?

True.. so, would you prefer to move them one layer up to not confuse the users? I would be fine with having them in Component models - I would then add as first line a statement saying that they are added automatically.

Hmhm, if there is a large warning, I guess they could stay in the component models. I have some other ideas, but we have until May to figure out if this leads to confusion.

:+1: