Dendro: Input Factors Guide

Introduction

Input factors are at the heart of Dendro optimization - they define what Dendro can change to improve your supply chain performance. Think of input factors as the "knobs" Dendro can turn to find better inventory policies.

Key concepts:

• Input Factors = What can be optimized (the variables) - this document
• Output Factors = What you want to improve (the objectives) - see the Dendro: Output Factors Guide

This guide explains how to configure input factors to give Dendro the right level of control over your inventory policies. These can be specified in the Input Factors input table in Cosmic Frog.

Recommended reading prior to diving into this guide: Getting Started with Dendro, a high-level overview of how Dendro works, and Dendro: Genetic Algorithm Guide which explains the inner workings of Dendro in more detail.

What Are Input Factors?

The Big Picture

An input factor tells Dendro's Genetic Algorithm:

1. What to change: Which field in which table (e.g., reorder point in the inventory policies table)
2. For which items: Which facility-product combinations (e.g., "Warehouse A + Product 1")
3. How to change it: What values are allowed (e.g., minimum 100, maximum 1000, step by 10)
4. Starting point: Where to begin (e.g., current value of 500)

Dendro explores these decisions systematically across your entire network to find the optimal combination.

Types of Input Factors

Dendro supports three types of input factors, each suited for different kinds of optimization variables. These are all specified on the Input Factors input table, see also "The Input Factors Table" section further below.

1. Range Input Factors

What they are: Numeric values that can vary within a minimum and maximum range.

Best for:

• Inventory policy parameters (reorder points, order quantities)
• Any numeric value with logical bounds

Configuration fields:

• ‍InputFactorName:  WH_A_Prod_1_ReorderPoint
• TableName:        InventoryPolicies
• ColumnName:       SimulationPolicyValue1
• Filter:           FacilityName='Warehouse A' AND ProductName='Product 1'
• MinValue:         100
• MaxValue:         1000
• StepSize:         10
• BaseValue:        500

How it works:

• Dendro is allowed to set the value to any number between 100 and 1000
• Changes happen in increments of 10 (e.g., 100, 110, 120, ..., 1000)
• First chromosome starts at 500 (current baseline)
• Other chromosomes explore random values within the range
• Mutations adjust values up or down by the step size

Example:

• ‍Chromosome 1 (baseline):       500
• Chromosome 2 (random):         730
• Chromosome 3 (random):         220
• Chromosome 4 (mutated from 2): 740 (increased by one step)

2. Enumeration Input Factors

What they are: Values selected from a predefined list of discrete options.

Best for:

• Policy types (s,S), (R,Q), (T,S)
• Supplier selection (Supplier A, Supplier B, Supplier C)
• Transportation modes (Air, Sea, Ground)
• Any categorical choice

Configuration fields:

• ‍InputFactorName:  DC_Policy_Type
• TableName:        InventoryPolicies
• ColumnName:       SimulationPolicy
• Filter:           FacilityName='Distribution Center'
• Enumerate:        (s,S)|(R,Q)|(T,S)
• BaseValue:        (s,S)

How it works:

• Dendro selects from the pipe-delimited list: "(s,S)", "(R,Q)", or "(T,S)"
• First chromosome uses the base value: (s,S)
• Other chromosomes randomly select from available options
• Mutations switch to a different option from the list

Example:

• ‍Chromosome 1 (baseline):       (s,S)
• Chromosome 2 (random):         (R,Q)
• Chromosome 3 (random):         (T,S)
• Chromosome 4 (mutated from 2): (s,S) (switched from R,Q)

3. Inventory Policy Sets (Advanced)

What they are: Grouped input factors that manage related inventory policy parameters together as a coordinated set.

Best for:

• Complete inventory policy optimization (policy type + parameters)
• Maintaining logical consistency between related values
• Automatic policy conversion (e.g., converting between (R,Q) and (s,S))

How they work:

• Multiple input factors (policy type, value1, value2) are grouped by their filter
• Dendro treats them as a coordinated "gene"
• When policy type changes, parameter values are automatically converted
• Special mutation logic ensures policy parameters remain valid

Example configuration:

