Introducing MOSOX - A simpler route from model to solution
Mark Howells
glpsol and used less peak memory on the largest case.set PLAYERS := 1..7;
/* Abilities: Assisting, Throwing, Rebounding, Defense */
param A{PLAYERS}; param T{PLAYERS}; param R{PLAYERS}; param D{PLAYERS};
/* Decision variable: 1 if player plays, 0 otherwise */
var y{i in PLAYERS} binary;
/* Objective: Maximize total defensive ability */
maximize total_defense: sum{i in PLAYERS} D[i] * y[i];
/* Constraints */
s.t. five_players: sum{i in PLAYERS} y[i] = 5;
/* Position constraints based on player capabilities */
s.t. backfield: y[1] + y[3] + y[5] + y[7] >= 3;
s.t. frontfield: y[4] + y[5] + y[6] + y[7] >= 2;
s.t. midfield: y[2] + y[3] + y[4] + y[6] >= 1;
/* Average ability constraints (Avg >= 2 across 5 players) */
s.t. avg_assist: sum{i in PLAYERS} A[i] * y[i] >= 10;
s.t. avg_throw: sum{i in PLAYERS} T[i] * y[i] >= 10;
s.t. avg_rebound: sum{i in PLAYERS} R[i] * y[i] >= 10;
/* Logical constraints */
s.t. exclusivity: y[3] + y[6] <= 1; /* If 3 plays, 6 cannot */
s.t. requirement_4: y[1] <= y[4]; /* If 1 plays, 4 must play */
s.t. requirement_5: y[1] <= y[5]; /* If 1 plays, 5 must play */
s.t. mandatory_choice: y[2] + y[3] >= 1; /* Either 2 or 3 must play */
data;
param A := 1 3 2 2 3 2 1 1 3 2 3 6 3 7 3;
param T := 1 3 2 1 3 3 4 3 5 3 6 1 7 2;
param R := 1 1 2 3 3 2 4 3 5 1 6 2 7 2;
param D := 1 3 2 2 3 2 4 1 5 2 6 3 7 1;
end;
Joint Director STEER Centre, Loughborough University
Robbie Morrison
Close-to-maths or close-to-semantics?
Hello Mark, all
Thanks for the MOSOX update.
There is a philosophical debate as to whether energy system models would be better formulated as close‑to‑maths or close‑to‑semantics.
Neither paradigm is necessarily superior but each offers different features, advantages, and possibilities.
Several models have opted to use algebraic modeling languages (AML) (normally GAMS or MathProg), the best known of which is OSeMOSYS. Mark described this approach as close‑to‑maths in his original posting.
The MOSOX pre‑print (Arderne et al 2026) advocates for close‑to‑maths and readers should review the arguments presented there in favor.
Framework architectures based on object‑oriented programming usually employ a solver interface abstraction (Pyomo, Linopy, JuMP, custom), examples here include xeona, PyPSA, and oemof. I am going to label this approach as close‑to‑semantics.
The AML programming paradigm offers classical optimization, simplicity, inspectability, and mathematical clarity, as the MOSOX example provided earlier demonstrates (this code should also be legal MathProg).
The close‑to‑semantics paradigm can support everything that MILP programming can offer plus more. The paradigm draws naturally on established semantic standards such as the Open Energy Ontology (OEO). The coding overhead for these frameworks (written in C++, Python, Julia) is vastly higher than constructing an AML model. But the resulting modular architecture allows for simplified model construction, integrity tests on model instantiation and during runtime, and the most important technical aspect for me, individual components can be unit tested and signed off. Thus, sophisticated engineering can be embedded, confirmed correct, and made available in class hierarchies (examples include dedicated busses, gas turbines, refrigeration machines, and simplified building stock). The paradigm lends itself to extended strategies, including hybrid agent‑based modeling and prompted user engagement during runtime.
The model building overhead between the two paradigms might be roughly similar — indeed that comparison would make for an interesting case study.* The close‑to‑semantics approach is perhaps also better suited to GUI developments such as drag‑and‑drop model building.
The role of ontologies is significant. A key reason for developing sets of interoperable ontologies is to support domain‑specific knowledge graphs, populated with conformant data. I would argue that the close‑to‑semantics paradigm readily aligns with this emerging data ecosystem because both share similar underlying semantic disciplines and structures.
Users should think carefully about which paradigm they select in light of their given research questions and objectives and the kind of systems they intend to study. Both paradigms have pluses and minuses. Both have and can play valuable roles.
The aging GLPK project, which introduced the MathProg algebraic modeling language, has not released an update for almost six years. I suspect the entire project is spent. At least the GLPK solver certainly is. MOSOX, with its MIT license, represents a valuable addition to the MILP programming space. The legacy MathProg translator glpsol, written in ANSI standard C and extensively tested, will doubtless continue to compile and run for many years without maintenance. BTW, I was a member of the GLPK project for eight years and am also credited in the GLPK MathProg manual (Makhorin 2016:74).
Note * : OSeMOSYS and oemof were recently compared in an unpublished masters thesis (but I have not seen a copy).
Thoughts anyone?
best, Robbie
--
You received this message because you are subscribed to the Google Groups "openmod initiative" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openmod-initiat...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openmod-initiative/DB7PR04MB44093EB6B36BE6A9CDD1ED8FF8FA2%40DB7PR04MB4409.eurprd04.prod.outlook.com.
-- Robbie Morrison Address: Schillerstrasse 85, 10627 Berlin, Germany Phone: +49.30.612-87617
Mark Howells
Sent: 16 July 2026 19:13
To: openmod-i...@googlegroups.com <openmod-i...@googlegroups.com>
Cc: Mark Howells <M.I.H...@lboro.ac.uk>
Subject: Re: [openmod-initiative] Introducing MOSOX - A simpler route from model to solution
** THIS MESSAGE ORIGINATED OUTSIDE LOUGHBOROUGH UNIVERSITY **
** Be wary of links or attachments, especially if the email is unsolicited or you don't recognise the sender's email address. **