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

Support for emissions associated with transmissions #9

Open
trulsf opened this issue Feb 27, 2024 · 2 comments · Fixed by #26
Open

Support for emissions associated with transmissions #9

trulsf opened this issue Feb 27, 2024 · 2 comments · Fixed by #26
Labels
enhancement New feature or request

Comments

@trulsf
Copy link
Contributor

trulsf commented Feb 27, 2024

There is currently no support for modeling the emissions associated with the transmissions. This is especially relevant if the transmission represents an underlying transport using e.g. trucks or ships.

As an initial attempt to show how this may be implemented, I have made a first version which can be found here:
https://github.com/EnergyModelsX/EnergyModelsGeography.jl/tree/feature/emission

To get these emissions into the total emissions as modeled in EnergyModelsBase.jl, I use a slightly "hacky" solution where the constraint coefficients are modified directly based on the name of the constraint. This require a slightly modifed version of EnergyModelsBase (https://github.com/EnergyModelsX/EnergyModelsBase.jl/tree/test/emission) and should not be considered as a more permanent solution.

@trulsf trulsf added the enhancement New feature or request label Feb 27, 2024
@JulStraus
Copy link
Member

We are currently evaluating to redefine TransmissionModes as

abstract type TransmissionMode <: EMB.Link

and add the potential for Links to have associated variable creation and potential for emissions using a similar functionality as we have through the function has_emissions(n::Node) . This would solve the problem for TransmissionMode, but may not be a general solution to include, e.g., emissions from investments.

At the time being, I would suggest to keep the "hacky" solution until we are able to identify a generalized solution that is sufficiently flexible for all potential changes. The current solution allows for easy rebase of the branch when a new version is released, but unfortunately not to use a registered version.

@JulStraus
Copy link
Member

Reopened to keep it up for discussing approaches for an improved inclusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants