-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate biofuel supply; add biofuel boiler #419
Conversation
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
My only concern is the removal of the existing mechanism. This leads to the addition of at least one more carrier in all models that use biofuel. Do we know about the runtime and numerical scaling implications?
docs/model/customisation.md
Outdated
@@ -15,13 +15,13 @@ You have the following three options: | |||
With the Calliope model in your hands, you will be able to change any model parameter, any technology specifics, and the model definition to your liking. | |||
This kind of customisation can be useful to get to know the model and its parameters. | |||
To create reliable results, we advise making manual changes only to the model definition (`example-model.yaml`) as this makes it possible to trace those changes later. | |||
A typical customisation here would be to change the solver from `gurobi` to an open-source solver, e.g. `cbc` (see [Calliope's documentation](https://calliope.readthedocs.io/en/v{{ calliope_version }}/user/config_defaults.html#run-configuration)). | |||
A typical customisation here would be to change the solver from `gurobi` to an open-source solver, e.g. `cbc` (see [Calliope's documentation](<https://calliope.readthedocs.io/en/v{{> calliope_version }}/user/config_defaults.html#run-configuration)). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you briefly explain this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, that looks like it snuck in for some reason. It certainly doesn't look like it makes any sense to me.
docs/model/customisation.md
Outdated
|
||
**biofuel_boiler**: Biofuel-consuming boiler. | ||
|
||
**biofuel_tech_heat_to_demand**: Dummy technology to convert biofuel boiler output to a carrier that can be used to meet heat demand. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a unclear to me. Why is this a dummy technology?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it doesn't actually represent a "real" technology. It's just a modelling artefact to be able to have storage buffers per heat tech (this will be a non-issue when using calliope v0.7)
essentials: | ||
name: Electricity from anaerobically digested biofuel | ||
parent: conversion | ||
carrier_in: biofuel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to remove the old approach, meaning that it won't be possible anymore to avoid modelling biofuel explicitly. I am fine with as long as it doesn't impact performance much. Do you know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know about memory use, but runtime for building and solving the optimisation problem increases by ~3% (43.8s -> 45.1s) in a test I made (UK+IRL, 1yr @ 2hr resolution, using %timeit
magic).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, ran it again and it was the other way around. So, within margins of error, there is no change 😅
locs: [{{ id }}] | ||
techs: [biofuel_supply] | ||
carrier_prod_max: | ||
biofuel: {{ location.biofuel_potential_mwh_per_year * scaling_factors.power }} # {{ (1 / scaling_factors.power) | unit("MWh") }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line may be negative for numerical scaling as it introduces a fairly large number. Previously this was solved by applying the efficiency and assuming a 6 month use period, which reduced the number by ~factor 4.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Differences in ranges:
Before
[2024-07-30 17:51:46] DEBUG Matrix range [4e-05, 1e+02]
[2024-07-30 17:51:46] DEBUG Objective range [1e+00, 1e+00]
[2024-07-30 17:51:46] DEBUG Bounds range [1e-05, 2e+01]
[2024-07-30 17:51:46] DEBUG RHS range [8e-10, 2e+02]
After
[2024-07-30 18:04:13] DEBUG Matrix range [4e-05, 1e+02]
[2024-07-30 18:04:13] DEBUG Objective range [1e+00, 1e+00]
[2024-07-30 18:04:13] DEBUG Bounds range [1e-05, 2e+01]
[2024-07-30 18:04:13] DEBUG RHS range [8e-10, 1e+03]
So, yes, the RHS range increases by an order of magnitude.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure there is an equivalent way to handle that with biofuel as a separate carrier. I guess you just don't need carrier_prod_max
if you have an hourly resource
since that resource already effectively sets an annual value once it's all been added up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, so without the annual limit, it becomes:
[2024-07-30 18:25:14] DEBUG Matrix range [4e-05, 1e+02]
[2024-07-30 18:25:14] DEBUG Objective range [1e+00, 1e+00]
[2024-07-30 18:25:14] DEBUG Bounds range [1e-05, 2e+01]
[2024-07-30 18:25:14] DEBUG RHS range [8e-10, 5e+02]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But that would mean that biofuel must be burned whenever it's becoming available as a resource
, right? That wouldn't be ideal either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the resource per timestep just gives a quantity available. So long as force_resource
isn't set to True
it won't be forced to make use of it. It can also choose to make use of it but to store it instead of having it converted to electricity etc.
@timtroendle if we keep the existing approach as an option, how would you see it being included as a model file? It could be kept as its own module alongside |
I am not sure whether we should keep it, but if we do a name like |
I mean the numerical scaling is an issue, but then again, it didn't seem to affect your runs, right? So maybe we can get around it without keeping the original approach. |
@timtroendle I've reorganised the techs slightly so that we have an |
Fixes #417
Adds partial fix to #39
Checklist
Any checks which are not relevant to the PR can be pre-checked by the PR creator. All others should be checked by the reviewer. You can add extra checklist items here if required by the PR.