Adding change in number of vehicles with change of demand in the model

[kaskranenburgQ]

Fixing the issues as explained in issue #2967 .

[mabijkerk]

Seems to work great, nice work @kaskranenburgQ! I have slightly editing the formatting in the inputs, for consistency. Additionally, I have two questions:

• The AREA attribute is not updated with these inputs, so if I make changes to the modal split of e.g., cars, the number_of_units on the node is updated accordingly, but if I query AREA(number_of_cars), I get the same value. Is this something we want to update as well? We do not seem to use in currently in any queries, but we may in the future. What do you think?
• If I increase the efficiency of e.g., electric vehicles, number_of_units does not change either. This means that, if vehicles get more efficient, we don't use fewer vehicles but instead the vehicles that we use need less energy for each tkm or pkm. Implicitly this means that we assume that the average tkm or pkm delivered per vehicle per year is not affected by efficiency changes. I'm okay with this implicit assumption. What do you think?

[kaskranenburgQ]

@mabijkerk Thanks for the changes! Regarding your questions:

1. I will follow your call on this matter, at the moment I don't have enough experience with the AREA attributes to form an opinion about this. I'm not quite sure how and when these attributes are used and I therefore find it difficult to get to a conclusion. Would like to discuss this some time.
2. I agree with you. I think the efficiency should affect the tkm.

[github-actions[bot]]

This pull request 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.

[kndehaan]

I've tried to implement updating the AREA attribute number_of_xxx when changing the share of certain transport technologies in passenger demand and freight demand, as well as updating this attribute when changing expected yearly change in passenger km or freight kms. The latter is not that straightforward, since transport_useful_demand_passenger_kms and transport_useful_demand_freight_tonne_kms have update_type = %y. Therefore, the following gives very strange results in the updated AREA attribute:

EACH(
      UPDATE(V(transport_useful_demand_passenger_kms), preset_demand, USER_INPUT()),
      UPDATE(V(transport_useful_demand_cars), number_of_units, USER_INPUT()),
      UPDATE(V(transport_useful_demand_busses), number_of_units, USER_INPUT()),
      UPDATE(
        AREA(),
        number_of_cars, 
        V(transport_useful_demand_cars, number_of_units)
      ),
      UPDATE(
        AREA(),
        number_of_busses, 
        V(transport_useful_demand_busses, number_of_units)
      )
    )

AREA(number_of_cars) --> 1.4e242 AREA(number_of_busses) --> 8.7e147

Some questions / solutions:

• Is there a good/quick method to correctly update the AREA attributes in or outside this query, while maintaining the update_type = %y (so no required changes to the first 3 update statements)
• A possibility is to not use the update_type = %y, but to manually apply the equation behind this to the first 3 UPDATE statements. However, it might not be desirable to write this out since we have created the method update_type = %y ETEngine for a reason.
• Other possibility is to change the input type of change in passenger km or freight km to not indicate the expected change per year, but the overall change between start and future year... And then change this query accordingly.

Already discussed with @kaskranenburgQ. @mabijkerk what do you think is the best way?

[mabijkerk]

Some thoughts:

• I think the issue here may be that both the "transport demand change" input and the "modal split" inputs update the number_of_units. If these updates are applied sequentially, then you will get a rather large number of units indeed, as in shown in the results of @kndehaan .
• The difficulty is that in any scenario, only one of the two input types may be set. We therefore cannot just apply the number of units change in one of the two input types.
• We will need to find a way to only update the number of units once, if one or both inputs are set.
• The most straightforward way, which I also applied in the household section, is to calculate the value in both inputs and set it 'hardcoded' instead of applying a change to the value. This works, but is quite cumbersome, as we're calculating the same value in two inputs. I feel there may be better ways to go about this, but as of yet I have not come up with one. Any ideas are welcome.
• Finally, I'm not overly fond of the update_type functionality. I would rather have dedicated GQL for this, for example UPDATE_PER_YEAR.

Other possibility is to change the input type of change in passenger km or freight km to not indicate the expected change per year, but the overall change between start and future year... And then change this query accordingly.

We have recently implemented this change for industry efficiency inputs. The upside of % per year is that it is an assumptions that can be maintained across scenarios. 2% per year is the same for a scenario with end year 2030 as it is for 2050. The downside is that the absolute change is a bit harder to the determine. Switching to % absolute change requires a migration for all relevant inputs, which is why it is not my preferred solution.

[kndehaan]

I've restructured the inputs of % annual change of demand passenger kms and demand freight tonne kms, as well as the inputs for share cars and busses in total passenger km fleet and share trucks and busses in total freight tonne km fleet.

With these changes, the effect of either or both % annual change and modal split are updated once. In order to calculate the result of annual % change, two new GQL functions are added to ETEngine.

@mabijkerk @kaskranenburgQ can you both have a look at these changes and see if it works as desired?

Goes with:

• https://github.com/quintel/etengine/pull/1427
• https://github.com/quintel/etsource/pull/2970

Next step (when PR is approved):

• [ ] Include new functions in GQL documentation

[kndehaan]

I will rewrite to issue since the implementation of the fix is larger than initially expected.

[kndehaan]

More effort is required to solve this issue, therefore this PR will be closed and proposed next steps are described in this issue https://github.com/quintel/etsource/issues/2967