• ‍Factor 1:
  
  • InputFactorName:  WH_A_Prod_1_PolicyType
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicy
  • Filter:           FacilityName='Warehouse A' AND ProductName='Product 1'
  • Enumerate:        (s,S)|(R,Q)
• Factor 2:
  
  • InputFactorName:  WH_A_Prod_1_Value1
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicyValue1
  • Filter:           FacilityName='Warehouse A' AND ProductName='Product 1'
  • MinValue:         0
  • MaxValue:         1000
  • StepSize:         10
• Factor 3:
  
  • InputFactorName:  WH_A_Prod_1_Value2
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicyValue2
  • Filter:           FacilityName='Warehouse A' AND ProductName='Product 1'
  • MinValue:         0
  • MaxValue:         1500
  • StepSize:         10

Automatic policy conversion: When policy type changes from (R,Q) to (s,S):

• Old: (R,Q) with R=200, Q=300
• New: (s,S) with s=200, S=500 (automatically calculates S = R + Q)

When changing from (s,S) to (R,Q):

• Old: (s,S) with s=200, S=500
• New: (R,Q) with R=200, Q=300 (automatically calculates Q = S - s)

Input Factor Configuration

The Input Factors Table

Input factors are configured in the Input Factors input table with the following columns:

*Filter is required for inventory policy input factors to identify the specific facility-product combination.

The following 2 screenshots show the Input Factors table in Cosmic Frog. It contains 3 records which are set up the same as the example in the "Inventory Policy Sets (Advanced)" section above:

Configuration Examples

Example 1: Simple Reorder Point Range

Optimize the reorder point for a single facility-product:

• ‍InputFactorName:  Seattle_Widget_ReorderPoint
• TableName:        InventoryPolicies
• ColumnName:       SimulationPolicyValue1
• Filter:           FacilityName='Seattle DC' AND ProductName='Widget A'
• MinValue:         200
• MaxValue:         800
• StepSize:         20
• BaseValue:        500
• Status:           Include

Result: Dendro will explore reorder points from 200 to 800 in steps of 20 (200, 220, 240, ..., 800).

Example 2: Order Quantity with Fine Control

Optimize order quantity with small increments:

• ‍InputFactorName:  Boston_Gadget_OrderQty
• TableName:        InventoryPolicies
• ColumnName:       SimulationPolicyValue2
• Filter:           FacilityName='Boston WH' AND ProductName='Gadget B'
• MinValue:         50
• MaxValue:         500
• StepSize:         5
• BaseValue:        200
• Status:           Include

Result: Dendro will explore 91 different values (50, 55, 60, ..., 500).

Example 3: Policy Type Selection

Let Dendro choose between different inventory policies:

• ‍InputFactorName:  Chicago_Part_PolicyType
• TableName:        InventoryPolicies
• ColumnName:       SimulationPolicy
• Filter:           FacilityName='Chicago Plant' AND ProductName='Part C'
• Enumerate:        (s,S)|(R,Q)|(T,S)
• BaseValue:        (s,S)
• Status:           Include

Result: Dendro will test (s,S), (R,Q), and (T,S) policies to see which performs best.

Example 4: Complete Policy Optimization

Optimize both policy type and parameters:

• ‍Policy Type
  
  • InputFactorName:  LA_Motor_PolicyType
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicy
  • Filter:           FacilityName='LA Warehouse' AND ProductName='Motor D'
  • Enumerate:        (s,S)|(R,Q)
  • BaseValue:        (s,S)
• Parameter 1 (reorder point or 's')
  
  • InputFactorName:  LA_Motor_Value1
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicyValue1
  • Filter:           FacilityName='LA Warehouse' AND ProductName='Motor D'
  • MinValue:         0
  • MaxValue:         500
  • StepSize:         10
  • BaseValue:        100
• Parameter 2 (order-up-to or order quantity)
  
  • InputFactorName:  LA_Motor_Value2
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicyValue2
  • Filter:           FacilityName='LA Warehouse' AND ProductName='Motor D'
  • MinValue:         0
  • MaxValue:         800
  • StepSize:         10
  • BaseValue:        300

Result: Dendro will:

