AI-Powered Abaqus Simulation: With vs. Without Skills — The Results Are Worlds Apart

Introduction: Can AI Handle Engineering Simulation Reliably?

Abaqus is a cornerstone tool in mechanical, materials, and structural engineering. Developed by Dassault Systèmes under the SIMULIA brand, it sees widespread use in aerospace, automotive, civil engineering, and biomedical applications — particularly for nonlinear problems such as material plasticity, large deformation, and contact/impact. Finite Element Analysis (FEA) fundamentally works by discretizing complex structures into small elements and solving mechanical equations numerically. The learning curve is steep, the parameters are numerous, and setting up a model typically demands significant time from experienced engineers. Recently, more and more teams have been experimenting with connecting large AI models to Abaqus, hoping to automate the entire workflow — from modeling and meshing to material assignment and solving — using natural language instructions.

However, a Bilibili content creator ran a controlled experiment that revealed a striking conclusion: when it comes to AI-driven Abaqus simulation, whether or not you load a "Skills" package makes an almost night-and-day difference. Without Skills, the AI produces nothing useful. With Skills loaded, it effortlessly generates batch stress contour plots. This gap cuts right to the core challenge — and the core solution — of deploying AI Agents in specialized engineering domains.

Experiment 1: No Skills, AI Simulation Ends in a Half-Finished Mess

The task was straightforward: have the AI complete a simulation of a ball penetrating a steel plate. The creator loaded a GPT-based plugin into Abaqus, cleared all default Skills, and tested the AI's performance with zero domain-specific guidance.

The result? In about a minute, the AI generated the ball and plate geometries, assigned material properties, and even configured a full set of parameters — plasticity, yield hardening, elasticity, density, ductile damage, damage evolution, and failure displacement. On the surface, this looked impressively professional. These parameters correspond to a complete mechanical response chain for metals under high-velocity impact: plasticity and hardening describe material flow beyond the yield point, while damage evolution and failure displacement control when elements are deleted to simulate penetration — core elements of the widely-used Johnson-Cook constitutive model framework.

But the devil was in the details. The creator pointed out that the AI set the density value to 7850 — a number that clearly ignored the unit system conventions required by Abaqus. This is a fundamental trap in engineering simulation: Abaqus has no built-in unit system, so users must ensure all inputs are self-consistent within a chosen unit framework. In the mm-N-tonne system commonly used in the automotive industry, the mass unit is tonne (1 tonne = 1000 kg), making the density unit tonne/mm³. Steel has a density of approximately 7850 kg/m³, which converts to about 7.85×10⁻⁹ tonne/mm³ — not 7850. The value the AI entered effectively inflated the steel's density by a factor of roughly one billion, completely distorting the mass inertia calculations. To make matters worse, the assembly step was never completed. In the end, with no Skills to guide it, the AI produced absolutely no usable results.

This demonstrates a clear limitation: general-purpose large language models may "know" the broad strokes of a simulation workflow, but they lack precise mastery of the engineering conventions specific to a given tool — unit systems, assembly sequences, boundary condition standards — and can easily fail on the parameters that matter most.

Experiment 2: With Skills Loaded, AI Executes Flawlessly

For the comparison, the creator pre-downloaded two Skill files — a "mesh generation" skill and a "ball penetrating steel plate" skill — imported them into the plugin, started a fresh model, and issued a more complex instruction: use the Skills to simulate three balls penetrating a steel plate at different velocities.

The difference was dramatic. The AI correctly matched the "ball penetrating steel plate" and "sphere mesh generation" skills and executed each step in sequence:

• Meshing: Completed fully automatically, with no manual intervention;
• Boundary conditions: Three separate velocities assigned to the three balls (-12000, -8000, -16000);
• Interactions: General Contact configured automatically;
• Job creation and submission: Submitted with one click and solved quickly.

From model setup to solution, nearly the entire process was handled independently by the AI — the engineer only needed to click submit at the appropriate moment. The contrast with Experiment 1's half-finished output could not have been sharper.

From "No Results" to "Plate Penetrated": Iterating Through the Parameters

