SolutionSet class

The SolutionSet class stores the result of solving a Problem object.

A SolutionSet object is the standard result object returned by solve. It may contain a single solved run, as in ordinary single-objective optimization, or multiple solved runs, as in weighted-sum, $\epsilon$-constraint, or AUGMECON workflows.

The object stores the original problem, run-level design and outcome tables, objective values, diagnostics, method metadata, and additional metadata needed to inspect, compare, and analyse optimization results.

Value

No return value. This page documents the SolutionSet class.

Details

Conceptual role

The SolutionSet class represents the result of a solving workflow:


Problem -> solve() -> SolutionSet

Single-objective workflows are represented as SolutionSet objects with one run. Multi-objective workflows are represented as SolutionSet objects with one or more runs generated by the selected method.

This design provides a common result structure for downstream analysis, including objective-value extraction, run diagnostics, trade-off analysis, Pareto-frontier summaries, distance-based ranking, and comparison between scenarios.

Typical use cases

A SolutionSet is used to inspect and analyse the results returned by solve. Typical use cases include:

inspecting selected planning units or actions;
extracting run-level objective values;
comparing alternative solutions produced by a multi-objective method;
analysing trade-offs between objectives;
filtering feasible, unique, or non-dominated solutions;
computing distances to observed ideal or nadir points;
preparing plots and tables for reporting.

Internal structure

A SolutionSet object separates information into several layers:

problem: The Problem object used to generate the solution set.
solution: A named list containing the core solving outputs. This typically includes the run design, the run summary table, and the stored run-level solution objects used internally by multiscape.
summary: A named list containing user-facing summaries aggregated across runs when such summaries are available.
diagnostics: A named list containing diagnostics about the solution set as a whole.
method: A named list describing the optimization method used.
meta: A named list containing additional metadata.
name: A character(1) identifier for the solution set.

Run-level content

The solution field is the main internal container for run-level information. Typical entries include:

design: A data.frame describing the optimization design. In multi-objective workflows this may include weights, $\epsilon$-levels, or other method-specific parameters. In single-objective workflows this table usually contains one row.
runs: A data.frame summarizing the outcome of each run. This typically includes run identifiers, solver status, runtime, optimality gap, objective values, and method-specific information.
solutions: A list of stored run-level solution objects used internally by multiscape. Users should normally rely on accessor functions rather than directly manipulating this list.

In most workflows, the runs table is the most useful compact representation of the solution set. Detailed inspection should preferably be done through accessor functions such as get_pu, get_actions, get_features, and get_targets.

Objective values and run tables

The run table may store objective values in columns named value_<alias>, where <alias> is the alias of a registered objective. For example:

value_cost,
value_frag,
value_benefit.

This convention provides a compact format for downstream functions that analyse trade-offs, frontiers, or distances between solutions.

Depending on the solving method, the run table may also contain design columns such as:

weight_<alias> for weighted-sum runs;
eps_<alias> for $\epsilon$-constraint or AUGMECON runs.

Single-objective and multi-objective results

solve() always returns a SolutionSet. For a single-objective problem, the returned object contains one run. For a multi-objective workflow, the returned object contains one or more runs generated by the selected method.

This unified output structure makes it possible to use the same inspection and analysis functions regardless of whether the original problem was single-objective or multi-objective.

Diagnostics

The diagnostics field stores metadata about the solve process. Depending on the workflow, it may summarize:

number of design rows;
number of attempted runs;
number of stored solutions;
status frequencies;
runtime ranges;
gap ranges;
and other aggregate information about the set of runs.

Printing

The print() method provides a concise summary of the solution set. It reports:

the optimization method and participating objective aliases;
the run-design type when this information is available;
the number of design rows, attempted runs, stored solutions, and runs without a stored solution;
run-level status, runtime, and optimality-gap summaries;
the observed range of each objective across stored solutions;
and any filtering, uniqueness, or append metadata already recorded in the object.

Printing does not calculate non-dominance, uniqueness, similarities, selection frequencies, or distances. These analyses are intentionally kept outside the print method so that printing remains fast and does not depend on optional packages.

This printed output is intended as a quick overview. Detailed inspection should use public accessor and analysis functions such as get_runs, get_objectives, solution_filter, and frontier_distances.

Fields

problem: The Problem object used to generate the solution set.
solution: A named list containing the core solving outputs, typically including design, runs, and internally stored run-level solutions.
summary: A named list containing user-facing summaries associated with the solution set.
diagnostics: A named list containing diagnostics about the solution set as a whole.
method: A named list describing the optimization method used.
meta: A named list of additional metadata.
name: A character(1) name for the solution set object.

Methods

print(): Print a concise summary of the solution set, including method name, number of runs, and run-level diagnostics.
show(): Alias of print().
repr(): Return a short one-line representation of the solution set.
getMethod(): Return the method specification stored in self$method.
getDesign(): Return the design table stored in self$solution$design.
getRuns(): Return the run summary table stored in self$solution$runs.
getSolutions(): Return the internally stored run-level solution objects. This is mainly intended for advanced use; most users should prefer higher-level accessor functions.

Value

Details

Fields

Methods

See also