Large Language Model Agent for User-friendly Chemical Process Simulations

This paper presents a Large Language Model agent integrated with AVEVA Process Simulation via the Model Context Protocol, which enables natural language interaction for automating complex chemical process tasks like analysis, optimization, and flowsheet synthesis, thereby enhancing both educational accessibility and professional efficiency while still requiring expert oversight.

The Gist

Imagine you are trying to build a complex Lego castle, but the instruction manual is written in a secret code that only a master architect understands. You have to manually click through hundreds of tiny menus, choose the right bricks from a massive catalog, and calculate the structural integrity yourself. If you make a mistake, the whole thing might collapse, and you'd have to start over. This is what using traditional chemical process simulators is like for most people: powerful, but incredibly difficult to use without years of training.

This paper introduces a new "smart assistant" designed to talk to that complex software for you. Here is how it works, broken down into simple concepts:

The "Translator" and the "Robot Hand"

The researchers built a system that acts like a translator between you and the complex software (called AVEVA Process Simulation, or APS).

• You (The User): You just talk to the system in plain English, like asking a friend for help. "Can you show me how to separate water and methanol?" or "How can I make this process more efficient?"
• The LLM Agent (The Brain): This is the "Large Language Model" part. Think of it as a very knowledgeable but slightly over-eager intern. It understands your request, breaks it down into steps, and knows what tools to use.
• The MCP Server (The Robot Hand): This is the crucial bridge. The "Brain" can't actually touch the software directly. The "Robot Hand" (built using a protocol called MCP) takes the Brain's instructions and physically clicks the buttons, types the numbers, and runs the calculations inside the software.

The Two Tests: Reading a Map and Building a House

To see if this system actually works, the researchers tested it with a common chemical problem: separating a mixture of water and methanol (like separating oil and water, but with chemicals). They ran two different tests:

1. The Detective Test (Analysis)

• The Task: They gave the agent an existing, pre-built simulation and asked, "What is happening here, and how can we make it better?"
• The Result: The agent acted like a detective. It looked at the "crime scene" (the simulation), read the clues (data), and wrote a report. It correctly identified the equipment and the numbers.
• The Catch: When asked for ideas to improve the process, the agent gave a long list of suggestions. Some were brilliant (like "turn up the heat slightly"), but some were a bit "hallucinated" or overly optimistic (like suggesting a complex new machine that wasn't needed).
• The Lesson: The agent is great at finding data and brainstorming ideas, but it sometimes gets too excited and suggests things that aren't quite right. It needs a human expert to double-check the "best ideas" before trying them.

2. The Builder Test (Synthesis)

• The Task: They asked the agent to build the entire simulation from scratch. They tested two ways of giving instructions:
  • The "Step-by-Step" Guide: The user told the agent exactly what to do one small step at a time ("Connect this pipe," then "Add this tank"). The agent followed orders perfectly, like a robot obeying a remote control.
  • The "One-Shot" Prompt: The user gave one simple sentence: "Build a water-methanol separator." The agent tried to figure out the whole plan on its own.
• The Result: The agent could build the simulation in both modes. In the "One-Shot" mode, it was impressive but made a few small mistakes, like trying to adjust a dial that didn't exist or setting a value that the software couldn't handle yet.
• The Lesson: The agent can build the structure, but it sometimes tries to turn knobs that are locked. It needs a human to step in and fix the "convergence" issues (the point where the math gets too hard for the computer to solve automatically).

The Bottom Line: A Co-Pilot, Not a Pilot

The paper concludes that this system is a valuable co-pilot, not an autopilot.

• For Students: It's like having a tutor who can show you how the software works and explain the jargon in simple words.
• For Experts: It's like having a super-fast assistant who can pull up all the data you need in seconds, saving you from clicking through menus for hours.
• The Safety Rule: Because the agent is an AI, it can sometimes "dream up" facts or make small math errors. The paper emphasizes that a human expert must always be in the loop to verify the results. The software itself acts as a safety net (it won't let physics break), but the human is needed to interpret the AI's suggestions.

In short, this paper shows that we can now talk to complex chemical engineering software in plain English. The AI does the heavy lifting of finding data and building models, but the human engineer remains the captain, steering the ship and making the final decisions.

Technical Summary

Technical Summary: LLM Agent for User-Friendly Chemical Process Simulations

Problem Statement

Modern chemical process simulators, such as AVEVA Process Simulation (APS), are indispensable for designing and optimizing industrial systems. However, their widespread adoption is hindered by steep learning curves, extensive manual configuration requirements, and the necessity for deep domain expertise. Traditional workflows require engineers to navigate complex graphical interfaces, manually select thermodynamic models, and possess intimate knowledge of physical principles to achieve meaningful results. These barriers restrict accessibility for junior engineers, interdisciplinary teams, and organizations with limited simulation expertise. While Artificial Intelligence (AI) and Large Language Models (LLMs) have shown promise in autonomous reasoning and tool integration, existing solutions have not yet successfully bridged the gap between conversational AI interfaces and the rigorous, deterministic requirements of safety-critical chemical engineering simulations.

Methodology

The authors propose a novel framework that integrates an LLM-based agent with a commercial process simulator (APS) via the Model Context Protocol (MCP). This architecture replaces direct manual interaction with an intelligent, conversational interface while preserving the underlying rigor of the simulation engine.

Architecture

The framework consists of three primary components:

1. LLM Agent (MCP Client): Running within a host application (Claude Desktop powered by Claude Sonnet 4.0), this component interprets natural language requests, decomposes complex tasks, orchestrates tool calls, and maintains conversational context. It acts as the cognitive core, planning multi-step workflows.
2. MCP Server: This intermediary layer abstracts the simulator's Python API into a clean, high-level toolset. Built using FastMCP, the server exposes typed Python functions as tools with defined inputs, outputs, and usage descriptions. This decoupled architecture allows the LLM to interact with the simulator without needing model-specific customization, enabling seamless migration across different LLMs.
3. Process Simulator Integration: The MCP server connects to APS (version 2025) via its scripting interface. A curated set of tools encapsulates APS API calls into meaningful operations (e.g., aps_connect, sim_create, model_add, var_set_multiple, fluid_create). This ensures that all deterministic engineering computations remain grounded in APS's physics-based solvers, while the LLM handles the semantic translation of user intent into engineering actions.

Case Studies

The framework was evaluated using a binary water-methanol separation process (distillation) through two distinct case studies:

• Case Study 1 (Analysis & Optimization): The agent was tasked with analyzing an existing simulation flowsheet, identifying improvement opportunities, and iteratively optimizing the reflux ratio to achieve a target methanol purity (>95 mol%).
• Case Study 2 (Flowsheet Synthesis): The agent was evaluated on its ability to construct a simulation flowsheet from high-level specifications under two modes:
  • Step-by-Step Dialogue: The user provided incremental instructions for each step (e.g., adding a column, connecting ports).
  • Single-Prompt: The user provided a single, high-level prompt to construct the entire flowsheet autonomously.

Key Contributions

• MCP-Based Integration: The paper introduces a standardized, vendor-neutral approach to connecting LLM agents with commercial engineering software using the Model Context Protocol, facilitating a decoupled architecture where agents dynamically discover and invoke simulation capabilities.
• Curated Toolset for APS: Development of a comprehensive Python-based toolset that translates natural language commands into rigorous APS operations, covering flowsheet construction, parameter manipulation, and result extraction.
• Dual-Mode Interaction Framework: Demonstration of two interaction paradigms—guided step-by-step construction for educational/oversight contexts and autonomous single-prompt synthesis for rapid prototyping—highlighting the trade-offs between user control and agent autonomy.
• Empirical Evaluation: A rigorous assessment of the agent's capabilities in analyzing complex simulation data, generating process improvement suggestions, and executing iterative optimization loops without continuous human intervention.

Results

The framework demonstrated significant capabilities in both analysis and synthesis tasks, though with notable limitations requiring human oversight.

Analysis and Optimization (Case Study 1)

• Data Extraction: The agent successfully connected to APS, retrieved flowsheet topology, and extracted key variables (e.g., 356 out of 2006 variables) to generate a structured summary of the process.
• Improvement Suggestions: The agent generated a comprehensive list of 11 potential improvements (e.g., increasing stages, optimizing reflux ratio, heat integration). While most suggestions were technically sound (rated "Very Good" or "Good"), some lacked context-specific relevance (e.g., suggesting reactive distillation for a non-reactive separation) or contained minor inaccuracies regarding tray efficiency assumptions.
• Iterative Optimization: The agent successfully executed an iterative loop to adjust the reflux ratio, achieving the target methanol purity (95.1 mol%) from a baseline of 84.2 mol%. It correctly identified the energy trade-off (6% increase in duty).
• Limitations: The agent exhibited minor calculation errors in derived metrics (e.g., percentage changes) and generated economic estimates based on training data rather than verified sources. It also occasionally offered "overly optimistic" observations without critical caveats.

Flowsheet Synthesis (Case Study 2)

• Step-by-Step Mode: The agent reliably followed incremental user instructions to construct the flowsheet, correctly handling tool calls for adding models, connecting ports, and setting variables. This mode proved effective for educational contexts where users maintain granular control.
• Single-Prompt Mode: The agent demonstrated high autonomy, constructing a functional flowsheet from a single prompt. It successfully selected thermodynamic models (NRTL), configured equipment, and set operating parameters.
• Technical Issues: In the single-prompt mode, the agent attempted to set variables that were unspecified in the APS interface (e.g., distillate flow rate as a direct input) and made premature parameter adjustments (e.g., setting contact efficiency before switching to "Solve" mode). It also failed to recognize that certain port names could not be retrieved programmatically, requiring user intervention for connections.
• Convergence: In both modes, the framework relied on human intervention to switch the simulation from "Configure" to "Solve" mode, as this step frequently triggers convergence issues requiring expert diagnosis.

Significance and Claims

The paper claims that this framework represents a valuable step toward democratizing access to advanced chemical process simulation capabilities without compromising engineering standards.

• Collaborative, Not Replacement: The authors position LLM agents as collaborative tools that augment, rather than replace, engineering expertise. The framework is designed to assist experienced practitioners by automating routine data extraction and brainstorming, while guiding novices through complex workflows.
• Safety and Rigor: By keeping the deterministic physics-based solver (APS) as the execution engine and using the LLM only for orchestration and semantic translation, the framework maintains the safety and reliability required for industrial applications. The simulator itself provides a layer of automatic validation for physical laws.
• Educational and Practical Value: The system shows promise as an educational tool for translating technical concepts and demonstrating workflows, and as a productivity tool for experienced engineers to accelerate preliminary design and optimization.
• Future Directions: The authors acknowledge current limitations, including the need for expert oversight to correct hallucinations, calculation errors, and context-specific misinterpretations. They propose future work involving Multi-Agent Systems (MAS) with specialized roles (e.g., thermodynamics, troubleshooting), Retrieval-Augmented Generation (RAG) for domain knowledge, and expanded toolsets for sensitivity analysis and optimization to handle more complex industrial flowsheets.

In conclusion, the study demonstrates that LLM-based agents can effectively serve as intelligent interfaces for chemical process simulators, bridging the gap between natural language intent and rigorous engineering execution, provided that human oversight remains integral to the workflow.