SIMUS (Sequential Interactive Model for Urban Systems)

SIMUS is a method for ranking alternatives once you hold a numerical decision table, but it takes a different route from most other ranking methods. It performs no weighted sum and no distance calculation; instead it picks one criterion at a time as "the objective to optimise this round," treats every other criterion as a constraint, and builds and solves a linear programming problem from that. As many separate linear programming problems are solved as there are criteria. Each solution yields how much "share" the alternatives take on that criterion; once these shares are gathered and summed, the alternatives' final scores and ranking emerge. Nolberto Munier developed it for multi-criteria decision-making in urban and environmental projects and set it out in detail in his 2011 book.

SIMUS's underlying idea is that criteria in real decisions usually conflict with one another: raising quality while a budget constraint holds, or improving safety while shortening the schedule. SIMUS takes on this conflict directly, in the language of linear programming. While optimising one criterion, it requires every other criterion to stay at least at its average level; this is the mathematical counterpart of "let me improve on one criterion without writing off the rest." Each criterion takes its turn playing this "objective" role, so no criterion is treated as privileged from the outset.

This idea carries a philosophical consequence: SIMUS asks for no weights, because each criterion's relative importance already emerges from how tight its constraints are, that is, from the structure of the data itself. In decisions where resources (budget, time, capacity) must be allocated mathematically, project-portfolio selection for instance, SIMUS's linear-programming foundation fits naturally; where criteria carry no such resource-sharing relationship, the method's strength goes unused.

The method proceeds through six steps.

First, reading the decision table and the criterion directions. For every criterion, "more is better" or "less is better" is established.

Second, building and solving a separate linear programming problem for each criterion. One criterion is chosen as the objective in turn: the best distribution of shares among the alternatives is sought with respect to that criterion. Every other criterion becomes a constraint: it must not fall below its average level. The shares given to the alternatives are bounded so that they sum to one or less. This mathematically enforces the rule of "seeking the best on one criterion without sacrificing the others too badly." This operation is repeated for every criterion; for a problem with n criteria, n separate linear programming problems are solved.

Third, gathering the results into one table. The alternatives' shares from each criterion's solution are placed side by side; this table is called the "effective results matrix."

Fourth, taking row sums. Every alternative's shares across all criteria are summed; this sum is the alternative's overall score.

Fifth, pairwise dominance counting. SIMUS additionally compares every pair of alternatives criterion by criterion and counts on how many criteria one outperforms the other; this provides a cross-check alongside the row sum.

Sixth, ranking. Alternatives are ordered from the highest to the lowest total score from the fourth step.

DecisionMind implements these six steps with a standard linear programming solver and fixes the constraint structure (no criterion may fall below its own average) in place. The formulas behind each step, the intermediate tables and the citation formats are given on the DecisionMind method page; this card carries no formulas.

SIMUS's score shows how much total share an alternative gains once every criterion has taken its turn as the objective. This score is not a percentage or a probability; it is meaningful only for this particular alternative set and this constraint structure. An alternative taking no share on some criterion (a share of zero) does not mean it is "bad" on that criterion; it means that, when that criterion is the objective, other alternatives sit in a more advantageous position within the linear programming solution.

Thus instead of writing:

"SIMUS calculated the most efficient alternative"

the report should read:

"With this constraint structure (each criterion required to stay at or above its average), this is the alternative taking the highest total share; the share distribution varies from criterion to criterion"

SIMUS works with crisp data: one number per cell. DecisionMind currently offers no fuzzy, grey or other data-type extension of SIMUS; the method is presented in a single form.

You need alternatives in rows, criteria in columns, one number per cell, no empty cells, and direction information for every criterion. SIMUS asks for no external weight; even if one is entered, it is not used in the calculation, because the method derives the relative priority between criteria from the constraint structure of the linear programme itself. Since the linear programme is solved separately for each criterion, the computational load rises as the number of criteria grows, but modern solvers handle this quickly. A minimum of two alternatives and two criteria is required.

SIMUS is a suitable choice if your decision involves a genuine resource conflict between criteria (situations where progress on one criterion requires giving up something on another) and you would rather handle this conflict directly, through a mathematical constraint structure, than by setting weights. Its typical territory includes urban infrastructure, environmental project selection, and portfolio decisions that require resource sharing.

It should not be used where no such resource conflict exists between criteria and only a simple preference ranking is sought; SIMUS's linear-programming machinery brings needless complexity there. The requirement not to fall below the average can also turn into a very tight constraint on some tables and produce an infeasible problem; when that happens, the constraint structure needs to be reviewed.

A genuine resource conflict between criteria, resource sharing → SIMUS

A simple preference ranking, weights available or easily calculated → TOPSIS, SAW, VIKOR

Weights wanted from expert opinion or from the data → AHP, BWM, SWARA (subjective); Entropy, CRITIC (objective)

Constraints come out infeasible → the constraint structure (the average threshold) should be reviewed

SIMUS's greatest strength is that it models the trade-off between criteria directly, in the exact language of linear programming; this gives a mathematical basis to the question of how much is given up on criterion B to gain on criterion A. Because it asks for no weights, it removes the subjective-weight debate altogether. It also offers pairwise dominance counting alongside the row sum, allowing the result to be cross-checked from more than one angle.

Its limitations stem from the method's linear-programming foundation. First, if the constraints are too tight (as in tables with many criteria and few alternatives), the linear programming problem can come out infeasible, in which case the method produces no result. Second, the result is sensitive to the alternatives' scale magnitude; if the criteria's raw values sit at very different orders of magnitude, the shares can drift unexpectedly towards a single criterion, so the comparability of scales should be checked beforehand. Third, the method's literature rests largely on its founder's own publications; independent testing by other researchers across different data sets is more limited than for other established methods such as TOPSIS or AHP. Fourth, its six-step structure is more elaborate than that of other ranking methods, and explaining the result to a decision-maker takes more effort.

The most common mistake is feeding SIMUS the criteria's raw values when their scales differ greatly; a large-scale criterion (a budget figure in the thousands, say) can pull the linear programming solution in its own favour. A second mistake is entering an external set of weights and assuming SIMUS will use it; the method disregards weights. A third is forcing a result out of an infeasible linear programme instead of asking why the constraint structure does not fit this table. A fourth is reading the row-sum score as a percentage and comparing it across different analyses.

The governing principle is this:

A SIMUS ranking is a summary of how the resource conflict between criteria has been resolved through linear programming; if the scales are not comparable or the constraints prove infeasible, the result is not reliable.