• Test both (s,S) and (R,Q) policies
• Explore parameter values within specified ranges
• Automatically convert parameters when switching policy types
• Maintain logical consistency (e.g., S > s in (s,S) policies)

Inventory Policy Input Factors

Standard Inventory Policy Columns

The most common input factors for inventory optimization target these columns in the Inventory Policies input table:

How Input Factors Work in the Genetic Algorithm

From Input Factors to Chromosomes

1. ‍Step 1: Loading - Dendro loads all active input factors from the Input Factors table.‍
2. Step 2: Grouping - Input factors for the same facility-product (same filter) in Inventory Policies are automatically grouped into policy sets.‍
3. Step 3: Indexing - Each input factor (or factor set) is assigned an index position in the chromosome.‍
4. Step 4: Population Creation - Each chromosome in the initial population gets a value for each input factor:

• Chromosome 1 (baseline): Uses BaseValue for all factors
• Other chromosomes: Random values within allowed ranges/enumerations

Example:

Input Factors:

• ‍[0] WH_A_Prod_1_ReorderPoint (Range: 100-1000, Step: 10, Base: 500)
• [1] WH_A_Prod_1_ReorderPoint (Range: 200-800, Step: 20, Base: 400)
• [2] WH_A_Prod_1_PolicyType   (Enum: (s,S)|(R,Q), Base: (s,S))

Results in:

• ‍Chromosome 1 (baseline): [500, 400, 0]   (0 = first enum value = (s,S))
• Chromosome 2 (random):   [730, 560, 1]   (1 = second enum value = (R,Q))
• Chromosome 3 (random):   [220, 640, 0]   (0 = first enum value = (s,S))

Mutation: Exploring New Values

When Dendro mutates a chromosome, it changes one or more input factor values:

For Range factors:

• Selects a new random value within [MinValue, MaxValue]
• Respects StepSize increments
• May adjust min/max temporarily for policy constraints

For Enumeration factors:

• Selects a different option from the value list
• For policy sets, may trigger parameter conversion

Example mutation:

• ‍Original:  [500, 400, 0]
• Mutated:   [500, 420, 0]    (Position 1 changed: 400 to 420)

Scenario Generation: Applying Input Factors

When Dendro creates a scenario to simulate using the Throg engine:

1. It starts with baseline scenario data
2. For each input factor, it applies the chromosome's value:
   • Finds the target table (e.g., InventoryPolicies)
   • Finds the target row (using the Filter clause)
   • Updates the target column (e.g., SimulationPolicyValue1)
   • Writes the value from the chromosome
3. Saves the modified scenario with a unique name, e.g., base scenario name with the postfix "_GA3.5" appended. This means the 5th scenario (=chromosome) of the 3rd generation.

Result: Each chromosome becomes a complete, runnable supply chain scenario with its specific inventory policy settings.

Automatic Input Factor Generation

Overview

When turned on, the Automatically Generate Input Factors option (a model run option in the Dendro section of the Technology Parameters) automatically creates input factor configurations based on your inventory policies and service targets.

When to use:

• Starting a new Dendro project
• You do not have pre-configured input factors
• You want to ensure all relevant facility-products are included

How it works:

1. Analyzes your Inventory Policies table
2. Identifies facility-product combinations with active inventory policies
3. Runs a baseline simulation to gather performance statistics
4. Creates appropriate min/max ranges based on:
   • Current policy values
   • Service level performance
   • Order quantity patterns
   • Demand characteristics

Range Calculation Logic

The automatic builder uses intelligent rules to set min/max ranges based on current values and service performance:

For Small Values (<= 10 units):

• ‍MinValue:  0
• MaxValue:  value + 5 (or adjusted based on service)
• StepSize:  1

Rationale: Small values need fine-grained control and room to explore modest increases.

For Medium Values (11-50 units):

• ‍MinValue:  max(1, rounded_value - 15)
• MaxValue:  rounded_value + 15
• StepSize:  5

Values are rounded to base 5

Rationale: Medium values can use larger steps (5) while still providing good resolution.

For Larger Values (51-300 units):

