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 GDX file generated by ixmp.JDBCBackend has a parameter named
MESSAGE_ix_versionwith 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().