• IO Reference
• • Shared Input
  • generate_alternatives_optimization!
  • generate_alternatives_sweep!
  • generate_alternatives_arclength!
  • generate_alternatives_metaheuristics
  • Modeling Methods
  • Output

IO Reference

This page lists every argument accepted by each alternative-generation function, and the structure they all return. See How to use for a quick-start guide, and Concepts for the theory behind each modeling method and generation strategy.

Shared Input

These arguments are shared by all four functions:

• model: The solved JuMP model for which alternatives are generated. When using optimization, the solver already attached to model also performs the alternative-generating solves.
• optimality_gap: The maximum relative deviation an alternative's objective value may have from the optimum. A gap of 0.5 means an alternative's objective value may deviate at most 50% from the optimal value found when solving model.
• fixed_variables::Vector{VariableRef} = []: Variables that must keep their optimal value when searching for alternatives.
• metric::Distances.SemiMetric = SqEuclidean(): The distance metric used to measure diversity between alternatives (and, for :Max_Distance, between an alternative and the optimum). Must be a SemiMetric from Distances.jl. Some metrics may not be usable with a given solver when generating alternatives via optimization; any metric is usable with a metaheuristic.

generate_alternatives_optimization!

Finds one alternative per direction. See Single Point per Direction.

• variables: The variables of model considered when generating alternatives.
• n_alternatives: The number of alternative solutions to find.
• modeling_method::Symbol = :Max_Distance: The method used to pick each direction. See Modeling Methods below.
• weights = zeros(length(variables)): Initial direction weights, accumulated in place by some modeling methods (e.g. :Spores).
• reconfigure_solver!::Union{Nothing,Function} = nothing: An optional model -> nothing callback, invoked once after alternative #1 is found. Use it to switch the attached solver's algorithm (e.g. barrier to primal simplex) so alternatives #2 onward warm-start from alternative #1's basis instead of solving cold. The callback should only set solver attributes; the function itself handles the mandatory re-solve. Ignored when n_alternatives == 1. See the warm-starting tutorial for a full worked example.

generate_alternatives_sweep!

Returns a dense near-optimal front per direction instead of a single point. See Budget Sweep.

• variables: The variables of model considered when generating alternatives.
• n_directions: The number of search directions to discover and sweep.
• n_budget::Int64 = 6: The number of cost levels per direction, evenly spaced strictly inside the near-optimal region (the cost-optimal face itself is never sampled).
• modeling_method::Symbol = :Spores: The method used to pick each direction. See Modeling Methods below.
• weights = zeros(length(variables)): Initial direction weights, accumulated in place by some modeling methods.
• warm_start::Bool = false: When true, seed each solve from the previous budget level's solution (variable primal starts and constraint dual starts). Useful for solvers that exploit warm starts (e.g. simplex, first-order/ADMM methods); leave false for interior-point solvers that ignore or dislike start values (e.g. Gurobi/HiGHS barrier).

generate_alternatives_arclength!

Like the budget sweep, but spaces points evenly along the trade-off curve instead of the budget axis. See Arclength Continuation.

• variables: The variables of model considered when generating alternatives.
• n_directions: The number of search directions to discover.
• n_budget::Int64 = 6: The number of points placed per direction (>= 2; the two budget endpoints are always solved first).
• modeling_method::Symbol = :Spores: The method used to pick each direction. See Modeling Methods below.
• weights = zeros(length(variables)): Initial direction weights, accumulated in place by some modeling methods.
• reconfigure_solver!::Union{Nothing,Function} = nothing: An optional model -> restore! callback, applied once per direction, immediately after that direction's first point succeeds. Use it to switch the solver's algorithm (e.g. barrier to dual simplex) so the rest of that direction's points warm-start off the resulting basis. It should return either nothing, or a model -> nothing closure that restores the original config; that closure is applied at the start of the next direction. See the warm-starting tutorial for a full worked example.

generate_alternatives_metaheuristics

Finds alternatives using a metaheuristic algorithm instead of mathematical optimization.

• n_alternatives: The number of alternative solutions to find.
• metaheuristic_algorithm: The algorithm used to find alternatives. Can be any algorithm from Metaheuristics.jl, or PSOGA, the algorithm developed in this package. The former are repeated iteratively to find multiple alternatives; PSOGA generates all of them concurrently.

Modeling Methods

The modeling_method argument (accepted by generate_alternatives_optimization!, generate_alternatives_sweep!, and generate_alternatives_arclength!) selects how the next search direction is chosen. See Optimization-based Methods for the theory behind each.

Output

All four functions return an AlternativeSolutions, with fields:

• solutions: A vector of dictionaries mapping each VariableRef in model to its value, one dictionary per alternative found.
• objective_values: A vector of the original objective value of each alternative.
• tags: A vector of NamedTuples with per-alternative metadata. Empty for generate_alternatives_optimization! and generate_alternatives_metaheuristics. For generate_alternatives_sweep!, each entry is (direction, budget_idx, budget_level, diversity_objective, solve_time). For generate_alternatives_arclength!, each entry is (direction, budget_idx, budget_level, gap, diversity_objective, solve_time). In both cases, budget_idx is the point's placement order within its direction, and diversity_objective is the optimal value of the diversity objective at that point — plot it against objective_values to see the near-optimal front for each direction.