Skip to content

Adjust to EMGUI v0.6.0 #21

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.

Sign up for GitHub

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

Merged
JulStraus merged 8 commits into from
Dec 17, 2025
Merged

Adjust to EMGUI v0.6.0 #21

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
226361d
Adjust to EMGUI v0.6.0
Dec 14, 2025
67f7d7b
Fix formatting
Dec 16, 2025
12f7606
skip GUI-related imports/tests until Makie enables headless CI runs f…
Dec 16, 2025
c9e0e25
Add suggestions from review
Dec 16, 2025
0ab4ac0
Move EMGUI to a weak dependency in an attempt to resolve CI
Dec 16, 2025
827dbcc
Enable simple test runs locally
Dec 16, 2025
3e40d8c
Skip EMGUI related tests for now.
Dec 16, 2025
fb2ab87
Add suggestion from review
Dec 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Project.toml
View file
Open in desktop

@JulStraus JulStraus Dec 17, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a problem in the changes in the Project.toml: The way the weak dependency is introduced does not make sense. Without specifying an extension, there is not point to specify a weak dependency as outlined in the Pkg documentation.

As the EMGUI extension does not provide new code (only the YAML file), I would suggest removing the weak dependency. Note that I will not allow for EMGUI in the CI test set anyhow (as tested out in, e.g., 226361d) as loading the package takes too long.

@Zetison Zetison Dec 17, 2025

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If deps for EMGUI is removed there will be an error with EMGUI v0.5* versions, and in this sense this would be a breaking change?

@JulStraus JulStraus Dec 17, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit of a hen and egg problem, I see it now. That implies it requires a more thorough thought process how we handle it.

In theory, if we provide the file here, we need to have the version number regarding EMGUI to limit the application to the latest version to which it is compatible. In this case, we would see EMGUI as one of the core packages to which all other are dependent. The disadvantage is that if there are changes in the files in EMGUI, we would need to adjust all packages (as it is the case here right now)

The alternative is that all names are included in EMGUI for the supported packages of the EnergyModelsX organization. In this situation, we unfortunately would require changes in EMGUI for changes in the individual packages which is neither beneficial. We would also require a dependency for each package to limit its applicability to a given version.

I would still argue to remove the compatibility. We did not have a limitation beforehand for v0.5. As a consequence, it is possible to use 0.1.3 (the version before this) with EMGUI v0.6.0. If people update their package versions with pgk> update, they will anyhow update to the latest version of both. In the second case of having either of the package cloned or downloaded, the compatibility in EMHeat does not change the picture.

Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
name = "EnergyModelsHeat"
uuid = "ad1b8b27-e232-4da9-b498-bea9c19a30d7"
authors = ["Lars Hellemo, Hanne Kauko, and Till Holmes"]
version = "0.1.3"
version = "0.1.4"

[deps]
EnergyModelsBase = "5d7e687e-f956-46f3-9045-6f5a5fd49f50"
Expand Down
47 changes: 25 additions & 22 deletions ext/EMGUIExt/descriptive_names.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,27 +1,30 @@
# This file contains descriptions of EnergyModelsHeat-structures and variables
# with fields of type TimeStruct.TimeProfile
# with fields of type TimeStruct.TimeProfile and fields that cannot be inherited
# from supertypes.
structures:
HeatPump:
cap: "Installed capacity"
t_source: "Temperature profile of the heat source"
t_sink: "Sink temperature of the condensator"
eff_carnot: "Carnot Efficiency"
opex_var: "Variable operating expense per energy unit produced"
opex_fixed: "Fixed operating expense per installed capacity"
ResourceHeat:
t_supply: "Supply temperature in °C"
t_return: "Return temperature in °C"
DHPipe:
cap: "Heat transport capacity of the pipe"
t_ground: "Ground temperature in °C"
HeatExchanger:
cap: "Installed capacity"
opex_var: "Variable operating expense per energy unit produced"
opex_fixed: "Fixed operating expense"
DirectHeatUpgrade:
cap: "Installed capacity"
opex_var: "Variable operating expense per energy unit produced"
opex_fixed: "Fixed operating expense"
EnergyModelsHeat:
## link.jl
DHPipe:
cap: "Heat transport capacity of the pipe"
t_ground: "Ground temperature in °C"

## node.jl
HeatPump:
t_source: "Heat source temperature"
t_sink: "Heat sink temperature"
eff_carnot: "Carnot Efficiency"

## resource.jl
ResourceHeat:
t_supply: "Supply temperature in °C"
t_return: "Return temperature in °C"

PinchData:
T_SH_hot: "Hot temperature of surplus heat source in °C"
T_SH_cold: "Cold temperature of surplus heat source in °C"
ΔT_min: "Minimum temperature difference between surplus source and DH network in °C"
T_DH_hot: "Hot temperature of district heating network in °C"
T_DH_cold: "Cold temperature of district heating network in °C"

# Add description for all JuMP variables using a TimeStruct.TimeProfile type
variables:
Expand Down