Debugging Large GT-SUITE Models with GT Intelligence Studio

A modern engine or vehicle model is no longer a diagram an engineer holds in their head. A production-grade turbocharged diesel model carries hundreds of parts, dozens of distinct templates, and a web of reference objects: maps, profiles, and data tables shared across multiple parts, often inherited from a colleague, a supplier deliverable, or a model built three program cycles ago. That structure is what makes the model reusable. It is also what makes it opaque when something breaks.

When a solver stops, it reports the template where the failure occurred, which narrows the search but does not by itself identify the value responsible. The engineer then has to trace through the model to find what caused it. In a large model, finding the problem often takes far longer than fixing it. The actual fix may be as simple as correcting one row in a data table.

The Engineering Challenge Behind Debugging Large System Models

Error messages in 1D system simulation are precise about the failure condition and deliberately non-committal about the cause, because the same condition can arise several ways. A single compressor map error can mean any of the following:

• Bad imported data — a speed line with too few points to interpolate, a duplicated row, or a unit mismatch introduced during map conversion
• Over-restrictive tolerance settings — a Tolerance for Speed Line Spread value that is legitimate for one map and too tight for another
• A reference object mismatch — the part points at a map object that was edited for a different build or a different turbocharger frame size
• Extrapolation limits — a maximum speed limit or map extent that no longer covers the operating range after a boost target changed

Each of these produces a similar message. Distinguishing between them requires opening the object, reading the raw data table, counting points per speed line, and cross-checking against the template documentation. In a model with several hundred parts, the engineer must first work out which object is even being referenced, a compressor map may be defined once and used by several parts, or several near-identical map objects may exist with only one in the active case.

This is a search problem before it is an engineering problem. The engineering judgement takes seconds. The search takes the afternoon.

Diagnosing a Compressor Map Failure with AI.modeler and AI.advisor

GT Intelligence Studio pairs two agents that address the two halves of that problem. AI.advisor is the GT-SUITE knowledge agent: it interprets error messages, template behaviour, and attribute semantics against GT-SUITE documentation. AI.modeler is the modeling agent: it operates inside GT-SUITE, reads and writes objects, edits attributes, and runs the model.

The two are not used sequentially by the engineer. AI.modeler consults AI.advisor on its own during diagnosis, then acts on the answer. The walkthrough below is taken from a recorded session on a four-cylinder turbocharged diesel model with EGR rate control, a semi-predictive intercooler, model-based VGT control, and smoke-limited fuel injection.

The Failure

The following example shows how AI.modeler and AI.advisor work together to diagnose and resolve the error. Starting with only the solver error message, the agents identify the problem, determine its root cause, apply the correction, and verify the result.

*FAIL: Error encountered on speed line 3 with a corrected speed of 163891. RPM. Please check number of points on speed line and add more points if fewer than three points have been used. This message might also be triggered if the restriction imposed by the Tolerance for Speed Line Spread attribute is too strict… Error encountered in: CompressorMap/CompressorMap. Stopping the Run

The message offers two candidate causes and no way to choose between them without opening the data.

Figure 1 — The CompressorMap failure in the context of the full model. The message identifies the template and the speed line, but not which of the two suggested causes applies. Resolving that ambiguity by hand means leaving the model and opening the template documentation.

The five steps below trace that session in the order it happened: reading the error, locating the object it points to, inspecting the data table, applying the correction, and verifying the run.

Step 1: A single natural-language prompt

The engineer pastes the error into AI.modeler with one instruction: “I have an error in this model. Can you correct it?” No object path, no attribute name, no pointer to where in the model tree to look.

Figure 2 — The complete engineer input. Everything downstream — object lookup, documentation query, table edit, verification run — is initiated from this one prompt.

Step 2: Locating the referenced object

AI.modeler lists the objects in the model and isolates CompressorMap as the object referenced by the failing part. It then consults AI.advisor to establish what the error condition means at the template level, specifically the minimum point count GT-SUITE requires per speed line and how the Tolerance for Speed Line Spread attribute interacts with it. This is the step that resolves the ambiguity in the original message.
• Enumerates model objects and resolves the reference from the failing part
• Consults AI.advisor for template-level semantics rather than guessing from the message text
• Narrows to the two candidate causes and establishes a test that separates them

Figure 3 — AI.modeler consulting AI.advisor mid-diagnosis. The agent trace is visible in the panel: list objects, consult, then inspect. The engineer is not orchestrating these steps.

Step 3: Reading the data table and isolating the cause

AI.modeler reads the CompressorMap object twice — once for attribute settings, once for the raw table — and counts points per speed line.

AI.modeler then reports back in the chat panel:

Found the problem. The Data Table has a single stray data point at ~163,891 RPM (row 20, 0-indexed) sandwiched between the 143,891 and 171,730 RPM speed lines. Every other speed line has 6–11 points, but this one has exactly 1 point — which is below the required minimum of 3. It needs to be removed.

