Fuel prices - Update #1509
Fuel prices - Update #1509
Conversation
Code changed such that LHS of slider calculates and shows the absolute fuel prices. New variables, present_value and relative_value, created for clearer repsentation of calculations. Initial,max,min values changed from percentage range to absolute price range.
| - query = PRODUCT(V(AREA(co2_price)),KG_PER_TONNE) | ||
| - query = | ||
| PRODUCT( | ||
| V(AREA(co2_price)),KG_PER_TONNE) |
There was a problem hiding this comment.
Nitpicky: can this be cleaned up to:
- query =
PRODUCT(
V(AREA(co2_price)), KG_PER_TONNE)or
- query = PRODUCT(V(AREA(co2_price)), KG_PER_TONNE)Hmm..
|
|
||
| - query = | ||
| 100.0 * DIVIDE( | ||
| SUM(QUERY_FUTURE(-> {Q(price_of_co2)}), PRODUCT(-1,QUERY_PRESENT(-> {Q(price_of_co2)}))), |
There was a problem hiding this comment.
PRODUCT(-1, x) can also be written as -x in GQL, the same for adding +, dividing / and subtracting -. At least - in the Sandbox of ETEngine I'm allowed to write: (V(households_final_demand_electricity, demand) * -1 / 5 + 2 - 10). So I think this can become:
100 * ((QUERY_FUTURE(-> {Q(price_of_co2)}) - QUERY_PRESENT(-> {Q(price_of_co2)})) / QUERY_PRESENT(-> {Q(price_of_co2)}))I haven't tried this myself, so I could be wrong 😅 but if it works in the sandbox, I dare to say it would work in a query.
💡 Edit: In this situation I would also validate that price_of_co2 in the present stituation won't become 0. As dividing by 0 can cause some problems.
inputs/costs/costs_co2.ad
Outdated
| - label_query = Q(price_of_co2) | ||
|
|
||
| # - label = €/tonne | ||
| # - label_query = Q(price_of_co2) |
There was a problem hiding this comment.
If these lines are intended to be removed, please do so. The same for the blank lines following.
There was a problem hiding this comment.
I left them as comments as these lines refer to the RHS of the slider ( which should show the percentage change in fuel price) but this part of the issue is postponed for later as changes to the ETengine need to be made to facilitate this.
So if these changes will be made at some point, I guess it's better to leave them as comments so that it's easier to fix. Do you agree?
inputs/costs/costs_biomass.ad
Outdated
| - update_period = future | ||
| - update_type = % | ||
| - update_type = mixed |
There was a problem hiding this comment.
FYI: mixed is not a valid update_type. It should be blank, %, or %y. In this case I expect it would be blank.
Ditto for the other cost inputs.
There was a problem hiding this comment.
All looks good @nairnamratha! Made some minor changes. One issue Ive found is that in local datasets, the maximum value of the sliders are scaled at the moment (in Antwerp for example, the maximum gas price a user can set is 10 euro). That should be fixed by: https://github.com/quintel/etengine/compare/non_scaleable_prices?expand=1.
| - label_query = Q(price_of_wood_pellets) | ||
| - query = | ||
| present_value = QUERY_PRESENT(-> {Q(price_of_wood_pellets)}); | ||
| relative_value = USER_INPUT() / present_value; |
There was a problem hiding this comment.
I also created variables in a query once, yet refrained from doing so. I'm still not sure where the balance in this case lies, maybe @antw has a stronger opinion in this case.
One side-note: what is the difference between:
QUERY_PRESENT(-> {Q(price_of_wood_pellets)});
and
present:Q(price_of_wood_pellets)
Doesn't this return the same thing?
There was a problem hiding this comment.
I first tried present:Q(price_of_wood_pellets) but it didn't work
There was a problem hiding this comment.
One side-note: what is the difference between:
QUERY_PRESENTandpresent:
present: is used as a prefix for the entire query, not a single expression.
For example:
Yes:
- start_value_gql = present: Q(price_of_wood_pellets)No:
- start_value_gql =
value = present: Q(price_of_wood_pellets) # ← syntax error
value * 10Nonetheless, I think...
QUERY_PRESENT(-> {Q(price_of_wood_pellets)})... can be simplified as ...
QUERY_PRESENT(price_of_wood_pellets)There was a problem hiding this comment.
I also created variables in a query once, yet refrained from doing so. I'm still not sure where the balance in this case lies, maybe @antw has a stronger opinion in this case.
This is personal opinion, but I would refrain from using variables unless they make a complex query much easier to read and understand. Variables are a quirk of GQL being implemented in Ruby rather than something which is officially supported. However, I doubt we'll ever do anything that causes variables to stop working, so... /shrug.
Here's how I would write the query:
UPDATE_WITH_FACTOR(
CARRIER(
biogas,
greengas,
torrified_biomass_pellets,
wood,
woody_biomass,
wood_pellets
),
cost_per_mj,
USER_INPUT() / QUERY_PRESENT(price_of_wood_pellets)
)
Changed slider LHS to show absolute fuel prices instead of percentage changes for natural gas, oil, coal, biomass and CO2 emissions.
Note: RHS (showing percentage change values) still needs to be fixed. Check #2622 for further reference.