How the Simulation Engine Works
Understand the mechanics behind ProcessMind's discrete event simulation engine and how it models your process.
On This Page
Periodicity and Time-Varying Parameters
What is Periodicity?
Real processes don’t operate the same way at all times. Customer service handles more calls during business hours. Manufacturing runs different shifts with different staffing. Retail experiences seasonal peaks.
Periodicity allows you to define when specific simulation rules apply. Instead of using one global value, you can specify different parameters for different time periods:
- Weekdays vs. weekends
- Morning shift vs. evening shift
- Peak season vs. off-season
- Business hours vs. after hours
This makes your simulation behave realistically across different time contexts.
Why Periodicity Matters
Consider a simple example: modeling customer arrivals.
Without periodicity:
- 10 customers per hour, 24/7
With periodicity:
- 25 customers per hour, weekdays 9AM-6PM
- 15 customers per hour, weekdays 6PM-9PM
- 5 customers per hour, weekends
- 2 customers per hour, overnight
The second model captures realistic demand patterns that affect queuing, resource utilization, and throughput.
Available Periodicity Types
ProcessMind supports nine periodicity types, each defining when a rule applies:
| Type | Parameters | Description |
|---|---|---|
| Always | (none) | Rule applies at all times, no variation |
| Default | (none) | Fallback rule when no other time-based rule matches |
| Fixed Period | startDateTime, endDateTime | One-time period (not recurring) |
| Each Day | startTime, endTime | Same hours every day |
| Each Weekday | startTime, endTime | Monday through Friday only |
| Each Weekend Day | startTime, endTime | Saturday and Sunday only |
| Each Week | startDay, startTime, endDay, endTime | Weekly recurring, can span multiple days |
| Each Month | startDayOfMonth, startTime, endDayOfMonth, endTime | Monthly recurring pattern |
| Each Year | startMonth, startDayOfMonth, startTime, endMonth, endDayOfMonth, endTime | Annual/seasonal pattern |
Periodicity Types in Detail
Always
The simplest option—the rule applies at all times with no variation.
Use when: The parameter truly doesn’t vary by time, or you’re creating a simple baseline simulation.
Default
Acts as a fallback when no other time-based rule matches the current simulation time.
Use when: You want to define exceptions for specific times and have everything else use a default value.
Always Include a Default
When using multiple periodicity rules, always include a Default rule to cover any gaps in your time-based rules. This prevents unexpected behavior when no specific rule matches.
Each Day
The rule applies during specific hours every day of the week.
Parameters:
startTime: Time the rule begins (e.g., 09:00)endTime: Time the rule ends (e.g., 17:00)
Example: General business hours 09:00-17:00 apply every day including weekends.
Each Weekday
The rule applies during specific hours Monday through Friday only.
Parameters:
startTime: Time the rule beginsendTime: Time the rule ends
Example: Customer service operates 08:00-18:00 on weekdays, with different rules for weekends.
Each Weekend Day
The rule applies during specific hours Saturday and Sunday only.
Parameters:
startTime: Time the rule beginsendTime: Time the rule ends
Example: Reduced support hours 10:00-16:00 on weekends.
Each Week
The rule applies during a time range that can span multiple days within each week. This is useful for patterns that don’t align neatly with single days.
Parameters:
startDay: Day the rule begins (Monday, Tuesday, etc.)startTime: Time on the start dayendDay: Day the rule endsendTime: Time on the end day
Example: High-volume period from Wednesday at 14:00 through Friday at 12:00.
Each Month
The rule applies during specific days each month.
Parameters:
startDayOfMonth: Day of month the rule begins (1-31)startTime: Time on the start dayendDayOfMonth: Day of month the rule endsendTime: Time on the end day
Example: Month-end processing rush from the 25th at 08:00 through the last day at 23:59.
Each Year
The rule applies during specific dates annually.
Parameters:
startMonth: Month the rule beginsstartDayOfMonth: Day of the start monthstartTime: Time on the start dayendMonth: Month the rule endsendDayOfMonth: Day of the end monthendTime: Time on the end day
Example: Holiday retail peak from November 15 at 00:00 through December 31 at 23:59.
Fixed Period
The rule applies during a specific date and time range (not recurring). Use this for one-time events.
Parameters:
startDateTime: Exact start date and timeendDateTime: Exact end date and time
Example: Product launch week March 15-22, 2025, with special handling rules.
Combining Multiple Rules
The real power of periodicity comes from combining multiple rules. You can define different parameters for different time contexts, and the simulation evaluates which rule applies at each moment.
Example: Multi-Shift Processing Time
Consider a manufacturing process with different processing times based on shift:
| Rule Name | Periodicity | Processing Time Distribution |
|---|---|---|
| Day Shift | Each Weekday, 08:00-16:00 | Normal(30 min, 5 min) |
| Evening Shift | Each Weekday, 16:00-00:00 | Normal(45 min, 10 min) |
| Weekend Crew | Each Weekend Day, 10:00-18:00 | Normal(60 min, 15 min) |
| Overnight/Default | Default | Normal(90 min, 20 min) |
The day shift is fastest (full staff, fresh workers). Evening is slower (reduced supervision). Weekends are slowest (skeleton crew). The default catches overnight hours.
Rule Priority
When multiple rules could potentially match:
- Rules are evaluated in the order they are defined in your configuration
- The first matching rule is used (top-most wins)
- Default rules match only when no other rule applies
Tip: Place more specific rules above general ones. Put “Each Weekday” before “Each Day” if you want weekdays to have different behavior than weekends.
Where to Use Periodicity
Periodicity can be applied to many simulation parameters:
| Parameter | Periodicity Use Case |
|---|---|
| Case Arrivals | Higher arrival rates during business hours, lower overnight |
| Processing Times | Faster processing with full staff, slower during reduced hours |
| Resource Capacity | More staff during peak hours, skeleton crew overnight |
| Skip Chances | Different routing rules on weekends or holidays |
| Gateway Probabilities | Different decision patterns by time of day |
Comprehensive Example: Customer Support Center
Here’s a realistic example showing how periodicity works across multiple parameters for a customer support simulation:
Arrival Rate Configuration
| Periodicity | Arrival Rate |
|---|---|
| Each Weekday 09:00-18:00 | Poisson(50 per hour) |
| Each Weekday 18:00-22:00 | Poisson(20 per hour) |
| Each Weekend Day 10:00-16:00 | Poisson(15 per hour) |
| Default | Poisson(5 per hour) |
High volume during business hours, moderate evening traffic, light weekend and overnight.
Processing Time Configuration
| Periodicity | Distribution |
|---|---|
| Each Weekday 09:00-17:00 | Triangular(10, 20, 45 min) |
| Each Weekend Day | Triangular(20, 40, 90 min) |
| Default | Triangular(30, 60, 120 min) |
Fastest during peak staffing, slower on weekends and off-hours.
Staff Capacity Configuration
| Periodicity | Available Agents |
|---|---|
| Each Weekday 09:00-18:00 | 10 agents |
| Each Weekday 18:00-22:00 | 4 agents |
| Each Weekend Day 10:00-16:00 | 3 agents |
| Default | 1 agent |
Full staff during business hours, reduced coverage otherwise.
How It Works Together
At 10:00 AM on a Tuesday:
- Arrivals use the 50/hour rate
- Processing uses the fast triangular distribution
- 10 agents are available
At 8:00 PM on a Tuesday:
- Arrivals drop to 20/hour
- Processing uses the default (slower) distribution
- Only 4 agents available
At 2:00 PM on Saturday:
- Arrivals are 15/hour
- Processing uses the weekend distribution
- 3 agents available
Best Practices
1. Start with Default
Always define your Default rule first. This ensures you have coverage for any time not explicitly handled by other rules.
2. Work from General to Specific
Start with broad patterns (weekday vs. weekend), then add more specific rules (individual shift times) as needed.
3. Keep It Simple Initially
Begin with simple weekday/weekend distinctions before adding hourly or seasonal detail. You can always add complexity later.
4. Base Patterns on Data
When possible, analyze your historical data to understand actual patterns. Look at arrival rates, processing times, and staffing by hour and day of week.
5. Test Edge Cases
Verify your rules handle transition times correctly:
- What happens at exactly 17:00 when the shift changes?
- Is midnight handled correctly?
- Do month-end rules work in months with different lengths?
6. Document Your Rules
Complex periodicity configurations can be hard to understand later. Document why each rule exists and what business pattern it represents.
Next Steps
Distributions
Learn about the distribution types used within periodicity rules.
Running Simulations
Apply periodicity when configuring your simulation.
Resources
Use periodicity to model time-varying resource capacity.