• ‍MinValue:  max(1, rounded_value - 50)
• MaxValue:  rounded_value + 50
• StepSize:  10

Values are rounded to base 10

Rationale: Larger inventories need wider exploration ranges with proportionally larger steps.

For Very Large Values (> 300 units):

• ‍MinValue:  max(1, rounded_value - 200)
• MaxValue:  rounded_value + 200
• StepSize:  20

Values are rounded to base 20

Rationale: Very large inventories benefit from broad exploration with coarse granularity.

Service-Driven Adjustments

The builder adjusts ranges based on current service performance:

When fill rate < target service level: The ratio = target_service / current_fill_rate is used to expand the maximum:

MaxValue = max(value + buffer, ratio * value)

Example:

• Current value: 500 units
• Current fill rate: 85%
• Target service: 95%
• Ratio: 95/85 = 1.12
• MaxValue adjusted to explore up to 560 units (500 * 1.12)

When fill rate => target service level: The builder is more conservative, allowing exploration below current value:

MaxValue = min(value + buffer, quantity_bounds)

Rationale: If service is already good, there may be opportunity to reduce inventory without harming service.

When fill rate <= 85% (poor service): MinValue is set to current value - does not explore lower values that would worsen service further.

What Gets Created

For each inventory policy, the automatic generator typically creates:

• SimulationPolicyValue1 range (reorder point s or R / parameter 1)
• SimulationPolicyValue2 range (order-up-to S / parameter 2)

Result: A complete Input Factors table ready for Dendro optimization.

Best Practices

1. Start with Reasonable Ranges

Too narrow:

• ‍MinValue: 490
• MaxValue: 510
• StepSize: 1

Problem: Dendro cannot explore significantly different solutions. Only 21 values to test.

Too wide:

• ‍MinValue: 0
• MaxValue: 100000
• StepSize: 1

Problem: 100,000 possible values means Dendro will likely miss the optimal value in the haystack.

Just right:

• ‍MinValue: 200
• MaxValue: 800
• StepSize: 20

Why: Reasonable range around current value (500), coarse enough for efficient exploration (31 values), fine enough for precision.

2. Choose Appropriate Step Sizes

Rule of thumb: Step size should be 1-5% of the expected optimal value.

For value of approximately 100:

• Good: StepSize = 1-5
• Too fine: StepSize = 0.1
• Too coarse: StepSize = 50

For value of approximately 1000:

• Good: StepSize = 10-50
• Too fine: StepSize = 1
• Too coarse: StepSize = 500

Why it matters:

• Too fine = Unnecessarily large search space, slow convergence
• Too coarse = May skip over optimal values, imprecise results

3. Ensure Step Size Divides Range Evenly

Bad:

• ‍MinValue: 100
• MaxValue: 1000
• StepSize: 40

Problem: (1000-100) / 40 = 22 remainder 20; the max might not be reachable exactly.

Good:

• ‍MinValue: 100
• MaxValue: 1000
• StepSize: 30

Check: (1000-100) / 30 = 30 remainder 0; the max can be reached exactly.

Dendro automatically adjusts MaxValue if needed to ensure even division.

4. Use Base Values Wisely

Best practice: Set BaseValue to your current policy value.

Why:

• First chromosome (baseline) represents your current state
• Provides a benchmark for improvement
• Ensures you do not end up worse than where you started

When BaseValue is null:

• First chromosome uses random value
• Useful when current policies are very poor or non-existent
• May miss easy wins from the current state

5. Group Related Factors

For inventory policies, always configure factors for the same facility-product together:

Good - Coordinated filters:

• ‍All three factors have identical Filter
  
  • WH_A_Prod_1_PolicyType  Filter: FacilityName='WH A' AND ProductName='Prod 1'
  • WH_A_Prod_1_Value1      Filter: FacilityName='WH A' AND ProductName='Prod 1'
  • WH_A_Prod_1_Value2      Filter: FacilityName='WH A' AND ProductName='Prod 1'

Bad - Mismatched filters:

