Optimisation evaluations: probing methods with AnyLogic

Aug 21, 2023, updated July 31, 2026

Summary

AnyLogic is a powerful simulation tool that can be used to simulate a wide range of systems and processes. It allows developers to build simulations that take in a user defined set of inputs and provide a robust set of outputs. Therefore, it can be a useful tool to aid in optimisation problems by taking in a set of inputs and quickly generating outputs that can then be evaluated to determine how well these inputs performed. Over multiple runs of the simulation with varying inputs you can determine which inputs provide the optimal results.

AnyLogic provides two main types of experiment that can be used for optimisation. Firstly, there is the Optimisation Experiment which is built on top of the OptQuest Simulation Engine and is quick and easy to set up within AnyLogic. Secondly, there is the Custom Experiment which is entirely specified by the user and gives them full control and flexibility over how the simulation runs. However, to perform optimisation with Custom Experiment it requires the user to set up an external Java programme which calls and runs it. Another area that is useful to consider is how accessing python optimisation scripts can enhance an AnyLogic simulation and allow it to make better decisions or perform more complex processes. The best method for this is using the Java Pypeline library which provides AnyLogic with a way to make calls to external python scripts.

Optimisation Experiment

The Optimisation Experiment is a built-in feature within AnyLogic which is designed for running multiple scenarios to try and minimise/maximise the ‘objective function’. The objective function is the value that we want to optimise such as minimising lead time or maximising revenue. This could be a single output or multiple outputs that are resolved into a single aggregated value. The user can specify a set of inputs that are either fixed or are varied between runs of the model so that the best values can be determined. By varying inputs, such as the number of available resources, the model can determine the optimal set of inputs. There is also built-in functionality for performing runs of the model in parallel and evaluating multiple runs of the same inputs to account for randomness within the model such as varying levels of demand for resources at different times. These are good out-of-the box features that are easy to use and can provide a lot of value for simple optimisation problems.

What are the Limitations of Native AnyLogic Optimisation?

The out-of-the-box features provide immediate value for straightforward scenarios, the native setup falls short for highly complex engineering or logistics problems.

• Algorithmic Constraints: The native experiment types are strictly limited to minimising or maximising a specific value. Advanced heuristic search techniques, such as the Hill Climbing method, are not natively supported.
• Parameter Structure Restrictions: The optimiser cannot natively vary complex inputs like arrays or lists.

Consequently, varying complex data structures must still be managed manually between runs. Developers may find it necessary to implement dummy inputs simply to ensure the optimiser completes, subsequently collecting performance statistics manually rather than relying on the engine’s built-in outputs.

In theory, a developer can write custom code within the experiment to execute algorithms like Hill Climbing. However, this approach essentially bypasses the actual OptQuest engine, utilising the platform’s multi-run framework as a workaround for something that could be achieved just as effectively using a standard Monte Carlo experiment.

Custom Experiments: The Cloud-Native Paradigm

While built-in experiments offer out-of-the-box simplicity, the Custom Experiment framework unlocks total flexibility, granting full programmatic control over simulation logic, execution parameters, and model run-times.

Historically, running a custom experiment meant orchestrating a cumbersome, local Java programme to manually trigger consecutive simulation iterations. Today, this restrictive approach has been entirely replaced by a cloud-native paradigm. Rather than binding computation to a developer’s local machine, modern architectures decouple the simulation model from the optimisation logic.

Scaling with the AnyLogic Cloud RESTful API

The contemporary standard for advanced orchestration relies on the AnyLogic Cloud RESTful API, which features native client libraries for Python, Java, and JavaScript. This multi-language web interface fundamentally transforms how custom optimisation loops are executed:

• Serverless-Style Execution: Developers can completely bypass local environmental constraints. Simulation models are uploaded to a cloud or private server instance, where individual runs are triggered headlessly and asynchronously on-demand.
• Distributed Parallelisation: Highly intensive, multi-run optimisation loops are offloaded to high-performance infrastructure. The cloud platform splits the workload horizontally across distributed cloud nodes and cores, executing thousands of scenarios simultaneously and drastically shortening time-to-insight.
• Language-Agnostic Heuristics: By utilising the Cloud API, engineers are no longer forced to write complex search heuristics exclusively in Java. A data scientist can now design sophisticated search algorithms (such as the Hill Climbing method, genetic algorithms, or deep reinforcement learning policies) directly within a Python script, leveraging powerful open-source libraries like Google OR-Tools, SciPy, or PyTorch.

For example, a Python orchestration script can execute a supply chain simulation via a clean REST call, instantly analyse the returned outputs to pinpoint a localised bottleneck (such as a depleted inventory layer or an asset constraint), update the input vectors, and immediately fire a new flight of parallelised runs across the cloud cluster.

This modern cloud workflow allows businesses to use their AnyLogic digital twins as highly scalable, serverless objective function evaluators for cutting-edge external solvers.

Hybrid Decision Intelligence: Choosing Your Architectural Pattern

When moving beyond native probing limits, enterprise models require a hybrid approach that pairs discrete-event simulation with sophisticated mathematical solvers or analytical models. Depending on your tech stack, latent memory requirements, and data science infrastructure, two primary patterns emerge.

Pattern A: The Analytics & ML Bridge (Figure 4)

