Changing full load wind hours does not change wind production in Noordoostpolder

[MartLubben]

When you start a new scenario for the Noordoostpolder and increase the full load hours.

I did not change the amount of wind turbines, however I can reset them and then it shows the right amount of produced wind power.

[marliekeverweij]

Good catch! I think I will notify @antw in this issue, because I don't directly see what I can do here 😉

[antw]

Merit takes the new FLH into account (which is why the amount of import falls), and you can see the result in the time charts:

However, the input doesn't set a new preset demand, which is why when queried it returns the same value regardless of the FLH setting. The same is true of the solar PV producer.

This gets "fixed" as soon as you move the "number of units" slider because it updates the preset_demand:

UPDATE(L(energy_power_wind_turbine_inland), preset_demand_by_electricity_production, V(energy_power_wind_turbine_inland, production_based_on_number_of_units))

The FLH input probably needs to do this as well?

[marliekeverweij]

Okay, I understand what is going on, thanks.

The FLH input probably needs to do this as well?

Yes that would fix it!

I was trying to fix it, but I do not exactly know how. Because in this input statementV(energy_power_wind_turbine_inland, production_based_on_number_of_units) is used. Does V(energy_power_wind_turbine_inland, production_based_on_full_load_hours) maybe also work?

[antw]

I think using production_based_on_number_of_units will work even inside the FLH input. It should account for the new FLH when calculating production. It's basically the same as running: number_of_units × input_capacity × full_load_seconds.

Something like...

- query =
    EACH(
      UPDATE(V(energy_power_wind_turbine_inland), full_load_hours, USER_INPUT()),
      UPDATE(L(energy_power_wind_turbine_inland), preset_demand_by_electricity_production, V(energy_power_wind_turbine_inland, production_based_on_number_of_units))
    )

[marliekeverweij]

I have tried the above idea, but it does not seem to work yet. I've looked into ETEngine and the production_based_on_number_of_units statement does this:

  def production_based_on_number_of_units
    fetch(:production_based_on_number_of_units) do
      number_of_units * typical_electricity_production_per_unit
    end
  end
  unit_for_calculation "production_based_on_number_of_units", 'MJ'

So it does not use the updated full_load_hours. So I think that we need a new definition, something like production_based_on_full_load_hours. What do you think @antw ?

I still find it quite mysterious that the flh-slider does work when the #-slider is used first....

[antw]

I'm pretty sure production_based_on_number_of_units is the correct thing to use. It calls typical_electricity_producer_per_unit which in turn calls full_load_seconds.

I have found out why adding this line is not enough to fix the problem: the number_of_units calculation is based on the input capacity and full load hours.

As an example, we have an electricity producer with a capacity of 10MW and 100 FLH, and annual demand of 20000MWh:

• ETEngine calculates that the number of units for this producer must be 20:
  20000MWh ÷ (10MW × 100 hours) = 20
• An input now sets 200 FLH...
• ETEngine calculates that the number of units for this producer is 10: 20000MWh ÷ (10MW × 200 hours) = 10

The amount of energy produced is exactly the same! This is what's happening in ETEngine. When you set the wind turbine FLH to 3500, the number of units is falling from 693 to 380. Therefore when we later call production_based_on_full_load_hours, the total demand does not change.

Only when the number of units slider is moved is the correct NoU set, and the production_based_on_full_load_hours calculation is correct.

I think the solution is for the FLH input to get the original NoU before setting the FLH, and then set that value again after updating the NoU. This version works for me:

# The query starts by fetching the original number of units: we want the new FLH
# to increase the preset demand, so we have to set this value after updating FLH
# to prevent ETEngine from calculating a new (lower) NoU.
#
# See https://github.com/quintel/etmodel/issues/2906
- query =
    original_nou = V(energy_power_wind_turbine_inland, number_of_units);

    EACH(
      UPDATE(V(energy_power_wind_turbine_inland), full_load_hours, USER_INPUT()),
      UPDATE(V(energy_power_wind_turbine_inland), number_of_units, original_nou),
      UPDATE(
        V(energy_power_wind_turbine_inland),
        preset_demand_by_electricity_production,
        V(energy_power_wind_turbine_inland, production_based_on_number_of_units)
      )
    )
- priority = 1

[marliekeverweij]

Thanks for the clear explanation! The wind flh sliders are working again.

Only for solar the input statement does not seem to work yet... In this input statement thefull_load_hours and preset_demand need to be updated for four solar pv nodes. Here is what I have done so far: https://github.com/quintel/etsource/commit/f1b04a1bd71f695171ec167975660e3a6a12f48d

[antw]

Only for solar the input statement does not seem to work yet...

This is because...

• energy_hydrogen_solar_pv_solar_radiation
• buildings_solar_pv_solar_radiation
• households_solar_pv_solar_radiation

... are not members of the preset demand group. Therefore ETEngine cannot calculate their number_of_units attribute at the start of the input.

energy_power_solar_pv_solar_radiation is fine because it does belong to the group.

I'm not too sure what we can do about this as there's no way to calculate the NoU without demand.

[marliekeverweij]

Thanks for finding out what the issue is. Would it a possibility to add them to the preset demand group?

[redekok]

I've created a new brach (fix-flh-sliders-after-deploy) for this issue. I've adopted the input statements from @marliekeverweij's old branch for wind turbines. For the input statement of PV parcs I've added the fix for PV parcs. This fixes the issue for PV parcs but not yet for energy_hydrogen_solar_pv_solar_radiation, buildings_solar_pv_solar_radiation, and households_solar_pv_solar_radiation.

Since we cannot calculate the number_of_units attribute without demand at the start of the input, I was wondering if there is a workaround. I've tried querying the (primary) demand at the start of the input statement but unfortunately this results in an error as well.

@antw Are there any possibilities to retrieve the (primary) demand for households_solar_pv_solar_radiation, etc. at the start of the input statement? Or would it be a possibility to retrieve the demand after updating the FLH slider (i.e., after the EACH block of updates)? This would allow us to calculate the original number of units at the end of the input statement, since we do are allowed to retrieve the original number of FLH (and the availability, etc.) at the start of the input statement.

[redekok]

Resolved by https://github.com/quintel/etsource/pull/1956. Closing this issue but opening a new one (https://github.com/quintel/etmodel/issues/3002) to solve the bug for energy_hydrogen_solar_pv_solar_radiation, buildings_solar_pv_solar_radiation, and households_solar_pv_solar_radiation.