• ‍WH_A_Prod_1_PolicyType  Filter: FacilityName='WH A' AND ProductName='Prod 1'
• WH_A_Prod_1_Value1      Filter: FacilityName='WH A' AND ProductName='Prod 1'
• WH_A_AllProds_Value2    Filter: FacilityName='WH A'    # WRONG - does not match!

Why: Dendro groups factors by filter. Mismatched filters create separate uncoordinated genes.

6. Do Not Over-Configure

Guideline: More input factors = larger search space = longer optimization

Example calculation:

• 100 facility-product combinations
• Each with 2 parameters (value1, value2)
• Each parameter has 50 possible values

Search space size: 50^200 = enormous!

Best practice:

• Focus on high-value items (ABC analysis)
• Use automatic generation with filters
• Exclude low-impact facility-products
• Group similar items when possible

Use the Status column: Set Status = 'Exclude' for factors you want to temporarily disable without deleting.

7. Validate Filter Syntax

Common mistakes:

Wrong - Missing quotes:

Filter: FacilityName=Warehouse A AND ProductName=Widget

Correct - Proper quotes:

Filter: FacilityName='Warehouse A' AND ProductName='Widget'

Wrong - Incorrect column names:

Filter: Facility='WH A' AND Product='Widget'

Correct - Match actual table column names:

Filter: FacilityName='WH A' AND ProductName='Widget'

Testing tip: Run your filter as a SQL WHERE clause to verify it returns exactly one row (you can use the SQL Editor application on the Optilogic platform for this):

SELECT * FROM InventoryPolicies 
WHERE FacilityName='WH A' AND ProductName='Widget';

Common Scenarios

Scenario 1: Optimize Reorder Points Only

Goal: Keep current policy types and order quantities; optimize reorder points only.

Configuration:

For each facility-product:

• ‍InputFactorName:  {Facility}_{Product}_ReorderPt
• TableName:        InventoryPolicies
• ColumnName:       SimulationPolicyValue1
• Filter:           FacilityName='{Facility}' AND ProductName='{Product}'
• MinValue:         [calculated]
• MaxValue:         [calculated]
• StepSize:         [appropriate for value scale]
• BaseValue:        [current value]

Result: Dendro explores different reorder points while keeping other policy parameters fixed.

Scenario 2: Optimize Complete Policies

Goal: Let Dendro choose policy types and all parameters.

Configuration:

For each facility-product:

• ‍Policy type
  
  • InputFactorName:  {Facility}_{Product}_Policy
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicy
  • Filter:           FacilityName='{Facility}' AND ProductName='{Product}'
  • Enumerate:        (s,S)|(R,Q)
• Parameter 1
  
  • InputFactorName:  {Facility}_{Product}_Value1
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicyValue1
  • Filter:           FacilityName='{Facility}' AND ProductName='{Product}'
  • [Range configuration]
• Parameter 2
  
  • InputFactorName:  {Facility}_{Product}_Value2
  • TableName:        InventoryPolicies
  • ColumnName:       SimulationPolicyValue2
  • Filter:           FacilityName='{Facility}' AND ProductName='{Product}'
  • [Range configuration]

Result: Maximum flexibility - Dendro explores different policy types and parameter values.

Scenario 3: Focus on High-Value Items

Goal: Optimize top 20% of items by revenue; leave others unchanged.

Approach:

1. Identify high-value facility-products (ABC analysis)
2. Create input factors only for A and B items
3. Use automatic generation with appropriate filters

SQL example for selective generation - Create Input Factors for top revenue items only:

INSERT INTO InputFactors (...) 
SELECT ... FROM InventoryPolicies ip 
JOIN ProductRevenue pr ON ip.ProductName = pr.ProductName 
WHERE pr.AnnualRevenue > [threshold] 

‍

Result: Focused optimization on items that matter most, faster runtime.

Scenario 4: Different Ranges by Product Category

Goal: Use wider ranges for variable-demand products, tighter for stable products.

Configuration:

Stable, predictable products:

• ‍MinValue: current_value * 0.8
• MaxValue: current_value * 1.2
• StepSize: small (fine control)

Variable, unpredictable products:

• ‍MinValue: current_value * 0.5
• MaxValue: current_value * 2.0
• StepSize: larger (broader exploration)

