Creating and Using Parameters

A parameter is a named variable that replaces hardcoded numbers throughout your model. Instead of repeatedly typing 5 into delay fields and metric formulas, you declare SERVICE_TIME = 5 and reference that identifier.

---

Why Use Parameters

1. Centralized Modifications

In real systems, values recur in multiple locations: buffer limits that set initial place markings and serve as denominators in utilization metrics; or network latencies shared across three separate stages. With parameters, changes are made in one place and propagate immediately.

2. Clarity and Readability

Compare these two metric expressions:

E{#InService} / 5
E{#InService} / SERVICE_TIME

The first requires external documentation to remember what 5 represents. The second is self-documenting.

3. Automated Scenario Sweeps

Jupiter's Compare Scenarios feature can only vary variables that possess names. To run sensitivity sweeps (such as testing service times from 1 to 10), the value must be defined as a named parameter.

Rule of Thumb

If a value could ever change — whether due to future measurements, design decisions, or sensitivity studies —, assign it a parameter. Reserve literal constants strictly for structural net topology that will never change.

---

Two Parameter Data Types

In the inspector panel, each parameter is assigned one of two data types:

Type	Intended for	Example	Behavior in initial marking
INTEGER	Discrete counts	Number of workers, capacity limits, CPU cores	Fractional values are rounded
DOUBLE	Continuous values	Mean delays, service times, rates, probabilities	Preserves full floating-point precision

When initializing place markings, the engine requires discrete integer token counts. Fractional numbers like 2.7 assigned to an INTEGER parameter will round to 3. In other contexts (delays, guards, and metrics), full decimal precision is preserved.

---

Where to Use Parameters

Parameters can be placed in five primary model locations:

1. Initial Place Markings

Define capacity limits or starting worker counts:

Place	Initial Marking	Meaning
Workers	WORKERS	Initial staff available
Slots	BUFFER_CAPACITY	Available waiting positions

2. Timed Transition Delays

In the mean delay field of timed transitions:

ARRIVAL_DELAY
SERVICE_TIME

For normal distributions, both the mean and the standard deviation accept parameter names.

3. Arc Multiplicities

To specify variable batch sizes:

BATCH_SIZE

4. Guard Conditions

In boolean logic within transition properties:

#Queue < MAX_QUEUE_LIMIT
#Slots > SAFETY_MARGIN

This makes capacity thresholds tunable across scenario comparisons.

5. Metric Formulas

Inside performance queries:

E{#InService} / SERVICE_TIME
(E{#InService} / WORKERS) * 100

Common Parametric Sweep Pitfall

Hardcoding a number (such as / 5) inside a metric formula and later sweeping SERVICE_TIME in scenario analysis. The metric will continue dividing by 5 across every point on the graph. Always use the parameter name inside metric formulas.

---

Managing Parameters in the UI

1. Open the Parameters section in the right inspector panel.
2. Click +.
3. Enter the Name (e.g., SERVICE_TIME), select the Type (INTEGER or DOUBLE), and enter the Value.
4. To trace usage: click any parameter in the list to highlight in blue every place, transition, and arc on the canvas that references it.
5. If clicking a parameter highlights no elements, check for typos in node fields.

Naming Conventions

• Use uppercase letters, numbers, and underscores (_).
• Names must start with a letter or underscore: [A-Z_][A-Z0-9_]*.
• Avoid spaces, accents, and hyphens.
• Good examples: SERVICE_TIME, NUM_WORKERS, BUFFER_SIZE.

Next steps

Learn how to create dynamic dependencies between parameters in Expressions with Parameters.