levelized_cost parameter is empty

[Tyler-lc]

What happened?

I found that when we run
scenario.par("levelized_cost")
we get an empty data frame.
It is the same if we try to use the reporter:

lc = rep.get("levelized_cost")

AttrSeries([], Name: levelized_cost, dtype: float64), units: dimensionless

This problem happens across platforms (windows11, macos) and both with the pip install -e . and conda installations.
Currently, I am testing on windows 11, with message_ix 3.11 installed through conda-forge, while IXMP is 3.11.1 also installed through conda-forge.

The odd part is that, if I check the gdx output file in GAMS Studio, the levelized_cost parameter is actually populated with all the correct entries.

Code Sample

import message_ix
from message_ix import Scenario
import ixmp

mp = ixmp.Platform()
scen = Scenario(mp, "model", "scenario")

lc = scen.par("levelized_cost") # returns empty df

from message_ix.report import Reporter
rep = Reporter.from_scenario(scen)
lc_rep = rep.get("levelized_cost") # returns attrseries[]

What did you expect to happen?

Expected behavior

I would expect to the data in the first place appearing, possibly in a DF-like format, as the rest of the data retrieved through either scenario.par() or rep.get.().

Versions

ixmp:              3.11.1
message_ix:        0.0.0
message_ix_models: (not installed)
message_data:      (not installed)

click:             8.2.1
dask:              2025.5.1
genno:             1.28.2
graphviz:          (not installed)
ixmp4:             (not installed)
jpype:             1.6.0
     Java VM path: C:\Users\casamassima\.conda\envs\message_devs\Library\lib\jvm\bin\server\jvm.dll
openpyxl:          3.1.5
pandas:            2.3.1
pint:              0.25
xarray:            2025.8.0
yaml:              6.0.2

iam_units:         2023.9.12
jupyter:           5.8.1
matplotlib:        3.10.1
plotnine:          0.15.0
pyam:              1.6.0

GAMS:              50.4.0
       system dir: C:\GAMS\50

python:            3.13.5 | packaged by Anaconda, Inc. | (main, Jun 12 2025, 16:37:03) [MSC v.1929 64 bit (AMD64)]
python-bits:       64
OS:                Windows
OS-release:        2022Server
machine:           AMD64
processor:         Intel64 Family 6 Model 85 Stepping 6, GenuineIntel
byteorder:         little
LC_ALL:            None
LANG:              None
LOCALE:            ('English_United States', '1252')

Additional Context

No response

[khaeru]

Thanks for filing this!

A few thoughts:

• One relevant limitation is actually in ixmp:
  • The original JDBCBackend/Java ixmp_source supports:
    • Writing values for GAMS Parameters from the ixmp backend/database to the input GDX file, and
    • Reading values for GAMS Equations and Variables from the output GDX file to the ixmp backend/database. (This is why one can pass Scenario.solve(…, equ_list=[...], var_list=[...]) to customize the set of GAMS Equations and Variables read.)
  • In other words, the architecture is built around the idea that parameters are exogenous to the model: their values are determined before GAMS is invoked, and are not changed during the GAMS invocation.
  • The parameter values available through ixmp.Scenario after the .solve(…) call are thus identical to the values existing before the solve.
  • This is why values for a parameter like levelized_cost—not in the ixmp database or input GDX file—do not appear in the database after the model is solved.
• levelized_cost is exogenous: it does not depend on the model solution, only on the values of other parameters. This means its value can be determined before the model is solved, and even before GAMS is invoked.
• It only happens that the calculation is done in GAMS code. We can review the Git blame for those lines. My guesses would be that this was done for 1+ of the following reasons:
  • It was only imagined that this particular form of levelized_cost would be useful and relevant for the soft constraints, as described in the comments.
  • It was intended to reduce the work of the user/Python code, so that input data could be given without levelized_cost at all, and this would be automatically populated. This would be relevant e.g. for people running the MESSAGE GAMS code directly, with manually-constructed GDX input, and not through message_ix/ixmp.
• This suggests we could do 1 or more of the following:
  • Add Python code to message_ix that computes identical levelized_cost values for a given Scenario—whether it has been solved or not.
  • Actually store the above values in a Scenario and write them to the input GDX file to be used by the GAMS code.
  • Add either or both of these to the auto-populated contents of message_ix.Reporter.