While using native Java remains the foundation for internal scripting, enhancing an AnyLogic simulation with Python’s vast ecosystem of data science, optimisation, and machine learning libraries is now standard practice. However, Python integration is no longer a one-size-fits-all workaround. Modern architectures deploy a structured, dual-pathway approach depending entirely on which environment dictates the execution flow.

Pathway 1: Pypeline (v1.9.6) – The Python-inside-Java Architecture

The Pypeline custom library is the premier tool for workflows where the AnyLogic model acts as the parent process. In this configuration, the simulation runs normally in its Java environment but reaches out to a local Python installation to execute discrete, targeted scripts on demand.

• Best For: Scenarios where the simulation requires real-time assistance from a Python library to make an internal decision (such as querying a pre-trained scikit-learn model to predict an asset failure rate mid-run or calling Google OR-Tools to solve a complex Travelling Salesman problem for fleet routing).
• The Jsonifier Advantage: Modern iterations of Pypeline are deeply integrated with the Jsonifier serialisation framework. This eliminates the historical headache of manually converting Java data structures into standard text strings. Jsonifier allows entire agent populations, multidimensional tables, and complex database tuples to be seamlessly serialised into machine-readable JSON strings and deserialised back into native Java objects with minimal computational overhead.

Pathway 2: Alpyne (v1.2.1 Beta) – The Java-inside-Python Architecture

When the orchestration flow needs to be completely reversed, the Alpyne (v1.2.1 Beta) library provides a powerful alternative. Under this paradigm, the master Python script acts as the host environment, treating the AnyLogic simulation as an importable, interactive object.

• Best For: Advanced AI training, complex heuristic loops, and intensive Reinforcement Learning (RL) pipelines.
• How it Works: Developers export their model from AnyLogic using the native Reinforcement Learning experiment framework. The Alpyne package then initialises a standalone AnyLogicSim connection inside Python. The Python script can interactively step the simulation forward, freeze execution at pre-defined decision points, inspect the exact internal observation state, inject an algorithmic action, and collect rewards.
• AI Testbed Compatibility: Because Python serves as the control room, engineers can natively wrap the simulation inside standard machine learning frameworks (like OpenAI Gym/Gymnasium) to train neural networks using deep RL frameworks like PyTorch, TensorFlow, or Stable-Baselines3.

Pattern B: The High-Performance Embedded Engine (Figure 6)

Embedding the Gurobi Optimiser for Mathematical Rigour

For large-scale enterprise problems (such as global supply chain networks, complex asset-scheduling, or multi-echelon inventory routing) standard heuristics and search algorithms often struggle to converge on a true mathematical optimum. In these scenarios, the highly robust architecture option involves embedding a high-performance mathematical solver like Gurobi directly into the simulation environment.

Because AnyLogic is natively built on Java, developers can easily add the gurobi.jar dependency directly into the simulation project’s build path. This setup unlocks a powerful, two-way hybrid framework:

• Balancing Stochasticity with Deterministic Rigour: AnyLogic excels at capturing the messy, unpredictable realities of a system (stochastic delays, machine breakdowns, fluctuating demand). Meanwhile, Gurobi excels at solving dense, deterministic mathematical models with millions of variables and constraints.
• Dynamic, Mid-Simulation Re-optimisation: Rather than just using an optimiser to find inputs before a model runs, an AnyLogic model can call the Gurobi Java API during a run. For example, every simulated 24 hours, the model can halt, pass its current state (such as unexpected delivery disruptions or machine outages) to Gurobi as a matrix, and allow Gurobi to instantly calculate a mathematically optimal production schedule or fleet routing blueprint for the next day. The simulation then resumes using that flawless plan.

By combining AnyLogic’s granular, event-driven simulation with Gurobi’s industry-leading prescriptive analytics engine, engineers can construct highly resilient digital twins that not only accurately predict system bottlenecks but actively solve them with absolute mathematical certainty.

Architectural Decision Matrix

Final Thoughts: Choosing Your Optimisation Architecture

Selecting the right optimisation pathway in AnyLogic depends entirely on the scale of your problem and the complexity of the data structures involved. There is no single “correct” approach, but rather a spectrum of engineering choices tailored to enterprise requirements:

• For Straightforward Parameters: If your objective is simply to vary a handful of discrete or continuous scalar variables to find a clear minimum or maximum, the native Optimisation Experiment offers a highly capable, out-of-the-box framework driven by OptQuest that requires minimal development overhead.
• For High-Performance Cloud Scaling: When optimisation loops involve multi-dimensional arrays or require advanced custom search heuristics, pivoting to a Custom Experiment executed via the AnyLogic Cloud RESTful API is the modern benchmark. This allows you to offload computational strain serverless-style across distributed cloud nodes.
• For Ecosystem Integration: If your solution relies on data science or machine learning libraries, deploying a structured, dual-pathway approach via Pypeline (v1.9.6) or Alpyne (v1.2.1 Beta) ensures a robust data exchange between Java and Python, depending on whether the simulation or an external script controls the parent execution flow.
• For Absolute Mathematical Rigour: For highly dense, combinatorial problems where heuristics fail to guarantee a true global optimum, embedding a premium solver like Gurobi directly into the simulation code path unlocks powerful math-heuristic capabilities. This empowers digital twins to balance unpredictable real-world stochasticity with precise, mid-run prescriptive analytics.

By understanding these structural boundaries, engineering teams can stop treating simulation models as passive visual tools and start utilising them as scalable, highly intelligent decision-support engines.