Interestingly, the first solve run did not result in the balls penetrating the plate — the velocities were too low, and the kinetic energy wasn't enough to cause full penetration failure. The creator then raised the third ball's velocity from 16000 to 32000 and resubmitted — still no penetration. At 64000, the plate was finally successfully breached. This "adjust velocity → solve → observe" iteration loop vividly demonstrates the physical principle that higher velocity means greater kinetic energy means more pronounced damage. Physically, the velocity jumps correspond to a qualitative shift from elastic indentation to complete penetration, driven by the coupling of stress wave propagation, adiabatic shear band formation, and material failure — which is precisely why high-velocity impact simulation is so highly nonlinear.

This phase also makes an important point: Skills solve the problem of process correctness, but the reasonableness of physical parameters still requires an engineer's judgment. AI can ensure the model runs without errors and produces valid output, but getting results that match engineering intent still requires human involvement.

Why Are Skills the Key to AI-Driven Simulation?

This pair of experiments illuminates the core methodology for deploying AI Agents in specialized professional domains: general-purpose model + domain-specific skill packages.

Skills Are Essentially "Encapsulated Expert Knowledge"

AI Agents are the dominant paradigm for deploying large models in real-world applications. The core idea is to enable large language models (LLMs) to go beyond text generation — to take real-world actions by calling external tools, APIs, or functions. In the Abaqus context, the AI Agent issues Python script commands to the software through a plugin interface, effectively acting as a "thinking macro recorder." Skill files are a combination of predefined tool schemas and operation scripts that tell the LLM what a tool can do, what parameters it needs, and in what order to invoke it — translating vague natural-language intent into a precise engineering operation sequence.

General-purpose LLMs have broad knowledge, but engineering simulation demands precise, standardized, and reproducible operation sequences. A Skill file packages an expert's complete workflow — correct unit systems, meshing strategies, boundary condition templates, material parameter specifications — into a callable "skill module" for the AI. When the AI matches the right Skill, it effectively executes the task "standing on the expert's shoulders."

A Downloadable, Extensible Capability Ecosystem

The design philosophy behind Skills packages is closely aligned with two major ideas in AI research: RAG (Retrieval-Augmented Generation) and Tool Learning. RAG's core insight is that rather than hard-coding all specialized knowledge into model weights (expensive and slow to update), it's more efficient to dynamically retrieve the necessary knowledge at inference time. Skills function like an "expert knowledge base": when the AI receives a task instruction, it first retrieves the best-matching operation template from the skill library, then executes it with the specific parameters provided. This architecture — general-purpose model backbone + domain knowledge plugins — has become the mainstream approach for enterprise AI deployment. Commercial products such as Microsoft Copilot and Salesforce Einstein adopt similar strategies.

The creator mentioned that the newer version of the plugin supports the AI autonomously acquiring and downloading Skills, and that the developer will continue releasing new skills for users. This means Skills are forming an extensible capability ecosystem: when a new type of simulation task arises, simply download or write the corresponding Skill, and the AI quickly gains that new capability — no model retraining required. This aligns closely with the mainstream direction of AI Agent development: rather than trying to make a single model capable of everything, the goal is to decouple general capability from specialized knowledge through tool calling, skill plugins, and knowledge injection — each doing what it does best.

Summary and Takeaways

This "produces nothing vs. generates batch stress plots" comparison offers several lessons for AI applications in engineering:

First, general-purpose LLMs are not reliable for direct professional simulation. They are especially prone to errors on details like unit systems and parameter conventions, ultimately producing invalid results.

Second, Skills packages are the critical bridge that makes AI genuinely usable. By structurally encapsulating expert knowledge, they dramatically improve the accuracy and success rate of AI-executed professional tasks.

Third, AI is not replacing engineers — it is reshaping how they work. Repetitive tasks like modeling, meshing, and boundary condition setup can be delegated to AI, while engineers focus on physical reasoning, parameter validation, and results interpretation. Human-AI collaboration is the most pragmatic path forward today.

As Skills continue to accumulate across more domains, the barrier to AI-assisted FEA is likely to drop further. This may well mark an important starting point for an efficiency revolution in the CAE industry.