Catalog and Metadata

This guide follows a benchmark-selection workflow: find candidates, interpret their static metadata, and construct an instance for an experiment. For the complete keyword list and function contracts, see filter_problems and get_problem_names in the API Reference.

Select candidates for an experiment

Suppose an experiment needs a ZDT problem with variable bounds and an analytical objective Jacobian. Query the catalog before constructing any instances:

julia> using MOProblems

julia> candidates = filter_problems(
           name_pattern = r"^ZDT",
           has_bounds = true,
           has_jacobian = true,
       )
5-element Vector{String}:
 "ZDT1"
 "ZDT2"
 "ZDT3"
 "ZDT4"
 "ZDT6"

These names identify candidates to investigate. The query checks registered properties; consult the ZDT family page for the formulations, bounds, constructor parameters, and derivative-domain restrictions before choosing one.

Interpret the catalog defaults

Inspect the ProblemMeta entry for ZDT1 in META:

julia> meta = META["ZDT1"];

julia> typeof(meta.dimension)
VariableNvar

julia> default_nvar(meta)
30

julia> default_nobj(meta)
2

The default has 30 variables and two objectives. Its VariableNvar specification means that the constructor can select a different number of variables while keeping the objective count fixed.

If the experiment is limited to ten variables, adding a numeric filter selects problems whose default instances meet that limit:

julia> small_defaults = filter_problems(
           name_pattern = r"^ZDT",
           has_bounds = true,
           has_jacobian = true,
           max_nvar = 10,
       )
2-element Vector{String}:
 "ZDT4"
 "ZDT6"

ZDT1 is absent because its default has 30 variables. This does not rule out using a smaller ZDT1 instance: the catalog query does not search the constructor's supported configurations.

Construct the chosen instance

The ZDT1 constructor accepts nvar >= 2, so it can still be used in the ten-variable experiment:

julia> prob = ZDT1(nvar = 10);

julia> prob.nvar
10

julia> prob.nobj
2

julia> default_nvar(meta)
30

The constructed instance has ten variables and two objectives; the catalog default remains 30 variables. Once constructed, each instance has fixed nvar and nobj fields. Continue with Evaluation and Derivatives to evaluate the chosen instance.

Obtain a box for an initial point

recommended_bounds returns a finite box that can be used to define a sampling region. For a problem with registered variable bounds, it returns those bounds. Otherwise, it returns a working box recommended by the package developers; this box is not part of the problem definition and does not modify prob.bounds.

A recommended working box specifies only coordinate intervals. It does not guarantee that every point satisfies the problem constraints, admits well-defined objective and derivative evaluations, or lies near the Pareto set. These properties must be checked separately when required by an experiment.

julia> using Random

julia> bounded = ZDT1();

julia> recommended_bounds(bounded) == bounded.bounds
true

julia> prob = Lov5();

julia> isnothing(prob.bounds)
true

julia> lower, upper = recommended_bounds(prob)
([-2.0, -2.0, -2.0], [2.0, 2.0, 2.0])

julia> rng = MersenneTwister(1234);

julia> α = rand(rng, prob.nvar);

julia> x = lower .+ α .* (upper .- lower);

julia> values = eval_f(prob, x);

julia> (length(x), length(values), all((lower .<= x) .& (x .<= upper)))
(3, 2, true)

Passing a problem name returns the box for the default dimensions. Passing an instance returns vectors compatible with prob.nvar, including supported non-default dimensions.

Apply the workflow to other families

For a study that varies problem size, use the dimension specification to identify which dimensions a family can change. The dimension_type keyword of filter_problems selects one of these categories:

The family documentation gives the constructor syntax and admissible parameter values for each candidate. A dimension category alone does not specify which sizes are valid.

Metadata availability also affects the selection of an experimental set. For example, a strict-convexity query excludes problems whose meta.strict_convexity is nothing, even when requesting false. Such an exclusion reflects unavailable information, rather than evidence about the objectives' convexity. See filter_problems for the precise predicates and ProblemMeta for the metadata representation.