Renewability chart does not sum to 100%

[mabijkerk]

When opening a blank scenario for nl2019 the chart does not sum to 100%, but to 99.93%. This should be fixed. Additionally, it may be useful to write a mechanical turk spec for this chart.

[kaskranenburgQ]

After some investigation I found the cause of this issue.

@mabijkerk found that if the oil mix is completely set to renewable sources the graph would add up to 100%.

The total number is automatically produced by the graph itself. This indicates that the problem lies in the queries.

The queries have the following structure :
V(INTERSECTION(G(final_demand_group),USE(energetic)), "sustainability_share * supply_of_network_gas") for the queries that calculate renewable final demand

and :
V(INTERSECTION(G(final_demand_group),USE(energetic)), "(1.0 - sustainability_share) * supply_of_network_gas") for the queries that calculate non renewable final demand.

This is not consistently done for all carriers. For fossil carriers like oil, the sustainability share is ignored in the queries. The query has the following structure:

V(INTERSECTION(G(final_demand_group),USE(energetic)), supply_of_oily_biomass)

For primarily renewable carriers like biomass, only the renewable variant is queried in the table.

For the table to add up to 100 again. I added the non renewable variant to the oil and products query for the table. This fixed the issue.

It appears that in a blank nl 2019 scenario, the following occurs:

It might be that this happens since in the nodes buildings_final_demand_crude_oil, agriculture_final_demand_crude_oil and industry_final_demand_crude_oil, these are mixed to crude_oil. This crude_oil flow has a sustainability share that is less than 1, since a great deal is from non renewable sources (like actual crude oil). The biodiesel inherits this sustainability share. If we only query the sustainability share in the table, a part of the energy flow gets lost.

This also explains why the table would get to 100% if you change the oil mix to completely renewable or completely non renewable.

In the case of completely renewable, the sustainability share of the crude_oil flow to industry would be 1. No energy would be left out.

In the case of completely non renewable, no biomass or bio oil would be used in the crude_oil flow, so no energy would be misqueried.

I added a query that queries a total share of the table. We can use this query to create a mt test.

I propose we take a look on how we can make these queries more MECE @mabijkerk.

[mabijkerk]

Thanks for this @kaskranenburgQ, this is very helpful. I did wonder why adding sustainability_share to biocarriers fixes the problem: I would expect all biocarriers to have sustainability_share of 1.0. I therefore dived into the issue a bit.

Taking the agriculture_final_demand_crude_oil as an example in a blank nl2019 scenario:

It has a mix of bio and fossil carriers, which means that its overall sustainability_share is 0.54. Each of the incoming nodes however, either has a sustainability_share of 1.0 or 0.0.

EACH(
  V(agriculture_final_demand_crude_oil,sustainability_share),
  V(agriculture_final_demand_bio_kerosene,sustainability_share),
  V(agriculture_final_demand_biodiesel,sustainability_share),
  V(agriculture_final_demand_diesel,sustainability_share),
  V(agriculture_final_demand_kerosene,sustainability_share),
  V(agriculture_final_demand_lpg,sustainability_share),
  V(agriculture_final_demand_other_bio_oil,sustainability_share),
  V(agriculture_final_demand_other_oil,sustainability_share)
)

[
  0.5356283681344821,
  1.0,
  1.0,
  0.0,
  0.0,
  0.0,
  1.0,
  0.0,
]

The tricky part here is that, in the renewability queries we multiply the input of a carrier with the sustainability_share of the agriculture_final_demand_crude_oil node. Therefore the input of a biocarrier, multiplied with the sustainability_share of the node, will in this case make it seems as though the input of e.g. bio_oil is not fully renewable, though in fact it is.

The reason why the final_demand_of_oil_and_derivatives_in_renewability query does not include a fossil and bio version is because it is (in this case rightly) assumed that this will always be fossil. The same should be applied to the final_demand_of_biomass_products_in_renewability query. Instead of adding new carriers to the final_demand_of_oil_and_derivatives_in_renewability query, I would therefore propose to update the query final_demand_of_biomass_products_in_renewability in the following way:

- query =
    100 * SUM(
        V(INTERSECTION(G(final_demand_group),USE(energetic)), supply_of_biodiesel),
        V(INTERSECTION(G(final_demand_group),USE(energetic)), supply_of_bio_ethanol),
        V(INTERSECTION(G(final_demand_group),USE(energetic)), supply_of_wood_pellets),
        V(INTERSECTION(G(final_demand_group),USE(energetic)), supply_of_bio_lng),
        V(INTERSECTION(G(final_demand_group),USE(energetic)), supply_of_bio_oil),
        V(INTERSECTION(G(final_demand_group),USE(energetic)), supply_of_bio_kerosene)
    )

The only remaining question then is whether these queries are robust for all future developments: what if at some point we use some fossil input to create a bio carrier? In this case though I suspect the queries would have to be rewritten entirely to avoid the 'tricky part' I mention above.

Do you agree with my line of reasoning @kaskranenburgQ?

[kaskranenburgQ]

I would therefore propose to update the query final_demand_of_biomass_products_in_renewability in the following way

I think you are correct @mabijkerk . In the way I set up the queries at the moment, oil and derivatives would obtain a higher share since the fossil part in the oil mix is calculated twice.

In this case though I suspect the queries would have to be rewritten entirely to avoid the 'tricky part' I mention above.

I agree, I feel that the queries are not robust in the way they are written at the moment.

[mabijkerk]

@kaskranenburgQ I would then first solve and close this issue by rewriting the bio carriers query. After that we can open a new issue that discusses the robustness of the renewability queries in general.

[kaskranenburgQ]

I have changed the queries in this PR