You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GDX file generated by ixmp.JDBCBackend has a parameter named MESSAGE_ix_version with values like {"major": 2, "minor": 0}. The original intent of this was to aid with debugging when inspecting/comparing GDX files.
This has not been updated for recent MESSAGE versions, for multiple reasons:
It is a "stack level violation", in other words in the wrong place: ixmp (or its backends) should be agnostic to whether they are being used by message_ix or not; similarly, logic relevant to message_ix should be actually in message_ix.
The team lacks a Java developer capable of updating the code and the JAR file in ixmp.
We can use the code underlying show_versions() to generate a string with more informative version information (like " 3.7.1.dev55+g2e0a9c49"), and store this in a parameter.
This can be updated in message_ix.Scenario.solve().
The name should be something other than "MESSAGE_ix_version" (perhaps just "version"?) in order to avoid a collision with the (fixed) behaviour of the Java code.
The text was updated successfully, but these errors were encountered:
The GDX file generated by ixmp.JDBCBackend has a parameter named
MESSAGE_ix_version
with values like {"major": 2, "minor": 0}. The original intent of this was to aid with debugging when inspecting/comparing GDX files.This has not been updated for recent MESSAGE versions, for multiple reasons:
Raised by @volker-krey in the 2023-10-19 MESSAGEix meeting.
Fix
show_versions()
to generate a string with more informative version information (like " 3.7.1.dev55+g2e0a9c49"), and store this in a parameter.message_ix.Scenario.solve()
.The text was updated successfully, but these errors were encountered: