Skip to contents

Development status and roadmap

Source: vignettes/articles/roadmap.Rmd
roadmap.Rmd

multimod 0.5.0 is the first CRAN release. Function signatures and class structures may still change between minor versions, and the NEWS file records every such change. This page lists what the release does not do yet, and the order in which the gaps are to be closed. What it does is in the README’s capability table and in the articles.

Limitations in 0.5.0

  • Model class. Linear programs with continuous variables are the tested path. Integer and binary variables are carried in the AST and written by the JuMP and Pyomo writers; nonlinear expressions have AST nodes but no tested route to a solver.
  • Readers. read_gams() covers the linear subset of GAMS that energy system templates use: sets and subsets, aliases, parameters, $ conditions, sum/prod, ord/card, smax/smin. It does not read TABLE data, loop or if blocks, or macros. read_gmpl() reads MathProg model files with data sections, computed parameters and parametric defaults. It does not yet read set expressions in declarations, a set of tuples declared as set S within A cross B (it is read as one-dimensional), a tuple condition such as (t,r) in S inside an iterated operator, or two-dimensional parameter data in list form (param p := a x 1 b y 2;). JuMP is read one constraint at a time — mm_equation(lang = "jump") takes a @constraint() statement — not as a whole model. There is no Pyomo reader.
  • Writers. write_gams_data(), which writes a GDX through the ‘gdxtools’ package, is experimental and has not been tested with the current ‘gdxtools’ release. write_gams() output has not been compiled with a licensed GAMS installation. write_pyomo(data_mode = "embedded") is not implemented and falls back to the external loader.
  • Matrix route. A symbol declared over plain sets, with no domain mapping, is expanded over their cross product; an equation restricted by a condition contributes the rows that satisfy it; lags and leads resolve by position in the set, linear unless declared circular; parameters defined by a formula are computed. A circular lag has no syntax in MathProg, JuMP or Pyomo, so those writers refuse it rather than flatten it.
  • Experimental exports. Functions grouped under “Experimental” in the reference index (as_r(), the compare_*() helpers, visualization, the granular storage functions, configuration file writers) are exported but have no tests yet.

Next

0.5.x

  • An opt-in streaming write_mps() that writes the matrix to disk as it is assembled, so a large model is not held in memory as a whole.
  • The four SC2_*/SC4_* storage-bracket equations of OSeMOSYS assemble with no coefficients; the cause is to be established.
  • read_gmpl(): sets of tuples declared with within ... cross, tuple conditions in iterated operators, and two-dimensional list data.
  • write_gams() output verified with a GAMS installation, including ord() for a set element used in arithmetic.
  • Replace the remaining cat() diagnostics with message() so they can be silenced.
  • Tests for the experimental exports, or their retirement.

0.6 to 0.8

  • API consolidation: one argument vocabulary across the write_*() and solve_*() families, consistent return values, fewer exported helpers.
  • The matrix route as the default for linear problems; the symbolic writers remain for interoperability, inspection and documentation.
  • Row and column names in the written MPS as an option.
  • read_gmpl(): set expressions in declarations.
  • Larger GAMS coverage: TABLE data, loop blocks.

1.0

  • Stable API.
  • Readers and writers for GAMS, MathProg, JuMP and Pyomo at the level the energy system models need, each verified against a reference objective.

Later

  • A native C++ or Rust core with R, Python and Julia interfaces to the same AST and JSON schema.
  • AMPL reader and writer; LP and MPS readers.
  • Symbolic simplification of equations; redundancy detection with safeguards; data-driven generation of domain mappings.
  • Direct solver APIs without files in between.
  • An interactive model explorer and equation dependency graphs.

Scope

multimod does not aim to translate every model automatically. It keeps a transparent intermediate representation that a modeler can read, adapt and re-render: the symbolic structure is there to be edited by hand during development, testing and teaching, and to be documented exactly as solved.

Contributing

Issues and pull requests are welcome at github.com/optimal2050/multimod. The most useful contributions today are models that break a reader, test cases for the experimental functions, and reports from platforms the authors do not use.