Technical Roadmap

This document outlines the technical architecture and phased development path for FEA Sidekick. FEA workflows face two bottlenecks — long model development times (especially meshing) and long solution times — and each phase of this roadmap targets a progressively harder bottleneck.

Phase 1: Model-Aware Meshing

The proof of concept is the near-term wedge. It does not require ML; it uses the model deck itself to understand where accuracy matters and produces adaptive meshing recommendations. Four milestones define the PoC:

• Parse CalculiX/Abaqus-style input decks (via tree-sitter) into an open model format that captures both syntax and semantics.
• Build a linked model graph that connects syntax and semantics (sets, surfaces, steps, BCs/loads, materials, contacts) to mesh connectivity.
• Produce adaptive meshing recommendations that prioritise the regions that matter: load introduction points, constraint boundaries, contact interfaces, and material transitions.
• Close the loop with CalculiX: remesh, rerun, and quantify gains on a small benchmark suite (time-to-QoI, iteration count, DOFs) versus baseline meshing.

Phase 2: The Claude Code Moment for FEA

The second objective is to build a “Claude Code” moment for FEA — an AI agent that understands the model and automates labour-intensive tasks such as meshing, contact definition, and boundary condition specification. The architecture should ideally comprise two tiers: a physics-informed model layer that understands the model tree and uses graph neural networks (GNN), and a conversational LLM layer that interacts with the user.

The physics-informed model layer uses GNN to tokenise 3D geometries and tree-sitter grammar to construct model trees. This enables the model to predict optimal meshing strategies based on load definitions, anticipate convergence issues before they occur, and recommend solver control variables.

The LLM layer would converse with the user and call into the physics-informed model layer via MCP (Model Context Protocol). MCP is a standardised tool-calling protocol — it lets an external LLM (e.g., Claude, OpenAI) discover and invoke specific capabilities exposed by the application: mesh suggestions, convergence risk checks, solver control recommendations. The two internal layers do not talk to each other through MCP; they communicate via regular code (Python function calls, message passing). MCP is the interface to the external LLM, not the internal bus.

The model graph constrains which changes the LLM can propose, preventing the generation of syntactically valid but physically nonsensical input decks — a known failure mode of current AI modelling assistants when applied to FEA.

A future extension is pre-processor integration: allowing the LLM to apply suggested changes directly in the modelling environment. Most major pre-processors (Abaqus CAE, HyperMesh, ANSA) expose Python APIs for this. Rather than wrapping these in MCP, the application core would call the native APIs directly — MCP is only necessary when an external LLM needs a standardised schema to discover and call tools. If both ends are controlled internally, direct API calls are simpler and more performant. The architecture would be: the LLM calls MCP tools; MCP tools call the application core; the core calls pre-processor APIs natively.

This dual-layer architecture enables advanced future applications, such as recommending surrogate or reduced-order FEA models based on target output variables. For example, the agent could automatically analyse multiple output databases from WAAM multi-physics models to calibrate eigenstrain values for rapid distortion prediction in complex parts using the eigenstrain method.

Phase 3: Solver-Level Acceleration

The most ambitious objective is to use the agent to accelerate the solver in real time, ideally through AI-driven adaptive re-meshing. The goal is to adaptively remesh the model at every step based on a physics understanding.

Also, methods such as Jacobian or tangent initialisation could reduce solution times by orders of magnitude. Currently, this initialisation relies on the converged solution from the previous increment. If a physics-informed model can predict the displacement field at the next increment to within the basin of quadratic convergence for Newton-Raphson, the solver reaches convergence in significantly fewer iterations. The actual improvement depends on the problem: for mildly nonlinear problems, a sufficiently accurate initial guess can yield convergence in 1–2 iterations; for highly nonlinear problems (large deformation, contact, buckling), more iterations may still be required even with a good initial guess. The time saving also varies by FEA formulation (e.g., Newton-Raphson vs. line search). In all cases, the solver still converges to the true solution — the AI provides a better starting point, not a shortcut — so mathematical rigour is maintained.

The primary obstacle is that this capability requires tight integration with the solver, necessitating partnerships with solver developers. This represents a future goal that requires establishing company reputation first. Nevertheless, this represents the holy grail of AI for FEA: a method promising both speed and reliability.