Skip to content
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

Merged
merged 4 commits into from
Aug 5, 2024
Merged

Conversation

brynpickering
Copy link
Member

@brynpickering brynpickering commented Jul 25, 2024

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.

  • CHANGELOG updated
  • Minimal workflow tests pass
  • Tests added to cover contribution
  • Documentation updated
  • Configuration schema updated

Copy link
Member

@timtroendle timtroendle left a 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?

@@ -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)).
Copy link
Member

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?

Copy link
Member Author

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.


**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.
Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member

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?

Copy link
Member Author

@brynpickering brynpickering Jul 30, 2024

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).

Copy link
Member Author

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") }}
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Member Author

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]

Copy link
Member

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.

Copy link
Member Author

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.

@brynpickering
Copy link
Member Author

@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 biofuel.yaml, but then it needs a name that clearly distinguishes it (supply/electricity-from-biofuel.yaml, as a distinction from conversion/electricity-from-biofuel.yaml? Or supply/bio-electricity.yaml or similar?)

@timtroendle
Copy link
Member

I am not sure whether we should keep it, but if we do a name like supply/electricity-only-biofuel.smk may work?

@timtroendle
Copy link
Member

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.

@brynpickering
Copy link
Member Author

@timtroendle I've reorganised the techs slightly so that we have an electrified-biofuel.yaml module that can be used in place of biofuel.yaml and electricity-from-biofuel.yaml. They are drop in replacements for each other, so the objective function value is the same using either, but the latter would be used when introducing other uses for biofuel (e.g. heating).

@timtroendle timtroendle merged commit 331313c into develop Aug 5, 2024
4 checks passed
@timtroendle timtroendle deleted the separate-biofuel branch August 5, 2024 15:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Separate biofuel as a unique energy carrier
2 participants