Skip to main content

Auto Calculation Time

The Auto Calculation Time feature automatically determines the optimal solver duration for each planning request. Instead of using a fixed timeframe for every run, it dynamically adjusts the calculation time based on the complexity of the data (e.g., number of orders and vehicles).

Stateless API

This feature is currently not available in the Optimization (Stateless) API. It works only within the Integration API. The feature can also be used with simple optimization API

Why use this?​

In planning, time is a precious resource.

  • Problem: If you set a fixed 10-minute solver limit, a simple plan with only 5 jobs still forces you to wait 10 minutes, killing productivity. Conversely, a massive plan with 1000 jobs might need 20 minutes to find a viable route, meaning a 10-minute limit yields poor results.
  • Solution: This feature acts as an "autopilot" for your solver settings. It gives simple jobs a quick turnaround time (e.g., seconds) while allocating more time to complex scenarios that actually need it.

Value for Planners:

  • Faster Operations: Stop waiting unnecessarily for small adjustments.
  • Better Quality: Ensure complex routes get the computation time they deserve.
  • Reduced Cognitive Load: No need to manually guess or tweak the time_limit for every single simulation.

Overview​

The system analyzes your payload—specifically the number of nodes (pickup/delivery points), vehicles, and their interactions—to calculate a "sweet spot" duration. This recommended time is designed to find a near-optimal solution without diminishing returns.

Safety Cap

Regardless of the calculation, the system will never exceed the absolute maximum time limit defined in your engine_settings.solver.parameters.time_limit_ms. This ensures you still have a hard ceiling for cost and operation control.

Configuration​

You can enable this feature in the logistics_api_settings of your simulation or request. You can choose between two calculation methods: Stepwise (simple lookup) or Linear (formula-based).

Stepwise Method​

This is the simplest and most recommended approach for most users. You define time limits based on ranges of node counts (orders). It functions like a predictable lookup table.

Example Configuration:

{
  "auto_calculate_time_limit_enabled": true,
  "auto_calculate_time_limit_params": {
    "stepwise": {
      "10": 10,
      "50": 20,
      "100": 40
    }
  }
}

Node is not equal to an order. An order has at least two nodes. :::

How it works:

  • If you have 10 or fewer nodes, the solver runs for 10 seconds.
  • If you have between 11 and 50 nodes, it runs for 20 seconds.
  • If you have between 51 and 100 nodes, it runs for 40 seconds.
  • If you have more than 100 nodes, it uses the highest value (40 seconds).

Linear Method​

This method offers granular precision by using a mathematical formula. It is best suited for advanced data science teams who have calibrated specific coefficients for their operational models.

Example Configuration:

{
  "auto_calculate_time_limit_enabled": true,
  "auto_calculate_time_limit_params": {
    "linear": {
      "coeff_node_count": 2.5,
      "coeff_vehicle_count": -0.6,
      "coeff_node_vehicle_interaction": -0.004,
      "bias_term": -4
    }
  }
}

Formula: The time limit yy is calculated as: y=(a×Nodes)+(b×Vehicles)+(c×Interaction)+Biasy = (a \times \text{Nodes}) + (b \times \text{Vehicles}) + (c \times \text{Interaction}) + \text{Bias}

Precedence

If both stepwise and linear are defined in the same payload, the linear function takes precedence and is used for the calculation.

Simulation Settings Example​

Here is a full snippet of how to include this in your API request within logistics_api_settings:

{
  "logistics_api_settings": {
    "auto_calculate_time_limit_enabled": true,
    "auto_calculate_time_limit_params": {
      "stepwise": {
        "20": 15,
        "100": 60,
        "500": 300
      }
    }
  }
}
Fallback Mechanism

If the auto-calculation parameters are invalid, missing, or malformed, the system automatically defaults to the fixed time_limit_ms setting. This ensures your simulation requests never fail due to a configuration error in this feature.

Last updated on