The diagnosis is clear: the tolerance is not causing the error. Instead, a stray data point, likely introduced during data import or copy-pasting, is being interpreted as a separate speed line.

Figure 4 — Root cause identified. One orphaned point at ~163,891 RPM, read by the solver as a speed line, against neighbouring lines carrying 6–11 points each. The agent states the row index and the reason it fails, not just that something is wrong.

Step 4: Applying the fix across all four columns

The agent confirms the attribute is an array type and edits the table directly, removing row 20 from all four columns simultaneously — Speed/Corrected (RPM), Mass Flow Rate (MASS), Pressure Ratio (PR), and Efficiency (EFFI). Since these four columns contain the corresponding values for each data point, row 20 must be removed from all four columns to keep the data consistent. The table resolves to 65 rows across seven clean speed lines:

AI.modeler then saves a checkpoint of the model before proceeding, and flags a secondary observation the engineer did not ask about: whether the maximum speed limit setting (RPMMAX), currently 260,000 RPM, remains appropriate for a seven-line map. That is a matter of engineering judgement, and the agent leaves it with the engineer rather than changing it.

Figure 5 — The applied fix and the resulting speed line structure. All four columns edited together, 65 rows across seven clean speed lines, and the maximum speed limit observation raised for engineer review rather than silently changed.

Step 5: Verification

The model is re-run from GT-SUITE. The case sweep executes, the flow and ODE clusters reach steady state, and the compressor and turbine report converged performance. The failure is closed by a successful run, not by an assertion that the fix should work.

Figure 6 — The post-fix run. Converged steady-state solution across the case sweep. Verification is part of the same session, so the engineer never has to re-establish context to check the result.

From an engineer’s perspective, the workflow remains simple: describe the problem, review the diagnosis, and make the engineering decisions. The agents handle the search, documentation lookup, model inspection, correction, and verification.

Where the Time Actually Goes

The engineering content of this fix is one deleted row. The cost is in everything around it and that is what the two agents compress:

• Message interpretation. The original error lists two possible causes. Resolving which one applies normally means opening the template documentation. AI.advisor resolves it during the diagnosis, without the engineer leaving GT-SUITE.
• Object location. In a model with hundreds of parts and shared reference objects, identifying the specific object instance behind a failing part requires manually searching through the model. The agent resolves the reference directly.
• Data inspection. Counting points per speed line across a 66-row, four-column table is mechanical work with a real error rate when done by eye.
• Multi-column consistency. Editing all four columns together is the kind of step that is obvious in hindsight and easy to get wrong at 6 p.m. on a deadline.
• Knowledge transfer. An engineer who did not build the model — a new hire, or someone inheriting a program — needs no prior familiarity with this model’s object structure to complete the fix.

The Role of Agentic Debugging in Model-Based Development

Model debugging has historically scaled badly with model size: the larger and more reusable the model, the further the distance between the reported symptom and the responsible number, and the more that distance depends on an individual engineer’s familiarity with a specific file. Pairing a knowledge agent that interprets GT-SUITE behaviour with a modeling agent that can read objects, edit attributes, and run cases inside GT-SUITE changes what that distance costs. In the compressor map case above, the engineer supplied one pasted error message and two decisions — whether the diagnosis was right, and whether the maximum speed limit still suited a seven-line map. Everything between those two points, the object lookup, the documentation check, the four-column edit and the verification run, was absorbed by the agents. The shift is from debugging as a search through the model to debugging as a conversation about it.

Discover how GT Intelligence Studio can accelerate your own modeling workflow. Visit the GT Intelligence Studio product page to learn more about AI.advisor, AI.coder, and AI.modeler, join our LinkedIn community to stay updated on simulation-driven workflows, and contact us to see a walkthrough. Subscribe to the GT blog to receive updates on new AI capabilities, engineering solutions, and industry trends.

Frequently Asked Questions

Does AI.modeler change my model without asking?
AI.modeler edits objects and attributes directly, and saves a versioned checkpoint of the model before applying changes so any edit can be reverted. Where a change involves engineering judgement rather than a clear defect , the agent raises the question and leaves the decision with the engineer.

What does AI.advisor do that searching the GT-SUITE documentation does not?
AI.advisor answers against GT-SUITE documentation in the context of the model that is open, so a question about a template attribute returns an answer tied to how that attribute is actually set in your file. It is also queried by AI.modeler during diagnosis, which means the documentation lookup happens inside the debugging workflow instead of in a separate browser tab.

Can these agents work on models they did not build, including legacy files from a previous program?
Yes. The agents operate on the model’s object structure as it exists in the file, so no prior familiarity with the model, its naming conventions, or its author’s intent is required. This matters most for inherited models, where the engineer debugging the file is rarely the engineer who built it.