search

quintel / etmodel

Professional interface of the Energy Transition model.
https://energytransitionmodel.com/
MIT License
33 stars 14 forks source link

Changing solar PV FLH does not update households, buildings and hydrogen solar PV production (when leaving the installed capacity-related sliders untouched) #3002

Open redekok opened 5 years ago

redekok commented 5 years ago

Follow-up on https://github.com/quintel/etmodel/issues/2906:

The previous issue was fixed for wind turbines by storing the original number of units in the input statement before updating the FLH and afterwards calculating the new production based on the updated FLH and the original number of units. This also works for updating the production for solar PV parcs but doesn't work for energy_hydrogen_solar_pv_solar_radiation, buildings_solar_pv_solar_radiation, and households_solar_pv_solar_radiation since these nodes are not included in the preset_demand group (which is why the number of units cannot be calculated at the start of the input statement for the FLH of solar PV.

In order to fix this issue we should find a workaround for storing the original number of units for the producer nodes mentioned above. @antw do you know why the sandbox does allow us to query the number of units but a query at the start of the input statement doesn't? Does that have to do with the fact that not all nodes in the graph have been calculated yet at the time the input statement is executed?

Screen Shot 2019-03-12 at 14 58 35

Edit: The previous issue hasn't been fixed for flh_of_energy_hydrogen_wind_turbine_offshore, since energy_hydrogen_wind_turbine_offshore isn't part of the preset_demand group either.

redekok commented 5 years ago

@ChaelKruip, @michieldenhaan, @marliekeverweij and I just had a short meeting about this issue and some (more specific) questions arose:

  1. What is the reason for the fact that the NoU (in the present year) can't be queried at the the start of the input statement? Does that have to do with the fact that not all nodes in the graph have been calculated yet at the time the input statement is executed?

  2. How are the demand and FLH values from the central_producers.csv queried for converters? When a converter is in a certain group (for example, the preset_demand or central_producers group), this is done implicitly, isn't it? What exactly happens in the engine in these situations?

  3. For other converters (for example, energy_hydrogen_electrolysis_wind_electricity, these values are queried by ~ demand = CENTRAL_PRODUCTION(name_of_converter, demand) and ~ full_load_hours = CENTRAL_PRODUCTION(name_of_converter, full_load_hours). Do you know if we can use such queries in input statements as well?

  4. What exactly is the influence of the priority = 1 line of code in an input statement? Would it be a possibility to lower the priority value for this input statement in order to calculate the demand for the relevant nodes first (before updating the input statements)?

@antw We were wondering if you have any answers to these questions?

antw commented 5 years ago
  1. What is the reason for the fact that the NoU (in the present year) can't be queried at the the start of the input statement? Does that have to do with the fact that not all nodes in the graph have been calculated yet at the time the input statement is executed?

The number of units is probably calculated by ETEngine or Merit, based on the capacity, full load hours, and demand of the node. If the demand is not yet known (because the graph has not been calculated when inputs are run), then the NoU will not be available.

  1. How are the demand and FLH values from the central_producers.csv queried for converters? When a converter is in a certain group (for example, the preset_demand or central_producers group), this is done implicitly, isn't it? What exactly happens in the engine in these situations?

The central_producers.csv file is used by Atlas+Refinery, but not by ETEngine. I believe the full_load_hours from the CSV are kept and used by ETEngine, but demand is not. The only time demand is carried over from Atlas+Refinery to ETEngine is when a node belongs to the preset_demand group; only these nodes have a demand which can be read while running inputs.

  1. [...] Do you know if we can use such queries in input statements as well?

CENTRAL_PRODUCTION is currently only available in Atlas+Refinery.

  1. What exactly is the influence of the priority = 1 line of code in an input statement?

The priority controls the order in which inputs are executed. For example, if the values set by input A might influence input B, we would set input A to have a higher priority to ensure it is executed first.

  1. Would it be a possibility to lower the priority value for this input statement in order to calculate the demand for the relevant nodes first (before updating the input statements)?

I don't think this would work. Setting the FLH after the graph has been calculated (which includes Merit, Fever, Hydrogen) will be too late: the graph (and the merit order) will have been calculated with the old FLH.

michieldenhaan commented 4 years ago

Is this issue still relevant @redekok? It looks like PV production of households, buildings and H2 is updated when changing the FLH slider

marliekeverweij commented 4 years ago

A miracle has happened! ✨  Somehow this issue has been fixed. Who has a clue what fixed the issue? The merit order calculation has been updated lately right?

redekok commented 4 years ago

It doesn't seem to be fixed for solar PV on rooftops, does it? When I leave the shares of solar PV on rooftops untouched and first change the # FLH for solar PV, the energy production stays the same (on BETA).

marliekeverweij commented 4 years ago

Yes you are right! That's the issue. Te vroeg gejuicht......

redekok commented 4 years ago

Haha, too bad.. So to conclude: yes, unfortunately this issue is still relevant @michieldenhaan.. :(

marliekeverweij commented 4 years ago

Shall we change the title of the issue since it only happens when users do not change the installed solar pv capacity in their scenario? And this almost never happens :)

(I'll put the label 'minor' on the this issue)

redekok commented 4 years ago

I've changed the title of the issue. Feel free to rename the issue if you have a better suggestion. And @marliekeverweij, do you think we could remove the on hold label again?

github-actions[bot] commented 3 years ago

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.