Result: Appropriate exploration ranges based on demand variability.

Troubleshooting

Problem: "No matching inventory policy"

Symptom: During loading, you see "no matching inventory policy" in the Job Log.

Cause: The Filter does not match any row in the InventoryPolicies table.

Solutions:

1. Verify filter syntax (quotes, column names)
2. Check for case sensitivity in facility/product names
3. Run test query: SELECT * FROM InventoryPolicies WHERE [your filter]
4. Ensure the facility-product combination exists in the table

Problem: Input factors not being grouped

Symptom: Multiple separate genes instead of one coordinated policy set.

Cause: Filters do not match exactly across related factors.

Example problem:

• ‍Factor 1 Filter: FacilityName='WH A' AND ProductName='Widget'
• Factor 2 Filter: FacilityName='WH A' and ProductName='Widget'   # lowercase 'and'!

Solution: Ensure identical filter text across all factors for the same facility-product.

Problem: GA explores unrealistic values

Symptom: Dendro tests impractical inventory levels (too high or too low).

Cause: Min/Max ranges too wide or poorly set.

Solutions:

1. Review and tighten ranges based on:
   • Physical storage constraints
   • Budget limitations
   • Supplier minimum order quantities
   • Historical demand patterns
2. Use automatic generation which sets realistic ranges
3. Add validation logic in custom fitness calculators

Problem: Optimization not improving

Symptom: Fitness scores are not getting better across generations.

Possible causes:

Cause 1: Ranges too narrow

• Dendro cannot explore different enough solutions
• Solution: Widen MinValue/MaxValue ranges

Cause 2: Step size too coarse

• Dendro skips over optimal values
• Solution: Reduce StepSize for finer granularity

Cause 3: Wrong factors optimized

• Optimizing parameters that do not significantly impact objectives
• Solution: Review which factors actually influence your output metrics

Cause 4: Conflicting objectives

• Improving one metric worsens another
• Solution: Review output factor weights and utility curves

Overall Fitness Scores can be assessed in the Simulation Evolutionary Algorithm Summary output table after a Dendro run has completed, while scores of individual output factors can be reviewed in the Simulation Evolutionary Algorithm Output Factor Report output table:

Problem: S < s violations in (s,S) policies

Symptom: Warnings or errors about order-up-to levels below reorder points.

Cause: Ranges configured without considering logical constraints.

Solution: Dendro handles this automatically through special mutation logic, but you can help by:

1. Setting MinValue for Value2 higher than typical Value1
2. Using automatic generation which sets appropriate ranges
3. Trusting Dendro's built-in constraint handling

Note: Dendro automatically enforces S => s during gene creation and mutation.

Summary

Input factors are the foundation of Dendro optimization:

• ‍Define what changes: Which table, column, and rows
• ‍Define how it changes: Ranges, enumerations, or policy sets
• ‍Define exploration bounds: Min, max, step size
• ‍Define starting point: Base values for baseline

Key takeaways:

1. Use automatic generation - get started quickly with sensible defaults‍
2. Focus on high-impact items - do not try to optimize everything at once‍
3. Set realistic ranges - not too narrow, not too wide‍
4. Choose appropriate step sizes - balance precision vs. search space size‍
5. Group related factors - use matching filters for policy components‍
6. Validate your configuration - test filters; check ranges make sense‍
7. Iterate and refine - start broad, narrow down based on results

Well-configured input factors give Dendro the right level of control to find optimal solutions efficiently. Too much freedom creates an intractably large search space; too little prevents discovering improvements. The art is finding the right balance for your specific supply chain.

Other Helpful Resources

You may find these links helpful, some of which have already been mentioned above:

• Learn all about Cosmic Frog
• Dendro Help Center articles:
  • Getting Started with Dendro
  • Dendro: Genetic Algorithm Guide
  • Dendro: Output Factors Guide
• On-demand simulation (Throg) training courses:
  • Introduction to Simulation Concepts
  • Introduction to Simulation Inputs
  • Introduction to Simulation Outputs
• Throg-specific help center articles

Please do not hesitate to contact the Optilogic Support team on support@optilogic.com for any questions or feedback.