Define an experiment

Define is the first step in PM Optimizer, where you lay out the experiment: what to vary, what to measure, and what best means.

One model, many experiments

The list on the left holds every experiment saved with this model. Each one is independent, with its own factors, responses, and goal, so you can keep a quick screening study next to a full optimization and switch between them. Use New Experiment to start another, and the pencil, copy, and trash icons to rename, duplicate, or remove one. Give each a plain name that says what it asks, such as “Queue size and who goes first”.

The objective: what best means

An experiment measures several responses, but one of them is the primary goal that drives the search. Pick that response and a direction:

• Maximize it, for something you want more of, such as throughput.
• Minimize it, for something you want less of, such as time in system or cost.
• Target a value, when you want to land on a number rather than push it to an extreme.

When more than one response matters, give each a weight so they combine into a single score. A higher weight pulls the search harder toward that response. The other responses are still measured and shown for every configuration, so you can compare them even when they are not part of the goal.

Limits keep results sensible

Add a limit to rule out configurations you would never accept, such as a cost ceiling or a longest-wait cap. A configuration that breaks a limit is marked infeasible: it still runs, but it is set aside rather than recommended, and it shows on the charts as a hollow point so you can see where the boundary sits.

The run summary

Before you commit, the bar along the bottom does the arithmetic for you: how many design points, how many replications per point, and the total number of runs that adds up to. Set the replications there, then move on to the Run step.