@@ -36,11 +36,11 @@ The Graph-Based Optimization Modeling Language (GBOML) is a modeling language fo
# Statement of need
Many planning and control problems (e.g., in the field of energy systems) can be formulated as mathematical programs. Notably, many models of practical interest can be viewed as collections of smaller models with some form of coupling between them. Such models display a natural block structure, where each block represents a small model.
Many planning and control problems (e.g., in the field of energy systems) can be formulated as mathematical programs. Notably, many models of practical interest can be viewed as collections of smaller models with some form of coupling between them. Such models display a natural block structure, where each block represents a small model or component.
Broadly speaking, two classes of tools can be used to implement such models, namely algebraic modeling languages (AMLs) and so-called object-oriented modeling environments (OOMEs). In short, AMLs typically allow users to compactly encode broad classes of optimization problems (e.g., mixed-integer nonlinear programs) while decoupling models and solvers. AMLs can be either stand-alone (e.g., GAMS [@GAMS] or AMPL [@AMPL]) or embedded in general-purpose programming languages, such as JuMP [@JuMP] (in Julia), Pyomo [@Pyomo] and PuLP [@PuLP] (in Python). They may also be open-source (e.g., JuMP, Pyomo and PuLP). On the other hand, OOMEs usually make it easy to construct instances of specific problems from pre-defined components. For instance, in the field of energy systems, established OOMEs include PyPSA (power flow calculations and capacity expansion planning) [@PyPSA], Calliope (multi-energy carrier capacity expansion planning) [@Calliope] or Balmorel (long-term planning and short-term operational analyses) [@Balmorel].
Unfortunately, both AMLs and OOMEs suffer from several drawbacks. More precisely, AMLs usually lack modularity, which we define as the ability to take advantage of problem structure for various purposes, including simplifying problem encoding, enabling model re-use, speeding up model generation (e.g., by parallelising it) and facilitating the use of structure-exploiting solution algorithms. Extensions to established AMLs were proposed to address the latter concern, such as StructJuMP [@StructJuMP], PySP [@PySP] and SML [@SML] (extending JuMP, Pyomo and AMPL, respectively). However, these extensions were usually designed with the primary aim of exposing very specific problem structures (e.g., dual block angular structures found in stochastic linear programming models). On the other hand, OOMEs typically lack expressiveness and adding components is often cumbersome. Furthermore, they very often rely on established AMLs themselves and thus automatically inherit any shortcomings of the AML on top of which they are built (e.g., it may not be open-source).
Unfortunately, both AMLs and OOMEs suffer from several drawbacks. More precisely, AMLs rarely provide language constructs to represent the block structure in a model and typically fail to take advantage of it, although this may be used to simplify problem encoding (e.g., by treating blocks as independent objects), enable model re-use (e.g., by allowing the import of model components), speed up model generation (e.g., by parallelising block generation) and facilitate the use of structure-exploiting solution algorithms. Extensions to established AMLs were proposed to address some of these concerns, such as StructJuMP [@StructJuMP], PySP [@PySP] and SML [@SML] (extending JuMP, Pyomo and AMPL, respectively). However, these extensions were usually designed with the primary aim of handling very specific problem structures (e.g., dual block angular structures found in stochastic linear programming models). On the other hand, OOMEs typically lack expressiveness and adding components is often cumbersome. Furthermore, they very often rely on established AMLs themselves and thus automatically inherit any shortcomings of the AML on top of which they are built (e.g., it may not be open-source).
The tools that appear closest in spirit to our own are the recent SMS++ modeling framework [@SMSpp] and Plasmo.jl [@Plasmo] (an extension of JuMP). The former makes it possible to implement fairly general block-structured models and aims to ease the development and deployment of advanced structure-exploiting algorithms. The latter relies on a graph abstraction of optimization models to enable modular model construction, partitioning and the use of structure-exploiting algorithms.
...
...
@@ -106,7 +106,7 @@ Then, the command-line interface or the Python API may be used to generate the m
Finally, results are retrieved and can be either printed to file or used directly in Python. Two file formats are supported at the time of writing, namely CSV and JSON.
The full GBOML syntax is described in the online documentation, along with advanced features such as model imports and hierarchical model construction as well as solver options. The data files required to run the example above are available in the GBOML repository.
The full GBOML syntax is described in the online documentation, along with advanced features such as model imports and hierarchical model construction as well as solver options. The files required to run the example above are available in the GBOML repository.
