Introduction .

The Abaqus INP

Comprehensive Analyzer

Learning Center Companion Reader

A Guided Walkthrough

Combating Engineering Mind Blindness

Joseph P. McFadden Sr.

The Holistic Analyst  ·  McFaddenCAE.com  ·  McFadden@snet.net

Companion to the audiobook edition  ·  Version 26.1  ·  June 13, 2026

Developed in collaboration with Claude (Anthropic)

‍ ‍

Contents

Contents.............................................................................. 1

Introduction........................................................................ 1

The First Why — Who Gets to Read a Simulation?............ 1

The Deeper Why — Combating Engineering Mind Blindness............................................................................ 1

The Holistic View................................................................ 1

A Guided Walkthrough of the Five Categories................... 1

1. Analysis Types............................................................. 1

2. Materials..................................................................... 1

3. Best Practices.............................................................. 1

4. Behind the Scenes....................................................... 1

5. Reference..................................................................... 1

How to Use This Book........................................................ 1

A Word on the Collaboration.............................................. 1

‍ ‍

Introduction

What you’re reading is a companion to two things: a piece of software, and the book that grew up beside it. The software is the Abaqus INP Comprehensive Analyzer. The book is its Learning Center Companion Reader. Over the next little while, I want to walk you through both — not feature by feature, but idea by idea. I’ll start with the why, because the why is the whole point. Then I’ll take you category by category through the Reader, so that when you open it, you already know where everything lives and how to find what you need.

This walkthrough, the Reader it describes, and the tool itself were developed in collaboration with Claude, from Anthropic. I’ll come back to what that partnership means near the end. For now, let’s begin where every good analysis begins — with a question.

The First Why — Who Gets to Read a Simulation?

Here is the question. Who actually gets to read a simulation?

A finite element model lives in a file. In the Abaqus world, that file is the input deck — the .inp. It is the single source of truth for the entire analysis. Every node, every element, every material card, every load and boundary condition, every contact definition — all of it is written down in that one text file. If you want to know what a simulation really assumed, you don’t look at the colorful contour plot. You look at the input file.

And yet, for decades, reading that file required an expensive solver license and years of practice. The people who most needed to understand the model often could not even open it. The industrial designer who shaped the housing. The program manager deciding whether to ship. The young engineer learning the craft. The reviewer on a different network, far from a license server. All of them locked out of the very document that decides whether a product survives a drop, a shock, or a lifetime of vibration.

The Abaqus INP Comprehensive Analyzer was built to remove that lock. It opens any input file. It renders the model in three dimensions. It summarizes the bill of materials and the loading. It checks the material cards against best practice. And then it explains, in plain language, what it found — all without a solver license. That is the first why: to put the truth of the analysis back into the hands of everyone who has a stake in it.

The Deeper Why — Combating Engineering Mind Blindness

But a reviewer that only reports is doing half the job. The deeper why lives in a phrase I’ve carried for years: combating engineering mind blindness.

Mind blindness is the quiet failure mode of our profession. It is not the model that crashes. A model that crashes is honest — it tells you something is wrong. Mind blindness is the model that runs cleanly, finishes overnight, produces a beautiful stress plot, and is completely, confidently wrong, because a single assumption went unexamined.

I’ve seen it take many shapes. Mass scaling that quietly multiplied the inertia of the whole model, so a drop test reported forces that could never happen. A unit system error that turned five milliseconds into five seconds, off by a factor of a thousand, with no warning at all. Quasi-static material data — measured slowly, in a lab — driving a high-rate impact event, making a brittle part look tough. A single-point fracture value standing in for a material that tears at one strain in tension and a very different strain in shear. None of these throw an error. Every one of them misleads. The simulation looks plausible. The physics is fiction.

So the tool was designed to do what mind blindness cannot survive: to surface the questions. To notice the quiet assumption and say it out loud. Not to overrule the engineer — never that — but to make sure the engineer is choosing the assumption, rather than inheriting it by accident.

The Holistic View

And that is where the holistic view comes in, because checking a model is not enough. You have to understand it. It is not enough to be told that a displacement-based damage law is mesh-sensitive, or that slow material data is unsafe for a fast event. An engineer deserves to know why — well enough to argue it, well enough to defend it in a design review, well enough to feel it in the gut before the solver ever runs.

The holistic analyst doesn’t start with the mesh. The holistic analyst starts with the material — with how it actually behaves when you bend it, drop it, freeze it, or load it a thousand times a second. Glass is not a number; it’s a population of invisible surface flaws waiting for a tensile stress to find the worst one. A polycarbonate housing is ductile at room temperature and brittle in the cold. A weld line, where two flow fronts met inside the mold, can cut a material’s strain-to-break from a hundred percent down to fourteen. If you model the material as a tidy constant, you will be precisely, elegantly wrong. The holistic view asks you to respect the nature of the thing before you trust the number.

That is the spirit the Learning Center was written in. It does not just hand you rules. It teaches the reasoning behind the rules. And this Reader gathers all of that reasoning into one place — free, and meant to be read. Whether you are a student meeting modal analysis for the first time, or a seasoned analyst calibrating a ductile damage model at impact rates, the goal is the same: to make the reasoning visible.

A Guided Walkthrough of the Five Categories

So let’s open the Reader together. It is organized into five categories, in a deliberate reading order. We move from what analyses exist, to the materials they act on, to how to do the work well, to how the tool itself reasons on your behalf, and finally to a quick reference. Each topic carries a difficulty tag — beginner, intermediate, or advanced — so you can calibrate where to start. Let me walk you through all five.

1. Analysis Types

This is the lay of the land — the families of simulation you’ll meet in structural work, and how each one is built. We begin gently, with modal analysis: finding the natural frequencies and mode shapes of a structure, the equivalent of discovering the natural notes a guitar string wants to sing. From there it broadens. Shock analysis, for transient dynamic events. The shock response spectrum, for characterizing how a structure answers a sudden jolt. Random vibration, where the loading is described by a power spectral density rather than a single history. Harmonic response, for steady-state vibration. And static analysis, the implicit, patient cousin of the explicit world.

The category closes with three short pieces on step sequences — how you actually stack the pieces of a simulation in order: for static and quasi-static jobs, for impact and drop, and for perturbation and vibration. Think of this category as the map you consult first. If you’re not yet sure which kind of analysis your problem even is, start here. The beginner topics — modal and static — are the natural front door.

2. Materials

This is the heart of the Reader, and the largest of the five, with seventeen topics, because materials are where holistic thinking pays off the most.

It opens, fittingly, with glass — beginning with the nature of glass as a lived, flawed, statistical material, then moving into thin brittle modeling, Weibull statistics and fracture criteria, and the subtle world of edge quality, the heat-affected zone, and bend-radius design. From glass it moves through the families you meet every day: plastics and how they really fail; metals — steel, aluminum, and magnesium, in wrought, cast, and die-cast forms; elastomers and silicones, modeled as hyperelastic materials rather than with a simple modulus; and foams, like Poron, for cushioning and compressible seals.

Then it turns to the cross-cutting truths. There are guides to choosing materials for drop and impact, for static and structural work, and for modal and frequency analysis. There is a deep, careful topic on damage and failure modeling — ductile, brittle, and energy-based — which I think is the most important advanced topic in the whole book, because it’s the easiest to get wrong. And there are two essential companions: strain-rate dependency and temperature dependency, each comparing how metals, plastics, and glass respond when you load them faster or chill them down. The category is crowned by the holistic materials approach itself — the philosophy that ties the rest together. If you only read one category slowly, make it this one.

3. Best Practices

If the first two categories tell you what you’re doing, this one tells you how to do it without fooling yourself. There are seventeen topics here, and many of them are the hard-won habits that separate a defensible analysis from one that merely looks finished.

This is the home of the famous traps. Mass scaling and the unit-system traps — the silent killer I mentioned earlier, where a hidden factor of a thousand or a million quietly corrupts your inertia. The millisecond time trap, where the units look right and the physics is off by orders of magnitude. Alongside the traps are the constructive skills: energy-balance validation, so you can prove an explicit run is physical and not just pretty. Hourglassing and how to control it. Bulk viscosity for shock waves. Mesh convergence studies. Element selection and element types. Contact formulations, general versus pairs. Stabilizing a static analysis that has contact. Overmold and multi-part assembly with tie constraints. And output requests and post-processing, so you ask the solver for the right data in the first place. Reach for this category when your model runs but you don’t yet trust it. The answer to “why don’t I trust it” is almost always somewhere in here.

4. Behind the Scenes

This is the most unusual category, and in some ways the most honest. With nineteen topics, it pulls back the curtain on the tool itself — how it reasons, what it assumes, and where its limits are.

Some of these are guides to specific instruments inside the tool: the output request builder, the impact and drop analysis, the projectile and ball-drop evaluator, the boundary-condition and load viewer, the interaction viewer, the contact analysis, the surface-correction tool, and the convert-for-HyperMesh path. Others explain the quiet machinery: how three-dimensional rendering works in tessellated versus actual-mesh mode, how assembly instance transforms position your parts, how the tool merges nodes and handles a flat orphan mesh, how it tells engineering stress-strain from true stress-strain, and how it detects coincident surfaces and classifies your simulation’s intent.

But the two topics I’d point a new user to first are the most candid ones: the assumptions and limitations of the tool, and the engineering judgment notice. Together they say, plainly, that everything the tool reports is advisory. The tool surfaces questions. You answer them. It does not replace verification, validation, or the responsibility that comes with signing your name to an analysis. Read those two early, and you’ll read everything else in the right spirit.

5. Reference

It’s the smallest — just two topics — and it’s exactly what the name suggests. A complete guide to every item in the Tools menu, so you always know what each command does. And a clear explanation of the Abaqus step approach — how a simulation is built up, step by step, into the sequence the solver actually runs. This is the category you’ll return to quickly, mid-task, when you just need to confirm one thing and get back to work.

How to Use This Book

So how should you actually use this book? You can read it cover to cover, and the order is deliberate if you do. But you don’t have to. Every topic is written to stand on its own, and the difficulty tags are there to guide you. If you’re new, follow the beginner topics across the categories first — modal analysis, static analysis, understanding unit systems, the assumptions and limitations. If you’re experienced, dive straight into the advanced material on damage, fracture, and contact, and use the rest as reference. And whatever your level, let the cross-references carry you. The topics talk to each other, the way the physics does.

Everything in this Reader, and every flag the tool raises, is advisory. The tool surfaces the question. The engineer answers it. Trust nothing you cannot explain. That sentence is the difference between using a tool and being used by one.

A Word on the Collaboration

This Reader, the Learning Center it compiles, and the analyzer itself were developed together with Claude, from Anthropic. I want to be clear about why that matters, because it isn’t a footnote. The method here is to combine decades of hands-on simulation judgment — the kind that only comes from watching real parts crack on real test rigs — with a tireless partner for drafting, for checking, for explaining the same idea five different ways until it lands. The judgment is human. The reach is shared. And the aim, start to finish, has been to get the reasoning into the hands of as many engineers as possible. That, in the end, is what combating engineering mind blindness really means: not smarter software, but more engineers who can see.

Thank you for reading. This has been Joe McFadden.

Combating engineering mind blindness.

Engineer. Lifelong Learner. Holistic Analyst.

www.McFaddenCAE.com  ·  McFadden@snet.net

Have a thoughtful and wonderful day.

What’s New

Version 27.4

ABAQUS INP COMPREHENSIVE ANALYZER

V27.4

Documentation Library

A Reading Guide to the Analyzer Manuals & Walkthroughs

Joseph P. McFadden Sr.

The Holistic Analyst  •  Combating Engineering Mind Blindness

www.McFaddenCAE.com  •  McFadden@snet.net

June 2026

Developed in collaboration with Claude (Anthropic).

‍ ‍

Contents

About This Library............................................................. 3

1  The Library at a Glance................................................... 3

2  Which Guide Should You Read?.................................... 4

By role............................................................................. 4

By task............................................................................ 5

3  The Guides in Detail....................................................... 5

3.1.  Standalone Quick Start Guide................................. 5

3.2.  User Manual........................................................... 6

3.3.  The Student’s Guide to Finite Element Simulation 6

3.4.  The Analyst’s Orientation Guide............................ 6

3.5.  The Non-Analyst’s Orientation Guide.................... 6

3.6.  Peeking Under the Hood........................................ 7

3.7.  Reading the Comprehensive Report....................... 7

3.8.  Loads & Boundary Conditions Walkthrough......... 8

3.9.  Evaluating Random & Modal Analysis Models...... 8

3.10.  Evaluating Impact Analysis Models..................... 8

3.11.  Evaluating Overmold & Bonded-Interface Assemblies...................................................................... 8

4  How the Guides Fit Together......................................... 9

The common thread....................................................... 9

5  The Document Set.......................................................... 9

‍ ‍

‍ ‍

About This Library

The Abaqus INP Comprehensive Analyzer reads an Abaqus input file — the text file that defines a simulation — and reports what is inside it, in plain language and visual displays, without an Abaqus license or a solver run. This library is the set of guides that explain how to use it. Each guide is written for a particular reader and a particular kind of model, but all of them share one purpose: to make the contents of a simulation visible to the people whose decisions depend on it.

That purpose has a name. Engineering mind blindness is the condition that develops when the people who build, consume, or approve a simulation cannot see what is actually inside the model — when stress contours are trusted because the software produced them, not because anyone verified that the model represents the physical problem. Every guide in this library exists to replace that blind trust with visible evidence: a parts list checked against the bill of materials, a material assignment checked against the spec sheet, a load checked against the test requirement, an interface checked against the physical bond.

Use this reading guide to find the right document for who you are and what you are trying to do. Each guide stands on its own — you do not need to read them in order — but together they cover the full range of work the Analyzer supports, from getting the tool running and reading its first report to a production drop simulation.

1  The Library at a Glance

Guide

Primary audience

What it covers

Standalone Quick Start Guide

Anyone installing or first running the tool

Installing and first-running the Standalone Edition — a single portable program that needs no Abaqus, license, or installation and changes nothing on your computer

User Manual

All users — the complete reference

The complete tab-by-tab and tool-by-tool reference: every tab, the 3D viewer, the Tools menu, the Learning Center, workflows, units, exports, and troubleshooting

The Student’s Guide to Finite Element Simulation

Students and engineers new to FEA

The concepts behind simulation — nodes, elements, materials, solvers, analysis types — using the Analyzer to make the theory concrete

The Analyst’s Orientation Guide

Analysts getting oriented to the tool

Why the tool exists, plus a high-level map of every tab and tool and where to find the detail for each

The Non-Analyst’s Orientation Guide

Designers, program managers, reviewers

Why the tool matters to non-specialists, and how to read and verify a model without an Abaqus license or a solver run

Peeking Under the Hood

Design engineers and program managers

How a non-analyst can verify, in six minutes, that a model represents the product and the test it claims to simulate

Reading the Comprehensive Report

Analysts and reviewers together

How to read the Comprehensive Report from both sides — the analyst who builds the model and the reviewer who must trust it — turning the report into a shared conversation

Loads & Boundary Conditions Walkthrough

Analysts (all model types)

Reading the Step Summary and using the BC & Load Viewer to confirm supports and loads are applied correctly across every step

Evaluating Random & Modal Analysis Models

Analysts (vibration / perturbation)

A step-by-step review of modal and random vibration models, including the eight-point random vibration validation and the PSD tools

Evaluating Impact Analysis Models

Analysts (explicit dynamic / drop)

A step-by-step review of explicit drop simulations — velocity, contact, mass scaling, energy balance, and bonded interfaces

Evaluating Overmold & Bonded-Interface Assemblies

Analysts (multi-part bonded assemblies)

Coincident-surface detection and surface correction for overmold, solder, and adhesive interfaces that must transfer load

2  Which Guide Should You Read?

By role

•      I am setting the tool up for the first time. Read the Standalone Quick Start Guide — it gets the tool running in minutes and explains why it changes nothing on your computer. Keep the User Manual alongside as the complete reference for every tab, tool, and menu.

•      I am learning FEA. Start with the Student’s Guide. It explains what the solver computes and how to tell whether a result is meaningful, then shows how to use the Analyzer to explore real models.

•      I build and submit the simulations. Start with the Analyst’s Orientation Guide to learn why the tool exists and where everything lives, then use the walkthrough that matches your model type — Loads & BCs for every model, plus Random & Modal, Impact, or Overmold as appropriate. When you generate the full report, read Reading the Comprehensive Report (Part I).

•      I design the product but do not run the simulation. Start with the Non-Analyst’s Orientation Guide for the lay of the land, then read Peeking Under the Hood for the focused six-minute verification — both show how to confirm the model contains your materials, your geometry, your bonded interfaces, and the right test setup, without learning Abaqus. If you are handed a report, Reading the Comprehensive Report (Part II) shows how to read it.

•      I approve the program or sign off on the report. Read the Non-Analyst’s Orientation Guide,Peeking Under the Hood, and Reading the Comprehensive Report (Part II). Together they turn a signature based on trust into a sign-off based on evidence.

By task

If you need to…

Read this guide

Install the tool and analyze your first model

Standalone Quick Start Guide

Look up exactly what a tab, tool, or menu does

User Manual

Understand the fundamentals before building anything

The Student’s Guide to Finite Element Simulation

Get oriented to the tool and find where every tab and feature lives (analyst)

The Analyst’s Orientation Guide

Understand the tool and verify a model without running a simulation (non-analyst)

The Non-Analyst’s Orientation Guide

Verify a model you did not build matches the product and the test

Peeking Under the Hood

Read and act on a Comprehensive Report — as analyst or reviewer

Reading the Comprehensive Report

Confirm supports and loads are correct across all analysis steps

Loads & Boundary Conditions Walkthrough

Review a modal or random vibration (perturbation) model

Evaluating Random & Modal Analysis Models

Review an explicit dynamic drop or impact model

Evaluating Impact Analysis Models

Verify bonded interfaces in an overmold or multi-part assembly

Evaluating Overmold & Bonded-Interface Assemblies

3  The Guides in Detail

3.1.  Standalone Quick Start Guide

Audience.  Anyone installing or first running the tool — analysts and non-analysts alike.

Purpose.  To get the Standalone Edition running in minutes, and to make clear that it changes nothing on the computer it runs on.

It explains what the Standalone Edition is — a single, self-contained program that needs no Abaqus, no CAE license, no Python, and no installation — and lays out the no-footprint guarantee: no installer or setup wizard, no administrator rights, no Registry or PATH changes, nothing written to system folders, fully portable, and removed by simply deleting the one file. It covers the system requirements, the copy-and-run install, the Windows SmartScreen and managed-machine antivirus prompts and how to clear them, a first-model quick start across the tabs, where exported files go, and how to update and remove the program.

3.2.  User Manual

Audience.  All users — the complete reference for analysts and non-analysts.

Purpose.  To document the Analyzer in full: every tab, viewer, tool, and menu, plus the workflows and pitfalls that tie them together.

It opens with the Holistic Analyst philosophy and what the tool does and does not do, then covers installation and launch for both the standalone and folder editions and the no-footprint behavior. From there it documents the interface and a section for every tab — Summary, Materials, Material Properties, Material Plots, Sections, Parts, 1D Elements, Recommendations, and Edits — followed by the 3D viewer (tessellated versus actual mesh, and the interface and penetration tools), the complete Tools-menu reference, and the Learning Center and its five categories. It closes with recommended workflows, units and common pitfalls, exports and sharing, and troubleshooting.

3.3.  The Student’s Guide to Finite Element Simulation

Audience.  Students and engineers new to finite element analysis.

Purpose.  To teach the concepts, physics, and judgment behind simulation — not just how to operate software — using the Analyzer as a way to touch real models while learning the theory.

It explains what FEA actually computes, defines the core vocabulary (nodes, elements, mesh, degrees of freedom, stiffness matrix, boundary conditions, loads), distinguishes the implicit and explicit solvers, and walks through the anatomy of an Abaqus model. It covers the four main analysis types — static, modal, random vibration, and impact — and multi-part assemblies with bonded interfaces, then names the five mistakes every student makes and how the Analyzer catches each one. It closes with a structured way to read real models and a set of skills to develop.

3.4.  The Analyst’s Orientation Guide

Audience.  Analysts — anyone who builds, reviews, or submits models and wants to find their way around the tool.

Purpose.  To orient the analyst: the why of the tool, where to learn it, and a high-level map of every tab and feature, with pointers to the deep walkthroughs for each.

It opens with why the tool exists — engineering mind blindness, license-free transparent reading of the model, and the principles that flags are conversations rather than verdicts and that engineering judgment stays with the analyst. It then begins the tour at the Learning Center — more than fifty topics across five categories — before walking, at a high level, through every tab (Summary, the material-evaluation cluster, Parts, 1D Elements, Recommendations, and Edits) and the Tools menu grouped by purpose. It closes with a suggested first pass for an unfamiliar model and a map to the type-specific walkthroughs. It is the connective piece that ties the rest of the analyst library together.

3.5.  The Non-Analyst’s Orientation Guide

Audience.  Designers, program managers, and reviewers — anyone who depends on simulation results without building the model.

Purpose.  To orient the non-specialist: why the tool matters to the people most exposed to mind blindness, how to read what it shows, and how to verify a model without an Abaqus license or a solver run.

It reframes the why around the designer, the program manager, and the reviewer, and sets two boundaries: a flag is a question to bring to the analyst, and the tool supports a stakeholder’s judgment without replacing the analyst’s. It tours the Learning Center at the beginner level, then walks the tabs as the questions they answer — “is my product in here?”, “is it made of the right stuff?”, “what should I ask?” — and highlights the bill-of-materials export and the load and interaction viewers among the tools. It ends with a no-Abaqus first-pass routine that hands off to Peeking Under the Hood for the guided six-minute verification.

3.6.  Peeking Under the Hood

Audience.  Design engineers and program managers — anyone who relies on simulation results but does not build the model.

Purpose.  To let a non-analyst verify, with their own product knowledge, that a simulation represents the physical problem — turning a consumer of reports into a collaborator.

It explains the gap between a report and the model that produced it, then shows the six checks that matter most: the model-type banner, the parts list (compared against the bill of materials, which the Analyzer can export), the materials, the bonded interfaces, the loads and supports in 3D, and the recommendations. It ends with a six-minute review and the upstream questions that visibility lets a stakeholder ask.

3.7.  Reading the Comprehensive Report

Audience.  Both the analyst who builds the model and the reviewer or stakeholder who must trust it — one document, two tracks.

Purpose.  To turn the Comprehensive Report into a shared, neutral basis for an honest conversation — so the analyst’s judgment is visible and the reviewer’s questions land as informed curiosity.

Part I, the Analyst’s Track, reads the report as a pre-flight setup audit — what the model is built from and where the setup carries risk, not results. It establishes that findings are recommendations rather than mandates, explains the High / Medium / Low confidence tags, and prescribes reading in priority order: Tier 1 silent result-corrupters (unit system, mass, material-model traps) first, then Tier 2 cost and accuracy, then Tier 3 validation and connectivity. A section-by-section pass follows, and the track closes on what a clean report does not settle.

Part II, the Reviewer & Stakeholder Track, explains what the report is and is not — the setup plan, not the results — how to read the red / yellow / green tags, the handful of checks a non-specialist can make (total mass against the bill of materials, the unit system, the count of red flags, and whether the run can even be validated), what the common warnings mean in plain language, and a short list of questions that open the conversation. Both tracks converge on one habit: treat the report as the start of a conversation, not the end of one.

3.8.  Loads & Boundary Conditions Walkthrough

Audience.  Analysts working with any model type.

Purpose.  To confirm, before the solver runs, that boundary conditions and loads are applied correctly in the right direction, magnitude, and sequence across every step.

It explains the Step Summary — a color-coded report of every load and boundary condition in the order the solver applies them — including the status tags and the critical distinction between OP=MOD and OP=NEW. It then covers the pre-launch display selector and the BC & Load Viewer with its live controls, condition types, inferred-connection overlay, and keyboard map, with worked examples for drop, static-symmetry, and random-vibration setups.

3.9.  Evaluating Random & Modal Analysis Models

Audience.  Analysts working with modal and random vibration (perturbation) models.

Purpose.  To verify, one check at a time, that an eigenvalue extraction and any random vibration response built on it will be physically meaningful.

It explains why perturbation models fail — singular stiffness, missing mass, island parts, pre-stress from penetrating nodes, and the random vibration keyword chain — then walks through thirteen steps from loading the file to evaluating the PSD input. It documents the eight-point random vibration validation (Section 7), the Miles’ equation estimator, the staged edit proposals that close gaps in the keyword chain, and a reference library of more than forty industry-standard PSD profiles across ten environment categories.

3.10.  Evaluating Impact Analysis Models

Audience.  Analysts working with explicit dynamic drop and impact models.

Purpose.  To build a chain of evidence that an explicit drop simulation represents the physical test — since the explicit solver will run a fundamentally wrong model to completion without complaint.

It explains the physics of an explicit drop and the four categories of impact setup error (initial conditions, contact gaps, mass-scaling misuse, missing energy output), then walks through fourteen steps. The drop visualization — velocity, gravity, hit surface, and center of mass shown together in 3D — is the single most powerful pre-submission check. It also covers contact verification, bonded-interface detection, rate-dependent materials with the strain-rate estimator, and the energy-output requests that make the post-run energy-balance check possible.

3.11.  Evaluating Overmold & Bonded-Interface Assemblies

Audience.  Analysts working with overmold assemblies, solder-bonded PCB stacks, adhesive joints, and press-fit components.

Purpose.  To verify and correct bonded interfaces — confirming every interface that must transfer load is connected, and that penetrating nodes do not pre-stress the model.

It explains the physics of bonded interfaces, how Abaqus models them with *TIE and the position tolerance, and why independent meshing produces penetrating nodes. A seventeen-step walkthrough takes the model from coincident-surface detection through surface correction to a corrected, analysis-ready export, and a closing reference explains why a POOR coverage grade is normal and what the metrics that actually matter for bond correctness are.

4  How the Guides Fit Together

The guides are layered rather than sequential. Two of them are about operating the tool: the Standalone Quick Start Guide gets it running in minutes, and the User Manual is the complete tab-by-tab and tool-by-tool reference. The Student’s Guide builds the foundation: what simulation computes and how to judge a result. The two orientation guides build the map: why the tool exists and where every tab and feature lives — one for the analyst who builds models, one for the non-specialist who depends on them. Peeking Under the Hood and Reading the Comprehensive Report build the bridge: how anyone on the team can verify a model and read its report as a shared, neutral basis for conversation. The four walkthroughs build the depth: the specific, model-type-aware review each kind of simulation requires.

They also share a spine. Every walkthrough begins by loading the file and confirming the model-type banner, checks for island parts and material density, and ends at the Recommendations tab. The BC & Load Viewer, the Interaction Viewer, the Material Consistency Review, and coincident-surface detection recur across model types because the questions they answer — are the supports right, are the parts connected, are the materials sound, are the bonded interfaces real — matter regardless of the analysis. Reading one walkthrough makes the others faster to absorb.

The common thread

Whatever your role and whatever the model, the discipline is the same: open the model, apply the knowledge you have that the tool does not, and confirm that what the solver will compute matches the physical problem you need solved. The flags the Analyzer raises are an invitation to a conversation, not a verdict — the goal is shared understanding across the analyst, the designer, and the program manager.

5  The Document Set

All guides in this library carry the same version as the tool they document and are produced in the McFadden CAE Services house style.

Guide

Version

File

Standalone Quick Start Guide

V27.4

Abaqus_INP_Analyzer_V27_4_Standalone_QuickStart.pdf

User Manual

V27.4

Abaqus_INP_Analyzer_V27_4_User_Manual.pdf

The Student’s Guide to Finite Element Simulation

V27.4

Abaqus_INP_Analyzer_V27_4_Students_Guide.docx

The Analyst’s Orientation Guide

V27.4

Abaqus_INP_Analyzer_V27_4_Analyst_Orientation_Guide.docx

The Non-Analyst’s Orientation Guide

V27.4

Abaqus_INP_Analyzer_V27_4_Non_Analyst_Orientation_Guide.docx

Peeking Under the Hood

V27.4

Abaqus_INP_Analyzer_V27_4_Peeking_Under_The_Hood.docx

Reading the Comprehensive Report

V27.4

LC_Report_Reading_Combined_Essay_McFadden.pdf

Loads & Boundary Conditions Walkthrough

V27.4

Abaqus_INP_Analyzer_V27_4_Loads_BC_Walkthrough.docx

Evaluating Random & Modal Analysis Models

V27.4

Abaqus_INP_Analyzer_V27_4_Random_Modal_Walkthrough.docx

Evaluating Impact Analysis Models

V27.4

Abaqus_INP_Analyzer_V27_4_Impact_Walkthrough.docx

Evaluating Overmold & Bonded-Interface Assemblies

V27.4

Abaqus_INP_Analyzer_V27_4_Overmold_Walkthrough.docx

Documentation Library — Reading Guide  •  Abaqus INP Comprehensive Analyzer  V27.4

Engineer. Lifelong Learner. Holistic Analyst.

www.McFaddenCAE.com  •  McFadden@snet.net

Developed in collaboration with Claude (Anthropic).

CAE Evaluator, for the CAE Analyst

‍ ‍

‍ ‍

Abaqus INP Comprehensive Analyzer

‍ ‍

Version 21.0

‍ ‍

User Manual

‍ ‍

For CAE Analysts, Design Engineers, and Program Managers

‍ ‍

Joseph P. McFadden Sr.

‍ ‍

The Holistic Analyst

‍ ‍

Combating Engineering Mind Blindness

‍ ‍

www.McFaddenCAE.com  •  McFadden@snet.net

‍ ‍

April 2026

‍ ‍

Developed in collaboration with Claude (Anthropic).

‍ ‍
‍ ‍

‍ ‍

1. Introduction.................................................................... 1

‍ ‍

1.1 The Mission: Combating Engineering Mind Blindness......................................................................... 1

‍ ‍

1.2 Who This Manual Is For............................................ 1

‍ ‍

1.3 What You Need.......................................................... 1

‍ ‍

2. Installation and Setup.................................................... 1

‍ ‍

2.1 Downloading the Analyzer........................................ 1

‍ ‍

2.2 First Launch.............................................................. 1

‍ ‍

2.3 System Requirements............................................... 1

‍ ‍

3. Getting Started................................................................ 1

‍ ‍

3.1 Loading Your First Model......................................... 1

‍ ‍

3.2 The Model Type Detection Banner........................... 1

‍ ‍

3.3 The Tab Interface...................................................... 1

‍ ‍

4. The Parts Tab.................................................................. 1

‍ ‍

4.1 Parts List and Selection............................................. 1

‍ ‍

4.2 Island Part Detection................................................ 1

‍ ‍

4.3 Interactive 3D Assembly Viewer............................... 1

‍ ‍

4.3.1 Part Visibility Controls........................................ 1

‍ ‍

4.3.2 View Styles: Tessellated vs. Actual Mesh........... 1

‍ ‍

4.3.3 Section Cutting................................................... 1

‍ ‍

4.3.4 Camera Controls................................................. 1

‍ ‍

4.4 Part Naming Scheme................................................ 1

‍ ‍

4.5 Working Set............................................................... 1

‍ ‍

4.6 Multi-Part INP Export.............................................. 1

‍ ‍

4.7 STL Export................................................................ 1

‍ ‍

4.8 Spatial Analysis Tools............................................... 1

‍ ‍

5. Materials Tab.................................................................. 1

‍ ‍

6. Sections Tab.................................................................... 1

‍ ‍

7. Property Viewer Tab....................................................... 1

‍ ‍

8. 1D Elements Tab............................................................. 1

‍ ‍

9. Tools Menu Reference.................................................... 1

‍ ‍

9.1 BC and Load Viewer.................................................. 1

‍ ‍

9.2 Drop Simulation Analysis......................................... 1

‍ ‍

9.3 Perturbation Review................................................. 1

‍ ‍

9.4 Contact Analysis........................................................ 1

‍ ‍

9.5 Interaction Viewer.................................................... 1

‍ ‍

9.6 PSD Plotter and GRMS Calculator........................... 1

‍ ‍

9.7 Analyze Simulation Intent........................................ 1

‍ ‍

9.8 Material Consistency Review.................................... 1

‍ ‍

9.9 Model Quality Report............................................... 1

‍ ‍

9.10 Convert for HyperMesh.......................................... 1

‍ ‍

9.11 Export Redacted INP............................................... 1

‍ ‍

9.12 Extract Material Data.............................................. 1

‍ ‍

9.13 Other Tools.............................................................. 1

‍ ‍

10. Recommendations Tab................................................. 1

‍ ‍

11. Edits Tab........................................................................ 1

‍ ‍

12. Learning Center............................................................ 1

‍ ‍

12.1 Analysis Types.......................................................... 1

‍ ‍

12.2 Best Practices........................................................... 1

‍ ‍

12.3 Material Properties.................................................. 1

‍ ‍

12.4 Behind the Scenes................................................... 1

‍ ‍

13. Version 21.0 Improvements.......................................... 1

‍ ‍

13.1 Smart Contact Analysis (V20.3).............................. 1

‍ ‍

13.2 PSD Plotter and Random Vibration Validation (V20.4)............................................................................ 1

‍ ‍

13.3 Multi-Part Export Enhancements (V21.0).............. 1

‍ ‍

13.4 HyperMesh Converter............................................. 1

‍ ‍

13.5 Secure Model Sharing.............................................. 1

‍ ‍

13.6 Expanded Keyword Parsing.................................... 1

‍ ‍

13.7 Interactive Assembly Viewer Enhancements.......... 1

‍ ‍

13.8 Version 21.0: Safety and Robustness Fixes............. 1

‍ ‍

13.8.1 Safe Node Merging............................................ 1

‍ ‍

13.8.2 Export Safety.................................................... 1

‍ ‍

13.8.3 STL Exporter Robustness................................. 1

‍ ‍

13.8.4 Viewer Settings Applied Everywhere................ 1

‍ ‍

13.8.5 Material Consistency Review Dialog................ 1

‍ ‍

14. Troubleshooting............................................................ 1

‍ ‍

14.1 Common Issues........................................................ 1

‍ ‍

14.2 Getting Help............................................................ 1

‍ ‍

Appendix A: Supported Abaqus Keywords........................ 1

‍ ‍

‍ ‍

‍ ‍

1. Introduction

‍ ‍

The Abaqus INP Comprehensive Analyzer is a free, standalone Windows desktop tool that reads Abaqus finite element input files (.inp) and presents the model’s contents in an organized, searchable, and visual format. It does not modify your simulation files. It does not run simulations. It reads what is already there and helps you understand it, question it, and verify it.

‍ ‍

Version 21.0 is the most capable release to date. Building on the model type detection and static analysis support introduced in Version 20.0, it adds a smart contact analysis tool, an interaction viewer for all constraint types, a PSD plotter with Miles’ equation estimator, a 42-profile PSD reference library, random vibration best-practices validation, a HyperMesh converter, redacted INP export for secure model sharing, material data extraction, and a multi-part INP export pipeline with submodel and harmonic response step templates. The Learning Center has grown to more than twenty-five topics across four categories with difficulty-level filtering. Version 21.0 also applies a set of critical safety fixes to the node merging, export, and STL pipelines identified through a multi-AI code review process.

‍ ‍

1.1 The Mission: Combating Engineering Mind Blindness

‍ ‍

Engineering mind blindness is the condition that develops when engineers use simulation tools fluently but no longer truly see what those tools are doing. It is the analyst who trusts the mesh because the software accepted it. It is the program manager who approves a simulation report without being able to read it. It is the designer who receives a frequency response table and does not know whether the model even had a proper boundary condition. This tool was built to fight that condition at every level of the engineering organization.

‍ ‍

By making the model readable without a solver license, by surfacing automated recommendations that explain their reasoning, and by providing a Learning Center that teaches the concepts behind the checks, the Analyzer turns opaque input files into understandable engineering artifacts. That transparency is the core purpose.

‍ ‍

1.2 Who This Manual Is For

‍ ‍

This manual is written for three audiences. CAE analysts will find detailed coverage of every parsing capability, the full tab and tools reference, and the model evaluation workflows for each of the supported analysis categories. Design engineers will find accessible explanations of what the simulation model contains and how the tool’s visual and summary features help them verify design intent. Program managers will find plain-language descriptions of the model review outputs they can use for oversight and documentation.

‍ ‍

The manual is written so that each section can be read independently. A program manager does not need to read the constraint parsing reference. An analyst does not need to read the executive summary section. Navigate by chapter heading to the content most relevant to your role.

‍ ‍

1.3 What You Need

‍ ‍

The Abaqus INP Comprehensive Analyzer requires Windows 10 or Windows 11, an Abaqus .inp input file in text format, and no Abaqus license of any kind. The standalone EXE includes all required libraries. You do not need Python, PyVista, or any other software installed separately.

‍ ‍

If someone hands you a .cae binary file rather than a .inp text file, the Analyzer will detect this and display a clear message. Ask the analyst to export the input file from Abaqus/CAE using Job, Write Input.

‍ ‍

Note: Version 21.0 was developed and tested on Python 3.13 and Windows 11. The EXE is self-contained. The EXE filename follows the convention: McFadden_Version_21_0_AbaqusINPAnalyzer.exe.

‍ ‍
‍ ‍

‍ ‍

2. Installation and Setup

‍ ‍

2.1 Downloading the Analyzer

‍ ‍

The Analyzer is distributed as a free download from www.McFaddenCAE.com. Download the ZIP archive, extract it to any folder on your machine, and double-click the EXE to launch. The ZIP archive contains the EXE and a required subfolder named _internal. Both the EXE and the _internal folder must remain in the same directory for the application to function. Do not move the EXE to a different location without also moving the _internal folder.

‍ ‍

2.2 First Launch

‍ ‍

On first launch, Windows SmartScreen may display a warning indicating that the publisher is unknown. This is expected for any EXE that is not code-signed through Microsoft’s commercial certificate authority. Click More Info and then Run Anyway to proceed. This prompt appears only on the first launch after downloading.

‍ ‍

When the main window opens, you will see a file path field and Browse button at the top, the model type detection banner just below, and the tabbed analysis interface filling the remainder of the window. No configuration is needed before loading your first file.

‍ ‍

2.3 System Requirements

‍ ‍

Requirement

Detail

Operating System

Windows 10 or Windows 11 (64-bit)

Disk Space

Approximately 200 MB for the EXE and _internal folder

RAM

4 GB minimum; 8 GB recommended for assemblies over 500,000 elements

GPU

Any DirectX 11 capable GPU for 3D visualization; integrated graphics work but may be slow on very large models

Display

1280×720 minimum; the interface is screen-aware and adapts to monitor resolution

Abaqus License

Not required

‍ ‍
‍ ‍

‍ ‍

3. Getting Started

‍ ‍

3.1 Loading Your First Model

‍ ‍

Click Browse in the top file bar and navigate to your .inp file, or type the full path directly into the path field. When a file is selected, the Process button becomes active. Click Process to begin parsing.

‍ ‍

A progress dialog appears showing each parsing stage as it completes. For a typical 200,000-element assembly the processing takes approximately 10 to 15 seconds. A 1.1-million-element model processes in approximately 25 seconds. You may cancel processing at any time; the progress dialog includes a Cancel button that terminates parsing cleanly.

‍ ‍

3.2 The Model Type Detection Banner

‍ ‍

This is the first thing to read after processing. The banner spans the full width of the window just below the file bar and reports what category of analysis the Analyzer detected in your model. Version 21.0 recognizes four categories: Perturbation (modal and random vibration models), Impact (explicit dynamic drop and crash models), Static (implicit stress and structural models), and Mixed (models containing elements of more than one category).

‍ ‍

The detection logic examines the step keywords, procedure types, and loading conditions in the INP file. A model containing *FREQUENCY or *RANDOM RESPONSE under *STEP, PERTURBATION is classified as Perturbation. A model with *DYNAMIC, EXPLICIT and initial velocity loads is classified as Impact. A model with *STATIC or *STATIC, STABILIZE is classified as Static. When multiple procedure types coexist, the Mixed classification is reported.

‍ ‍

The model type classification drives automatic recommendations, configures the BC and Load Viewer, and gates certain tool behaviors. If the detected type appears incorrect, you can proceed to any of the specialized review dialogs, which will surface a mismatch warning and provide guidance on reconciling the classification with the model content.

‍ ‍

3.3 The Tab Interface

‍ ‍

After processing, the model’s contents are organized across ten tabs. The tabs are always visible; switching between them does not require reprocessing. The following table describes each tab.

‍ ‍

Tab

Content

Summary

High-level overview: part count, element count, node count, unit system, step summary, constraint counts, and detected model type

Materials

All material definitions parsed from the INP file, organized by keyword with full property tables

Mat. Properties

Searchable material-to-section-to-part mapping tree showing which materials are used where

Sections

Section assignments (solid, shell, beam, membrane, cohesive, gasket) with thickness values, orientation data, and part linkage

Mat. Plots

2D mesh visualization with element quality overlays and coordinate plane projection

Parts

Complete list of all identified parts with node/element counts, material assignments, 3D visualization, STL export, INP export, and working set management. Includes the Islands detection button.

1D Elements

Springs, masses, connectors, dashpots, and rigid elements with their properties and connectivity

Recommendations

Automated best-practice checks with severity ratings and plain-language explanations, calibrated to the detected model type

Edits

Proposed INP file modifications with preview and apply capability, including PSD-to-edit staging pipeline

Learning

Built-in reference with 25+ topics covering analysis types, best practices, material properties, and tool guides, with difficulty-level and category filtering

‍ ‍
‍ ‍

‍ ‍

4. The Parts Tab

‍ ‍

4.1 Parts List and Selection

‍ ‍

The left panel of the Parts tab shows all identified parts in the model. Parts are identified by the Analyzer’s reverse-engineering pass, which groups elements into coherent assemblies using element set declarations, instance-to-part mappings, and geometric connectivity. The part count shown in the banner reflects the number of parts the Analyzer has identified, which may differ from the number declared in the INP file when the naming scheme uses ELSET declarations.

‍ ‍

Click any part name to select it and view its details in the right panel. Use Ctrl+Click to add individual parts to a multi-part selection. Use Shift+Click to select a contiguous range. Type in the search field above the list and click Filter to narrow the display.

‍ ‍

4.2 Island Part Detection

‍ ‍

The top row of the Parts tab always includes the Islands button, which is active as soon as processing completes. The button label reads Islands followed by the count of detected island parts in parentheses. When no islands are detected the count reads zero. Click the button to open the Islands Detail dialog.

‍ ‍

An island part is one that has no connection to the rest of the assembly. It shares no nodes with any other part, is not involved in any constraint definition, and does not appear in any contact pair. Islands in a model intended for simulation are almost always errors: a part that was included in the geometry but never merged into the mesh, a component left over from an earlier model revision, or an instance that was added but never constrained.

‍ ‍

Tip: An island part in a modal analysis model is particularly significant: a disconnected mass adds modes at zero or near-zero frequency, distorts the mode shape participation, and produces meaningless results for that component. Address all islands before submitting a perturbation model.

‍ ‍

4.3 Interactive 3D Assembly Viewer

‍ ‍

Select one or more parts and click View 3D to open the Interactive Assembly Viewer. This is a full-featured GPU-accelerated PyVista viewer with a dark-themed control panel that provides real-time part visibility management, section cutting, and camera controls. Each part is rendered in a distinct color from a configurable palette.

‍ ‍

4.3.1 Part Visibility Controls

‍ ‍

The control panel lists every part with its assigned color. Click a part name to select it. The viewer supports show, hide, and isolate operations: Hide removes the selected parts from the viewport, Isolate hides everything except the selected parts, Show All restores all parts to visibility. Hidden parts appear grayed with an [H] prefix in the control panel. An opacity slider at the top of the panel adjusts transparency for all visible parts simultaneously.

‍ ‍

4.3.2 View Styles: Tessellated vs. Actual Mesh

‍ ‍

The viewer offers two rendering modes. Tessellated mode, the default, converts the element topology into smooth triangulated surfaces. This produces visually appealing geometry with smooth curved surfaces, but the edge lines shown are tessellation artifacts rather than true element boundaries. Actual Mesh mode renders the finite element mesh directly from the element connectivity data, showing true element edges and exact topology. This mode is preferred when you need to inspect mesh quality or verify element sizes.

‍ ‍

Toggle between the two modes using the view style control in the viewer panel. The Learning Center topic on 3D Rendering Modes explains the trade-offs in detail.

‍ ‍

4.3.3 Section Cutting

‍ ‍

The Section Cut feature provides an interactive clipping plane that slices through the entire assembly in real time. Click the Section Cut button in the control panel or press C in the VTK window to activate. Choose the cutting axis (X, Y, or Z) and drag the cutting plane to the desired position. The Dynamic Drag checkbox controls whether the cut updates continuously while dragging or freezes while orbiting the model. Press the button again or press C to deactivate and restore the full geometry.

‍ ‍

4.3.4 Camera Controls

‍ ‍

The viewer includes a full set of camera controls accessible both from toolbar buttons and keyboard shortcuts.

‍ ‍

Control

Action

Left mouse drag

Rotate the model

Right mouse drag or scroll wheel

Zoom in and out

Middle mouse drag

Pan the view

X / Y / Z buttons

Snap to the corresponding axis view

Reverse button

Flip the current snap axis direction

Perspective button

Toggle between perspective and orthographic projection

Zoom All button

Reset camera to fit all visible parts

L key

Toggle the part name legend

E key

Toggle edge visibility

H key

Hide selected part

I key

Isolate selected part

S key

Show selected part

A key

Show all parts

R key

Reset camera

C key

Toggle section cut

Q key

Close the 3D window

‍ ‍

4.4 Part Naming Scheme

‍ ‍

Click the Part Naming Scheme button to open the naming dialog. This dialog compares the number of parts declared in the INP file via ELSET annotations against the number of parts the Analyzer detected through its reverse-engineering pass. When the declared count is less than the detected count, the Analyzer recommends using the Detected naming method, which reflects the true number of distinct physical components the mesh represents. When the counts agree, Declared naming is appropriate and preserves the analyst-assigned names.

‍ ‍

4.5 Working Set

‍ ‍

The Working Set feature allows you to pin frequently accessed parts to a persistent list for quick re-selection. Pin parts from the main parts list and they remain available even when you filter or search the full list. The Output Request Builder pre-populates from the Working Set when available, streamlining the workflow of identifying nodes of interest in your most critical components.

‍ ‍

4.6 Multi-Part INP Export

‍ ‍

Select one or more parts and click Export Selected Parts (INP) to extract them into a standalone INP file. The export dialog provides per-part custom naming, interface node detection, and optional submodel helper blocks. Version 21.0 adds TIE constraint carryover, which writes TIE keyword blocks for constraints connecting two parts both within the export set. A harmonic response step template with configurable frequency range, point count, and modal damping ratio is available as a one-click preset.

‍ ‍

When the export detects boundary nodes between exported and non-exported parts, it writes CUT node sets and appends a commented submodel template block showing the correct *SUBMODEL syntax. This streamlines the workflow for analysts building submodels from extracted assemblies.

‍ ‍

4.7 STL Export

‍ ‍

Select one or more parts and use the STL export function to generate mesh files suitable for visualization in external tools or 3D printing review. The export dialog offers binary or ASCII format selection, triangle count limits, weld tolerance control, and per-part quality recommendations. For large selections (more than ten parts), a preliminary dialog offers recommended defaults for batch export.

‍ ‍

4.8 Spatial Analysis Tools

‍ ‍

The Parts tab includes several spatial analysis tools that operate in assembly-transformed coordinates. Find Nearest Parts uses a KD-tree algorithm to locate the N closest parts to the current selection, or all parts within a user-specified distance threshold. Common Nodes finds parts that share node IDs, indicating tied or merged mesh regions. The Suggest Pairs and Check Penetrations tools detect geometric overlap between parts.

‍ ‍
‍ ‍

‍ ‍

5. Materials Tab

‍ ‍

The Materials tab displays every *MATERIAL block found in the INP file. Materials are listed by name in the left panel. Selecting a material in the list populates the right panel with all sub-keywords and their data tables. The Analyzer recognizes more than thirty material keywords including *ELASTIC, *PLASTIC, *DENSITY, *DAMPING, *HYPERELASTIC, *VISCOELASTIC, *EXPANSION, *CONDUCTIVITY, *SPECIFIC HEAT, and *JOHNSON COOK, among others.

‍ ‍

Elastic type variants are handled explicitly: ISOTROPIC, ORTHOTROPIC, ANISOTROPIC, ENGINEERING CONSTANTS, and LAMINA all display with the correct number of columns for that formulation. Rate-dependent plasticity, defined by *PLASTIC with a RATE parameter, displays tabular yield stress, plastic strain, and strain rate in a three-column table.

‍ ‍

Material property values are shown in the detected unit system. If the unit system detection is uncertain, the Summary tab will show a confidence flag and you can override the detection via Tools, Unit System.

‍ ‍

Note: The Materials tab shows what is defined in the INP file. It does not validate whether those property values are physically realistic for the intended material. That validation is the purpose of the Recommendations tab, which checks density, modulus, and Poisson ratio values against expected ranges for the detected unit system.

‍ ‍
‍ ‍

‍ ‍

6. Sections Tab

‍ ‍

The Sections tab lists all *SOLID SECTION, *SHELL SECTION, *BEAM SECTION, *MEMBRANE SECTION, *COHESIVE SECTION, and *GASKET SECTION assignments. Each section entry shows the element set it applies to, the material it references, the section type, and any additional parameters such as shell thickness or beam profile. The part-to-section linkage is shown in the right panel, connecting each section assignment back to the parts that use it.

‍ ‍

Missing section assignments are flagged with a warning indicator. A part that appears in the parts list but has no corresponding section assignment cannot be submitted to the solver and represents an incomplete model. The Recommendations tab also surfaces this condition.

‍ ‍

7. Property Viewer Tab

‍ ‍

The Property Viewer provides a cross-reference view connecting materials to the sections that use them and the parts those sections govern. The left panel lists all materials. Selecting a material populates the dataset list with all property keyword datasets defined for that material. Selecting a dataset populates the right panel with the full tabular property data for that dataset.

‍ ‍

This tab is most useful for verifying material completeness: every material that appears in a section assignment should have at minimum an *ELASTIC and *DENSITY definition. Materials missing density cannot support inertial loads in dynamic analyses. Materials missing elastic data cannot compute stress. The Property Viewer makes it easy to spot gaps at a glance.

‍ ‍

8. 1D Elements Tab

‍ ‍

The 1D Elements tab reports on all discrete elements in the model: springs, dashpots, connectors, point masses, and rotary inertia elements. For each element type the tab shows the element count, node pair connectivity, and associated properties such as spring stiffness values, dashpot coefficients, and connector section definitions.

‍ ‍

The summary statistics at the top of the tab report the total count of 1D elements, the number of distinct types found, and the count of springs with explicitly defined stiffness values. This information is particularly useful for verifying that all connector and spring elements have been properly configured before submission.

‍ ‍
‍ ‍

‍ ‍

9. Tools Menu Reference

‍ ‍

The Tools menu provides access to the specialized analysis tools that go beyond passive display. These tools interpret the model’s content, perform calculations, and present findings that cannot be derived from reading individual tabs in isolation. Version 21.0 includes seventeen tool entries organized into analysis, export, and configuration groups.

‍ ‍

9.1 BC and Load Viewer

‍ ‍

The BC and Load Viewer opens a PyVista 3D window that renders the assembly and overlays boundary conditions and loads as directional arrows. The viewer is generalized to work with all model categories: Perturbation, Impact, and Static.

‍ ‍

For perturbation models the viewer renders applied displacement boundary conditions as cyan arrows at the constrained nodes, colored by instance so that boundary conditions applied to different instances are visually distinguishable. For impact models the viewer adds the initial velocity vector as a green arrow and the gravity vector as a yellow arrow. For static models the viewer renders CLOAD point forces as red arrows, gravity as yellow, PRESSURE load indicators at surface regions, and applied displacement arrows in cyan.

‍ ‍

If the model type detected in the banner does not match the content the viewer finds, a mismatch warning dialog appears before the viewer opens. The warning describes the discrepancy and suggests what to check in the INP file.

‍ ‍

Tip: The BC and Load Viewer is one of the most effective pre-submission checks available. A visual inspection of where boundary conditions are applied, and in which direction loads act, catches setup errors that would be invisible in the raw keyword listing.

‍ ‍

9.2 Drop Simulation Analysis

‍ ‍

The Drop Simulation Analysis tool is designed for impact models. It reads the *INITIAL CONDITIONS, TYPE=VELOCITY block and the *DLOAD or *GRAVITY blocks to identify the velocity vector, the gravity vector, and the candidate hit surface. The smart detection algorithm scores rigid-element parts by how well their surface normal opposes the velocity direction, with anti-parallel normals scoring highest and shown with a green indicator.

‍ ‍

The dialog shows a candidate hit surface list with scores and lets you preview each candidate in the 3D viewer before confirming the selection. The drop visualization renders the full assembly with the hit surface highlighted in red, the velocity vector as a green arrow, gravity as yellow, and the center of mass as an orange sphere, all positioned correctly in assembly coordinates.

‍ ‍

9.3 Perturbation Review

‍ ‍

The Perturbation Review dialog is the primary evaluation tool for modal and random vibration models. It presents a structured checklist organized into seven sections covering model classification, boundary conditions, constraint definitions, material completeness, island detection, step configuration, and random vibration best-practices validation.

‍ ‍

The constraint section covers all eight constraint types recognized by Version 21.0: TIE, MPC, RIGID BODY, COUPLING, EQUATION, EMBEDDED ELEMENT, and the two legacy constraint forms. For each constraint type the dialog reports the count found, lists the definitions, and notes any definitions that reference sets or surfaces the Analyzer could not resolve.

‍ ‍

Section 7, added in Version 20.4, validates random vibration model setup with eight checks: density on all materials, modal damping inside the random response step, base motion or DSLOAD excitation, correlation linking PSD to base motion, RMS output requests, PSD data quality (monotonicity, slope limits, extreme GRMS), effective mass and modal participation output, and unit consistency of the g-conversion factor on the PSD definition. A pass/warn/fail tally with critical-issue alert summarizes the results.

‍ ‍

9.4 Contact Analysis

‍ ‍

The Contact Analysis tool, introduced in Version 20.3, provides a smart review of every contact pair and TIE constraint in the model. For each contact definition it resolves the parts and materials behind each surface, compares elastic modulus between master and slave sides, identifies the surface friction coefficient from the surface interaction property, and estimates representative mesh element sizes.

‍ ‍

Best-practice flags are raised when the slave surface is on the stiffer side (the convention is that the slave should be less stiff or more finely meshed), when master-slave mesh ratios suggest potential penetration risk, or when friction coefficients appear inconsistent with typical engineering values for the materials involved. The dialog is searchable and exportable.

‍ ‍

9.5 Interaction Viewer

‍ ‍

The Interaction Viewer, introduced in Version 20.3, displays all interactions parsed from the model in a single searchable, exportable dialog. It covers tie constraints, contact pairs, general contact, couplings, MPCs, and equations. Each entry shows names, surfaces or node sets, and the interaction property. The total interaction count is shown in the dialog header.

‍ ‍

9.6 PSD Plotter and GRMS Calculator

‍ ‍

The PSD Plotter is a standalone tool for visualizing power spectral density profiles and computing the overall GRMS level. Enter frequency and PSD level pairs in the input area, or load a profile from the built-in reference library of 42 profiles spanning space and launch, military and defense, avionics, automotive, transport, rail, industrial and energy, marine and offshore, and medical and precision environments. The plotter renders a log-log graph with fill-under shading and displays the computed GRMS value.

‍ ‍

Version 20.4 added the Miles’ Equation Estimator, which takes a natural frequency and damping ratio as input and computes the one-sigma GRMS and three-sigma quasi-static design load using log-log interpolation of the PSD data at the specified frequency. The estimator includes SDOF assumption notes and validity limit warnings.

‍ ‍

A real-time search filter lets you find profiles by name, standard, category, or description. Double-click any result to load it into the plotter. The Stage for Export button sends the current PSD data to the Edits tab as a set of pre-checked proposals covering PSD definition insertion, modal damping, RMS output requests, base motion and correlation blocks, and frequency extraction limit adjustments.

‍ ‍

9.7 Analyze Simulation Intent

‍ ‍

The Simulation Intent Analyzer classifies the model’s purpose using a scoring algorithm that weighs evidence from step types, loading conditions, constraint configurations, element types, and output requests. The classification is presented with a confidence level and an evidence chain listing the specific keywords and patterns that contributed to the score.

‍ ‍

When the detected intent matches your expected analysis type, the dialog presents purpose-specific recommendations calibrated to that simulation type. When you believe the classification is wrong, the dialog provides a correction workflow: select the intended analysis type, and the Analyzer performs a gap analysis comparing the current model content against what a correctly configured model of that type should contain. Evaluation reports can be exported as formatted text.

‍ ‍

9.8 Material Consistency Review

‍ ‍

The Material Consistency Review scans all materials (or a filtered selection) and flags inconsistencies: missing density, missing elastic data, Poisson ratio out of physical range, density values that suggest unit errors, and modulus values that do not match the detected unit system. The dialog presents a summary of issues found with per-material detail and an overall health score.

‍ ‍

9.9 Model Quality Report

‍ ‍

The Model Quality Report is an automated scorecard covering mesh completeness, material definitions, boundary conditions, constraint configuration, and contact setup. It aggregates findings from multiple analysis passes into a single document suitable for archiving or review by team members.

‍ ‍

9.10 Convert for HyperMesh

‍ ‍

The Convert for HyperMesh tool transforms a loaded Abaqus CAE-generated INP into a HyperMesh-compatible flat INP by converting every *COUPLING and *KINEMATIC block into *MPC BEAM entries and removing the coupling-region node surface definitions that are superseded by the MPC entries. The underlying node set blocks are preserved. The resolution chain follows coupling surface definitions to node surfaces, then to node sets, and finally to individual slave node lists and reference point nodes.

‍ ‍

The tool detects whether the file also needs part and instance flattening and provides scaffolding for that transformation. The converted file is saved with an _HM suffix.

‍ ‍

9.11 Export Redacted INP

‍ ‍

The Export Redacted INP tool creates a version of the loaded INP file suitable for secure sharing. It preserves every keyword, comment, material, section, step, and constraint while replacing the bulk mesh data (node and element blocks) with a single redacted marker per block. A configuration dialog lets you choose how many data lines to keep at the start and end of each block for context. Material data is always preserved in full. The result can be viewed in a scrollable dialog or saved as a new file.

‍ ‍

9.12 Extract Material Data

‍ ‍

The Extract Material Data tool scans the loaded INP file and extracts every *MATERIAL block, including all sub-keywords, into a standalone INP snippet. The result is a valid Abaqus material library file that can be imported directly into another model or used as input for material parameter studies. A summary shows the material count and names before export.

‍ ‍

9.13 Other Tools

‍ ‍

Tool

Description

Unit System

Displays the detected unit system and the property values used to determine it. Allows manual override.

Check Unit Consistency

Scans all materials for property values inconsistent with the detected unit system. Flags likely unit errors.

Part Naming Scheme

Compares declared versus detected part counts and recommends the appropriate naming method.

Export FEA Bill of Materials

Structured BOM mapping every part to its material, section type, element count, and assembly instance.

Export Comprehensive Evaluation

Multi-section evaluation report covering all model aspects, formatted for distribution.

Output Request Builder

Staging queue for *OUTPUT HISTORY and FIELD blocks with three node selection strategies: center of mass nearest, uniform grid, and manual entry. Sends checked requests to the Edits tab.

3D Viewer Settings

Configures legend color, font size, background color, and default visibility for all 3D views.

Debug Console Output

Toggles diagnostic logging for troubleshooting. Debug logs can be opened from the Tools menu.

‍ ‍
‍ ‍

‍ ‍

10. Recommendations Tab

‍ ‍

The Recommendations tab aggregates the results of all automated best-practice checks into a single organized list. Each recommendation carries a severity level: Error (a condition that will likely prevent the model from running or produce meaningless results), Warning (a condition that may produce incorrect results or indicates a common setup mistake), and Note (an informational observation that does not indicate a problem but may be worth reviewing).

‍ ‍

In Version 21.0, the recommendation set is model-type aware. A Perturbation model receives a different recommendation profile than a Static model. The perturbation profile includes checks for base excitation boundary conditions, frequency extraction request completeness, and damping definition. The static profile includes checks for bolt loads, pressure boundary conditions, thermal loading consistency, stabilization adequacy, and reaction force output requests. The impact profile checks energy balance outputs, mass scaling limits, hourglass control, and contact pair completeness.

‍ ‍

11. Edits Tab

‍ ‍

The Edits tab presents proposed modifications to the INP file, generated by the automated analysis tools. Each proposed edit appears with a checkbox, a description, and a preview of the INP lines that would be added or modified. You can selectively enable or disable individual edits, preview the combined result, and apply the selected edits to generate a new INP file.

‍ ‍

Version 20.4 introduced the PSD-to-Edits pipeline, which stages five edit proposals from the PSD Plotter: E8 inserts or replaces the PSD definition block, E9 adds modal damping if missing, E10 adds RMS output requests including fatigue workflow annotations, E11 adds base motion and correlation blocks if missing, and E12 raises the frequency extraction limit to at least 1.5 times the PSD maximum frequency. Each proposal is pre-checked with a light green background and can be previewed before application.

‍ ‍

The tab also provides an Export TIE Constraints INP button that writes all parsed TIE constraint definitions to a standalone INP snippet for reference or inclusion in other models.

‍ ‍
‍ ‍

‍ ‍

12. Learning Center

‍ ‍

The Learning Center is a built-in educational reference organized into four categories: Analysis Types, Best Practices, Material Properties, and Behind the Scenes. Topics are filterable by category and difficulty level (Beginner, Intermediate, Advanced). Select any topic from the list to display the content in the reading panel.

‍ ‍

12.1 Analysis Types

‍ ‍

Analysis Types topics cover Modal Analysis, Shock Analysis, SRS (Shock Response Spectrum), Random Vibration, Harmonic Response, and Static Analysis. Each topic explains when the analysis type is appropriate, what keywords are required, what the output represents, and what common mistakes produce incorrect results. Analysis Type topics with INP generators include a Generate Example INP button that creates a minimal working INP file demonstrating correct setup. The generated file can be opened in Abaqus/CAE or submitted directly to the solver.

‍ ‍

12.2 Best Practices

‍ ‍

Best Practices topics cover element selection, thin brittle material modeling, millisecond unit systems, jerk and fragility assessment, output requests and post-processing, and stabilizing static analysis with contact. The random vibration content was significantly expanded in Version 20.4 to include Miles’ equation with formula and assumptions, a fatigue post-processing workflow covering RMS to Dirlik to Miner’s damage, output request templates, spectral methods comparison, and statistical peaks explanation.

‍ ‍

12.3 Material Properties

‍ ‍

Material Properties topics cover materials for drop and impact analysis (explicit dynamics), materials for static and structural analysis, materials for modal and frequency analysis, and hyperelastic, viscoelastic, and advanced material models. Each topic provides property value guidance in common unit systems and explains which material keywords are required for that analysis type.

‍ ‍

12.4 Behind the Scenes

‍ ‍

Behind the Scenes topics explain how the tool works. Topics include assumptions and limitations, 3D rendering modes (tessellated versus actual mesh), impact and drop analysis tool guide, assembly instance transforms, the HyperMesh converter, the redacted INP exporter, the BC and Load Viewer, the Interaction Viewer, assembly view styles, contact analysis methodology, and contact stabilization guidance. These topics help advanced users understand the algorithms driving the tool’s analysis.

‍ ‍

Note: The Learning Center content is embedded in the application. It does not require an internet connection and is available in any environment where the EXE can run.

‍ ‍
‍ ‍

‍ ‍

13. Version 21.0 Improvements

‍ ‍

13.1 Smart Contact Analysis (V20.3)

‍ ‍

The Contact Analysis tool resolves the parts, materials, elastic moduli, mesh sizes, and friction coefficients behind every contact pair and TIE constraint. It flags master-slave convention violations, mesh ratio concerns, and friction inconsistencies. Combined with the Interaction Viewer, which lists all constraints in a searchable dialog, these tools provide the most complete contact review available without a solver license.

‍ ‍

13.2 PSD Plotter and Random Vibration Validation (V20.4)

‍ ‍

The PSD Plotter gained a reference library of 42 profiles with real-time search filtering, a Miles’ Equation Estimator for quick design load estimation, and a staging pipeline that sends PSD data and associated model edits to the Edits tab. The Perturbation Review dialog added Section 7 with eight random vibration best-practices checks covering density, damping, excitation, correlation, output requests, PSD data quality, effective mass, and unit consistency.

‍ ‍

13.3 Multi-Part Export Enhancements (V21.0)

‍ ‍

The multi-part INP export now carries over TIE constraints between exported parts, writes CUT boundary node sets with true connectivity-based detection, appends commented submodel template blocks, and offers a one-click harmonic response step preset with configurable frequency range and modal damping ratio.

‍ ‍

13.4 HyperMesh Converter

‍ ‍

The Convert for HyperMesh tool converts Abaqus CAE coupling blocks to HyperMesh-compatible MPC BEAM entries, removing coupling-region surfaces while preserving node sets. This enables analysts to move models between Abaqus/CAE and HyperMesh without manual constraint conversion.

‍ ‍

13.5 Secure Model Sharing

‍ ‍

The Export Redacted INP tool and the Extract Material Data tool address two common workflows: sharing model structure without proprietary mesh data, and extracting reusable material libraries from existing models. Both tools preserve complete keyword and material information while giving the user control over what mesh data is retained.

‍ ‍

13.6 Expanded Keyword Parsing

‍ ‍

Version 21.0 parses more than seventy Abaqus keywords. The additions since Version 20.0 include *DSLOAD, *CONNECTOR LOAD, *CONNECTOR MOTION, *NONSTRUCTURAL MASS, *ROTARY INERTIA, *GLOBAL DAMPING, *DAMPING, *COHESIVE SECTION, *GASKET SECTION, *SELECT EIGENMODES, *MODAL OUTPUT, *CONTACT OUTPUT, *DIRECT CYCLIC, *STEADY STATE TRANSPORT, *SUBSPACE DYNAMIC, *PSD-DEFINITION, *BASE MOTION, *CORRELATION, *MODAL DAMPING, *FRICTION, and *SURFACE INTERACTION.

‍ ‍

13.7 Interactive Assembly Viewer Enhancements

‍ ‍

The Interactive Assembly Viewer gained section cutting with dynamic drag, two rendering modes (tessellated and actual mesh), an opacity slider, a working set system, and keyboard shortcuts for all visibility operations. Camera controls include axis snap, perspective toggle, and zoom-all, all accessible from both buttons and keyboard. In Version 21.0, the duplicate opacity slider that previously appeared in the VTK viewport has been removed; the tkinter control panel slider is now the single opacity control, eliminating sync issues between the two sliders.

‍ ‍

13.8 Version 21.0: Safety and Robustness Fixes

‍ ‍

Version 21.0 applies a set of targeted safety and robustness fixes identified through a multi-AI code review process involving Grok, Perplexity, and Claude. The fixes address the highest-risk areas in the satellite module pipeline without modifying the sacred parse pipeline in the main application.

‍ ‍

13.8.1 Safe Node Merging

‍ ‍

The node merging logic in model_analyzer.py was rewritten to preserve original local node IDs whenever they are free, only remapping to new IDs on true collisions across parts. The previous implementation aggressively renumbered every composite node key, which silently broke *NSET, *BOUNDARY, *INITIAL CONDITIONS, *RIGID BODY, and *TIE references that depend on original node IDs. This was the highest-priority fix identified in the review.

‍ ‍

13.8.2 Export Safety

‍ ‍

The INP exporter module was updated to use the merged global node map safely, eliminating a fragile composite-key reconstruction path that guessed the node key format during export. The exporter now falls back to the global node coordinate map when per-part node data is unavailable, and logs warnings for any missing nodes rather than silently producing incomplete output.

‍ ‍

13.8.3 STL Exporter Robustness

‍ ‍

The STL exporter’s element face dictionary was expanded from 9 to 21 element types. The additions include C3D20 (quadratic hex), C3D6 and C3D15 (wedge and pentahedral), S8R, S8R5, and S9R5 (quadratic shell), and M3D3, M3D4, M3D6, M3D8, and M3D8R (membrane). A double-tuple nesting bug in the surface element face handling was also corrected, and the element suffix stripping logic now handles multi-character suffixes like RH and IH correctly.

‍ ‍

13.8.4 Viewer Settings Applied Everywhere

‍ ‍

The 3D Viewer Settings (viewport background color, legend colors, font size, section cut plane color) are now applied to all seven viewer paths in the application: single-part view, interactive assembly viewer, BC and Load Viewer, drop simulation preview, drop simulation main visualization, and the multiple views grid. Two call sites that were previously missing the preference handoff have been corrected.

‍ ‍

13.8.5 Material Consistency Review Dialog

‍ ‍

The Material Consistency Review dialog was rebuilt with a scrollable canvas layout. The previous fixed-height layout caused the Strain Rate Data section and Close button to be pushed below the visible window area when multiple sections were present. The new layout wraps all content in a single scrollable canvas with a bottom-first Close button that is always visible regardless of content height. The material table height is now dynamic, sizing to fit the actual number of materials.

‍ ‍
‍ ‍

‍ ‍

14. Troubleshooting

‍ ‍

14.1 Common Issues

‍ ‍

Symptom

Resolution

The application says my file is a CAE binary

The tool needs the text-format .inp file. In Abaqus/CAE use Job > Write Input to export it.

Parts count shows zero after processing

This usually indicates a Python 3.13 compatibility issue in an older version. Version 21.0 corrects the known crash. If the problem persists, enable Debug Console Output from the Tools menu and check the log.

3D view does not open or crashes

Ensure the _internal folder is in the same directory as the EXE. The PyVista VTK libraries in _internal are required for 3D rendering.

Processing is very slow on large models

Models over 500,000 elements take 30 to 60 seconds. Multi-pass parsing including the volume calculation pass drives most of the time. The progress dialog shows which stage is running.

Assembly parts appear stacked at the origin

The INP file does not contain *INSTANCE transformation data. Ask the analyst to verify that the model was exported from an assembled job, not a part-level job.

Unit system was detected incorrectly

Use Tools > Unit System to view the evidence and override the detection manually.

Islands count is unexpectedly high

Verify whether the model uses a node-based assembly where many parts share a global node set. Such models may appear to have many islands because the shared-node detection relies on explicit NSET definitions.

Section cut plane does not appear

Ensure at least one part is visible in the viewer before activating the section cut. The cutting plane requires visible geometry to clip.

‍ ‍

14.2 Getting Help

‍ ‍

Send questions, bug reports, and suggestions to McFadden@snet.net. Visit www.McFaddenCAE.com for updated documentation, new version announcements, and companion tools. Connect with Joseph P. McFadden Sr. on LinkedIn under The Holistic Analyst for ongoing educational content about simulation transparency and best practices.

‍ ‍
‍ ‍

‍ ‍

Appendix A: Supported Abaqus Keywords

‍ ‍

The following table lists the major Abaqus input file keywords that Version 21.0 parses and processes. Keywords not in this list are passed over silently and do not cause errors.

‍ ‍

Keyword

Category

Notes

*NODE

Geometry

Global and part-local node coordinate blocks

*ELEMENT

Geometry

All standard element types including C3D4, C3D8R, C3D10, R3D4, M3D4, S3, S4R, B31, CONN3D2

*NSET

Sets

Named node sets with GENERATE support

*ELSET

Sets

Named element sets with GENERATE support and ELSET=name@id naming

*PART / *END PART

Assembly

Part definition blocks

*ASSEMBLY / *END ASSEMBLY

Assembly

Assembly block with instance definitions

*INSTANCE / *END INSTANCE

Assembly

Instance placement with translation and rotation

*SYSTEM

Coordinate

Local coordinate system transforms for R3D rigid body placement

*MATERIAL

Material

Material definition block

*ELASTIC

Material

Isotropic, orthotropic, anisotropic, engineering constants, lamina

*PLASTIC

Material

Rate-dependent and rate-independent plasticity

*DENSITY

Material

Mass density

*DAMPING

Material

Alpha and beta Rayleigh damping coefficients

*GLOBAL DAMPING

Material

Model-level alpha and beta damping

*HYPERELASTIC

Material

Neo-Hookean, Mooney-Rivlin, Ogden, Arruda-Boyce

*EXPANSION

Material

Thermal expansion coefficient

*CONDUCTIVITY

Material

Thermal conductivity

*SPECIFIC HEAT

Material

Heat capacity

*SOLID SECTION

Section

Continuum element section assignments

*SHELL SECTION

Section

Shell section with thickness

*BEAM SECTION

Section

Beam section with profile and orientation

*MEMBRANE SECTION

Section

Membrane section

*COHESIVE SECTION

Section

Cohesive element section

*GASKET SECTION

Section

Gasket element section

*RIGID BODY

Constraint

Rigid body constraint with reference node

*TIE

Constraint

Surface-to-surface tie constraint

*MPC

Constraint

Multi-point constraint

*EQUATION

Constraint

Linear constraint equation

*COUPLING

Constraint

Distributing and kinematic coupling

*EMBEDDED ELEMENT

Constraint

Embedded element constraint

*STEP / *END STEP

Step

Step definition block

*FREQUENCY

Step

Frequency extraction (perturbation)

*RANDOM RESPONSE

Step

Random response procedure

*MODAL DYNAMIC

Step

Modal dynamic procedure

*STEADY STATE DYNAMICS

Step

Harmonic response procedure

*DYNAMIC, EXPLICIT

Step

Explicit dynamic procedure

*STATIC

Step

General static procedure

*STATIC, STABILIZE

Step

Static with automatic stabilization

*DIRECT CYCLIC

Step

Direct cyclic loading procedure

*SUBSPACE DYNAMIC

Step

Subspace dynamic procedure

*BOUNDARY

Loads/BCs

Boundary condition definitions

*CLOAD

Loads/BCs

Concentrated force loads

*DLOAD

Loads/BCs

Distributed loads

*DSLOAD

Loads/BCs

Distributed surface loads and pressures

*GRAVITY

Loads/BCs

Gravity body force

*PRESSURE

Loads/BCs

Surface pressure loads

*TEMPERATURE

Loads/BCs

Temperature field loads

*BOLT LOAD

Loads/BCs

Bolt preload definition

*INITIAL CONDITIONS

Loads/BCs

Initial velocity and temperature conditions

*BASE MOTION

Loads/BCs

Base excitation for random/harmonic response

*PSD-DEFINITION

Loads/BCs

Power spectral density profile definition

*CORRELATION

Loads/BCs

PSD-to-base-motion correlation

*MODAL DAMPING

Loads/BCs

Modal damping ratio specification

*CONTACT PAIR

Contact

Surface-to-surface contact pair

*CONTACT CONTROLS

Contact

Contact algorithm control parameters

*SURFACE

Contact

Surface definition from element faces

*SURFACE INTERACTION

Contact

Contact interaction property

*FRICTION

Contact

Friction coefficient definition

*MASS

Elements

Point mass elements

*NONSTRUCTURAL MASS

Elements

Distributed non-structural mass

*ROTARY INERTIA

Elements

Point rotary inertia

*SPRING

Elements

Discrete spring elements

*DASHPOT

Elements

Discrete dashpot elements

*CONNECTOR SECTION

Elements

Connector element section

*CONNECTOR LOAD

Elements

Connector load definition

*OUTPUT

Output

Output request control

*NODE OUTPUT

Output

Nodal variable output (including RF, CF detection)

*ELEMENT OUTPUT

Output

Element variable output

*MODAL OUTPUT

Output

Modal variable output

*CONTACT OUTPUT

Output

Contact variable output

*SELECT EIGENMODES

Output

Mode selection for output

*INCLUDE

File Control

File inclusion with recursive resolution

‍ ‍
‍ ‍

‍ ‍

End of User Manual

‍ ‍

Abaqus INP Comprehensive Analyzer V21.0

‍ ‍

Joseph P. McFadden Sr.  •  www.McFaddenCAE.com  •  McFadden@snet.net

‍ ‍

Developed in collaboration with Claude (Anthropic).

‍ ‍

A Student’s Guide to the INP Analyzer

Abaqus INP Comprehensive Analyzer

Version 21.0

The Student’s Guide to Finite Element Simulation

Learning to See What the Solver Sees

Joseph P. McFadden Sr.

The Holistic Analyst

Combating Engineering Mind Blindness

www.McFaddenCAE.com  •  McFadden@snet.net

April 2026

Developed in collaboration with Claude (Anthropic).

‍ ‍

Introduction........................................................................ 1

1. What Is Finite Element Analysis?................................... 1

1.1 The Problem FEA Solves............................................ 1

1.2 The Language of FEA................................................ 1

1.3 The Two Solvers: Implicit and Explicit..................... 1

2. The Anatomy of an Abaqus Model................................. 1

2.1 The INP File............................................................... 1

2.2 Nodes and Elements: Building the Mesh.................. 1

2.2.1 Element Types You Will Encounter.................... 1

2.3 Materials: What the Structure Is Made Of................ 1

2.4 Boundary Conditions and Loads: Defining the Problem........................................................................... 1

2.5 Steps: Sequencing the Analysis................................. 1

3. The Four Types of Analysis............................................. 1

3.1 Static Analysis........................................................... 1

3.2 Modal Analysis.......................................................... 1

3.3 Random Vibration Analysis...................................... 1

3.4 Impact and Drop Analysis........................................ 1

4. The Five Mistakes Every Student Makes........................ 1

4.1 Trusting the Default Mesh......................................... 1

4.2 Forgetting Density.................................................... 1

4.3 Wrong Boundary Conditions.................................... 1

4.4 Unit System Confusion............................................. 1

4.5 Not Checking the Results.......................................... 1

5. Using the Analyzer as a Learning Tool........................... 1

5.1 Loading Your First Model.......................................... 1

5.2 Reading a Real Model............................................... 1

5.3 The Learning Center................................................. 1

5.4 Building Your Own Models....................................... 1

6. Standards and Professional Practice.............................. 1

7. The Path Forward........................................................... 1

7.1 Skills to Develop........................................................ 1

7.2 Resources.................................................................. 1

7.3 A Final Word to the Student..................................... 1

‍ ‍

Introduction

This guide is written for the student who wants to understand finite element simulation — not just how to click buttons in software, but why simulation works, what it actually computes, how to tell whether the results are meaningful, and how to develop the engineering judgment that separates someone who runs simulations from someone who understands them.

Forty-five years of engineering practice have taught me that the most dangerous point in a young engineer’s career is not when they do not know how to use the software. It is the moment when they learn how to use the software but do not yet understand what the software is doing. They can build a mesh, apply loads, run the solver, and produce stress contours that look professional. But they cannot yet tell you whether those stress contours represent reality or fiction. They trust the result because the software produced it, and that trust — uncritical, uninformed, unearned — is engineering mind blindness.

This guide exists to prevent that. It teaches the concepts behind the simulation, the physics behind the solver, the meaning behind the results, and the judgment behind the decisions. It uses the Abaqus INP Comprehensive Analyzer as a teaching tool — a way to open a real simulation model and see every component, every material, every load, every constraint, and every assumption that determines whether the results are valid. The Analyzer does not replace your textbook or your coursework. It gives you a way to touch real models while you are learning the theory, so that the theory is never abstract.

If you are a student reading this, you are starting at the right time. The engineers who understand what their tools are doing — who can look at a mesh and know whether it is adequate, who can read a material definition and know whether it makes physical sense, who can see a boundary condition and know whether it represents the physical constraint — are the engineers who will make the best decisions and catch the errors that automated tools cannot. This guide is the beginning of that understanding.

‍ ‍

1. What Is Finite Element Analysis?

1.1 The Problem FEA Solves

Engineering structures are continuous. A steel bracket is not made of discrete pieces — it is a single continuous piece of metal with stress and strain varying smoothly from point to point. The equations that describe this continuous behavior (the partial differential equations of elasticity, heat transfer, or fluid mechanics) can be solved exactly for only a handful of simple shapes: a beam with a uniform cross section, a plate with a regular geometry, a sphere under uniform pressure. For everything else — every real product, every real assembly, every real engineering problem — the equations cannot be solved in closed form.

Finite element analysis solves this problem by replacing the continuous structure with a mesh of discrete pieces called elements. Each element is a simple geometric shape — a tetrahedron, a hexahedron, a triangle, a quadrilateral — with a known mathematical description. The behavior of each element is described by a set of equations that relate the forces at its corners (nodes) to the displacements at those corners. When all the element equations are assembled into a global system, the result is a set of simultaneous equations that can be solved by a computer to find the displacement at every node. From the displacements, the software computes strains, stresses, forces, and every other quantity of engineering interest.

The key insight is that the finite element solution is an approximation. It approximates the continuous structure with a discrete mesh, the smooth displacement field with a piecewise polynomial interpolation, and the exact solution with a numerical solution that converges toward the exact answer as the mesh is refined. Understanding that every FEA result is an approximation — and understanding what controls the quality of that approximation — is the foundation of simulation competence.

1.2 The Language of FEA

Term

What It Means

Node

A point in space with coordinates (x, y, z). Elements connect at nodes. The solver computes displacements at nodes.

Element

A geometric shape (tet, hex, shell, beam) that connects nodes. Elements carry the material properties and compute stress and strain.

Mesh

The complete collection of nodes and elements that represent the structure. Mesh quality directly affects result accuracy.

Part

A group of elements that represent a single physical component (a bracket, a housing, a bolt). An assembly is a collection of parts.

Material

The set of physical properties (elastic modulus, density, Poisson ratio, yield stress) assigned to elements. Determines stiffness and strength.

Section

The link between a material and a group of elements. Defines element thickness for shells and cross-section for beams.

Boundary Condition

A constraint on displacement or rotation at specific nodes. Represents how the structure is supported or attached.

Load

An applied force, pressure, acceleration, or temperature. Represents what the structure must resist.

Step

A phase of the analysis. A model may have multiple steps: preload first, then service load, then vibration.

Solver

The mathematical engine that assembles all element equations and solves the global system. Abaqus/Standard (implicit) or Abaqus/Explicit.

DOF (Degree of Freedom)

An independent direction of motion at a node. A 3D node has 6 DOFs: translations in X, Y, Z and rotations about X, Y, Z.

1.3 The Two Solvers: Implicit and Explicit

Abaqus provides two solvers that use fundamentally different algorithms. The implicit solver (Abaqus/Standard) finds the equilibrium state at each load increment by iterating until the internal forces balance the external loads. It is used for static analysis, modal analysis, and slow dynamic events. The implicit solver is accurate and efficient for smooth, well-behaved problems, but it can fail to converge when the problem involves severe nonlinearity — large deformations, contact opening and closing, or material failure.

The explicit solver (Abaqus/Explicit) advances through time by computing the acceleration at each node from the current forces and mass, then updating the velocity and position. It does not iterate. It does not check for equilibrium. It simply marches forward at time increments small enough that the physics is captured accurately. The explicit solver is used for impact, crash, blast, and any event where the deformation happens too fast for the implicit solver to iterate. Its strength is robustness — it handles severe nonlinearity without convergence problems. Its weakness is cost — the time increments are tiny (microseconds for a typical metal element), so a millisecond event requires thousands of steps.

The choice of solver is not a preference — it is driven by the physics. A static bolt preload analysis uses the implicit solver because the loading is slow and equilibrium is required at each step. A drop test uses the explicit solver because the impact event is fast and involves contact, plasticity, and potentially failure. Using the wrong solver for the wrong problem produces either wrong results (explicit for static — inertial effects contaminate the quasi-static response) or solver failure (implicit for high-speed impact — convergence fails at every increment).

‍ ‍

2. The Anatomy of an Abaqus Model

2.1 The INP File

An Abaqus model is defined by a text file with the extension .inp (input). This file contains every piece of information the solver needs: the node coordinates, the element connectivity, the material definitions, the section assignments, the boundary conditions, the loads, the step definitions, and the output requests. The INP file is the single source of truth. Whatever is in the file is what the solver computes. Whatever is not in the file does not exist in the simulation.

The Abaqus INP Comprehensive Analyzer reads this file and presents its contents in an organized, visual format. When you load an INP file into the Analyzer, you are looking at exactly what the solver will see — no more, no less. This is why the Analyzer is a powerful learning tool: it lets you connect the abstract concepts from your textbook (nodes, elements, boundary conditions) to concrete data from a real model.

2.2 Nodes and Elements: Building the Mesh

Nodes define the geometry. They are points in three-dimensional space, each with an integer ID and three coordinates. A model with 100,000 nodes has 100,000 points where the solver will compute displacements. The spacing and distribution of nodes determines the resolution of the solution: closely spaced nodes in a high-stress region produce a more accurate stress prediction than widely spaced nodes.

Elements connect nodes into geometric shapes. A tetrahedral element (C3D4) connects four nodes into a four-faced solid. A hexahedral element (C3D8R) connects eight nodes into a six-faced solid. A shell element (S4R) connects four nodes into a flat or curved surface with a specified thickness. A beam element (B31) connects two nodes into a line with a specified cross-section. The element type determines how the solver interpolates the displacement field between nodes, and different types have different accuracy and computational cost.

2.2.1 Element Types You Will Encounter

Element Type

What It Is and When to Use It

C3D4

4-node linear tetrahedron. Easy to mesh complex geometry. Low accuracy per element — needs a fine mesh. The workhorse of automatic meshing.

C3D10 / C3D10M

10-node quadratic tetrahedron. Much more accurate than C3D4 for the same mesh density. Preferred when tet meshing is required.

C3D8R

8-node linear hexahedron with reduced integration. The most efficient solid element for explicit analysis. Requires structured meshing. Susceptible to hourglassing.

C3D8 / C3D8I

8-node full-integration hex. More accurate than C3D8R, no hourglass risk, but slower and can exhibit shear locking in bending.

S4R

4-node shell with reduced integration. Used for thin-walled structures (housings, panels, sheet metal). Requires thickness definition in the section.

S3 / S3R

3-node triangular shell. Used to fill gaps in quad-dominant shell meshes. Less accurate than S4R.

B31 / B32

2-node and 3-node beam elements. Used for frames, trusses, and structural members where the cross-section is well-defined.

R3D3 / R3D4

3-node and 4-node rigid elements. Do not deform. Used for impact surfaces, fixtures, and rigid components.

CONN3D2

2-node connector element. Represents bolts, hinges, springs, and other mechanical connections between parts.

2.3 Materials: What the Structure Is Made Of

A material definition tells the solver how the element responds to deformation. The minimum definition for a structural analysis is the elastic modulus (E) and the Poisson ratio (ν), which define the linear relationship between stress and strain. For any analysis that involves inertia — vibration, impact, wave propagation — the density (ρ) is also required because the solver needs mass to compute acceleration.

Beyond the elastic regime, materials can exhibit plasticity (permanent deformation beyond the yield stress), rate dependence (stronger at high strain rates during impact), hyperelasticity (rubber and foam behavior at large strains), viscoelasticity (time-dependent response), thermal expansion (deformation due to temperature change), and damage (progressive degradation and failure). Each of these behaviors requires additional material keywords in the INP file, and the absence of a required keyword means the solver will not model that behavior — silently, without warning.

The single most common material error in student models is forgetting to define density. Without density, the mass matrix is zero. A modal analysis produces infinite frequencies. An explicit analysis produces infinite accelerations. A gravity load produces zero force. The solver does not warn you that density is missing — it simply computes the wrong answer. Always verify density in the Analyzer’s Materials tab.

2.4 Boundary Conditions and Loads: Defining the Problem

Boundary conditions constrain the structure. A node that is fixed in all six degrees of freedom (three translations, three rotations) cannot move or rotate. A node that is fixed in only one direction can move freely in the other five. The choice of boundary conditions defines how the structure is supported, and it is one of the most consequential decisions in model setup. A bracket analyzed with all bolt holes rigidly fixed behaves differently from the same bracket analyzed with bolt preload and contact at the bolt interfaces.

Loads define what the structure must resist. A concentrated force (CLOAD) applies a force vector at a specific node. A pressure applies a distributed force over a surface. Gravity applies a body force proportional to mass. An initial velocity sets the starting speed for an impact analysis. A temperature field drives thermal expansion. Each load type has its own Abaqus keyword, and the Analyzer’s BC and Load Viewer renders them as colored arrows in the 3D view so you can see exactly where and in what direction they act.

2.5 Steps: Sequencing the Analysis

An Abaqus analysis can have multiple steps, and the order matters. A bolt preload analysis applies the bolt force in Step 1, locks the bolt length in Step 2, and applies the service loads in Step 3. A vibration analysis applies gravity in Step 1 (to get the correct preloaded stiffness) and extracts frequencies in Step 2. A drop analysis may apply gravity gradually in Step 1 and then apply the initial velocity and run the explicit impact in Step 2.

Each step has a procedure type that tells the solver what algorithm to use: *STATIC for equilibrium, *FREQUENCY for eigenvalue extraction, *DYNAMIC EXPLICIT for time-domain impact, *RANDOM RESPONSE for spectral response. The Analyzer’s model type detection banner reads the procedure types and classifies the model accordingly. If the banner says the wrong type, the step definitions may not match the analyst’s intent.

‍ ‍

3. The Four Types of Analysis

3.1 Static Analysis

A static analysis finds the equilibrium deformation of a structure under applied loads. The solver assembles the global stiffness matrix K and the load vector F, then solves KU = F for the displacement vector U. From U it computes strains, stresses, and reaction forces. Static analysis assumes that inertial effects are negligible — the loads are applied slowly enough that the structure reaches equilibrium at each increment.

Static analysis is the most common simulation type and the one you will encounter first in your coursework. It answers questions like: How much does this bracket deflect under a 500 N load? Where is the highest stress? Does the stress exceed the yield strength? What is the safety factor? The Analyzer’s BC and Load Viewer shows the applied loads as red arrows and the boundary conditions as cyan arrows, giving you immediate visual confirmation that the model is loaded and constrained correctly.

3.2 Modal Analysis

A modal analysis extracts the natural frequencies and mode shapes of a structure. The solver solves the generalized eigenvalue problem Kφ = λ Mφ, where K is the stiffness matrix, M is the mass matrix, λ is the eigenvalue (frequency squared), and φ is the eigenvector (mode shape). The natural frequencies tell you where the structure resonates; the mode shapes tell you how it deforms at each resonance.

Modal analysis is the foundation of all dynamic simulation. Every vibration analysis, every random response calculation, every shock response spectrum evaluation starts with a modal extraction. If the natural frequencies are wrong — because the mesh is too coarse, because a material is missing density, because a constraint is not properly defined — every subsequent dynamic result built on those frequencies is also wrong.

Modal analysis requires both stiffness and mass. Stiffness comes from the elastic modulus through the material definition. Mass comes from density. A part with elastic but no density contributes stiffness but zero mass, pushing its modes to mathematically infinite frequency. The Analyzer’s Perturbation Review dialog checks every material for density completeness.

3.3 Random Vibration Analysis

Random vibration analysis computes the statistical response of a structure to broad-spectrum dynamic excitation defined by a power spectral density (PSD) profile. The analysis uses the modes from a prior frequency extraction to compute the RMS (root mean square) stress, displacement, and acceleration at every point in the model. This is the primary analysis type for products that must survive transportation, launch, or operational vibration environments.

The PSD profile defines how much vibrational energy exists at each frequency. The response at each mode is amplified by the dynamic magnification factor, which depends on the damping ratio. The total response is the statistical combination (square root of sum of squares) of all modal contributions. The Analyzer’s PSD Plotter lets you visualize the input spectrum, compute the GRMS level, and compare against 42 industry-standard profiles from eleven environment categories.

3.4 Impact and Drop Analysis

An impact analysis uses the explicit solver to compute the transient response of a structure to a sudden velocity change. The product is given an initial velocity and dropped onto a surface. The solver computes the stress waves, contact forces, plastic deformation, and potential failure at each time increment through the event. This is the most computationally demanding analysis type and the most sensitive to setup errors.

The key validation metric for an explicit analysis is the energy balance. The initial kinetic energy (½mv²) must be conserved as the event progresses — converting to internal strain energy, contact dissipation, and hourglass energy. If energy is not conserved, the simulation has a fundamental problem. The Analyzer’s Drop Simulation Analysis tool identifies the velocity vector, gravity direction, hit surface, and center of mass, and the Recommendations tab checks for energy output request completeness.

‍ ‍

4. The Five Mistakes Every Student Makes

These are not hypothetical errors. These are the five mistakes I have seen in every student’s first set of simulations, across forty-five years of mentoring. Learning to recognize them early will save you weeks of debugging.

4.1 Trusting the Default Mesh

Automatic mesh generators produce meshes that fill the geometry, not meshes that produce accurate results. A mesh that looks fine visually may be far too coarse in regions of high stress gradient. The only way to know whether a mesh is adequate is to run a mesh convergence study: refine the mesh, re-run the analysis, and compare the results. If the stress changes significantly with refinement, the original mesh was not adequate. If the stress converges to a stable value, the mesh is sufficient.

The Analyzer shows you the element count and element types for every part. If a critical structural component has 200 elements while a non-structural cover has 5000, the mesh allocation is inverted. The stress prediction in the critical component is likely mesh-dependent and unreliable.

4.2 Forgetting Density

A material without density has zero mass. A modal analysis produces infinite frequencies. An explicit analysis produces infinite acceleration. A gravity load produces zero force. The solver computes all of these without warning. The Analyzer’s Material Consistency Review flags every material that is missing density, and the Perturbation Review’s Check 7a verifies density completeness for vibration models.

4.3 Wrong Boundary Conditions

Students tend to over-constrain models because over-constraint produces an answer (the model is artificially stiff) while under-constraint produces a solver failure (the stiffness matrix is singular). The problem with over-constraint is that the answer is wrong — the structure appears stiffer and stronger than it actually is, and the safety margin is overestimated. The correct approach is to apply boundary conditions that represent the physical support conditions as closely as possible.

The Analyzer’s BC and Load Viewer shows you exactly where the boundary conditions are applied. If you see cyan arrows covering an entire face when the physical support is only at bolt locations, the model is over-constrained.

4.4 Unit System Confusion

Abaqus has no built-in unit system. You must choose one and be consistent. The three common systems are SI (m, kg, s, Pa), mm-tonne-s (mm, tonne, s, MPa), and mm-N-s (mm, kg, s, MPa with gravity in mm/s²). Mixing units within a model — entering density in kg/m³ when the model uses mm-tonne-s, for example — produces results that are off by orders of magnitude with no solver warning.

Quantity

SI (m-kg-s)

Length

m

Mass

kg

Time

s

Force

N

Stress

Pa

Density

kg/m³ (steel: 7850)

Elastic modulus

Pa (steel: 2.1×10¹¹)

Gravity

9.81 m/s²

The Analyzer’s unit detection system examines the material property values and infers the most likely unit system. If the detected system does not match your expectation, one or more material properties may be in the wrong units.

4.5 Not Checking the Results

The fifth mistake is the most fundamental: accepting the first set of results without verification. A simulation result is a prediction, not a fact. It must be checked against known solutions (benchmarks), physical intuition (does the deflection direction make sense?), hand calculations (does the peak stress agree with beam theory to within a factor of two?), and experimental data when available. A student who learns to question every result — to ask “is this physically reasonable?” before accepting it — develops the judgment that distinguishes a competent engineer from a software operator.

‍ ‍

5. Using the Analyzer as a Learning Tool

5.1 Loading Your First Model

The Learning Center in the Analyzer includes a Generate Example INP button for each analysis type. Click it to create a minimal working model that demonstrates the correct setup for that analysis type. Load the generated file into the Analyzer and explore every tab. Read the parts list, examine the material definitions, check the boundary conditions in the BC and Load Viewer, and read the recommendations. This is the fastest way to connect the concepts from your textbook to a concrete model that you can see and manipulate.

5.2 Reading a Real Model

When you have access to a real production model — from your coursework, from a senior colleague, or from a public repository — load it into the Analyzer and work through the following questions. Each question develops a specific skill that you will use throughout your career.

Question

What You Are Learning

How many parts are in the model, and what do they represent?

Assembly structure and model scope

What element types are used, and why were those types chosen?

Element selection and mesh strategy

What materials are assigned, and do the values make physical sense?

Material property verification and unit awareness

Where are the boundary conditions, and do they represent the physical support?

Boundary condition modeling and its effect on results

What type of analysis is this, and what does each step do?

Analysis procedure sequencing

What does the Recommendations tab say, and do you understand each finding?

Model quality assessment and best practices

Are there any island parts, and what would they mean for the results?

Assembly connectivity and its importance for dynamic analysis

Can you compute the expected deflection by hand and compare it to the simulation?

Result verification and engineering judgment

5.3 The Learning Center

The Analyzer’s Learning Center tab contains more than twenty-five topics organized into four categories: Analysis Types (modal, shock, SRS, random vibration, harmonic response, static), Best Practices (element selection, thin brittle materials, millisecond units, jerk and fragility, output requests, contact stabilization), Material Properties (drop/impact, static/structural, modal/frequency, advanced/hyperelastic), and Behind the Scenes (rendering modes, assembly transforms, tool guides). Each topic is written to explain not just what to do but why — the physics behind the practice. Topics are filterable by difficulty level: Beginner, Intermediate, and Advanced.

5.4 Building Your Own Models

As you progress from reading models to building them, the Analyzer becomes your pre-submission checklist. Before you submit any model to the solver, load it into the Analyzer and work through the Recommendations tab. Resolve every Error. Review every Warning. Confirm that the parts list, materials, boundary conditions, and step definitions match your intent. The five minutes you spend with the Analyzer before a solver run will save you hours of debugging wrong results after the run.

Make it a habit: never submit a model without loading it into the Analyzer first. This single practice will accelerate your learning more than any other, because it forces you to see every aspect of the model before the solver does, and it catches the errors that the solver will not report.

‍ ‍

6. Standards and Professional Practice

Simulation in a professional engineering context is never done in a vacuum. Every analysis exists to answer a question that comes from a requirement, and that requirement is almost always defined by an industrial standard. The standard defines the test environment (drop height, vibration spectrum, pressure level, temperature range), the acceptance criteria (maximum stress, minimum safety factor, maximum deflection), and the test procedure (number of samples, test duration, pass/fail criteria).

As a student, learning to work from standards rather than from assumptions is one of the most valuable professional habits you can develop. When a senior engineer says “drop it from 1.2 meters,” ask which standard defines that height and which product category it applies to. When a test report specifies a PSD profile, ask which standard it comes from and whether the category matches the product’s operational environment. This is not pedantry — it is engineering rigor, and it is what separates professional practice from guesswork.

The Analyzer’s PSD Plotter includes a library of 42 industry-standard vibration profiles from organizations including NASA, the U.S. Department of Defense, RTCA, ISO, ISTA, IEEE, DNV, and IEC. Each profile is traceable to its source standard. When you encounter a vibration specification in your coursework or early career, look it up in the library. Understanding where the numbers come from — and why they differ between a helicopter, a cargo aircraft, and a shipping truck — is the beginning of the environmental engineering knowledge that makes simulation meaningful.

‍ ‍

7. The Path Forward

7.1 Skills to Develop

Skill

Why It Matters

Mesh convergence studies

The only way to know if a mesh is adequate. Run the same problem with two mesh densities and compare.

Hand calculations for verification

The fastest sanity check. If beam theory says 5 mm deflection and the FEA says 50, something is wrong.

Unit system discipline

One misplaced decimal in density shifts every frequency by a factor of 30. Develop a unit table for every project.

Reading INP files

Understanding the text format gives you direct access to the model’s ground truth. The Analyzer helps, but reading raw keywords builds deeper understanding.

Result interpretation

Learning to look at results critically: Is the stress distribution physically reasonable? Is the deformation pattern consistent with the loading?

Correlation with test data

The gold standard. When simulation and test agree, you know both are right. When they disagree, you learn where your model needs improvement.

Communication

The ability to explain simulation results to non-specialists is as important as the ability to produce them. Practice writing reports that designers and managers can understand.

7.2 Resources

The FEA Best Practices audiobook series at McFaddenCAE.com covers four volumes of practical simulation guidance distilled from forty-five years of experience. The Analyzer’s Learning Center provides topic-by-topic educational content with difficulty-level filtering. The Abaqus documentation (available through your university license) provides the complete keyword reference. And real models — loaded into the Analyzer and explored systematically — provide the hands-on experience that no textbook can replicate.

7.3 A Final Word to the Student

The tools will change. The software will be updated. New element formulations will be developed. New solver algorithms will be released. But the fundamentals — the physics of the equations, the judgment to question the results, the discipline to verify the model, the curiosity to understand why the answer is what it is — these do not change. They are what make you an engineer rather than a user of engineering software.

Learn the tools. But more importantly, learn to see what the tools are doing. That is what the Analyzer is for. That is what this guide is for. And that is what will set you apart throughout your career.

The simulation does not know what it is supposed to compute. Only you do.

‍ ‍

End of Student’s Guide

Abaqus INP Comprehensive Analyzer V21.0

www.McFaddenCAE.com  •  McFadden@snet.net

Engineer. Lifelong Learner. Holistic Analyst.

Developed in collaboration with Claude (Anthropic).

Part 1

ABAQUS INP COMPREHENSIVE ANALYZER

Under the Hood  —  A Deep-Dive Series

PART 1

Model Processing

From File Open to Fully Parsed Assembly

Joseph P. McFadden Sr.

McFaddenCAE.com  |  The Holistic Analyst

© 2026 Joseph P. McFadden Sr. All rights reserved.

Series Introduction — Why We Open the Box

Welcome.

My name is Joe McFadden. I have been doing CAE work — computer-aided engineering, which means finite element analysis — since 1979. That is not a credential I drop to impress you. It is context. It means I have spent decades inside simulation tools, and for most of that time, those tools were black boxes.

You put a model in. Numbers came out. What happened in the middle was largely hidden. You either trusted it or you did not, and there was not much in between.

That bothered me then. It still bothers me. And it is the reason this program exists, and the reason you are reading this series.

The Abaqus INP Comprehensive Analyzer is a free, open-source Python tool that reads Abaqus input files — the .inp files — and breaks them apart, piece by piece, without requiring an Abaqus license to do it. But this series is not just a tour of what buttons do what.

This is a walk through the logic. The thinking. The decisions the code makes at every step, and why it makes them.

I designed this series for three audiences.

First, for engineers who use the tool and want to understand what is happening under the hood — not to distrust it, but to be able to reason with it.

Second, for people who want to build their own tools and need a concrete example of how to approach a complex parsing and analysis problem from scratch.

And third, for anyone who simply refuses to accept a black box. That is the most important group to me, because that is the mindset that leads to real understanding.

This first part covers model processing — everything that happens from the moment you open a file to the moment the program has a complete, analyzed picture of your assembly sitting in memory. We will go step by step. We will talk about what the code reads, how it reads it, what it is looking for, and what it does when it finds it.

Section 1 — The File Selector and the Starting Gun

The first thing the program does when you launch it is load a graphical interface built on Python's built-in tkinter library. Tkinter is not glamorous. It is not a modern web-based framework. It is a thin wrapper around the Tk toolkit that has been part of Python for decades. But it is cross-platform, it requires no installation, and for a desktop engineering tool that needs to run on Windows machines without any special setup, it is exactly right.

The interface opens with three key controls at the top: a file path entry box, a Browse button, and a Process button.

Notice that the Process button starts disabled. This is a deliberate design choice. You cannot process a file you have not selected, and the code enforces that. The Browse button opens a file dialog filtered to show .inp and .cae files. When you select a file and click Open, the path populates the entry box, and only then does the Process button activate.

This is a small detail, but it illustrates a principle that runs through the entire codebase: the program tries to prevent you from doing something incorrect before you do it, rather than waiting to fail after.

When you click Process, the program does something that might seem overly elaborate for what appears to be a simple button click. It does not just run the analysis. It spawns a separate background thread.

Here is why. Python's tkinter interface runs on what is called the main thread — the single execution path that draws the window, responds to mouse clicks, and keeps the application alive and responsive. If you run a long computation on that same thread, the entire window freezes. You cannot move it, you cannot click Cancel, and the operating system eventually marks it as unresponsive.

So the processing logic is handed off to a daemon thread — a background worker. The main thread stays free to do one thing: watch a progress dialog, check every hundred milliseconds whether the background thread has finished, and respond to a Cancel button if you need one.

That progress dialog with the indeterminate progress bar — the one that bounces back and forth — is the main thread's way of telling you that work is happening. The status message inside it updates as the background thread sends signals forward through a thread-safe queue. This is a common pattern in GUI programming, and understanding it is important for anyone building tools that need to stay responsive during heavy computation.

Section 2 — The File Reader and the Include Recursion

The first real task, once the background thread starts, is reading the file. This sounds simple. Open the file, read the lines, done.

But Abaqus input files are not always a single file.

Abaqus supports a keyword called *INCLUDE. When the Abaqus preprocessor encounters this keyword, it pauses reading the current file and starts reading a separate referenced file instead — then returns and continues. This lets large models be broken into pieces: a node file here, an element file there, a materials file somewhere else.

A naive file reader would miss this entirely. It would read the keyword and move on, losing all the data in the referenced files.

The program handles this with a function called read_inp_with_includes. This function does not just read the file. It reads recursively.

Here is how it works. The function accepts a file path and maintains two things: an output list, and a set of visited file paths. The visited set is how it prevents infinite loops — if two files somehow reference each other, the recursion stops.

For each line in the file, the function checks whether the line matches the pattern for a INCLUDE directive. It uses a compiled regular expression for this — a pattern that looks for the text INCLUDE, then INPUT=, then a file name.

If a match is found, the function resolves the referenced path relative to the directory of the current file, then calls itself on that new path. This is recursion — the function calling itself with a new argument.

If the referenced file is found, its lines are inserted into the output at exactly the right position. If it is not found, a warning comment is added to the output and processing continues. Resilience is intentional.

Every line that comes out of this function carries two pieces of information: the line content itself, and the source file it came from. This is important for debugging. If something unexpected shows up in the analysis, the source tracking tells you exactly which file that data came from — even if it was three levels of recursion deep.

The output of this function is a flat list of tuples: text and source, text and source, all the way through the model. From this point forward, the entire rest of the program works from this flat list. The file structure is gone. What remains is a clean, linear sequence of every meaningful line in the model.

Section 3 — Three Patterns That Do All the Heavy Lifting

Before we talk about parsing, we need to talk about the tools the parser uses. The entire structural intelligence of this program — its ability to distinguish a keyword from a data line, a parameter name from a parameter value — rests on three compiled regular expressions.

Regular expressions are pattern-matching rules for text. They are written in a compact notation that tells the computer exactly what to look for in a string. Compiled regular expressions are those same rules that have been pre-processed into an internal format that runs much faster during the millions of comparisons that happen during parsing.

Pattern One — The Include Detector

The first pattern matches *INCLUDE lines. It looks for optional whitespace, then a literal asterisk and the word INCLUDE, then optional whitespace, then an equals sign, then the file name. The case-insensitive flag means it catches INCLUDE, Include, and include all the same.

This pattern is applied to every line during the file reading phase. It runs before anything else.

Pattern Two — The Keyword Detector

The second pattern is the most important in the entire program. It identifies Abaqus keyword lines — lines that start with an asterisk, followed by a keyword name made of letters, numbers, spaces, underscores, or hyphens.

In the Abaqus input format, keywords always start with an asterisk. This is the structural grammar of the format. A line that starts with an asterisk is a command. A line that does not start with an asterisk is data for whatever command came before it.

This single distinction — asterisk line versus data line — is the foundation of every parsing decision the program makes.

The keyword pattern captures everything between the asterisk and either the first comma or the end of the line. That captured group is the keyword name, which the parser immediately converts to uppercase for consistent matching regardless of how it was written in the file.

Pattern Three — The Parameter Extractor

Keywords in Abaqus are almost always followed by parameters on the same line, separated by commas. The format is: keyword, name=value, name=value, and so on.

The third pattern extracts these name-value pairs. It looks for a comma, optional whitespace, a parameter name, optional whitespace, an equals sign, optional whitespace, and then the value extending up to the next comma.

Because this pattern uses the findall method — which returns all non-overlapping matches in a string — a single call against a keyword line returns every parameter at once. The result is immediately converted into a dictionary keyed by uppercase parameter names.

So when the parser encounters a line like *SOLID SECTION, ELSET=BodyElements, MATERIAL=Steel6061 — the keyword pattern extracts the text SOLID SECTION, the parameter pattern extracts a dictionary with ELSET equal to BodyElements and MATERIAL equal to Steel6061, and both are available immediately for routing and storage.

That is three lines of pattern logic standing between raw text and structured, queryable data.

Section 4 — The First Pass: Building the Model Summary

With the file fully read and the parsing tools ready, the first major function to run is called parse_inp_summary. This is the high-level reconnaissance pass. It reads the entire file once and builds a broad statistical picture of the model.

Think of it like doing a census before you start studying a population. You are not yet trying to understand relationships or calculate anything. You are counting and categorizing — taking inventory.

The function initializes a large dictionary before it even looks at the first line. This dictionary is the container for everything the summary pass will collect. Let me walk you through what is in it.

There is a count of nodes, a count of elements, and a counter — a specialized dictionary — that tracks how many elements of each type exist in the model. This is where you learn that your model has, say, forty thousand C3D8R elements and two thousand C3D10M elements.

There is a set of material names, a list of section definitions, counts of element sets and node sets, counts of surface definitions, tie constraints, contact pairs.

There is a step count and a detailed list of step definitions, including what type of analysis each step performs, what time period it runs to, and what incrementation parameters it uses.

There are lists for amplitude definitions, gravity and distributed load records, initial conditions, predefined fields, mass scaling settings, bulk viscosity settings, and hourglass control configurations.

There is a flag for whether General Contact is active. There is a list of assembly instances and their transformations.

The State Machine Concept

All of this comes from a single linear pass through the file. The logic is a state machine.

A state machine is a system that can be in one of several states at any time, and that transitions from one state to another based on inputs it receives.

In this parser, the state is tracked by three variables: the current keyword, the current material, and the current element type. There is also a boolean — a true or false flag — that tracks whether the parser is currently inside a step definition.

Here is the fundamental logic. For each line in the file:

First, skip it if it is blank or starts with two asterisks. Double-asterisk lines are Abaqus comments. They carry no structural meaning.

Second, try to match the line against the keyword pattern. If it matches, update the state — set the current keyword, extract parameters, and dispatch to the appropriate logic for that keyword.

Third, if the line does not match the keyword pattern, it is a data line. Handle it based on whatever state is currently active.

Here is what happens for each major keyword.

When the parser sees *NODE, it sets the current keyword to NODE. Every subsequent data line that starts with a digit is counted as one node.

When it sees *ELEMENT with a TYPE parameter, it sets the current element type. Every subsequent data line is counted as one element, and the element type counter for that type increments.

When it sees *MATERIAL with a NAME parameter, it adds that name to the materials set. Material names are unique — sets do not allow duplicates — so the same material referenced multiple times only appears once.

When it sees STEP, it initializes a new step object, stores the step name and step number, checks whether the perturbation flag is present, and sets the in-step flag to true. When it later sees END STEP, it finalizes that step object, pushes it to the step list, and clears the flag.

Inside a step, keywords like STATIC, DYNAMIC EXPLICIT, DYNAMIC IMPLICIT, FREQUENCY, BUCKLE, and STEADY STATE DYNAMICS each set the step type and add themselves to the global list of simulation types in use. The time period and incrementation parameters come from the first data line following the procedure keyword.

When the summary pass is complete, the program has a complete census. It knows how large the model is, what kind of simulation it runs, how it is connected, and what physics it attempts to solve. That information drives everything that comes next.

Section 5 — The Second Pass: Material DNA and Section Mapping

The first pass gave us a count. The second pass — handled by the function parse_material_section_part_and_props — gives us relationships.

This pass is where the program extracts what I call the material DNA of the model. It maps which materials are assigned to which sections, which sections belong to which parts, and what the actual numerical property values are for every material.

This function runs another linear pass through the same flat file list. It maintains a more complex set of state variables.

There is a part stack — a list that grows and shrinks as the parser moves in and out of PART and END PART blocks. The stack structure is important: it handles nested context. When you are inside a part, the stack has that part's name at its top. When you exit the part, the name pops off.

There is a current material variable and a current property variable. There are section and element-set ownership dictionaries.

Tracking Part Ownership

When the parser sees PART with a NAME parameter, it pushes that name onto the part stack. Every section and element set encountered while the stack is non-empty is tagged as belonging to that part. When END PART appears, the name pops off.

This lets the program track which parts own which element sets without any explicit labeling — the structure of the file itself carries that information through scope.

Section Records

When the parser sees SOLID SECTION, SHELL SECTION, or *MEMBRANE SECTION, it creates a section record. That record captures the section type, the raw keyword line, the current part from the stack, and extracts the ELSET and MATERIAL parameters.

For shell sections and membrane sections, the thickness is not on the keyword line. It is on the first data line that follows. So when the parser is tracking a shell or membrane section and the current section record has no thickness yet, the very next data line is treated as a thickness value and parsed accordingly. Once the thickness is captured, the section record is considered complete.

Material Property Extraction

When the parser sees *MATERIAL with a NAME parameter, it sets the current material. Every keyword that follows — ELASTIC, DENSITY, EXPANSION, CONDUCTIVITY, SPECIFIC HEAT, PLASTIC, DAMPING — is recognized as a material property keyword. Each one creates a new property record attached to the current material.

The data lines that follow are parsed as rows of floating-point numbers. Each number is converted from its text form using Python's float function. If conversion succeeds for every value on a line, the row is added to the property data. If any value fails to convert — perhaps it is a flag or a string token — the row is discarded. The parser is conservative: only clean numerical data is kept.

This is how you end up with a material that has, for example, an ELASTIC property with twelve rows of data — Young's modulus and Poisson's ratio at twelve different temperatures. That is temperature-dependent elastic data, and the program captures every row.

Building the Material-Section-Part Map

At the end of the second pass, the program does a final assembly step. It loops through all the section records it collected and builds a nested map: for each material, which sections reference it, and for each section, which parts are associated with it.

The association comes from two sources. First, if the section record carries a part name from the stack, that part is directly associated. Second, if the section's ELSET parameter matches a key in the element-set ownership dictionary, the owning parts from that dictionary are also added.

The result is the material-section mapping — a dictionary where each material name points to a list of section entries, and each entry includes the section type, the element set, the associated parts, and the thickness if applicable.

This mapping is the engine behind the Materials tab, the Sections tab, and the Parts tab. It is also the input to part identification, which is the next major step.

Section 6 — Node Coordinates and the Geometry Foundation

While the first two passes built the structural and material picture, the geometry — the actual spatial coordinates of every point in the mesh — is captured in a dedicated third pass called parse_node_coordinates.

A finite element model is fundamentally a set of points in space connected by elements. The points are nodes. Each node has an identifier and three coordinates: X, Y, and Z.

In a simple model, node IDs are unique across the entire file. But in a structured model — one where multiple parts are defined with *PART blocks — each part defines its own nodes with its own numbering. Two different parts can both have a node number one, and those are completely different points in space.

This is the node ID collision problem, and it is one of the most important challenges in multi-part model processing.

The program addresses it by maintaining two parallel storage structures. One is a flat dictionary keyed by integer node ID for simple models. The other is a dictionary keyed by part-node tuples — a pair containing the part name and the node ID — for structured models.

As the parser moves through the file, it tracks the current part context using the same PART and END PART pattern as before. When a node is encountered inside a part block, it is stored under the tuple key. When a node is encountered outside any part block, it is stored under the integer key.

The node coordinate record for a given node looks like this: a three-element tuple of floating-point numbers representing X, Y, and Z. The line itself is parsed by splitting on commas, taking the second through fourth values — skipping the first, which is the node ID — and converting each to a float.

The program also handles a special Abaqus feature: the *NODE GENERATE keyword, which defines a range of nodes with regular spacing. This is less common but the parser recognizes and handles it.

When node parsing is complete, every spatial point in the model is in memory, correctly keyed so that later computation can find any node's coordinates regardless of whether the model uses simple numbering or part-scoped numbering.

Section 7 — Element Connectivity: How Nodes Become Structure

Nodes are points. Elements are the connections between them. The element connectivity pass — parse_element_connectivity — reads the *ELEMENT blocks and builds the complete topology of the mesh.

Each element has three pieces of information: an ID, a type, and a list of node IDs that form its corners. The type is critical because it determines how many nodes there are and how they are arranged.

A C3D8R is an eight-noded brick element — a cube-like solid. A C3D4 is a four-noded tetrahedron. A C3D10M is a ten-noded quadratic tetrahedron — four corner nodes plus six midside nodes for curved-edge capability. A C3D20R is a twenty-noded quadratic brick. S4R is a four-noded shell. M3D4R is a four-noded membrane.

The element type determines something critical for parsing: the expected number of node entries per element. A C3D8R has eight nodes. If those eight IDs fit on one line, the element definition is one line. If they do not — which is common for quadratic elements with ten or twenty nodes — the definition continues onto the next line.

Handling Multi-Line Element Definitions

This is one of the places where the parser has to be smart about what constitutes a complete record. A naive line-by-line parser would see the element start on one line, see what looks like a new record on the next, and corrupt the connectivity table.

The program handles this by knowing the expected node count for each element type. When it starts reading an element, it collects node IDs until it has the expected count. If the current line does not provide enough IDs, the parser looks to the next line for continuation — as long as that next line does not start with an asterisk, which would indicate a new keyword.

This continuation logic was the subject of a bug fix in version 15.7. Large models with multi-line element definitions — particularly C3D10M and C3D20R meshes — were previously causing a list index out of range error during STL export because some elements were being stored with incomplete node lists. The fix added defensive validation: any element that does not have the expected number of nodes after parsing is flagged and excluded from geometry operations, rather than causing the entire export to fail.

Part Context and ELSET Tagging

Just as with nodes, element parsing tracks part context. Elements encountered inside a *PART block are tagged with the part name. This part tag is stored on every element record.

Elements can also carry an element-set tag — the ELSET parameter on the *ELEMENT keyword line. This becomes the element's membership identifier in the set-based grouping system.

Each element record that comes out of this function is a dictionary with four fields: the element ID, the element type string, the list of node IDs, and optionally the part name and element set name.

When element parsing is complete, the program has the full mesh topology in memory: every node's location in space, and every element's list of the nodes it connects. This is sufficient to calculate volumes, tessellate surfaces, perform penetration checks, and export geometry.

Section 8 — Part Identification: The Three-Tier Logic

We have nodes. We have elements. We have materials. We have sections. Now comes the question that sits at the heart of multi-part model analysis: which elements belong to which part?

This question sounds simple, but the answer depends entirely on how the model was built. Abaqus supports multiple modeling workflows, and those workflows produce input files with very different structures. The program handles three distinct cases.

Tier One — Structured Models with Explicit Part Definitions

The cleanest case. The input file contains explicit *PART blocks, each with a NAME parameter. Every element inside a part block carries a part tag that was applied during the connectivity pass. Grouping is direct: collect all elements with the same part tag, and you have the part.

The function identify_parts_from_inp_parts handles this case. It groups elements by their part tag, looks up section and material information from the mapping, and builds a part record that includes the element list, the material name, the section type, the thickness if applicable, and a flag marking this as a true structured-part record.

Tier Two — Orphan Meshes with Material-Section Grouping

An orphan mesh is a mesh that was exported from a CAD or meshing tool without preserving the original part structure. The *PART blocks are gone. Node and element IDs may be global and non-overlapping, but the concept of a part has been lost.

In this case, the program reverse-engineers parts from the material-section structure. The logic is: any group of elements that share the same material and the same section definition probably constitutes a distinct physical component.

The function identify_parts_by_material_section loops through the section records, builds a mapping from element-set names to section and material information, then groups elements by element set. Groups that share the same material-section combination are merged into a single part. The resulting parts are named sequentially: Part-1, Part-2, Part-3, and so on.

This is not perfect. Two physically separate components with identical materials and section types will be grouped as one part. But in practice, most models have enough material or section variation to produce useful separations, and the program makes its methodology transparent so you can evaluate whether the result makes sense.

Tier Three — ELSET-Based Part Naming

Some exported models — particularly those from certain meshing workflows — carry part names embedded in their element-set names using a specific convention: the set name contains the part name followed by an at-sign and an instance identifier.

The program detects this pattern and uses it to apply meaningful part names to what would otherwise be anonymous numbered parts. This is the ELSET-based naming path, and it can handle assemblies with well over a hundred named parts. The part naming validation dialog — which appears after processing — shows you exactly which names came from ELSET declarations, which came from reverse engineering, and whether there are any discrepancies.

The Dispatcher

The top-level function identify_parts makes the decision between tiers one and two by checking a single flag on the elements: if any element in the model carries a non-empty part tag, the model is structured and tier one applies. If none do, tier two applies.

Tier three operates on top of whichever identification method ran first, applying better names where it can find them.

There is an important subtlety here that any developer building a similar tool needs to understand. In structured models, you cannot filter elements by ID alone. Two parts can both have an element with ID one hundred. If you search by ID without first filtering by part name, you get the wrong element. This is the element ID collision problem, parallel to the node ID collision described earlier. The program solves it by always looking up elements through the part context first.

Section 9 — Model Type Detection and the Orphan Mesh Dialogue

Part identification tells us which elements belong to which parts. But the program also runs a separate, lighter-weight classification pass called detect_model_type that categorizes the overall model structure.

This function scans the raw file lines — not the parsed data, but the original text — and counts three things: how many *PART blocks there are, how many section definitions there are, and how many material definitions there are.

From those three numbers, it makes a classification decision.

If there are zero *PART blocks, the model is classified as an orphan mesh. The confidence is medium, because it is possible to have a valid single-part model with no explicit PART block.

If there is exactly one *PART block and more than one section or material, the model is classified as an orphan mesh with high confidence — the single PART block was likely added by an export tool and does not represent genuine structured assembly.

If there is exactly one *PART block with one section and one material, the model is classified as simple — a single-component model.

If there are two or more *PART blocks, the model is classified as structured with high confidence.

This classification drives the user experience after processing.

For structured models, the program parses the original part list from the file and offers a dual-view switcher in the Parts tab: you can see the parts as they were declared in the file, or you can see the parts as identified by material and section analysis. This comparison is often informative — it reveals whether the ELSET-based naming and the file-based naming agree.

For orphan meshes, the program shows a confirmation dialog before proceeding. This dialog explains what an orphan mesh is, notes that part names may be generic rather than meaningful, and asks you to confirm that you want to continue. This is the anti-black-box philosophy in action: rather than silently making assumptions, the program surfaces them.

A model banner at the top of the Parts tab then shows the detection result so it is always visible as you work.

Section 10 — Unit System Detection: The Detective Work

Abaqus does not enforce units. You can put any number you want in any field. The solver has no idea whether your modulus of two hundred thousand means two hundred thousand pascals or two hundred thousand megapascals. It just uses the number. The responsibility for consistency is entirely on the analyst.

This is one of the most dangerous aspects of finite element modeling, and one of the most common sources of invisible errors. A model with internally consistent units but the wrong unit system will produce results that are off by orders of magnitude — and if you do not know what answer to expect, you may not notice.

The program addresses this with a unit detection system built from two independent approaches: material library matching and value range analysis.

Material Library Matching

The program maintains an internal library of common engineering materials — steel, aluminum, titanium, FR4 circuit board material, SAC305 solder, various plastics, magnesium, brass, and more — with their property values tabulated for each of ten unit systems.

Ten unit systems. Let me name them so they are concrete. There are the SI systems: SI in meters, SI in millimeters, and SI in millimeters with tonnes for mass rather than kilograms. There are the time-based systems using milliseconds — grams, millimeters, and milliseconds; and tonnes, millimeters, and milliseconds. There are the imperial systems: inches, pounds-force, and seconds; and feet, pounds-force, and seconds. There are also mixed systems.

The detection function extracts Young's modulus and density from each material in the model. It then compares those values against the library entries for every material across all ten unit systems. The comparison is not a binary match — it is a tolerance-based proximity score. If your steel's modulus matches the steel library entry for the millimeter-tonne-second system within a percentage threshold, that is evidence for that unit system.

Evidence accumulates across all materials. The system with the highest total evidence score wins, and the result is presented as a confidence percentage.

There is a threshold check: if the best match is under twenty percent confidence, the library-based result is not reliable and the program falls back to the range-based approach.

The Ambiguity Flag

A critical feature added from external AI review — specifically Grok and Perplexity analysis — is the relative gap check between the top two unit systems. If the top scorer and the second scorer are very close to each other, the program flags the result as ambiguous rather than presenting a false confident answer.

The most important ambiguity case to understand is grams-millimeters-milliseconds versus tonnes-millimeters-seconds. Both unit systems happen to use the same Young's modulus values for common materials. The difference that distinguishes them is density — which differs by a factor of one million between the two systems. A model with only modulus data and no density data is genuinely undetectable from the library alone. The program surfaces this ambiguity explicitly rather than guessing.

The User Confirmation Dialog

Whatever the detection result, the program does not simply apply a unit system silently. It presents a dialog showing the detected system, the confidence level, which materials matched and to what, and a list of all ten unit systems to choose from.

You confirm the result or override it. If you skip the step entirely, the program records that no unit system was selected and proceeds without unit-aware labeling — and it warns you that this is not recommended.

The selected unit system then drives how results are displayed throughout the interface: mass in kilograms or grams or pounds-mass, volume in cubic millimeters or cubic inches, and so on.

Section 11 — Volume and Mass: Gaussian Quadrature Under the Hood

With parts identified, nodes located, elements connected, and a unit system selected, the program can calculate volumes and masses. This is more involved than it might sound.

For a regular geometric shape — a cube, a cylinder, a sphere — volume has a closed-form formula. But a finite element mesh is an irregular collection of polyhedral cells, each with eight or more nodes at potentially arbitrary positions in space. There is no single formula for the volume of an arbitrary hexahedral or tetrahedral element.

The method the program uses is Gaussian quadrature. This is a numerical integration technique that evaluates a function at a set of specific sample points — called Gauss points — and combines those evaluations with weights to approximate the integral over the element domain.

For volume, the integrand is simply the Jacobian determinant — a mathematical quantity that represents how local space within the element is scaled relative to a standard reference element. The reference element is a perfect unit cube or unit tetrahedron in a fictitious coordinate system. The real element is the distorted version of that reference in physical space. The Jacobian tells you how much volume a tiny unit of reference space corresponds to in physical space.

Integrate the Jacobian over the reference element using Gauss quadrature, and you get the physical volume of the element.

For an eight-noded brick — the C3D8 family — the reference domain uses two Gauss points in each of three directions, giving eight sample points total. For a four-noded tetrahedron, four Gauss points are used. For quadratic elements with midside nodes, more points and higher-order shape functions are required.

The program implements vectorized calculations — using NumPy array operations rather than Python loops — to evaluate the Jacobian across all elements of a given type simultaneously. This is the optimization credited in the code comments to the Gemini advisory review, and it produces roughly one hundred to one thousand times speedup on large models compared to element-by-element Python loops.

Mass Calculation and the Density Conversion

Mass is volume multiplied by density. But there is a trap here.

Density in Abaqus models can be expressed in different ways depending on the unit system. In the grams-millimeters-milliseconds system, a typical steel density is approximately 7.8 × 10⁻³ grams per cubic millimeter. In the tonnes-millimeters-seconds system, the same steel has a density of approximately 7.8 × 10⁻⁹ tonnes per cubic millimeter.

Those two numbers differ by a factor of one million. The program applies a density conversion check: if the raw density value is greater than 10⁻⁵, it is assumed to be in grams per cubic millimeter and is converted to tonnes per cubic millimeter by multiplying by 10⁻⁶. If it is already below that threshold, it is assumed to be in the correct form.

This is a heuristic — an educated assumption based on typical material property ranges. It will be wrong for exotic materials with unusually high or low densities. Understanding this heuristic, rather than assuming the conversion is universal, is part of why this series exists.

There is also a filtering step before volume calculation. Not all elements in a model are geometric. MASS elements, SPRING elements, and DASHPOT elements are point or connector entities with no volume. The program identifies and skips these before summing volumes, rather than letting them corrupt the result.

The validation of volume results against independent tools like SolidWorks is how we confirmed the correctness of the calculation. The benchmark comparison was the ground truth.

Section 12 — Interface Nodes, Part Relationships, and Interaction Detection

Once volumes and masses are calculated, the program moves into relationship analysis. It asks: which parts are physically connected to which other parts, and how?

Interface Nodes

The first step is finding interface nodes — nodes that are shared between two or more parts. In a well-meshed assembly, two parts that are bonded together at a surface share the same node IDs at that surface. If part A and part B both list node 500 in their element connectivity, that node sits on the interface between them.

The function find_interface_nodes builds a dictionary from node ID to the list of parts that use that node. Any node appearing in more than one part's list is an interface node. The count of shared nodes between any two parts is a measure of their contact area.

Interaction Detection

Physical connections also show up explicitly in the input file as Abaqus interaction keywords: TIE, CONTACT PAIR, GENERAL CONTACT, COUPLING, *MPC. The parse_interactions function scans for these and extracts the names of the surfaces or sets involved, which can then be traced back to parts.

This is more complex than node sharing because surface names and set names are indirect references. The program builds as complete a picture as the naming conventions in the file allow.

The Relationship Graph

The function build_part_relationships combines node sharing and explicit interactions into a relationship graph. For each pair of parts, it records whether they share interface nodes, how many nodes they share, whether they appear together in any interaction definition, and whether they likely interact mechanically based on both signals together.

This graph feeds the nearest-parts search, the penetration check, and the part interaction visualization in the interface. It is what allows the user to select a part and immediately see which other parts are in contact with it.

An important performance note: the penetration check — which detects geometric overlap between parts — was upgraded from a brute-force comparison to a K-D tree algorithm. A K-D tree is a spatial data structure that partitions points in three-dimensional space and allows nearest-neighbor queries in logarithmic time rather than linear time. The difference between an O(n×m) algorithm and an O(1) lookup for each point is what makes the penetration check practical on large assemblies.

Section 13 — Part Name Validation and the ELSET Cross-Check

Version 15.5 introduced a validation step that compares two independent sources of part name information: the declared names from ELSET-based naming in the input file, and the detected names produced by the reverse-engineering analysis.

The function validate_part_names builds two sets: the declared set, which comes from parsing element set names for the part-name@ID convention, and the detected set, which comes from the identify_parts logic. It then computes the intersection — parts found by both methods — and the two differences: parts declared but not detected, and parts detected but not declared.

If the intersection is complete and both differences are empty, validation passes. If there are discrepancies, the program reports them and presents a choice.

The validation dialog lets you choose whether to use the declared names, the detected names, or cancel loading entirely. This is not a decision the program makes for you. You see the data, you evaluate the discrepancies, and you choose.

This cross-check is particularly valuable for large assemblies with many parts. An assembly with 176 parts — which is a real case this program has been tested on — has a lot of opportunities for naming inconsistencies. Surfacing them before analysis rather than allowing them to corrupt downstream results is exactly the kind of quality gate that separates a professional tool from a script that assumes everything is fine.

Section 14 — Simulation Intent Classification

The final step of model processing — introduced in version 15.7 — is automatic simulation intent classification. After the full parse is complete and all parts are identified, the program scores the model against seventeen engineering simulation purposes.

The seventeen categories include: drop test, crash and impact, quasi-static structural, modal and frequency analysis, thermal analysis, thermomechanical coupling, buckling, fatigue, creep and relaxation, hyperelastic behavior, composites, connector and joint analysis, acoustic analysis, contact mechanics, manufacturing process simulation, and more.

The scoring uses an evidence chain: each simulation type has a set of indicators it looks for in the parsed model data. The presence of an EXPLICIT step, for example, is a strong indicator of a drop test or impact simulation. The presence of *FREQUENCY with a perturbation flag is a strong indicator of modal analysis. Temperature-dependent material properties are evidence of thermal or thermomechanical analysis.

Multiple indicators for a given category accumulate score. The final output is a ranked list of classification candidates with confidence levels, the top classification shown prominently, and the full evidence chain for each candidate visible on request.

The accept-reject-redirect workflow then gives you three choices. Accept the classification and proceed with purpose-specific best-practice recommendations calibrated to that simulation type. Reject it and provide the correct purpose, at which point the program performs a gap analysis — what features are present for the stated purpose, what is missing, and what conversion steps would bring the model into alignment. Or redirect, moving to a different classification.

For QA tracking and documentation, the evaluation results can be exported as a report.

This feature auto-launches after successful processing. It is not a gatekeeping step — you can dismiss it and proceed — but it is always there as a first-pass sanity check that can catch a model running the wrong procedure type before analysis is even attempted.

Section 15 — The Complete Processing Sequence, End to End

Here is the complete sequence from beginning to end, so the full pipeline is clear.

1.  You browse to your .inp file and the Process button activates.

2.  You click Process. A progress dialog opens. A background thread starts.

3.  The background thread calls read_inp_with_includes. The file is read recursively, following any *INCLUDE directives. Every line is paired with its source file. The output is a flat list.

4.  parse_inp_summary runs on the flat list. Node counts, element counts, material names, section counts, step definitions, contact data, amplitude definitions, boundary conditions — all collected in a single pass using the keyword state machine.

5.  parse_material_section_part_and_props runs on the flat list. Material property tables are extracted. Section records are built with thickness data. Part ownership of element sets is tracked through the part stack. The material-section-part mapping is assembled.

6.  parse_node_coordinates runs on the flat list. Node coordinates are stored with part-scoped keys for structured models and integer keys for orphan meshes.

7.  parse_element_connectivity runs on the flat list. Multi-line element definitions are handled. Each element record captures ID, type, node list, part tag, and element set tag.

8.  identify_parts runs. The dispatcher checks for part tags on elements, routes to structured or orphan-mesh identification, and builds the parts dictionary.

9.  validate_part_names compares declared ELSET names to detected part names and presents the validation dialog if discrepancies exist.

10. detect_model_type classifies the model as structured, orphan mesh, or simple. The appropriate confirmation dialog is shown.

11. detect_and_confirm_units extracts material property values, runs them against the material library for all ten unit systems, assesses confidence, and presents the unit confirmation dialog.

12. calculate_all_parts computes volume via Gaussian quadrature for every part. Densities are converted if needed. Non-geometric elements are filtered. Mass is calculated.

13. find_interface_nodes identifies shared nodes across parts. parse_interactions extracts explicit contact and constraint definitions. build_part_relationships assembles the relationship graph.

14. The interface updates: the Summary tab fills with model statistics, the Parts tab populates with the identified assembly, the Materials tab shows property data, the Sections tab shows section details.

15. The simulation intent classifier launches automatically and scores the model against seventeen simulation purposes.

That is the complete processing sequence. From a text file on disk to a fully analyzed, visualized, labeled assembly in memory — with every decision visible, every assumption surfaced, and every result available for independent verification.

Closing — The Point of All of This

I want to close by returning to why we built this the way we did.

Every step in that pipeline that surfaces information to the user — the orphan mesh confirmation, the unit detection dialog, the part validation cross-check, the intent classification — is there because the alternative is to make an assumption silently. And silent assumptions in engineering analysis are how you get wrong answers that look right.

This tool was built as an open-source reference implementation of a complete CAE preprocessing pipeline. Every function described in this document is readable, modifiable, and extensible. The code is not hidden. The logic is not locked. If you want to add a new unit system, a new material to the library, a new element type, a new simulation classification — you can. You now know where to put it.

The multi-AI development approach — using Claude as the primary implementation partner and routing review work to Grok, Gemini, ChatGPT, and Perplexity as independent technical advisors — produced specific, traceable improvements that are documented in the version history. The vectorized volume calculation. The K-D tree penetration check. The Poisson's ratio unit detection enhancement. The confidence gap flagging. Each one came from a deliberate review cycle, not from hoping the first implementation was good enough.

That is a model for how to develop complex technical software: build it, expose it to critical review from multiple independent perspectives, implement the improvements, and document what changed and why.

In the next part of this series, we will go into the three-dimensional geometry engine — how the program tessellates element surfaces into triangles, how it builds the STL representation, how the 3D viewer renders your assembly, and what the surface normals and winding order mean for visualization quality.

You can find the tool, the documentation, and the companion readers for this series at McFaddenCAE.com.

End of Part 1 — Model Processing

Next: Part 2 — The Geometry Engine: Tessellation, STL Export, and the 3D Viewer

© 2026 Joseph P. McFadden Sr. All rights reserved.  |  McFaddenCAE.com

Part 2

ABAQUS INP COMPREHENSIVE ANALYZER

Under the Hood  —  A Deep-Dive Series

PART 2

The Geometry Engine

Exterior Surfaces, Tessellation, the 3D Viewer, and STL Export

Joseph P. McFadden Sr.

McFaddenCAE.com  |  The Holistic Analyst

© 2026 Joseph P. McFadden Sr. All rights reserved.

Recap and Setup — Where Part One Left Us

In Part One of this series, we followed the model processing pipeline from file selection through the complete analysis sequence. We watched the file reader recurse through include directives, the keyword state machine count and categorize every entity in the model, the material-section-part mapping assemble the material DNA, the node coordinates land in memory with part-scoped keys to prevent ID collision, and the three-tier part identification logic reverse-engineer the assembly structure.

At the end of that sequence, the program had a complete structured picture of the model: parts identified, nodes located, elements connected, volumes calculated, relationships mapped.

But none of that is visible yet. It is all data in memory. Numbers in dictionaries.

Part Two is about turning that data into geometry — extracting the surfaces that define what each part looks like from the outside, rendering those surfaces in a three-dimensional viewer, and exporting them as STL files that other tools can consume.

This is where the mathematics of the mesh meets the requirements of visualization, and where a set of decisions about efficiency, quality, and correctness have to be made explicitly rather than assumed.

Section 1 — The Fundamental Problem: What Is the Outside of a Mesh?

A finite element mesh is a volume filling. It is not a surface. The elements pack together to fill the interior of a solid body. The nodes define corners. The elements define how those corners connect to form cells. The cells stack together until the entire volume is covered.

When you look at a physical part — a housing, a bracket, a screw — what you see is the exterior surface. You do not see the interior material. You see the boundary between the part and the air around it.

In a finite element mesh, that boundary is made up of element faces. Every solid element has faces — flat polygonal surfaces connecting subsets of its nodes. An eight-noded brick element has six rectangular faces. A four-noded tetrahedron has four triangular faces.

Here is the key insight that drives the entire geometry engine.

An interior face is shared between exactly two elements. Element A and element B sit next to each other. The face between them belongs to both. When you look at the part from outside, you cannot see that face — it is buried inside.

An exterior face belongs to exactly one element. It sits on the boundary of the part where no neighboring element exists on the other side. That face is what you see when you look at the part.

So the algorithm to extract the visible exterior surface of any mesh, regardless of element type or mesh complexity, is this: count how many times each unique face appears across all elements. Faces that appear exactly once are exterior. Faces that appear exactly twice are interior. Discard the interior faces. Everything that remains is the surface.

This is sometimes called the boundary face algorithm or the unique face algorithm, and it is one of the most elegant and general solutions in computational geometry. It makes no assumptions about the shape of the mesh, the element types used, or whether the mesh has any holes or concavities. It works on any manifold solid mesh without modification.

Consider what this means. You are not tracking neighbors. You are not doing spatial comparisons. You are not raycasting. You are simply counting. The information about what is inside and what is outside is already embedded in the connectivity table — it just has to be surfaced by counting how many times each face appears. That is a profound example of extracting hidden information through a counting operation rather than through geometric computation.

Section 2 — Face Topology: Every Element Type's Anatomy

To implement the face counting algorithm, you need a face topology table — a lookup that tells you, for each element type, which subsets of its node list form the faces.

This is one of those places where domain knowledge is non-negotiable. The code cannot figure out the face topology from first principles. Someone has to know the geometry of each element and encode it.

The Hexahedral Family — The Eight-Noded Brick

The C3D8 family — C3D8, C3D8R, C3D8I, C3D8H — is the eight-noded brick. Think of a slightly distorted cube. The eight nodes sit at the eight corners. The element has exactly six faces, each defined by four of those eight nodes.

Face 1 is the bottom: nodes at positions 1, 2, 3, 4 in the connectivity list. Face 2 is the top: nodes 5, 6, 7, 8. Face 3 is the front: nodes 1, 2, 6, 5. Face 4 is the back: nodes 4, 3, 7, 8. Face 5 is the right: nodes 2, 3, 7, 6. Face 6 is the left: nodes 1, 5, 8, 4.

The exact ordering within each face is the winding order — which we will come back to. For counting purposes, order does not matter. What matters is which set of node IDs defines each face.

The Tetrahedral Family — The Four-Noded Tet

The C3D4 is the four-noded linear tetrahedron. Four nodes, four triangular faces. Each face uses three of the four nodes. Face 1: nodes 1, 2, 3. Face 2: nodes 1, 4, 2. Face 3: nodes 2, 4, 3. Face 4: nodes 3, 4, 1.

The tet is the simplest solid element and the easiest to mesh complex geometry with. It is also the least accurate for bending problems, which is why the quadratic version — the C3D10 — is far more common in production models.

The Quadratic Tetrahedral Family — The Ten-Noded Tet

The C3D10 and C3D10M are ten-noded quadratic tetrahedra. The same four corner nodes as the linear tet, plus six midside nodes — one on each edge. Each face is now a six-noded quadratic triangle: three corners and three midsides.

This is where visualization gets more complex. The face itself is not flat — the midside nodes can be offset from the straight edge between corners, allowing the element to represent curved geometry. Drawing that curved face directly in a viewer is expensive. The solution is subdivision, which we will cover shortly.

The Wedge — Six and Fifteen Node

The C3D6 is a six-noded triangular prism — a wedge shape. It has two triangular faces and three rectangular faces. The C3D15 adds midside nodes to every edge.

Wedge elements appear frequently at the transition zones between hexahedral and tetrahedral meshes, where the mesher needs to bridge between the two topologies. They are less common than hexes and tets but the face extractor has to handle them.

Shell and Surface Elements

Shell elements like S4R and S3R are fundamentally different. They are two-dimensional — they represent a surface with an associated thickness, not a volume. Their face for visualization purposes is the element itself: a quadrilateral or triangle lying in space.

For the exterior surface algorithm, shells are handled differently from solids. A shell element's visible surface is the element face directly — there is no interior to subtract away. The program recognizes the shell type and takes the element faces as-is.

Membrane elements like M3D4R work the same way — they are purely surface elements with negligible structural thickness, used for things like thin film or flexible circuit overlays.

Non-Geometric Elements and the Filter

Before any face extraction runs, a pre-filter removes non-geometric elements. The program maintains a set of element types that have no spatial extent: MASS elements, SPRING1, SPRING2, SPRINGA, DASHPOT1, DASHPOT2, connector elements, rotary inertia elements.

These have no faces, no nodes in the geometric sense, and no contribution to the visible surface. If they are not filtered out before face extraction, the code will attempt to look up face topology for element types that have no topology table entry, producing errors or garbage output.

The filter is simple: check the element type string against the non-geometric set. Normalize the string first — strip whitespace and convert to uppercase — because type strings from different file sources can have inconsistent formatting.

Section 3 — The Face Key: Making Faces Comparable

The face counting algorithm needs to compare faces across different elements. Two elements share a face if and only if they both define a face with exactly the same set of node IDs.

But there is a subtle problem. Element A defines a face with nodes 100, 200, 300, 400 listed in that order. Element B, which shares that face, defines it with nodes 200, 300, 400, 100 listed in that order — rotated. Or even 400, 300, 200, 100 — reversed, because it is approaching the shared face from the other side.

If you compare the face lists as ordered sequences, these look like different faces. They are actually the same face described from different perspectives.

The solution is the face key. A face key is a canonical representation of a face that is independent of the order in which its nodes are listed. The most common approach is to sort the node ID list before comparison.

So nodes 200, 300, 400, 100 become the sorted tuple 100, 200, 300, 400. Nodes 400, 300, 200, 100 also become 100, 200, 300, 400. Both hash to the same key in a dictionary, and the counting works correctly regardless of how each element happens to list its face nodes.

In Python, this sorted tuple is kept as a hashable tuple, usable as a dictionary key. The face counting dictionary has face keys as its keys and integer counts as its values. After one pass through all elements of all types, the dictionary tells you exactly how many elements claim each face.

One more subtlety: winding order. When we sort the node IDs for counting purposes, we lose the original ordering. But the original ordering encodes the face normal direction — which way the face points outward. We need that for rendering.

So the implementation preserves the original face node list alongside the sorted key. The key is used for counting and comparison. The original ordered list is used for triangle generation and normal calculation. The V14.4 improvement to the code — credited in the version history to the Grok advisory review — specifically addressed this: face normalization was improved to preserve winding order even as the canonical key discards it.

Section 4 — Winding Order and Surface Normals

A face normal is a vector perpendicular to the face, pointing outward away from the part. You need normals for two things: lighting calculations in the 3D viewer so the part looks solid instead of flat, and consistency checking to make sure all faces point the right direction.

The normal direction is determined by the winding order — the sequence in which the face's corner nodes are listed. The convention in most computational geometry systems, and in Abaqus, is the right-hand rule: if you curl the fingers of your right hand in the direction the nodes are listed, your thumb points in the direction of the outward normal.

For a four-noded rectangular face listed as nodes A, B, C, D in counterclockwise order when viewed from outside the element, the normal points outward. If you accidentally reverse the order to A, D, C, B, the normal flips inward.

The face topology table for each element type is defined with a specific winding convention. For the C3D8 brick, each of the six faces is listed with nodes ordered counterclockwise when viewed from outside the element. This is why the face definition matters — it is not just which nodes, it is which order.

To compute the actual normal vector, you take two edge vectors of the face — say, from node A to node B, and from node A to node D — and compute their cross product. The cross product of two vectors in a plane gives a vector perpendicular to that plane. The direction follows the right-hand rule from the winding order.

For a perfect element, this calculation is exact. For a distorted element — one where the nodes have been pushed around by meshing to fit curved geometry — the face is no longer perfectly flat. Different triangulation paths across the same quadrilateral face give slightly different normals.

This is one reason why the geometry engine triangulates quadrilateral faces: triangles are always planar by definition, since three points define a unique plane. A four-node quad face may not be planar. Breaking it into two triangles guarantees planarity for each piece and consistent normal calculation.

The split is typically along one diagonal: nodes A, B, C form the first triangle, and nodes A, C, D form the second. The choice of diagonal can affect visual quality for highly distorted quads, but for most engineering meshes the difference is negligible.

Section 5 — Quadratic Element Subdivision

Linear elements have straight edges. Their faces are flat polygons. Rendering a mesh made of linear elements with the face counting algorithm produces an accurate but faceted surface — you can see every element face as a distinct flat patch.

Quadratic elements are different. A C3D10 tetrahedron or a C3D20 brick has midside nodes — extra nodes positioned along the edges between corners. These midside nodes can lie off the straight line between their corner neighbors, allowing the element edges to curve. And if the edges curve, the faces curve.

A direct rendering of a quadratic element's face using only its corner nodes produces a surface that visually misrepresents the element's actual geometry. You lose the curvature. A cylindrical feature meshed with quadratic elements would look like a polygon rather than a cylinder.

Subdivision Approach

The program solves this with face subdivision. When processing a quadratic element face, instead of producing one or two large triangles from the corner and midside nodes, the code subdivides the face into a grid of smaller triangles. The corners of each small triangle are computed using the element's shape functions — the mathematical interpolation rules that define where any point inside the element maps to in physical space.

The subdivision level controls how fine this grid is. A subdivision level of 1 produces 4 sub-triangles per face. Level 2 produces 16. Level 3 produces 64. Level 4 produces 256. The default in the program is level 2 — 16 sub-triangles per quadratic face — which gives smooth, accurate curved surface rendering for most models without excessive triangle count.

Shape function interpolation works as follows. Each node in the quadratic element has an associated shape function — a polynomial expression in the element's natural coordinates, which are a local coordinate system that maps the physical element to a standard reference shape. The value of the shape function at any point gives the weight of that node's contribution to the position of that point.

To find the physical coordinates of a subdivision grid point, you sum up each node's coordinates multiplied by the node's shape function value evaluated at the grid point's natural coordinates. The result is a position on the actual curved surface — not on the straight-edge approximation.

This is the same mathematics that Abaqus itself uses internally when it computes stresses at Gauss points and extrapolates them to nodes. The shape functions are not approximations — they are the defining representation of the element's geometry. Using them for visualization produces a surface that is faithful to how Abaqus actually understands the element's shape.

The toggle between quadratic and linear visualization is exposed in the program's settings. If you are working with a large model and the quadratic subdivision is slowing things down, you can switch to linear rendering for faster preview. If you need the most accurate surface for STL export, quadratic is the right choice.

Section 6 — The extract_surface_triangles Function

All of the logic we have discussed — face topology, face keys, winding order, quadratic subdivision — comes together in the function extract_surface_triangles. This is the workhorse of the geometry engine.

The function takes four inputs: a set of element IDs defining which elements belong to the part being processed, the full elements list, the node coordinate dictionary, and two flags — a boolean for whether to use quadratic subdivision, and an integer for the subdivision level.

It returns a list of triangles. Each triangle is three sets of three-dimensional coordinates — nine floating-point numbers representing the three corners of one triangle in physical space.

Step One — Filter to Part Elements

The first thing the function does is filter the element list to only those elements belonging to the current part. This sounds obvious, but the implementation requires care.

In a structured model — one with explicit part blocks — elements from different parts can have overlapping ID numbers. If the filter works by element ID alone, it will inadvertently include elements from other parts with the same IDs.

The correct filter is part-name-first. The program maintains a part-aware element retrieval method that first filters by the part name tag stored on each element during parsing, then within those results uses the element IDs as a secondary filter. This is the V15.6 fix documented in the version history.

Before this fix, certain multi-part structured models were producing surfaces with faces from neighboring parts included — because the ID-only filter was grabbing elements from the wrong part. The visual result was a surface that appeared correct at a glance but contained faces from the wrong geometry. That kind of silent error is exactly what this series is designed to help you recognize and reason about.

Step Two — Connectivity Validation

Before face extraction begins, every element passes through a connectivity validation check. The program maintains a minimum node count table: C3D4 requires 4 nodes, C3D8 requires 8, C3D10 requires 10, C3D20 requires 20, and so on.

Any element whose node list is shorter than the minimum for its type is flagged and excluded. These are malformed elements — most commonly produced when a file has multi-line element definitions where the continuation lines were not properly joined during parsing.

This validation step was added in V15.7 after a specific bug: large models with C3D10M and C3D20R elements were throwing a list index out of range error during STL export. The error occurred inside the face topology lookup when the code tried to access node position 9 in a list that only contained 8 entries. The element had been parsed with one continuation line missing.

The fix was not to change the face extraction logic. The fix was to catch invalid elements before they reached the extractor. Defensive programming: never let bad data propagate into downstream computation.

Step Three — The Face Count Pass

With a clean list of valid part elements, the function builds a face count dictionary. For each element, it looks up the face topology for that element type, extracts each face as a sorted tuple of node IDs, and increments the counter for that face key.

Alongside the count, it also stores the original ordered face node list — the one that preserves winding — associated with each face key. If a face is seen only once, this stored list is used for triangle generation. If a face is seen twice, it is discarded.

Step Four — Triangle Generation

For each exterior face — those with a count of exactly one — the function generates the triangles.

For linear faces: quadrilateral faces split into two triangles along the diagonal. Triangular faces are already triangles. Each triangle's three corners are looked up in the node coordinate dictionary to retrieve actual spatial positions.

For quadratic faces, when quadratic subdivision is enabled: the face node list is passed to the shape function interpolation routine, which generates a grid of physical positions at the requested subdivision level and returns the sub-triangles.

The result is a list of triangles — coordinate triplets — representing the exterior surface of the part. This list is what flows into the 3D viewer and the STL exporter.

Section 7 — The 3D Viewer: Rendering the Assembly

The 3D viewer in this program is built on matplotlib — the same plotting library used for the material property graphs in the Materials tab. The specific components used are the three-dimensional axes class, which provides a genuine three-dimensional coordinate space you can orbit, and the Poly3DCollection class, which renders a list of polygons — in our case, triangles — as a solid surface with shading.

Matplotlib is not a dedicated 3D rendering engine. Tools like OpenGL or VTK would produce faster, higher-quality visualization. But matplotlib is bundled with most Python scientific distributions, requires no separate installation, and provides perfectly functional visualization for engineering mesh review at the scale this tool targets. The explicit design choice is: zero additional dependencies for visualization.

From Triangles to Poly3DCollection

The triangle list output by extract_surface_triangles is a Python list of triplets, where each triplet is three three-dimensional points. Matplotlib's Poly3DCollection accepts exactly this format.

The collection is created with a face color, an edge color, and an alpha transparency value. The default alpha for multi-part viewing is 0.7 — seventy percent opaque. This allows you to see through the front parts to the parts behind them, which is useful for assembly review.

Edge rendering is enabled by default with a thin dark edge color. This draws the triangle edges on the surface, giving you a wireframe-over-shaded appearance that makes it easy to see the mesh density without losing the surface shading.

Lighting and Shading

Matplotlib's three-dimensional shading computes a simple ambient plus directional lighting model. It uses the face normals — derived from the winding order described earlier — to determine how much of the simulated light source each face receives. Faces pointing toward the light source appear brighter. Faces pointing away appear darker.

This is not physically accurate rendering. It is the same Gouraud-style shading that was common in early 3D graphics. For engineering purposes — distinguishing faces, identifying concavities, orienting parts — it is entirely sufficient.

If the face normals are inverted — pointing inward rather than outward — the shading inverts: faces pointing toward the viewer appear dark, concavities appear bright, and the part looks like a photographic negative of itself. This is the most visible symptom of a winding order error, and it is immediately obvious in the viewer.

Part Colors and the Default Palette

When viewing a multi-part assembly, each part is rendered in a distinct color. The program maintains a default palette of ten RGB color tuples: blue, orange, green, pink, yellow, purple, cyan, coral, light green, and mauve. Parts cycle through this palette in order.

You can override any part's color using the color picker dialog, which stores selections as RGB tuples in the program's preferences file. Custom colors persist across sessions for up to fifty parts — a cap that prevents the preferences file from growing unbounded in large assembly work.

Axes, Orientation, and Orbit Control

The three-dimensional axes in matplotlib support orbit interaction — click and drag to rotate the view, scroll to zoom, right-click drag to pan. The axes are automatically scaled to the bounding box of the triangle set so the part fills the view.

The initial view angle is set with an elevation and azimuth — twenty degrees above horizontal, rotated forty-five degrees. This isometric-like starting view shows three faces of a rectangular part simultaneously, which is generally the most useful orientation for first-look review.

The aspect ratio is set to equal in all three dimensions, so a cube-like part looks like a cube, not a rectangle. This sounds trivial but matplotlib's default behavior is to scale each axis independently based on data range, which distorts the visual shape of the part.

Section 8 — Auto-Decimation: Managing Triangle Count

Every quadratic element in a model produces multiple subdivision triangles per face. A C3D10M tet at subdivision level 2 produces four faces, each with 16 sub-triangles, for 64 triangles per element. A model with fifty thousand C3D10M elements produces over three million triangles.

Matplotlib becomes sluggish above roughly one hundred thousand triangles. The Poly3DCollection render time scales roughly linearly with triangle count, and at three million triangles the viewer would be non-interactive.

The program sets a default triangle threshold of one hundred thousand. When the extracted triangle count exceeds this threshold and auto-decimation is enabled, the program triggers a simplification step before rendering.

What Decimation Does

Triangle decimation — also called mesh simplification — reduces the number of triangles in a surface while attempting to preserve its overall shape. The simplest approach is random removal: discard triangles randomly until you reach the target count. This is fast but produces visual artifacts — holes, missing features, irregular gaps.

More sophisticated approaches preserve edge features and curvature by prioritizing which triangles to remove. The Quadric Error Metrics algorithm, developed in the late nineteen-nineties, is the standard for high-quality mesh simplification. It collapses edges selectively, choosing each collapse to minimize the change in surface shape as measured by a quadric error function.

The program offers a quality slider in the multi-part settings dialog: Full mesh at 100%, High Quality at 75%, Balanced at 50%, Fast Preview at 25%, and Draft at 10%. These correspond to the fraction of triangles retained after decimation.

Curvature-Based Quality Recommendations

Introduced in V15.5, the per-part STL export dialog analyzes the curvature of each part's extracted triangles before presenting the quality settings. It computes a curvature score from the distribution of face normal angles across neighboring triangles — parts with smooth planar surfaces have low curvature scores, and parts with curved features or sharp edges have higher scores.

Based on the curvature score, the dialog pre-selects a recommended quality level for each part. A flat plate might be recommended at 25% — decimation does not hurt it. A spherical housing with complex curved features gets a recommendation of 75% or higher — decimation would lose important shape information.

The use-recommended-defaults button applies all recommendations at once, which is especially useful when exporting assemblies with many parts. You can review and override individual part settings on the paged dialog, ten parts per page.

There is an important conceptual distinction here. Decimation for visualization is acceptable. Decimation for measurement or analysis is not. If you are exporting an STL to visually check assembly clearances in a downstream CAD tool, a 25% triangle count is fine. If you are exporting an STL to run a secondary FEA or to measure surface areas, you want the full mesh.

The program does not enforce this distinction — it presents the tools and lets you decide. Understanding why the choice matters is what this series is for.

Section 9 — The STL File Format: Under the Hood

STL is one of the simplest and most durable file formats in engineering. It stands for stereolithography — named after the early additive manufacturing process for which it was developed. Today it is used everywhere: 3D printing, CAD import, FEA preprocessing, visualization.

An STL file contains a flat list of triangles. That is it. No hierarchy, no material, no part names, no colors, no units. Just triangles. Each triangle has three vertex coordinates and an optional surface normal.

STL exists in two forms: ASCII and binary.

ASCII STL

The ASCII format is human-readable. The file opens with the keyword 'solid' followed by an optional name. Then each triangle is listed with its normal vector and three vertex coordinate lines. The file closes with 'endsolid' followed by the name.

ASCII STL is useful for debugging and for small models because you can open it in a text editor and read it directly. But it is bulky: each floating-point number is written as text, taking anywhere from 8 to 20 characters. A million-triangle model in ASCII might be several hundred megabytes.

Binary STL

The binary format is compact. The file starts with an 80-byte header — historically a comment field, often used today to store metadata. Then a 4-byte unsigned integer giving the total triangle count. Then the triangles: each stored as 12 four-byte floating-point numbers (one normal vector and three vertex positions) plus a 2-byte attribute byte count field that is almost always zero.

Each triangle in binary STL costs exactly 50 bytes. A million-triangle model in binary is 50 megabytes — roughly six to ten times smaller than the same model in ASCII. Binary is the default in the program for all exports above a small size threshold.

What the Program Writes

The STL exporter takes the triangle list — the same list produced by extract_surface_triangles — and writes it to disk. For each triangle, it computes the face normal from the cross product of the two edge vectors, then writes the normal and three vertices.

The normal in the file is technically redundant — any conforming STL reader is supposed to compute normals from the vertex ordering rather than trust the stored value. But including correct normals is good practice because some tools use the stored values as a shortcut, and incorrect normals produce rendering artifacts.

Vertex Welding

One optional processing step is vertex welding: merging vertices from different triangles that are at the same location in space into a single shared vertex. An un-welded mesh has separate vertex records for every corner of every triangle — which means two adjacent triangles that share an edge have two separate copies of each shared vertex.

Welding is important for smooth shading calculations in downstream tools, because shading algorithms average normals across shared vertices to produce smooth gradients. Without welding, every vertex is unique and every triangle shades independently — producing the faceted look.

The program exposes a weld tolerance parameter: the maximum distance between two vertices for them to be merged. A value of zero means exact coincidence only. A small positive value handles floating-point round-off. The default is zero, which is conservative — correct but may leave some jagged edges at boundaries between element faces in the output file.

Section 10 — Part-Aware Node Lookup: A Critical Subtlety

The geometry engine has a centralized method for retrieving node coordinates for a given part. This method — get_part_node_coords — is one of the places where architectural decisions made early in the program pay dividends.

The challenge is that node coordinates may be stored in different formats depending on the model type. For orphan meshes, node IDs are integers and the coordinate dictionary uses integer keys. For structured models, node IDs within parts can overlap, and the dictionary uses tuple keys: part-name, node-ID.

The node lookup method has to be smart about this. When asked for the coordinates of node 500 in the part named 'housing', it cannot just look up the key 500 — that might return coordinates belonging to a node 500 in a completely different part.

The method follows a resolution strategy with multiple fallback levels.

First, it tries the tuple key with the exact part name and the node ID. This is the canonical case for structured models.

If that fails — possibly because the part name as stored in the element record uses a slightly different format than the part name as stored in the node dictionary — it tries the base part name with underscores and suffixes stripped.

If that fails, it scans all tuple keys for any entry whose node ID component matches, regardless of part name. This broader search handles cases where the assembly export gave the node a slightly different part attribution than the element.

If that fails, it tries the integer key directly, for models where the node might have been recorded outside any part block.

This multi-strategy resolution is the product of debugging real models — not theoretical edge cases. Actual assembly exports from different Abaqus workflows produce subtly different node key formats. A lookup that only handles the happy path will fail silently on a significant fraction of real files.

The result of the method is a flat integer-keyed coordinate dictionary containing only the nodes belonging to the requested part. This dictionary is what gets passed to the face extractor and the STL writer. Every downstream function works with clean, unambiguous data.

Consider what this represents in terms of software design philosophy. The node lookup method is an abstraction boundary. Everything above it — the viewer, the STL exporter, the volume calculator — does not need to know whether the underlying storage uses integer keys or tuple keys or something else. It asks for a part's nodes, it gets a clean dictionary, and it proceeds.

Abstraction boundaries like this are what make a codebase maintainable. If the storage format ever changes — say, to handle some new Abaqus export format with a third key structure — only the lookup method needs to be updated. The rest of the program works unchanged.

Section 11 — Shell Elements: A Special Case for Surface Identification

Shell elements deserve a dedicated section because their relationship with the exterior surface algorithm is fundamentally different from solid elements.

A solid element has volume. Its exterior faces are those faces that no neighboring element shares. The face counting algorithm finds them.

A shell element has no volume. It is a surface. It represents a thin physical component — a sheet metal panel, a circuit board, a flexible membrane — modeled as a two-dimensional surface in space with an associated thickness property. The element itself is the visible surface. There is no interior to exclude.

For a pure shell model, the face counting algorithm behaves differently. Apply the algorithm naively, and every shell element's face appears exactly once — because shells do not share faces with neighboring shells at the element level, they share edges. The count of one marks every face as exterior, which is correct.

But what about a mixed model? A circuit board assembly might have solid C3D8R elements for the solder balls and chip packages, S4R shell elements for the PCB substrate, and M3D4R membrane elements for thin film overlays. The face extractor has to handle all three element families in the same pass.

The program handles this by classifying elements before face extraction. The is_geometric_element_type function — a Gemini-review fix in the version history — accepts both solid elements in the geometric solid set and surface elements in the surface elements dictionary. The surface elements dictionary is populated by the STL exporter module and includes shell, membrane, and rigid surface types.

For surface elements, the visualization path uses the element face directly as a triangle or triangulated quadrilateral, applying the same winding order and normal calculation as for solid exterior faces. The quadratic subdivision logic applies here too: S8R shell elements have midside nodes and benefit from subdivision for curved shell geometries.

The membrane overlay technique is worth a specific mention here because it is a common point of confusion. A membrane element placed over a solid substrate uses the same material as the substrate. Its thickness is negligible — essentially zero structurally. Its purpose is to report the stress at the surface integration point of the substrate, which is where the surface of the physical component actually is.

When such a model is processed, the membrane's faces are on top of the substrate's outer faces. The face counting algorithm sees the substrate's outer face appearing once — exterior from the substrate's perspective. It also sees the membrane's face appearing once — exterior from the membrane's perspective. If these faces use the same node IDs, they may cancel each other out in the count and disappear.

This is a known edge case and one reason the program provides the dual-view option: the original file structure view may reveal the membrane as a separate entity even if the identified-parts view merges it with the substrate.

Section 12 — The Complete Geometry Pipeline, End to End

Here is the complete sequence consolidated into a single numbered list.

1.  The user selects a part in the Parts tab and clicks View in 3D or Export STL.

2.  The part-aware element retrieval method filters all elements to those belonging to the requested part, using the part name tag from parsing rather than element ID alone.

3.  The connectivity validation filter checks every element's node list length against the minimum expected count for its type. Any element with an incomplete node list is excluded.

4.  Non-geometric elements — MASS, SPRING, DASHPOT, and others — are filtered from the list.

5.  The part-aware node lookup method builds a flat integer-keyed coordinate dictionary containing only nodes for this part, resolving tuple keys to integer keys through the multi-strategy fallback.

6.  The face count pass runs over all elements. For each element, the face topology table returns the list of face definitions. Each face definition becomes a sorted tuple face key. The key increments a count in the face dictionary. The original ordered node list is stored alongside for winding preservation.

7.  Face count equals one: exterior. Face count equals two: interior. Discard interior faces.

8.  For each exterior face: look up node coordinates. If linear, split quads into two triangles. If quadratic and subdivision is enabled, generate the subdivision grid using shape function interpolation at the specified level.

9.  The result is a list of triangles — coordinate triplets in physical space.

10. For 3D viewing: pass the triangle list to Poly3DCollection with the part's color, alpha, and edge settings. Render in the matplotlib three-dimensional axes. Apply equal-ratio axis scaling and an isometric starting orientation.

11. If the triangle count exceeds one hundred thousand and auto-decimation is enabled, the quality dialog appears. The curvature analysis pre-selects recommended quality levels per part. The user confirms or adjusts. Decimation runs. The reduced triangle list is rendered.

12. For STL export: the triangle list is written to disk in binary or ASCII format. Each triangle's face normal is computed from the cross product. The 80-byte header, triangle count, and per-triangle records are written in sequence. Vertex welding is applied if the weld tolerance is non-zero.

That is the complete geometry pipeline. From a parsed connectivity table to a three-dimensional rendering or a file on disk, with every step explicit and every decision traceable.

Section 13 — What Can Go Wrong, and What the Errors Tell You

A series about critical thinking has to include a section on failure modes. Understanding what can go wrong and why is how you develop diagnostic skill.

Inverted Surface — Wrong Winding Order

Symptom: In the 3D viewer, the part appears dark from the front and bright from the back. The lighting looks backwards.

Cause: The face winding order is inverted relative to the viewer's assumption. Either the face topology table has the nodes listed in the wrong order for a particular element type, or the model itself was exported with flipped element connectivity.

Diagnostic: Check one element manually. Look up its node IDs in the connectivity table, look up those nodes' coordinates, compute the face normal by hand using the cross product, and verify which direction it points relative to the element's center.

Missing Faces — Interior Faces Classified as Exterior

Symptom: The part surface has holes — you can see through it to the inside.

Cause: Some interior faces are appearing with a count of one instead of two. This happens when two adjacent elements that share a face define that face with different node orderings that, after sorting, produce different face keys.

For example: element A defines a face with nodes 100, 200, 300, 400. Element B defines what should be the same face with nodes 100, 300, 200, 400 — swapping two non-adjacent nodes. Sorted, A gives 100, 200, 300, 400. Sorted, B gives 100, 200, 300, 400. These match. But if B instead had 100, 200, 350, 400 — a slightly different node — the keys do not match, both faces appear once, and both are treated as exterior. You get a face on the inside of the model appearing as a visible surface.

In practice this is rare with well-formed meshes. It can appear in meshes that were manually edited, exported from non-standard tools, or stitched from multiple sources.

List Index Out of Range — Incomplete Element Connectivity

Symptom: An exception during STL export or 3D viewing. The error message says 'list index out of range.'

Cause: An element's node list is shorter than expected. The face topology table for the element type tried to access node at position 9, but the list only has 8 entries. This is the bug from the V15.7 fix discussed in Section 6.

Diagnostic: Look for multi-line element definitions in the input file for quadratic element types. Check whether continuation lines are properly joined in the parsed element records.

Resolution: The connectivity validation filter now catches this before the extractor runs. If you see this error in the console debug output and the extraction still succeeds, it means the filter caught the bad elements and excluded them, and the remaining valid elements produced the surface.

Empty Surface — No Triangles Extracted

Symptom: The viewer shows nothing. The STL export produces a zero-byte or near-zero-byte file.

Causes: The part was filtered to zero elements — either the part name lookup failed, all elements were non-geometric, or all elements failed connectivity validation. Or the face topology table has no entry for the element types in this part. Or all faces were shared — which should not happen for a physically valid closed mesh but can occur for a single-element test case.

Diagnostic: Check the debug console output. The program logs the number of elements retrieved for the part, the number of triangles extracted, and warnings about filtered or skipped elements. These messages trace the pipeline step by step and tell you exactly where the count went to zero.

Closing — Geometry as Information

The geometry engine is, at its foundation, an information extraction problem.

The mesh file contains everything needed to describe the exterior surface of every part. That information is implicit in the connectivity table — hidden in the counts of how many times each face appears. The geometry engine's job is to make that implicit information explicit: to surface the boundary from the interior, to convert connectivity data into renderable triangles, to write those triangles into a format that other tools can consume.

Every design decision in the pipeline has a reason.

The face key sorts nodes to handle order-independent matching. The winding order is preserved alongside the key to maintain normal direction. Quadratic subdivision uses shape functions — the same mathematics as the solver — to faithfully represent curved geometry. The connectivity validation filter stops bad data before it propagates. The part-aware element retrieval prevents cross-part ID collision. The multi-strategy node lookup handles format variations in real files.

None of these are arbitrary. Each one was added because a specific failure mode was observed on a real file. That is how production-grade software develops: not from theoretical completeness, but from the accumulated record of real cases that broke earlier, simpler versions.

In Part Three of this series, we will move into the material property system — how property datasets are stored, how the plotting engine selects axes and formats data, and how the recommendation engine uses material data to identify risks specific to the simulation type.

Everything described in this series is visible in the source code at McFaddenCAE.com.

End of Part 2 — The Geometry Engine

Next: Part 3 — Material Properties, Plotting, and the Recommendation Engine

© 2026 Joseph P. McFadden Sr. All rights reserved.  |  McFaddenCAE.com

Part 3

a

ABAQUS INP COMPREHENSIVE ANALYZER

Under the Hood  —  A Deep-Dive Series

PART 3

Material Properties, the Plotting Engine,

and the Recommendation System

From Property Tables to Diagnostics and Best-Practice Guidance

Joseph P. McFadden Sr.

McFaddenCAE.com  |  The Holistic Analyst

© 2026 Joseph P. McFadden Sr. All rights reserved.

Setup — What Material Data Actually Is

Parts One and Two of this series covered the structural side of the model: reading the file, identifying parts, extracting geometry, rendering surfaces. All of that is topology — the shape of things and how they connect.

Part Three is about what those parts are made of. Material data is where the physics lives. It is the bridge between the geometric model and the physical behavior you are trying to predict. Get it wrong — use the wrong modulus, misrepresent temperature dependence, omit failure criteria — and your simulation produces numbers that have no connection to reality, no matter how clean the mesh is.

This part of the program — the Materials tab, the Property Viewer tab, the Plotting tab, the Recommendations tab, and the Edit Proposals system — is where that data is made visible, auditable, and actionable. We will walk each piece in turn.

Section 1 — How Material Data Is Stored in Memory

By the time the interface loads, the material data has already been extracted — during the second parsing pass covered in Part One. What we have in memory is structured as a nested dictionary.

The top level is keyed by material name — the name as it appears after the equals sign in *MATERIAL. Each material name maps to a list of property records. Each property record is itself a dictionary with three fields: the keyword name, the keyword parameters, and the data.

The keyword name is the Abaqus property keyword: ELASTIC, DENSITY, EXPANSION, CONDUCTIVITY, SPECIFIC HEAT, PLASTIC, DAMPING. The parameters are the options specified on that keyword line — for example, MODULI=LONG TERM on a viscoelastic definition. The data is a list of rows, where each row is a list of floating-point numbers.

To make this concrete: a steel material with temperature-dependent elastic properties might have an ELASTIC record with twelve data rows. Each row has three values: Young's modulus E, Poisson's ratio nu, and temperature T. A material with a simple constant density has a DENSITY record with one row containing a single value.

A more complex material — a polymer used in a drop test simulation — might have ELASTIC data, DENSITY data, EXPANSION data for thermal strain calculation, and PLASTIC data with a yield curve defined at multiple temperatures. All of these appear as separate property records in the list for that material name.

The material names set is assembled from the *MATERIAL keyword pass. The mat_props dictionary is assembled from the property keyword pass. The two are linked by the current_material variable in the parser's state machine — when a DENSITY keyword appears, it gets attached to whichever material was most recently declared.

This linkage is maintained purely through sequential state. There is no explicit cross-referencing step. The parser knows which material is active because it saw the most recent MATERIAL line, and it keeps that in state until the next one. This is why the file structure matters: if a material property keyword appears before any MATERIAL line, it has no material to attach to and is silently discarded.

Section 2 — The Materials Tab: Selection, Details, and the Parts Map

The Materials tab is the first place most users go after processing a model. It gives you the complete material inventory: every material in the file, which sections reference each material, and which parts use each section.

The left panel is a scrollable listbox containing material names, alphabetically sorted. There is a search and filter control above it — a text entry and an Apply button. When you type a substring and click Apply, the listbox repopulates with only the materials whose names contain that substring. Clear restores the full list.

This filter is particularly useful in large models. A mobile device assembly might have fifteen or twenty material definitions: two or three grades of aluminum, a board material, several solder alloys, various polymers, adhesives, and potting compounds. Finding the one you want in an unsorted list of twenty entries requires scanning. A filter that responds to typing 'Al' and showing only aluminum alloys cuts that scan to a few entries.

When you select a material, the right panel displays the material details. This is a scrolled text widget rendered in a monospace font. It shows the material name at the top, then for each property record: the keyword and its parameters on one line, followed by the data table with inferred column headers.

The inferred headers come from the KNOWN_PROP_HEADERS dictionary. That dictionary maps each property keyword to a list of standard column names. ELASTIC maps to E, nu, T. DENSITY maps to rho, T. EXPANSION maps to alpha, T. CONDUCTIVITY maps to k, T. SPECIFIC HEAT maps to cp, T. PLASTIC maps to yield, plastic strain, T. DAMPING maps to alpha, beta.

When the data is displayed, the infer_headers function looks up the keyword, takes the first N entries from the known header list where N is the number of columns in the data, and uses those as column labels. If the data has more columns than the known headers cover, synthetic column names are generated: c4, c5, c6, and so on.

This column inference is an educated guess based on Abaqus conventions, not a guarantee. Temperature-independent elastic data has two columns: E and nu. Temperature-dependent elastic data has three: E, nu, T. The inferred header nu reads correctly in both cases because the function takes the first N entries from the known list. But if a material has a non-standard property definition — an orthotropic elastic definition with nine constants on one line, for example — the column headers will be wrong. The program displays what it can infer, and the analyst is expected to verify against the actual model definition for anything non-standard.

The Parts Using This Material Panel

Below the material details is the Parts Using This Material panel — a listbox with extended multi-selection enabled. This shows every part that was associated with the selected material through the material-section-part mapping built during the second parse pass.

This reverse lookup is one of the most practically useful features in the Materials tab. You have a material — say, a specific aluminum alloy — and you want to know which parts in the assembly use it. Select the material, and the parts list populates immediately. Select some or all of those parts, add them to the Parts tab pre-selection, and you can view or export just the aluminum parts as a group.

The Export Parts CSV button writes the mapping — material to part names — to a comma-separated file for external analysis. The Export DOT Graph button writes a graph-description file in the DOT language format, which can be rendered by Graphviz to produce a visual diagram of the material-section-part relationships. These are the network analysis exports: they treat the model's material assignments as a graph and let you see its structure.

Section 3 — The Property Viewer Tab: Dataset Navigation

The Property Viewer tab is a dedicated reader for raw material property data. Its purpose is simple: show you the exact numbers the solver will use, without any interpretation, so you can verify them yourself.

The interface has two listboxes on the left and a text display on the right. The top listbox is the material selector — the same list of material names as in the Materials tab. The bottom listbox is the dataset selector — it shows all property records for the selected material.

When you select a material, the dataset list populates with one entry per property record. Each entry shows the keyword name followed by the row count: ELASTIC (12 rows), DENSITY (1 row), PLASTIC (8 rows). Selecting an entry in the dataset list populates the right panel with the data table for that dataset, formatted with inferred column headers.

The right panel uses a scrolled text widget in a monospace font. Monospace is deliberate — it is the only font class that aligns column-formatted text reliably. A proportional font like Arial makes the numbers in adjacent rows appear to shift horizontally, which makes scanning a data table for anomalies much harder. Monospace keeps columns visually aligned.

The data is displayed exactly as parsed: floating-point numbers in their original precision from the file, with no rounding or reformatting. If the file has a value written as 2.07E+05, that is what you see. This matters because it lets you verify that the value was read correctly — not normalized, not scaled, not converted.

This is an important principle. A tool that displays processed or reformatted values hides the connection between the original file and the analysis. A tool that shows you the raw values gives you the foundation to cross-check manually. If your steel modulus shows as 207000 and you expected 200000, you know to go back to the file and investigate. If it showed as approximately 2.1 × 10⁵, the discrepancy might go unnoticed.

Section 4 — The Plotting Tab: Visualizing Material Behavior

Data tables tell you numbers. Plots tell you behavior. The Plotting tab converts material property datasets into graphs — the visual representation of how a material property changes as a function of another.

The most important use case for this tab is temperature-dependent properties. Modern simulation models — especially for drop testing and thermal-mechanical analysis — use materials whose stiffness, yield strength, and expansion coefficient all change with temperature. A material card might have twelve rows of elastic data covering temperatures from −40°C to +250°C. The only way to quickly assess whether that curve is physically reasonable is to see it.

The Plot Selection Flow

The interface has two listboxes on the left: a material selector and a dataset selector. Select a material, select a dataset, and two dropdown menus populate with the column names inferred for that dataset. One dropdown is the X axis column, the other is the Y axis column.

The dropdowns are populated dynamically — the available column choices change based on which dataset is selected. An ELASTIC dataset with three columns offers E, nu, and T as choices. A PLASTIC dataset offers yield, plastic_strain, and T. You choose which quantity to plot against which.

Click Plot X versus Y and a matplotlib figure window opens. The function extracts all data rows for the selected dataset, takes the column index for the X choice and the column index for the Y choice, converts the values to floating-point numbers, and passes them to plt.plot with circular markers and a connecting line. A grid is drawn, axes are labeled with the column names, and the title shows the material name, keyword, and axis names.

Auto Plot E of T

The Auto Plot E of T button is a one-click shortcut for the most common use case: temperature-dependent Young's modulus. The function searches the material's property records for the first ELASTIC dataset that has both an E column and a T column — which means temperature-dependent data. If found, it automatically assigns T to the X axis and E to the Y axis, then generates the plot without requiring you to select the columns manually.

This reflects a deliberate design choice worth noting. The common case should be frictionless. You should not have to select a material, select ELASTIC, then choose T as X and E as Y every time you want to see the stiffness curve. One click, result visible. The general mechanism — the manual X and Y selection — is there for everything else.

What Plots Tell You That Tables Do Not

A smooth, monotonically decreasing stiffness curve with temperature is physically expected for most metals and polymers. A curve that increases steeply at high temperature, or that has a sharp discontinuity between two data points, is a red flag — either an error in the material card or a material model that the analyst needs to understand more deeply before trusting the simulation.

A yield curve — stress versus plastic strain — should be monotonically increasing. A yield curve that decreases after some strain level implies material softening, which is physically possible under strain localization but should be deliberate, not accidental.

These checks are things you cannot see in a column of numbers without careful cross-comparison. A plot makes them visible in two seconds.

The Export Dataset CSV button on the Plotting tab writes the selected dataset — with inferred headers — to a CSV file. This is for users who want to pull the data into Excel or a Python script for more detailed analysis, independent of this tool.

Section 5 — The Sections Tab: Connecting Material to Mesh Region

The Sections tab sits between Materials and Parts in the program's conceptual flow. It displays the section definitions — the explicit assignments that link a material to a set of elements through an element set name.

A section definition in Abaqus is the formal declaration that a specific group of elements — identified by an element set name — is made of a specific material and has a specific section type. For solid elements, the section type is solid. For shell elements, the section type is shell, with thickness. For membrane elements, the type is membrane, also with thickness.

Without a section definition, elements in a model have no material. They are topologically present — they exist in the connectivity table — but the solver cannot compute stresses because it does not know the constitutive relationship. A section definition is what makes an element physically meaningful.

The Sections tab shows all section definitions extracted during parsing. The left panel is a scrollable list with the same filter control as the Materials tab. The right panel displays the section details: the raw keyword line as it appeared in the file, the section type, the material name, the element set, and — for shell and membrane sections — the thickness value.

Recall from Part One that shell and membrane thickness is not on the keyword line itself. It is on the first data line that follows the section keyword. The parser captures it and stores it on the section record. The Sections tab surfaces it so you can verify it is correct without having to find the line in the raw file.

The Parts Using This Section panel below the section details mirrors the Parts Using This Material panel in the Materials tab. It shows which parts are associated with the selected section — derived from the element-set ownership tracking built during the second parse pass.

Both panels support multi-selection and have an Add to Pre-selection button. Pre-selection is the staging area in the Parts tab: you can build up a set of parts from multiple materials or sections without having to remember which parts you wanted, then act on all of them at once.

Section 6 — The Recommendation Engine: Architecture

The Recommendations tab is where the program shifts from display to diagnosis. Instead of showing you what is in the model, it tells you what might be wrong with it — or what best practices the model does or does not follow.

The recommendation system has two layers that are architecturally separate but displayed together in the same tab.

The first layer is the best practices module — an external Python module called best_practices. It is imported at program startup and called during model processing. It receives the parsed model data and returns a list of recommendation objects — structured records each containing a severity level, a category, a title, a description, a recommended action, and an optional reference.

The second layer is the edit proposals system — a set of specific, executable changes to the INP file. These are older and more focused: they check for specific conditions and propose concrete keyword modifications to address them.

Severity Levels and Categories

Best practices recommendations use a four-level severity system. CRITICAL means a condition that is highly likely to produce incorrect results — an error, not a warning. WARNING means a condition that often causes problems and should be reviewed carefully. INFO means a condition worth knowing about that may or may not be a problem depending on intent. SUGGESTION means an optional improvement that follows best practice but is not strictly necessary.

Categories group recommendations by the type of issue: ELEMENT QUALITY, CONTACT, MATERIAL, OUTPUT, PERFORMANCE, STABILITY, BOUNDARY CONDITIONS, and others. This lets you filter mentally — if you are in a hurry to run and you know your output settings are already configured, you can skip the OUTPUT recommendations and focus on STABILITY.

In the interface, each recommendation is displayed with a colored severity prefix. Critical items appear in red. Warnings appear in orange. Info items appear in blue. Suggestions appear in green. Selecting an item in the list displays the full details in the right panel — severity, category, title, full description, the recommended action to take, and the reference source if one is provided.

Section 7 — What the Recommendation Engine Checks

The following six edit proposals are directly visible in the source code and illustrate exactly how the engine reasons.

Edit Proposal E1 — C3D8R to C3D8I Element Upgrade

The C3D8R is a reduced-integration eight-noded brick element. The R suffix means reduced integration: instead of using the full 2×2×2 Gauss point scheme — eight integration points — it uses only one point at the element center.

Reduced integration cuts computation time significantly. But for bending problems — scenarios where the element is subjected to bending rather than pure tension or compression — reduced integration introduces a known accuracy problem. The single-point integration cannot capture the bending strain gradient across the element thickness. The result is that bending stiffness is underestimated, strains at the surface of the part are underpredicted, and stress results near the outer fibers are too low.

For a drop test simulation, where a glass panel or a plastic housing is being bent by an impact load, underpredicting surface strain is exactly the wrong direction to err. It makes the part appear more robust than it is.

The C3D8I adds incompatible modes — extra internal degrees of freedom that capture the bending strain gradient without adding nodes. It is more expensive than C3D8R but dramatically more accurate for bending. The recommendation is to upgrade.

The proposal scans every *ELEMENT line in the file for the pattern TYPE=C3D8R. Each match is shown as a diff — the original line prefixed with a minus sign, the proposed line with C3D8I substituted prefixed with a plus sign. If you apply the proposal, the substitution is made in the in-memory line list. If you then export a modified INP, the exported file contains the upgraded element type.

Edit Proposal E2 — TIE Constraint Hardening

*TIE constraints are used to bond two surfaces that share no nodes. The constraint mathematically forces the nodal degrees of freedom on one surface to follow the other. This is the standard way to connect dissimilar meshes — for example, bonding a fine solder joint mesh to a coarser board mesh without requiring node coincidence.

The default behavior of *TIE includes an ADJUST parameter that is YES by default. ADJUST allows Abaqus to move slave nodes to exactly match the master surface before applying the constraint. In a well-meshed model with good surface proximity, this is fine. In a model where the surfaces are slightly offset — as happens when parts were meshed independently with no guaranteed node coincidence — ADJUST can snap nodes to unexpected positions, introducing artificial strain and over-constraining the interface.

Setting ADJUST=NO prevents this node movement. The constraint is enforced exactly at the nodes' current positions. Combined with a POSITION TOLERANCE of zero — which means only nodes within zero distance of the master surface are tied — the constraint is hardened against over-aggressive node snapping.

The proposal scans every *TIE line, checks for ADJUST and POSITION TOLERANCE parameters, and proposes adding or correcting them. The preview shows the before and after for every TIE constraint in the file.

Edit Proposal E3 — Field Output Block

A model without field output requests produces no stress, strain, displacement, or velocity results in the ODB file. This is a particularly easy mistake to make when building a model from a template that had output requests, then modifying the step type or step parameters in a way that invalidates the original requests.

The proposal checks whether the summary info dictionary shows any output field entries. If it does not, the proposal adds a standard field output block: OUTPUT, FIELD; ELEMENT OUTPUT requesting S, E, PE, and PEEQ — stress, strain, plastic strain, and equivalent plastic strain; and *NODE OUTPUT requesting U, V, and A — displacement, velocity, and acceleration. These are the minimum useful outputs for a drop simulation.

The insertion point is immediately after the first *STEP keyword in the file, ensuring the output block is in scope for the analysis step.

Edit Proposal E4 — Bulk Viscosity

Bulk viscosity is a numerical damping parameter used in explicit dynamic analyses to prevent non-physical oscillations in the shock wave that propagates through the mesh during impact. Abaqus Explicit has a default bulk viscosity, but the default is not always appropriate for all impact scenarios.

The recommended values — 0.06 for linear bulk viscosity and 1.2 for quadratic bulk viscosity — are tuned for drop simulations. The linear term damps long-wavelength oscillations. The quadratic term damps sharp-front shock waves. The specific values reflect accumulated experience in drop simulation engineering.

This proposal only activates if the model is an explicit dynamic simulation — verified by checking the simulation types list for DYNAMIC EXPLICIT. It has no relevance for implicit or static analyses and would never be proposed for them.

Edit Proposal E5 — Mass Scaling

Mass scaling artificially increases the density of elements to increase the stable time step in an explicit analysis. A larger time step means fewer increments to simulate the same event time, which means faster runs.

The problem is that mass scaling changes the inertia of the model. For a genuine dynamic event — an actual drop — the added inertia alters the dynamics. The accelerations, contact forces, and energy distribution all change. If mass scaling is large enough to significantly affect results, you are no longer simulating the original problem.

The proposal locates *MASS SCALING keywords and comments them out with double-asterisk comment markers, adding an annotation explaining why. This is a non-destructive modification — the original line is preserved as a comment and can be restored by removing the leading double asterisk.

Like E4, this proposal only activates for explicit simulations.

Edit Proposal E6 — History Output for Energy Balance

Energy balance monitoring is one of the most important quality checks in explicit dynamic simulation. In a well-behaved simulation, the ratio of kinetic energy to internal energy should remain below five to ten percent throughout the event. If kinetic energy is large relative to internal strain energy, the event is not quasi-static — the dynamics matter and a static analysis would be inappropriate.

More critically, if total energy — ETOTAL — drifts significantly from its initial value, numerical energy is either being created or destroyed. Either condition indicates a problem: hourglass modes adding artificial energy, contact instabilities, or time step issues.

The proposal adds a history output block requesting ALLKE (total kinetic energy), ALLIE (total internal energy), ALLSE (total strain energy), ALLPD (plastic dissipation), and ETOTAL (total energy). These output to the history portion of the ODB file at every increment, making the energy trace available for review.

This is the energy audit trail. If your simulation passes the energy balance check — ETOTAL flat, kinetic energy small relative to internal — you have meaningful evidence that the result is physically reasonable.

Section 8 — The Preview and Apply Architecture

Every edit proposal is structured as a dictionary with five fields: an ID, a title, a description, a preview function, and an apply function. The preview and apply are Python functions — callable objects that can be called at any time.

The preview function takes no arguments. It reads the original file lines — which were stored at parse time — and produces a diff-format text string showing what would change. Lines to be removed are prefixed with a minus sign. Lines to be added are prefixed with a plus sign. Lines that are unchanged are not shown.

This preview is generated fresh every time it is called, against the current state of the in-memory line list. If you have already applied some proposals, the preview for subsequent proposals reflects the already-modified lines.

The apply function takes the current line list and returns a new line list with the modification applied. It uses Python list comprehensions and the regular expression substitution function for pattern-based changes — for example, replacing C3D8R with C3D8I throughout all element keyword lines.

For insertions — adding output blocks or bulk viscosity — the apply function scans the line list for a target keyword, inserts the new lines immediately after, and returns the modified list. The original list is not modified in place. A new list is returned. This means you can call preview again after applying and compare.

The Edits tab — separate from the Recommendations tab — has checkboxes for each proposal. You can select any combination of proposals, preview all of them simultaneously as a combined diff, and then apply them to the in-memory line list. When you export a modified INP, you can choose to include any applied edits or export the original without changes.

No changes are ever made to the original file on disk. The program only modifies the in-memory copy of the lines. The original file is always preserved. This non-destructive approach is not optional — it is fundamental. A tool that silently modifies your working file would be dangerous to use in a production workflow.

Section 9 — The Best Practices Module: A Broader Lens

The edit proposals system — the six proposals described above — was designed specifically for Abaqus Explicit drop simulations. That is the original focus of this tool.

The best practices module, introduced in later versions, takes a broader view. It is a separate Python module — best_practices.py — that can be imported independently of the rest of the program. It exports a set of functions and two enumeration classes: Severity and Category.

The generate_recommendations function is the main entry point. It accepts the full parsed model data — the summary info dictionary and the material-section mapping — and returns a list of Recommendation objects. Each Recommendation is a structured data class with severity, category, title, description, action, and reference fields.

Because the best practices module is a separate file and a clean interface, it can be extended independently. Adding a new recommendation means adding a new function or a new condition check inside best_practices.py and returning an additional Recommendation object from generate_recommendations. Nothing else in the program needs to change.

This architectural separation — the recommendation logic in its own module, isolated from the interface code — is deliberate. It makes the recommendation rules testable in isolation, shareable between different tools, and updatable without risking changes to the display or parsing code.

The best practices module uses the same parsed data that everything else in the program uses. It looks at element types in the summary info dictionary and flags patterns that indicate risk. It looks at simulation types and checks whether appropriate control parameters are set. It looks at material data and flags materials that appear to be missing required properties for the detected simulation type.

The result is a diagnostics list that covers the entire model holistically, not just the narrow edit-proposal checklist.

Section 10 — Simulation Intent and Purpose-Specific Recommendations

The newest layer of the recommendation system — introduced in version 15.7 — is the simulation intent classifier. We touched on this at the end of Part One. Here we look at how it connects to the recommendation engine.

After the intent classifier scores the model and produces a top classification, the accept-reject-redirect workflow determines the path forward.

If you accept the classification — or if you override it with the correct simulation type — the function get_purpose_recommendations is called with that simulation type as input. It returns a list of recommendations calibrated specifically to that purpose.

A drop test model that is correctly classified gets recommendations about energy balance monitoring, mass scaling impact, contact stability, element type selection for impact. A modal analysis model gets recommendations about boundary condition completeness, mass verification, mode sufficiency checks, and residual vector implementation. These are completely different sets of guidance, and presenting the wrong set — drop test advice for a modal model — would add confusion rather than value.

The Gap Analysis

If you reject the classifier's result and state a different simulation type, the gap analysis activates. The generate_gap_analysis function compares the signals detected in the model against the signals expected for the stated purpose.

It produces two lists: what the model has that is consistent with the stated purpose, and what the model is missing or has wrong for that purpose. It also produces a conversion checklist: the specific keyword additions, modifications, or removals needed to make the model appropriate for the stated simulation type.

This is a diagnostic tool for model conversion. If you inherit a model built for static analysis and need to repurpose it for explicit dynamics, the gap analysis tells you exactly what is missing: no DYNAMIC EXPLICIT step, no mass scaling assessment, no bulk viscosity, no appropriate output requests. You do not need to enumerate those requirements from memory.

The evaluation report export writes the full classification result — top purpose, confidence, evidence chain, gap analysis if applicable — to a text file. In a QA workflow where you need to document the pre-run model review, this report is the artifact. It records what the program found, what decision was made, and what actions were recommended.

Section 11 — The CAE File Path: An Export Wrapper

There is one more aspect of the program's input handling worth discussing in this part: the CAE file path. While the program is built around INP files, it also accepts Abaqus CAE binary files — the native Abaqus Workbench format — as input.

A CAE file is not a text file. It is a binary database containing the model, the mesh, the material assignments, the step definitions, the analysis settings — everything. It cannot be parsed directly by the same text-based functions that read INP files.

The program's approach is a pragmatic wrapper. If the selected file ends in .cae, the program does not attempt to parse it directly. Instead, it calls the Abaqus command-line interface — specifically the abaqus cae command with a noGUI Python script — to export the CAE model to an INP file. That exported INP file is then processed through the same pipeline as any other INP.

The export script is embedded in the program as a multi-line Python string. It is written to a temporary file, then passed to the abaqus cae command as the script argument. The script uses the global openMdb function — not a method on the mdb object, which is a distinction that was confirmed through external AI review — to load the CAE file, iterates through the models in the loaded database, creates a job object for each model, and calls writeInput to produce the INP.

The subprocess runs with a timeout of 300 seconds. The output is captured and scanned for SUCCESS and ERROR markers embedded by the script. On success, the exported INP path is returned to the main program, which then processes it normally.

This path requires Abaqus to be installed and available in the system PATH. If it is not, the error message tells you exactly why: Abaqus command not found. There is no attempt to work around the absence of Abaqus for CAE export — the dependency is explicit and the failure mode is clear.

The temporary INP file from the export is cleaned up when the program closes. A reference to the temp file path is stored on the application object so cleanup can find it.

Section 12 — Critical Thinking: What the Material System Reveals

Material data is almost always the weakest link in a simulation model.

Mesh quality can be checked geometrically. Boundary conditions can be verified by inspection. Contact definitions can be traced to physical interfaces. But material data — the numbers that represent the constitutive behavior of the physical materials in the model — comes from somewhere outside the simulation: test data, literature values, datasheet specifications, or engineering judgment.

The most common material data problem is not wrong values. It is values from the wrong context. A modulus measured at room temperature applied to a simulation running at elevated temperature. A yield strength from a datasheet that represents the minimum specification, applied to a material that is actually at the midpoint of the distribution. A density copied from a general reference for a material family, rather than from the specific alloy and temper in the model.

These problems are not detectable from the file alone. The program can tell you that a material has a modulus of 200,000 and that this value is consistent with steel in the millimeter-tonne-second unit system. It cannot tell you whether that specific value is appropriate for the specific grade of steel, the specific processing condition, and the specific temperature range of the simulation.

What the program does — by surfacing the raw values, providing plotting for temperature dependence, and running unit detection against the material library — is give you the information you need to make that judgment yourself. That is the correct role of an analysis tool.

The recommendation engine extends this by checking patterns. Not just values, but relationships. Does this explicit dynamic model have energy balance output? Does this model with contact pairs have friction defined? Does this model with temperature-dependent materials have initial conditions for temperature? These are the pattern checks that experienced analysts run mentally when reviewing a model. The engine makes them automatic.

But — and this is important — the engine cannot make the final judgment. It can flag that energy balance output is missing. It cannot know whether energy balance is actually going to be an issue for this specific model at this specific mesh density. You still have to decide. The tool gives you data and flags. The engineer provides judgment.

Section 13 — The Complete Material System Pipeline, End to End

One final numbered summary, consistent with the end of each part in this series.

1.  During the second parse pass, every MATERIAL keyword sets the current material name. Every subsequent property keyword — ELASTIC, DENSITY, PLASTIC, and others — creates a property record attached to that material. Data lines are parsed as floating-point rows and appended to the record. This continues until the next MATERIAL keyword or until the end of the file.

2.  The material-section-part mapping assembles: sections are linked to materials via the MATERIAL parameter; sections are linked to parts via the part stack context and the element-set ownership dictionary.

3.  After processing, the Materials tab populates from the sorted material names list. Selecting a material triggers on_select_material, which retrieves the material's section list from the mapping, formats it with inferred column headers, and displays it in the details panel. The parts list populates from the mapping's associated parts.

4.  The Property Viewer tab's dataset list populates from the mat_props dictionary for the selected material. Selecting a dataset retrieves its rows, infers column headers, and displays the formatted data table.

5.  The Plotting tab's X and Y column dropdowns populate from the inferred headers of the selected dataset. Plot X versus Y extracts the two column arrays, calls plt.plot, and opens a matplotlib figure. Auto Plot E of T searches for ELASTIC data with a T column and plots it automatically.

6.  The Recommendations tab populates from two sources: the generate_recommendations call that ran during processing, and the propose_edits call that built the edit proposal list. Best practices recommendations are listed first with their severity icons. Edit proposals follow.

7.  Selecting a recommendation shows full details — severity in color, category, title, description, recommended action, reference. Selecting an edit proposal shows its preview diff.

8.  In the Edits tab, proposals can be selected by checkbox, previewed as a combined diff, and applied to the in-memory line list. Export then writes the modified line list to a new INP file.

9.  After intent classification, get_purpose_recommendations adds purpose-specific guidance. If classification is rejected, generate_gap_analysis produces the conversion checklist.

That is the complete material and recommendation pipeline — from a text table of numbers in a file to an actionable, auditable, exportable analysis of the model's material definitions and best-practice compliance.

Closing — The Chain from File to Judgment

We have now covered three complete pipelines across these first three parts.

Model processing: from raw text to structured assembly with parts, nodes, elements, volumes, and relationships.

Geometry: from connectivity tables to exterior surfaces, triangulated meshes, rendered views, and STL files.

Material and recommendations: from property data rows to auditable tables, behavior plots, and diagnostics.

The chain running through all three is consistent. The program reads what is in the file, structures it, makes it visible, and surfaces what it can assess. It does not make decisions for you. It does not hide its methods. Every piece of data displayed can be traced back to a specific line in a specific file. Every recommendation references a specific pattern it found in the parsed data.

That traceability is the goal. Not a tool that produces answers, but a tool that produces evidence — evidence you can evaluate, challenge, and build your own engineering judgment on top of.

Part Four of this series will cover the INP export system — how the program writes modified assemblies back to disk, how it handles the structural requirements of a valid Abaqus input file, and how the sub-assembly export produces clean, self-contained INP files from selected parts of a larger model.

The source code, documentation, and companion readers for this series are at McFaddenCAE.com.

End of Part 3 — Material Properties, Plotting, and the Recommendation System

Next: Part 4 — INP Export, Sub-Assembly Extraction, and the Output Pipeline

© 2026 Joseph P. McFadden Sr. All rights reserved.  |  McFaddenCAE.com

A Guide for Customers of FEA Services

‍ ‍

‍ ‍

Abaqus INP Comprehensive Analyzer

‍ ‍

Version 21.0

‍ ‍

Peeking Under the Hood

‍ ‍

A Guide for Design Engineers and Program Managers Why Understanding the Simulation Builds Confidence in the Decision

‍ ‍

Joseph P. McFadden Sr.

‍ ‍

The Holistic Analyst

‍ ‍

Combating Engineering Mind Blindness

‍ ‍

www.McFaddenCAE.com  •  McFadden@snet.net

‍ ‍

April 2026

‍ ‍

Developed in collaboration with Claude (Anthropic).

‍ ‍
‍ ‍

‍ ‍

Introduction........................................................................ 1

‍ ‍

1. Why Peeking Under the Hood Matters........................... 1

‍ ‍

1.1 The Gap Between the Report and the Model............. 1

‍ ‍

1.2 What You Can Verify Without Being an Analyst....... 1

‍ ‍

1.3 Confidence Comes from Visibility............................. 1

‍ ‍

2. What You Will See When You Open a Model................. 1

‍ ‍

2.1 The Model Type Banner — Is This the Right Kind of Simulation?..................................................................... 1

‍ ‍

2.2 The Parts List — Is Everything in the Model?.......... 1

‍ ‍

2.3 The Materials — Are the Properties What You Specified?........................................................................ 1

‍ ‍

2.4 The Loads and Boundary Conditions — Is the Test Setup Correct?................................................................. 1

‍ ‍

2.5 The Recommendations — What Did the Tool Find? 1

‍ ‍

3. The Collaboration That Visibility Enables...................... 1

‍ ‍

3.1 From Consumer to Collaborator............................... 1

‍ ‍

3.2 The Questions Visibility Lets You Ask...................... 1

‍ ‍

3.3 Building a Culture of Simulation Transparency....... 1

‍ ‍

4. Your Five-Minute Review............................................... 1

‍ ‍

Step 1 — Read the Banner (10 seconds).......................... 1

‍ ‍

Step 2 — Count the Parts (30 seconds)........................... 1

‍ ‍

Step 3 — Check the Materials (60 seconds).................... 1

‍ ‍

Step 4 — Look at the Loads (90 seconds)....................... 1

‍ ‍

Step 5 — Read the Recommendations (90 seconds)...... 1

‍ ‍

A Final Word....................................................................... 1

‍ ‍

‍ ‍

‍ ‍

Introduction

‍ ‍

This guide is not for the analyst who builds the simulation. It is for the designer who designed the product being simulated, and for the program manager who will make a business or safety decision based on the simulation’s results. It is for anyone who relies on simulation output but has never opened the input file that produced it.

‍ ‍

In most engineering organizations, simulation is a one-way street. The analyst receives a design, builds a model, runs the solver, and delivers a report. The designer reads the report and makes a design decision. The program manager reads the report and approves or rejects the product. At no point does anyone other than the analyst see what was actually inside the model — what materials were used, what boundary conditions were applied, which parts were included, and whether the simulation even represents the design it claims to simulate.

‍ ‍

This is engineering mind blindness. It is the condition that develops when the consumers of simulation — the people who make decisions based on the results — have no way to verify that the simulation represents the problem they asked the analyst to solve. It is not a matter of trust. It is a matter of visibility. An analyst can be highly skilled, deeply experienced, and completely trustworthy, and the model can still contain an error that nobody catches because nobody other than the analyst can read it.

‍ ‍

The Abaqus INP Comprehensive Analyzer was built to break this pattern. It reads the simulation input file without requiring an Abaqus license, organizes its contents into plain-language summaries and visual displays, and surfaces the information that designers and program managers need to verify that the simulation represents the physical problem. You do not need to understand Abaqus syntax. You do not need to know how to build a model. You need to know what your product looks like, what it is made of, and what it is supposed to survive — and this tool helps you confirm that the simulation reflects all three.

‍ ‍
‍ ‍

‍ ‍

1. Why Peeking Under the Hood Matters

‍ ‍

1.1 The Gap Between the Report and the Model

‍ ‍

A simulation report is a summary. It shows stress contours, displacement plots, safety margins, and a conclusion. What it does not show is the model that produced those results. A stress contour can look correct and still be wrong if the material properties were entered in the wrong unit system. A safety margin can be positive and still be meaningless if the boundary conditions do not represent the physical test. A displacement plot can look plausible and still be fiction if a critical component was left out of the assembly.

‍ ‍

The report does not show you these things because the report is a product of the model, not a description of the model. The analyst who wrote the report may have described the setup in the methodology section, but that description is the analyst’s interpretation of what the model contains. The model itself — the actual input file that the solver reads — is the ground truth. If the description says the model uses steel properties and the input file contains aluminum properties, the solver uses aluminum. If the description says all parts are included and the input file is missing the battery, the solver simulates a product without a battery. The report tells you what the analyst intended. The model tells you what the solver actually computed.

‍ ‍

The ability to peek under the hood — to see the model directly, in plain language, without needing a solver license or analyst training — is what transforms a simulation consumer into a simulation collaborator. It gives you the ability to ask informed questions, to spot discrepancies between the design and the model, and to have the kind of engineering conversation with the analyst that produces better simulations and better decisions.

‍ ‍

1.2 What You Can Verify Without Being an Analyst

‍ ‍

You do not need to understand finite element theory to verify the most consequential aspects of a simulation model. You need your own domain knowledge — knowledge of the product, its materials, its operating environment, and its failure modes — applied to the information the Analyzer extracts from the input file. Here is what you can verify and why each matters.

‍ ‍

What You Can Check

Why It Matters

Is every part of the product in the model?

A missing component means the simulation does not represent the physical product. The missing part’s mass, stiffness, and contact interactions are absent from the results.

Are the material assignments correct?

The wrong material on a component changes every result: stress, deflection, natural frequency, and failure prediction. A housing modeled as steel instead of polycarbonate is a different product.

Are the loads applied in the right direction?

A force pushing down instead of pulling up, or a pressure on the outside instead of the inside, produces a stress field that is the mirror image of reality. The magnitude may look correct while the sign is wrong everywhere.

Does the model represent the right test condition?

A model configured for a 1-meter drop at 4.43 m/s is a different simulation than a 1.5-meter drop at 5.42 m/s. The velocity, gravity, and drop orientation must match the test specification.

Are the support conditions physically correct?

A bracket modeled as rigidly fixed at all bolt holes behaves differently than one modeled with bolt preload and contact. The support conditions define how the structure resists the applied loads.

Is the unit system consistent?

A density value of 7850 means steel in SI units (kg/m³) but something impossibly dense in mm-tonne-s units (where steel is 7.85×10⁻⁹). A unit error shifts every result by orders of magnitude.

‍ ‍

None of these checks require you to read Abaqus keywords or understand element formulations. They require you to know your product and apply that knowledge to the information the Analyzer presents. That knowledge is exactly what you bring to the collaboration that the analyst cannot provide alone.

‍ ‍

1.3 Confidence Comes from Visibility

‍ ‍

When a program manager signs off on a simulation report, that signature represents confidence that the simulation is a valid representation of the physical problem. Without visibility into the model, that confidence is based entirely on trust in the analyst and the reputation of the simulation process. With visibility, that confidence is based on evidence — on having seen the parts list and confirmed it matches the BOM, on having seen the material assignments and confirmed they match the spec sheet, on having seen the loads and confirmed they match the test requirement.

‍ ‍

This distinction matters because trust alone does not catch errors. A trusted analyst working under schedule pressure can transpose two digits in a density value. An experienced analyst reusing a template from a previous project can carry forward a boundary condition that was correct for the old product and wrong for the new one. A skilled analyst coordinating with a design team can model the revision B geometry while the team has already moved to revision C. These are not competence failures. They are communication gaps — gaps between what the analyst intended and what the model contains, gaps between what the designer specified and what the analyst received, gaps between what the program expected and what was actually simulated. Visibility closes those gaps.

‍ ‍

The goal is not to second-guess the analyst. The goal is to give every stakeholder the information they need to have an informed conversation about whether the simulation represents the engineering problem. The best analysts welcome this kind of scrutiny because it catches errors early, before they become test failures or field failures.

‍ ‍
‍ ‍

‍ ‍

2. What You Will See When You Open a Model

‍ ‍

When you load an INP file into the Analyzer and click Process, the tool parses every keyword in the file and organizes the results into tabs. You do not need to visit every tab. The following walkthrough covers the five things that matter most for a non-analyst reviewer, in the order you should check them.

‍ ‍

2.1 The Model Type Banner — Is This the Right Kind of Simulation?

‍ ‍

The first thing to read is the model type banner at the top of the window. It tells you whether the model is a Perturbation (vibration) analysis, an Impact (drop/crash) simulation, a Static (structural) analysis, or a Mixed model that combines more than one type. Compare this to the test specification or program requirement. If the requirement calls for a random vibration analysis and the banner reads Static, the model is solving the wrong problem.

‍ ‍

Why this matters: The analysis type determines what physics the solver computes. A static analysis finds the equilibrium stress under constant loads. A modal analysis finds the natural frequencies and mode shapes. An impact analysis computes the transient response to a sudden velocity change. Each type uses different solver algorithms, different material properties, and different success criteria. Using the wrong type produces results that may look plausible but answer the wrong question.

‍ ‍

2.2 The Parts List — Is Everything in the Model?

‍ ‍

Open the Parts tab and read the list of parts. Compare this list to the product’s bill of materials. Every structural component that contributes mass, stiffness, or contact to the physical product should appear in the model. Select all parts and click View 3D to see the assembly in three dimensions. Rotate the model and confirm that the geometry looks like your product.

‍ ‍

Why this matters: A missing part is not just an absent component — it is absent mass, absent stiffness, and absent contact. If the battery is not in the model, the product’s mass is wrong, the center of gravity is wrong, and the internal load path during a drop impact is wrong. If a structural bracket is missing, the stiffness of the assembly is wrong and the stress distribution in the surrounding components is wrong. The solver does not know that a part is missing. It computes the correct answer to the incomplete model. Only someone who knows the physical product can spot the gap.

‍ ‍

The Islands button in the Parts tab tells you how many parts are disconnected from the rest of the assembly. An island count greater than zero means at least one part is floating in space with no mechanical connection to anything. In a physical product, every part is connected to something. In the model, a disconnected part is invisible to the solver and contributes nothing to the results.

‍ ‍

2.3 The Materials — Are the Properties What You Specified?

‍ ‍

Open the Materials tab and review the material names and properties. You do not need to understand every material keyword. What you need to confirm is that the materials assigned to each part match the materials in your design specification. If the spec calls for 6061-T6 aluminum and the model shows a generic aluminum with different density or modulus, the simulation is not testing your design — it is testing a different material.

‍ ‍

Use the Material Consistency Review tool (Tools, Review Material Consistency) for a structured check. This tool shows every material in the model with its elastic modulus, Poisson ratio, density, and plasticity data in a single table. It flags any material that is missing required properties, has values outside expected ranges, or shows inconsistencies with the detected unit system.

‍ ‍

Why this matters: Material properties drive every simulation result. The elastic modulus determines how much the structure deflects. The density determines the mass and therefore the natural frequencies and inertial forces. The yield stress determines when the material begins to deform permanently. A ten-percent error in modulus produces a ten-percent error in stiffness and a corresponding shift in every stress and displacement result. A three-order-of-magnitude error in density — common when the unit system is wrong — shifts every natural frequency by a factor of thirty.

‍ ‍

2.4 The Loads and Boundary Conditions — Is the Test Setup Correct?

‍ ‍

Open Tools, BC and Load Viewer. This is the single most powerful check available to a non-analyst reviewer. The viewer shows the entire assembly in 3D with colored arrows indicating every load and constraint in the model. Red arrows are applied forces. Yellow arrows are gravity. Cyan arrows are displacement constraints (fixed supports). You do not need to understand the numerical values. You need to confirm that the arrows are in the right places and pointing in the right directions.

‍ ‍

For a drop simulation, the green arrow should point from the product toward the impact surface — not away from it. For a static analysis, the red force arrows should be at the locations where the physical loads are applied — not at the supports or at a random location. For a vibration model, the cyan constraint arrows should be at the physical mounting points — not floating in space.

‍ ‍

Why this matters: The loads and boundary conditions define the problem the solver is solving. If the load is on the wrong face, the solver computes the stress from the wrong loading condition. If the support is at the wrong location, the solver computes the response of a differently supported structure. If the gravity direction is wrong, the solver computes the weight loading in the wrong orientation. These errors do not produce solver failures. They produce converged, plausible-looking results that answer the wrong question. The BC and Load Viewer makes them visible to anyone who knows where the loads and supports should be.

‍ ‍

2.5 The Recommendations — What Did the Tool Find?

‍ ‍

Open the Recommendations tab and read through the findings. Each recommendation is written in plain language with a severity level: Error (this will likely produce wrong results or a solver failure), Warning (this may produce incorrect results and should be reviewed), or Note (informational observation). You do not need to fix these items. You need to read them and, if any seem concerning, bring them to the analyst’s attention.

‍ ‍

Why this matters: The Recommendations tab is the Analyzer’s independent assessment of the model’s completeness and consistency. It checks things that are tedious to verify manually: whether every part has a material, whether every material has the properties required for the analysis type, whether the contact definitions cover the interfaces that will be active during the event, and whether the output requests will produce the data needed for post-processing. A non-analyst reviewer does not need to understand every recommendation. But a recommendation that says a part is missing density, or that a contact pair references a surface that does not exist, is something that should be discussed with the analyst before the model is submitted.

‍ ‍
‍ ‍

‍ ‍

3. The Collaboration That Visibility Enables

‍ ‍

3.1 From Consumer to Collaborator

‍ ‍

When a designer can open the simulation model and see that the housing material is polycarbonate with the correct glass fiber content, that the drop orientation matches the test specification, that all 47 components in the BOM appear in the parts list, and that the mounting points are constrained at the physical bolt locations — that designer is no longer a passive consumer of the analyst’s report. That designer is a collaborator who can confirm that the simulation represents the product as designed, or who can identify the specific discrepancy that needs to be corrected.

‍ ‍

This is a fundamentally different relationship than one based on trust alone. Trust says: I believe the analyst built the model correctly because the analyst is experienced and competent. Collaboration says: I have verified that the model contains the materials I specified, the geometry I designed, and the loads from the test requirement, and I can confirm that the simulation represents the problem I need solved. Both relationships produce signed-off reports. Only one produces evidence-based confidence.

‍ ‍

3.2 The Questions Visibility Lets You Ask

‍ ‍

Without visibility into the model, the only questions a designer or program manager can ask are about the results: What is the maximum stress? Does it pass? What is the safety margin? These are important questions, but they are downstream questions. They assume the model is correct and ask only about its output.

‍ ‍

With visibility, you can ask upstream questions — questions about the model itself that determine whether the results are meaningful. These are the questions that catch errors before they become test failures.

‍ ‍

Upstream Question

What It Catches

I see 41 parts in the model but we have 47 in the BOM — which six are missing and why?

Missing components that affect mass, stiffness, or load path

The material for the housing shows E = 2100 MPa — shouldn’t that be 2400 for the 30% glass-filled grade we specified?

Material property errors that shift stress and deflection results

The drop orientation shows the velocity arrow pointing at the short edge — the test spec calls for a face-down drop. Is this the right test case?

Wrong test configuration that produces results for the wrong scenario

The boundary conditions show constraints at four points but the product mounts at six bolts. Are the two missing bolts intentional?

Under-constrained model that allows non-physical deformation

The Recommendations tab says three parts have no density defined. Does that affect the vibration results?

Missing mass that corrupts natural frequency extraction

The unit system shows tonne-mm-s but the test report uses SI. Is the conversion handled correctly?

Unit system mismatch that shifts every result by orders of magnitude

‍ ‍

Every one of these questions comes from domain knowledge that the designer or program manager has and the analyst may not. The analyst knows how to build models. The designer knows what the product is made of. The program manager knows what test the product must pass. When all three people can see the model, all three forms of knowledge converge on the same set of facts. That convergence is what produces simulations that accurately represent reality.

‍ ‍

3.3 Building a Culture of Simulation Transparency

‍ ‍

The long-term value of peeking under the hood is not just catching individual errors. It is building a culture where simulation is a shared engineering artifact rather than a private analytical product. In organizations where only the analyst sees the model, simulation is a black box. Inputs go in, results come out, and everyone else takes the results on faith. In organizations where designers and managers routinely review the model’s contents — even briefly, even just the parts list and the loads — simulation becomes a transparent process that the entire team can verify and improve.

‍ ‍

This culture shift has practical consequences. Analysts who know their models will be reviewed build more carefully. Designers who can see the model catch material and geometry errors before the solver runs. Program managers who understand what the simulation contains can write better test specifications and ask sharper questions during design reviews. The simulation process becomes faster (fewer re-runs caused by late-discovered errors), more reliable (more eyes catching more problems), and more trusted (confidence based on evidence rather than faith).

‍ ‍

You do not need to review every model in detail. Even a five-minute check — confirming the parts count, verifying the material assignments, and glancing at the loads in the BC viewer — catches the most consequential errors and transforms your relationship with the simulation from passive consumption to active collaboration.

‍ ‍
‍ ‍

‍ ‍

4. Your Five-Minute Review

‍ ‍

If you have five minutes and a loaded model, here is exactly what to do and what to look for.

‍ ‍

Step 1 — Read the Banner (10 seconds)

‍ ‍

Is the model type what you expect? If the requirement calls for a vibration analysis, the banner should say Perturbation. If it calls for a drop test, the banner should say Impact. If it says the wrong type, stop and ask the analyst.

‍ ‍

Step 2 — Count the Parts (30 seconds)

‍ ‍

Open the Parts tab. Does the part count match your BOM? Click the Islands button. Is the count zero? If parts are missing or disconnected, note which ones and ask the analyst.

‍ ‍

Step 3 — Check the Materials (60 seconds)

‍ ‍

Open Tools, Review Material Consistency. Scan the table for your most critical materials. Is the modulus in the right range? Is density present for every material? Are there any issues flagged in red? If a material looks wrong, note the material name and the value that concerns you.

‍ ‍

Step 4 — Look at the Loads (90 seconds)

‍ ‍

Open Tools, BC and Load Viewer. Rotate the model. Are the arrows where you expect loads and supports to be? Are they pointing in the right directions? Does the overall setup look like the physical test? If something looks wrong, take a screenshot and ask the analyst.

‍ ‍

Step 5 — Read the Recommendations (90 seconds)

‍ ‍

Open the Recommendations tab. Read any items marked as Error or Warning. You do not need to understand every detail. If a recommendation mentions a missing property, an unresolved reference, or a configuration that will produce wrong results, note it and bring it to the analyst.

‍ ‍

Five minutes. Five checks. And you now have more direct evidence about the simulation’s validity than you would get from reading the entire results report without seeing the model. That is the power of peeking under the hood.

‍ ‍
‍ ‍

‍ ‍

A Final Word

‍ ‍

The Abaqus INP Comprehensive Analyzer exists because simulation should not be opaque to the people whose decisions depend on it. A designer who cannot see the model cannot verify that it represents the design. A program manager who cannot read the model cannot confirm that it tests the right condition. An organization that treats simulation as a black box is making decisions on faith when it could be making them on evidence.

‍ ‍

You do not need to become an analyst. You do not need to learn Abaqus. You need to take five minutes to look at the model, apply the product knowledge you already have, and confirm that what the solver is computing matches what the product actually is. That five-minute investment is the difference between trusting a report and understanding a simulation.

‍ ‍

That understanding is what true collaboration looks like.

‍ ‍

End of Guide

‍ ‍

Abaqus INP Comprehensive Analyzer V21.0

‍ ‍

www.McFaddenCAE.com  •  McFadden@snet.net

‍ ‍

Developed in collaboration with Claude (Anthropic).

‍ ‍

Part 4

ABAQUS INP COMPREHENSIVE ANALYZER

Under the Hood  —  A Deep-Dive Series

PART 4

INP Export, Sub-Assembly Extraction,

and the Full Output Pipeline

From Analysis to Action — Writing Valid Abaqus Files

Joseph P. McFadden Sr.

McFaddenCAE.com  |  The Holistic Analyst

© 2026 Joseph P. McFadden Sr. All rights reserved.

Setup — Why Export Matters

The first three parts of this series covered the inward journey: reading a file, turning it into structured data, extracting geometry, displaying properties, running diagnostics. All of that is analysis. You are consuming information about a model that already exists.

Part Four is about the outward journey: producing new files from what the program has learned. This is where analysis becomes action.

The export system has several distinct output types: INP sub-assembly files, STL geometry files, STEP files for CAD tools, CSV spreadsheets, and DOT graph files. Each serves a different downstream purpose. Each has its own requirements for what a valid output looks like.

We will go through all of them, but the deepest attention will go to the INP export — because writing a valid Abaqus input file is the most structurally demanding task in the output pipeline. It requires the program to reconstruct a document format that a solver will actually execute, and that means getting the structure exactly right.

Section 1 — What a Valid Abaqus INP File Must Contain

Before we can talk about how the program writes an INP file, we need to establish what a valid INP file must contain. The requirements are not arbitrary — they reflect the Abaqus solver's expectations for model input.

At minimum, a self-contained INP file that an Abaqus job can run needs these structural blocks in this order.

First, a heading block. The *Heading keyword followed by comment lines. This is metadata — the solver ignores it, but it is where you put the model name, date, author, and any notes. Well-formatted models always have this.

Second, part definitions. Each part is wrapped in a Part and End Part block. Inside the part: a Node block with all the node coordinates, one or more Element blocks grouped by element type, and a section definition — Solid Section or Shell Section — that assigns a material to the element set.

Third, an assembly block. The Assembly keyword opens it, End Assembly closes it. Inside the assembly, each part is instantiated with a Instance and End Instance block. The instance gives the part a position in the global coordinate system. It also allows the same part geometry to be reused at multiple positions — but in a sub-assembly export, each part typically has one instance.

Fourth, material definitions. These go after the assembly block in Abaqus CAE-format files. Each material begins with Material and a NAME parameter, followed by property keyword blocks — Elastic, *Density, and so on — each followed by their data lines.

Fifth, at least one step definition — Step through End Step — with a procedure keyword inside it, output requests, and any boundary conditions or loads. A model without a step definition has no analysis to run, though it is valid as a model definition.

The word 'order' is critical here. Abaqus reads the INP file sequentially. Parts must be defined before they are instantiated. Materials must be defined before they are referenced by sections. The assembly must close before material definitions begin. Steps come last.

A program that writes these blocks in the wrong order produces a file that either errors on input or produces silent garbage. This is exactly why the V15.0 version of the program — documented in the version history — included a dedicated fix for proper keyword casing and correct section definition placement. Earlier versions had produced files where material definitions appeared before the assembly block, which is not how Abaqus CAE exports structure the file.

Section 2 — The Heading Block and Encoding

The first thing the INP exporter writes is the heading block. Let us look at what it contains and why each line is there.

The block starts with the literal text *Heading. The case matters — Abaqus keywords in CAE-format files are mixed case, not all uppercase. The V15.0 fix specifically addressed this: earlier versions wrote keywords in all caps, which while technically valid, was inconsistent with what Abaqus CAE produces and could confuse tools that pattern-match against expected output formats.

The comment lines that follow use the double-asterisk comment prefix. They record: the export description, the number of parts included, the version of the analyzer that produced the file, the author name and contact email, the date of export formatted as a full month-day-year string using Python's datetime module, and the list of part names included in the export.

The *Preprint keyword with echo=NO, model=NO, history=NO, and contact=NO is written next. This suppresses the large diagnostic printout that Abaqus would otherwise write to the data file. In production runs you almost always want this suppressed — the default Abaqus verbosity produces files that can be many megabytes larger than needed.

Encoding: The UTF-8 Fix

Every file the program writes — INP exports, STL files, CSV exports, DOT graphs — is opened with the explicit encoding parameter set to UTF-8. This was a bug fix that appeared in the version history as resolution of Windows charmap encoding errors.

The issue is a Python behavior difference between operating systems. On Windows, when you open a file for writing without specifying an encoding, Python uses the system's default encoding — which on English Windows is typically CP-1252, often called Windows-1252. On Linux and macOS, the default is UTF-8.

If a material name, part name, or any other string in the model contains a character outside the basic ASCII range — an accented letter, a special symbol, a Unicode character used by some CAD tools in their generated names — writing it under CP-1252 either silently mangles it or raises a charmap error that crashes the export.

The fix is always explicit: open every output file with encoding=UTF-8. This produces consistent behavior on all platforms and handles the full Unicode character space. It is a two-word fix with no downsides, and the cost of not having it is a class of intermittent crashes that are hard to reproduce without the exact model that triggered them.

Section 3 — Writing Parts: Nodes, Elements, and Section Definitions

After the heading, the exporter writes the part blocks. This is the most data-intensive section of the output — it contains every node coordinate and every element connectivity record for every part being exported.

Node Writing

For each part, the exporter calls the part-aware node lookup method described in Part Two — the multi-strategy resolver that handles both integer-keyed orphan mesh models and tuple-keyed structured models. The result is a flat integer-keyed dictionary of node coordinates, containing only the nodes belonging to this specific part.

The nodes are written in sorted order by node ID. Sorting is not strictly required by Abaqus — the solver can handle nodes in any order — but it produces deterministic, human-readable output. If you export the same model twice, you get the same file. That matters for version control and for debugging.

Each node line has the format: node ID, comma, X coordinate, comma, Y coordinate, comma, Z coordinate. For two-dimensional nodes — models that have only X and Y — the third coordinate is omitted. The coordinates are written as floating-point numbers in their full precision as Python's string conversion of a float produces them. No rounding, no reformatting.

Element Writing — Grouped by Type

Elements are written grouped by element type. The exporter calls the part-aware element retrieval method, collects all elements for the part, then groups them by their type string. Each group gets its own *Element keyword line with the TYPE parameter set to the element type string and an ELSET parameter naming the element set.

Within each group, elements are sorted by element ID — again for determinism. Each element line is: element ID, comma, then the node IDs in their connectivity order joined by commas.

Here is a subtlety. For elements with many nodes — C3D20R with twenty nodes, for example — the connectivity list on a single line can be quite long. Abaqus has a line length limit. The exporter writes these as single lines regardless, relying on Abaqus to handle continuation. This works for most modern Abaqus versions, but it is worth noting as a difference from the canonical CAE-format which wraps long connectivity lines. The V15.7 fix addressed the inverse problem on the reading side — handling files with wrapped lines. The writing side is a known simplification.

Section Definition — Solid versus Shell

After the elements, the section definition is written. The exporter checks the element types present in the part to determine whether this is a solid or a shell part.

The detection logic checks the element type strings for shell indicators: any type containing S3 or S4 — the shell element family prefixes — or M3D — the membrane element prefix — is classified as a shell part. Everything else is classified as solid.

For solid parts: *Solid Section with ELSET and MATERIAL parameters. No additional data lines.

For shell parts: *Shell Section with ELSET and MATERIAL parameters, followed by a data line containing the thickness value. The thickness comes from the part data dictionary — it was captured during the second parse pass when the original shell section's first data line was read. If no thickness was captured, a default of 1.0 is written with no annotation — a known weakness that the analyst must verify.

The section definition is followed by *End Part and a comment separator. Then the next part begins.

Section 4 — The Assembly Block and Instance Declarations

After all part blocks are written, the assembly block opens. This is the global coordinate frame. It is where the solver is told that the parts it just read are being placed into a simulation together.

The assembly block starts with *Assembly, NAME=Assembly. In the exported file, the assembly is always named Assembly — singular, capitalized. This is the standard convention and what Abaqus CAE produces.

Inside the assembly, each part gets one instance declaration. The format is: Instance, NAME=export-name-1, PART=export-name. Then End Instance.

The naming convention is worth explaining. The instance name is the export name followed by a hyphen and the digit 1. Abaqus distinguishes between part names and instance names — a part can be instantiated multiple times, each with a different name and position. By convention, the first instance of a part named Housing is named Housing-1. The program follows this convention for all exported instances.

No translation or rotation transformations are written for the instances. The parts are positioned at the origin in their own coordinate system, and the instance places them at the same origin in the assembly. This means the exported assembly reflects the parts' positions as they were in the original model — which is correct when you are extracting a subset of an assembly that was already spatially positioned.

If the original model had instance transformations — *Instance blocks with translation and rotation data — those transformations are not propagated to the export. This is a known limitation. The export preserves geometry and material data but not global positioning. For sub-assembly extractions used for independent analysis, this is usually acceptable: the analyst defines new boundary conditions and loads relative to the sub-assembly anyway.

Interface Node Sets Inside the Assembly

When the include interface node sets option is checked in the export dialog, the assembly block also contains node set definitions for each part's interface nodes.

Interface nodes — those shared between two or more parts, identified during the find_interface_nodes pass described in Part One — represent the physical connection boundaries between parts. Knowing which nodes sit at those boundaries is essential for applying boundary conditions in a sub-assembly analysis: you typically fix the interface nodes to represent the constraint imposed by the rest of the assembly.

The node set is named using the export name followed by IFACENODES. It references the specific instance using the instance name. The node IDs are written in rows of sixteen per line — a formatting convention that keeps lines readable and matches Abaqus CAE output style.

The interface node set does not prescribe any specific boundary condition. It is simply a named collection of nodes that the analyst can reference when defining constraints in the analysis step. The responsibility for choosing the right boundary condition — fully fixed, pinned, spring-supported — belongs to the analyst. The tool provides the set; you decide what to do with it.

Section 5 — Material Definitions: Reconstructing Property Blocks

After the assembly block closes, the material definitions are written. This sequence — parts first, assembly second, materials third — is the correct CAE-format ordering, and it differs from some legacy INP formats where materials appear before the assembly.

The exporter collects the set of unique material names used by all exported parts. It then retrieves the property data for each material from the mat_props dictionary — the same dictionary built during the second parse pass.

For each material, it writes: *Material, NAME=material name. Then for each property record in that material's list: the property keyword with its parameters, followed by each data row as a comma-joined line of values.

The property keywords are written exactly as they were parsed — ELASTIC, DENSITY, PLASTIC, EXPANSION, and so on. If the original keyword had parameters — for example, MODULI=LONG TERM on a viscoelastic definition — those parameters are written back. This round-trip fidelity is important: the exported material should behave identically to the original in a solver run.

Data rows are written as comma-separated floating-point values. The values come directly from the parsed data lists — the same floating-point numbers that the Property Viewer tab displays. No rounding, no reformatting. What was in the original file is what goes into the exported file.

One practical consequence of this fidelity: if the original file had numeric precision that was truncated by the file's author — say, a density written as 7.8e-9 rather than 7.85e-9 — that truncation is preserved in the export. The program does not restore precision that was not in the source file. It cannot. The parser only has access to what was written.

Section 6 — The Analysis Step: Placeholders and Presets

Every valid Abaqus INP file that an analyst will actually run needs an analysis step. A sub-assembly export from a larger model has no analysis step by default — the original model's steps reference the full assembly with its original boundary conditions and loads, none of which transfer to the sub-assembly.

The export dialog handles this with two paths.

The first path — the default — writes a minimal placeholder. Three comment lines explain that no step was defined and invite the analyst to add their own Step definition. A lone End Step closes the block. This produces a syntactically valid file that will not run without modification, but will import into Abaqus CAE without errors.

The second path — activated by checking the modal step template checkbox — writes a complete Frequency extraction step. This is a one-click way to set up a sub-assembly for natural frequency analysis.

The Modal Step Template

The modal step is written as: Step, NAME=Frequency, PERTURBATION. The perturbation flag marks this as a linear perturbation step, which is required for eigenvalue extraction. Then Frequency, EIGENSOLVER=Lanczos, ACOUSTIC COUPLING=on, NORMALIZATION=displacement.

Lanczos is the standard eigensolver for large models — it is iterative and memory-efficient. The displacement normalization option normalizes mode shapes so that the maximum displacement component equals one. This is the most common normalization convention in structural dynamics work.

The number of modes to extract is taken from the modal modes entry in the dialog — defaulting to twenty but adjustable. A mode count suggestion is also displayed in the dialog based on the element count of the selected parts. The rule of thumb encoded is: below 20,000 elements, extract 40 modes; below 100,000, extract 30; below 300,000, extract 20; above that, 15. This is not a physical rule — it is an engineering heuristic based on practical experience with what mode counts tend to be sufficient for sub-assembly validation.

The output requests in the modal step template are minimal: Output, FIELD; Node Output requesting displacement U; *Element Output requesting stress S and strain E. These are the fields you need to visualize mode shapes in a post-processor. History output is left empty — in a modal analysis you rarely need history data.

Section 7 — Submodel Options: Cut Sets and Surfaces

The export dialog includes a submodel preset that activates a set of additional outputs useful when the exported sub-assembly will be used as a submodel — a focused high-fidelity analysis driven by results from the global model.

Submodeling in Abaqus is a two-stage process. In stage one, a global model runs — typically a coarser mesh of the full assembly. The solver saves displacement results at the boundaries of the submodel region. In stage two, the submodel runs with its boundaries driven by those interpolated displacement results from stage one. This lets you get high-fidelity results in a critical region without running the entire assembly at high mesh density.

For this workflow to work, the submodel needs specific infrastructure: node sets that identify which nodes sit at the driven boundary — the cut — and, optionally, element-based surfaces that define the cut geometry for contact or pressure applications.

Cut Node Sets

When the write cut sets option is active, the exporter adds node set definitions for each part's interface nodes under the name SUBMODEL_CUT_NODES_export-name. These are the nodes at the boundary between the extracted sub-assembly and the rest of the original model — exactly the nodes that will receive the driven boundary conditions from the global analysis.

A global combined cut set named SUBMODEL_CUT_NODES collects all interface nodes across all exported parts. This is what you reference in the submodel driving keyword in Abaqus — it tells the solver which nodes to interpolate displacements from the global ODB file onto.

Surface Definitions

The write surfaces option adds comment-block placeholders for element-based surface definitions — EXT surfaces covering the exterior faces of each part, and CUT surfaces covering the cut faces at the boundary.

Element-based surface definitions in Abaqus require specifying which face of which element set is part of the surface — for example, the S1 face of ELSET-NAME. This information cannot be derived from node sets alone; it requires knowing which element faces are on the boundary, which is exactly what the face counting algorithm from Part Two produces.

In the current implementation, the surface definitions are written as annotated comment placeholders rather than active definitions. This is an acknowledged limitation: generating fully specified element-based surfaces from the face extraction data is on the roadmap, but the comment placeholders document the intent and provide the analyst with the structure to complete manually.

Section 8 — Export Naming: ELSET, Part Name, and Generic Modes

The export dialog offers three naming modes for the exported parts: ELSET-based, part-name-based, and generic sequential numbering. Understanding why all three exist requires understanding the naming landscape of real Abaqus models.

In a structured model — one with explicit *Part blocks — part names are clear: the program read them from the file. Housing is Housing. PCB is PCB. These names carry semantic meaning.

In an orphan mesh — where parts were reverse-engineered by material-section grouping — the program assigned generic names: Part-1, Part-2, Part-3. These names are placeholders. They describe position in a list, not physical identity.

In a vendor-supplied model — an orphan mesh from a third-party tool — the element set names embedded in the file may be the most stable and meaningful identifiers available. An element set named PCB_SOLID or HOUSING_SHELL tells you more than Part-3.

ELSET Mode — The Stable Default

ELSET mode is the default because it uses the most stable available name. The suggest_name function for ELSET mode looks at the part data dictionary and retrieves the first entry in the elsets list — the element sets associated with this part. If there is an ELSET name available, it becomes the export name.

Stability matters for workflow reasons. If you export a sub-assembly today, review it, and export it again next week from the same source file, you want the exported part names to be the same. Names derived from ELSET definitions in the file are stable across exports as long as the source file has not changed. Names derived from the analysis-identified part order — Part-1, Part-2 — could shift if the ordering changes between versions.

Part Name Mode

Part name mode uses the internal part name as identified by the program — either the name from the *Part block in a structured model, or the reverse-engineered name from orphan mesh analysis. This is the name you see in the Parts tab list.

Generic Mode

Generic mode produces Part_001, Part_002, and so on — zero-padded sequential numbers. This is useful when you are producing a clean export for a recipient who does not need or want model-derived names. Consistent formatting across parts of different origins.

Uniqueness Enforcement and Custom Overrides

Whatever naming mode is chosen, the program enforces uniqueness. If two parts would receive the same suggested name — which can happen when multiple orphan mesh parts share an element set name, for example — the duplicate names are de-duplicated by appending an underscore and a counter. Part-1, Part-1 becomes Part-1, Part-1_2.

The custom checkbox per row allows you to override the suggestion for any individual part. Checking it marks that row as custom, and a dialog prompts for a replacement name at export time. Rows not marked custom keep their suggested name. Refreshing the suggestion mode — switching from ELSET to PartName, for example — updates only the non-custom rows, preserving any names you have explicitly set.

Section 9 — Writing the File: Lines, Joins, and the Output Path

The entire INP export is built as a Python list of strings — one string per line of the output file. The header lines, the node lines, the element lines, the keyword lines, the material data lines — all appended to the same list in the order they must appear in the file.

When the list is complete, the file is written in a single operation: the list is joined with newline characters and written to disk, followed by a final newline. This two-step approach — build list, then write — is preferred over writing line by line because it keeps the file operation as a single atomic action. Either the whole file is written correctly, or the write fails and nothing is on disk yet.

Python's file join pattern — '\n'.join(lines) — produces one newline between every pair of adjacent lines. The trailing write of a newline after the join adds the final newline that terminates the last line of the file. Text files that do not end in a newline are technically malformed on Unix systems, and some parsers — including Abaqus on Linux — can behave unexpectedly at the last line if it is not newline-terminated.

The output file path comes from the file save dialog — a standard operating system file chooser. The default extension is .inp and the default filename is a descriptive string built from the number of parts being exported. The user can navigate anywhere on disk and name the file anything they want. The program does not impose any path restrictions.

The file is opened with the write mode flag and encoding=UTF-8 — the same encoding convention applied throughout all output operations, as discussed in Section 2. There are no intermediate temp files, no staging area, no rename-on-completion. The target file is written directly. If the write fails partway through — disk full, permissions error, path not found — the exception bubbles up, is caught by the outer try-except block in the export function, and an error dialog is shown. No partial file is silently left on disk.

Section 10 — Single-Part Export versus Multi-Part Export

The export system has two entry points: single-part and multi-part. They share the same underlying writer logic but differ in how they are invoked and what dialog they present.

Single-Part Export

Single-part export is triggered from the Parts tab when exactly one part is selected and you click the INP export button. The program identifies the part name using the part index keys list — a parallel list maintained alongside the Parts tab listbox that stores the actual part names without the display formatting.

This parallel index list is an important implementation detail. The Parts tab listbox displays formatted strings: part name, element count, material, volume, mass. Parsing the part name back out of that formatted string would be fragile — any change to the display format would break the parser. The parallel index list avoids this entirely: the display string and the actual name are stored separately, and selection uses the index to look up the name from the clean list rather than from the display text.

Multi-Part Export

Multi-part export is triggered when multiple parts are selected — using control-click or shift-click in the Parts tab listbox — and you click the export button. All selected indices are converted to part names via the same index lookup, and the list of names is passed to the multi-part export dialog.

The multi-part dialog adds the naming controls, the submodel options, and the modal step template controls described in the previous sections. It also shows summary statistics at the top: total parts, total element count, and total mass. For large exports — assemblies with dozens of parts — this summary tells you immediately whether the selection is what you intended.

The underlying writer function — export_multiple_parts — is the same regardless of whether one part or one hundred parts are being exported. A single-part export simply calls it with a one-element list. This is deliberate: keeping one code path for all INP exports means one set of tests, one set of bugs, and one place to make improvements.

Section 11 — CSV Exports: Material Mapping and Part Properties

The CSV export system produces two types of spreadsheet output: material-section mapping files and part property files. Both are formatted for consumption in Excel, Python, or any tabular data tool.

Material Section CSV

The Export Material CSV button in the Materials tab writes the mapping for a selected material. The columns are: Material, Section Type, Section Raw, ELSET, and Parts. The Section Raw column contains the original keyword line exactly as it appeared in the INP file — the complete text including keyword and all parameters. This preserves full fidelity for downstream tools that need to reconstruct section definitions.

The Parts column is a semicolon-joined list of all part names associated with each section entry. This is because a single section can be associated with multiple parts — when an element set spans multiple part contexts — and a single CSV cell is the most compact representation.

Part Properties CSV

The Export Parts CSV button writes part-level data for all parts using the selected material. The columns are: Material, Part, Elements, Volume (mm³), Mass (kg), and Density. The volume and mass values come from the part properties dictionary populated by the Gaussian quadrature calculation during processing.

The values are formatted with deliberate precision: volume to four decimal places, mass to six decimal places, density in scientific notation with two significant figures. These precision choices reflect the expected useful range: volume differences below the fourth decimal place are below the noise of mesh discretization, mass differences below the sixth decimal place are below the practical accuracy of density data, and density spans many orders of magnitude so scientific notation is the clearest representation.

Both CSV writers open their output files with newline='' — a Python csv module requirement. Without this argument, the csv.writer module adds an extra carriage return on Windows, producing files with blank rows between every data row when opened in Excel. This is a common Python CSV pitfall that the program handles correctly.

Section 12 — The DOT Graph Export: Relationships as a Network

The DOT graph export produces a file in the DOT language format — the input format for Graphviz, an open-source graph rendering toolkit. The output is a directed graph showing the relationships between materials, sections, and parts.

DOT is a text-based format. The file opens with the keyword digraph G followed by an opening brace. Inside, each node in the graph is declared with a label. Each directed edge is declared with an arrow operator.

For a material named Steel-304 with two section definitions, each referencing different parts, the graph looks like this. A node for Steel-304 labeled as a material. A node for each section definition — sec0, sec1 — with the section raw text as the label. An edge from Steel-304 to sec0, another from Steel-304 to sec1. Then edges from each section node to each part it references.

The result, when rendered by Graphviz, is a visual diagram showing the material at the top, sections branching from it, and parts at the leaves. This makes the material DNA of the model visible as a graph structure — you can immediately see whether a material is used in one place or twenty, whether sections share parts, and whether any parts appear in multiple material branches.

DOT files can be rendered by the Graphviz command-line tool with the command: dot -Tpng filename.dot -o filename.png. They can also be opened by online Graphviz renderers, by the Gephi network visualization tool, and by VS Code extensions. The format is widely supported.

The DOT export is a small function — under thirty lines of code — but it illustrates an important design principle: the material-section-part mapping that was built for internal analysis purposes can be repurposed as a network representation without any change to the underlying data. The data structure was rich enough to support multiple output representations. Building data structures that support multiple views of the same information is a hallmark of well-designed engineering software.

Section 13 — The STEP Export Path

The program includes a STEP export capability — producing ISO 10303 STEP files, the standard CAD exchange format that allows mesh geometry to be imported into SolidWorks, CATIA, NX, and other CAD tools as solid bodies rather than triangulated surfaces.

STEP export is architecturally different from STL export. An STL file is just triangles — it makes no attempt to represent the geometric topology of the original solid. A STEP file represents B-Rep geometry: Boundary Representation, the native data structure of CAD solids. B-Rep stores the faces, edges, vertices, and their topological relationships as analytical surfaces — planes, cylinders, spheres — not as triangle approximations.

Converting a finite element mesh into B-Rep geometry is a hard problem. The mesh is discrete. B-Rep is continuous. The conversion requires fitting analytical surface patches to the triangulated exterior surfaces, detecting sharp edges and blending curvature, and building the topological relationships between faces.

The program delegates this to an external module: step_exporter.py, which in turn uses PythonOCC — the Python binding for OpenCASCADE, an open-source CAD kernel. OpenCASCADE is the same geometric engine used by FreeCAD, Salome, and several other open-source CAD tools. It includes facilities for constructing and exporting B-Rep solids.

The STEP exporter module is optional — if PythonOCC is not installed, the STEP export button in the interface is disabled and a message explains the dependency. This is consistent with the design philosophy of the whole program: zero required dependencies for the core features, optional dependencies for advanced capabilities that the user can install when needed.

The STEP export dialog shows a brief explanation of what the operation does and what to expect. It notes that the conversion is from mesh to CAD surfaces — which is an approximation — and that the quality of the resulting solid depends on the mesh density and regularity. A coarse mesh produces a faceted STEP body. A fine mesh with curved elements produces a smoother approximation.

For engineers who need to pass geometry back to a CAD system for drawing creation, tolerance analysis, or tooling design, even a faceted STEP body is more useful than a triangulated STL. The STEP format preserves the concept of faces and edges that CAD tools can reason about, while STL is opaque to topology.

Section 14 — The Summary Report: Text as Output

There is one more output type worth covering before we close: the model summary report — the text that populates the Summary tab after processing.

The summary is generated by the summarize function — or its unit-aware version, summarize_with_units, when a unit system has been confirmed. Both functions take the info dictionary — the high-level model census collected during the first parse pass — and build a formatted text report.

The report is built as a list of strings, exactly like the INP export, and then joined into a single text block. This text block is inserted into the Summary tab's scrolled text widget. The same text can be copied to the clipboard with a single right-click.

The report sections mirror the info dictionary structure: files and include chain, simulation type, mesh statistics with element type breakdown, materials and sections, assembly instances and transformations, element and node sets, surface definitions, analysis steps with time periods and incrementation, initial conditions, predefined fields, gravity and distributed loads, amplitude definitions, contact pairs and general contact status, mass scaling settings, bulk viscosity parameters, field and history output requests, and hourglass control settings.

When a unit system is confirmed, the unit-aware version adds dimension labels to the numerical values. Mesh dimensions in millimeters or inches depending on the unit system. Time periods in seconds or milliseconds. Material property values with their appropriate units. The same numbers, but now with the context that tells you what they mean physically.

The summary is not exported to a file automatically. It is a display artifact — it exists in the interface for reference. If you want to save it, you copy and paste it. This is an intentional design decision: the summary is a review tool, not a deliverable. Deliverables are the INP exports, the CSVs, the STLs, the STEP files. The summary is for the analyst's eyes during the review session.

Section 15 — The Complete Output Pipeline, End to End

Final numbered summary.

1.  User selects one or more parts in the Parts tab and clicks an export button — INP, STL, STEP, or the CSV and DOT buttons from the Materials tab.

2.  The part index keys list translates the listbox selection indices to actual part names without parsing display strings.

3.  For INP: the multi-part export dialog presents naming controls, submodel options, and modal step template. The name mode dropdown generates suggestions from ELSET, part name, or generic numbering. Custom overrides prompt individually. Uniqueness is enforced by de-duplication.

4.  The INP writer builds a line list. Heading block with metadata and Preprint suppression. For each part: Part, Node block sorted by ID, Element blocks grouped and sorted by type, section definition with shell detection, *End Part. Assembly block with instances and interface node sets. Material definitions from the mat_props dictionary. Analysis step — placeholder or modal template. Submodel cut sets and surface stubs if requested.

5.  The line list is joined with newlines and written to disk in a single operation with UTF-8 encoding.

6.  For STL: face extraction runs on the part elements, connectivity validation filters malformed elements, exterior faces are identified, triangles are generated with optional quadratic subdivision, the triangle list is written in binary or ASCII format.

7.  For STEP: PythonOCC is called with the triangle list to construct a B-Rep solid and export the STEP file.

8.  For CSV: material-section or part-property data is formatted with deliberate precision choices and written with correct newline handling for cross-platform compatibility.

9.  For DOT: the material-section-part mapping is traversed to build a directed graph and written in DOT format for Graphviz rendering.

10. Every output file is opened with encoding=UTF-8 to prevent Windows charmap encoding errors on models with non-ASCII characters in names.

That is the complete output pipeline. From selection in the interface to file on disk, with every structural decision traceable to a requirement.

Closing — The Act of Writing

Reading a file is an act of discovery. Writing a file is an act of commitment.

When you export an INP sub-assembly from this tool, you are committing to a specific structural description of a specific collection of parts, with specific material properties, with specific interface nodes identified. That file is now an artifact. It can be versioned, shared, run, and the results can be compared to results from the full model. The sub-assembly analysis is either consistent with the global model or it is not, and the comparison tells you something real.

Every design decision in the export system — the correct block ordering, the UTF-8 encoding, the sorted node and element output, the non-destructive in-memory approach, the ELSET-based stable naming, the interface node sets for boundary conditions — serves this commitment. The exported file should be correct, reproducible, and complete enough for the analyst to run an independent analysis without additional manual editing.

Part Five of this series will cover the Learning Center — the built-in educational reference system, the topic library covering unit systems, element types, common failure modes, and simulation pitfalls, and how the program uses the same parsed model data to contextualize that reference material to what is actually in the model you are working with.

Source code, documentation, and all companion readers are at McFaddenCAE.com.

End of Part 4 — INP Export, Sub-Assembly Extraction, and the Full Output Pipeline

Next: Part 5 — The Learning Center, the Topic Library, and Model-Contextualized Reference

© 2026 Joseph P. McFadden Sr. All rights reserved.  |  McFaddenCAE.com

Part 5

ABAQUS INP COMPREHENSIVE ANALYZER

Under the Hood  —  A Deep-Dive Series

PART 5

The Learning Center

Topics, Analysis Types, and the Example INP Generator

Joseph P. McFadden Sr.

McFaddenCAE.com  |  The Holistic Analyst

© 2026 Joseph P. McFadden Sr. All rights reserved.

Setup — Why a Tool Has a Learning Center

The first four parts of this series have described a tool for analyzing Abaqus input files. Every capability covered — parsing, geometry extraction, material analysis, export — serves an engineer who already has a model and wants to understand or improve it.

The Learning Center is different. It is for the engineer who is still building their understanding of what the model should be doing in the first place.

This distinction matters. A tool that only analyzes existing models assumes that the analyst already knows what a good model looks like. In practice — especially in organizations where simulation has grown faster than training — that assumption does not always hold. People inherit models, copy templates, follow procedures, and run analyses without fully understanding what each keyword does, why it is there, or what happens if it is wrong.

The Learning Center is the explicit acknowledgment that the tool has a responsibility beyond analysis. It should also teach. It should explain the underlying engineering so that the analyst builds the critical thinking framework to evaluate their own work, not just execute a procedure.

It is also the bridge between this tool and the McFaddenCAE.com audiobook series — four volumes of FEA best practices content covering unit systems, element selection, contact, mass scaling, energy balance, modal analysis, and more. The Learning Center inside the tool is the companion reference that points back to that deeper material.

Section 1 — Architecture: Topics, Categories, and Difficulty Levels

The Learning Center tab is built with a two-panel layout that mirrors the other analytical tabs. On the left, a topic list with filter controls. On the right, a content display area with a Generate Example INP button that activates for specific topics.

The topic list is populated from two sources. The first is a set of built-in analysis type topics — five analysis workflows defined directly in the main program. The second is the best practices module, imported at startup, which contributes a library of engineering best practice topics built from the same module architecture described in Part Three.

If the best practices module is not available — for example, on a minimal installation where only the core analyzer file is present — the topic list falls back gracefully to just the five analysis type topics. No error, no crash. The content that is available is shown; the content that requires the external module is silently absent.

Categories

Topics are organized into two categories: Analysis Types and Best Practices. The category dropdown at the top of the left panel filters the list to show only one category or all of them.

Analysis Types covers specific simulation workflows — modal analysis, shock analysis, Shock Response Spectrum (SRS), random vibration, and harmonic response. These are the dynamic analysis types most commonly encountered in consumer electronics and defense product qualification. Each has full educational content and an active Generate Example INP button.

Best Practices covers engineering judgment topics — element selection, unit systems, contact definition, mass scaling, energy balance monitoring, mesh convergence, hourglass control, bulk viscosity, output requests, post-processing, jerk and fragility assessment, and the thin brittle materials topic added in recent versions.

Difficulty Levels

Each topic carries a difficulty rating: Beginner, Intermediate, or Advanced. A row of radio buttons — All, Beginner, Intermediate, Advanced — filters the list by level. Green circle icons mark beginner topics, yellow mark intermediate, red mark advanced.

The difficulty ratings are honest. Modal analysis is labeled Beginner not because it is simple to do well, but because the conceptual entry point — what is a natural frequency, how do you extract one — is accessible without extensive background. Shock Response Spectrum is labeled Advanced because it requires understanding of modal superposition, damping, and the convolution mathematics behind the spectrum concept before the analysis result means anything.

This level tagging serves a navigation purpose. A new hire encountering FEA for the first time should start with Beginner topics. An experienced analyst looking to fill a specific gap can jump directly to Advanced without sifting through foundational material they already know.

Section 2 — Modal Analysis: Natural Frequencies and What They Mean

The modal analysis topic is the recommended starting point for anyone who has not worked with dynamic analysis before. It covers one of the most fundamental concepts in structural mechanics: the natural frequency.

The opening metaphor in the topic content is the guitar string. A string under tension has a set of frequencies at which it naturally vibrates — the fundamental tone and its harmonics. A structural component has the same property: it has frequencies it prefers, and if it is excited at those frequencies, it responds with amplified motion.

This is resonance. And avoiding resonance — or designing for it — is the primary reason you run modal analysis.

The governing equation of modal analysis is: the stiffness matrix times the mode shape vector equals ω² times the mass matrix times the mode shape vector. ω is the natural circular frequency in radians per second. Frequency in hertz is ω divided by 2π. The mode shape vector, called the eigenvector, describes the relative displacement pattern of every node in the structure at that frequency.

This is an eigenvalue problem — the same class of mathematical problem that appears in quantum mechanics, principal component analysis, and image compression. The word eigen is German for characteristic. Natural frequencies are the characteristic frequencies of the structure's stiffness and mass distribution.

The Perturbation Restriction — Non-Negotiable

The topic content includes a section labeled CRITICAL: PERTURBATION LIMITATION, and it deserves the emphasis. Modal analysis is a linear perturbation procedure in Abaqus. This means two things that are absolute.

First, contact elements cannot be used. Full stop. A contact pair introduces nonlinearity — the stiffness depends on whether surfaces are touching or separating. Linear perturbation procedures assume the stiffness is constant. Abaqus will either error out or produce meaningless results if contact is present in a perturbation step. Bolted joints, press fits, gaskets, and any interface that uses contact pairs must be replaced with tied constraints or merged nodes before running modal analysis.

Second, material nonlinearity and large deformations are not captured. Modal analysis computes the linearized dynamic response around the current state. If your structure is pre-stressed — compressed by a bolt load, for example — you would need a preload step followed by the perturbation step to capture the stress-stiffening effect correctly.

The same perturbation restriction applies to every frequency-domain analysis in the Learning Center: harmonic response, random vibration, and Shock Response Spectrum all share this limitation. The topic content states this explicitly for each analysis type, not just for modal, because the mistake of leaving contact elements in a perturbation model is common enough that it deserves repetition.

Mode Shapes Are Relative, Not Absolute

Mode shapes show relative displacement patterns, not absolute physical displacements. A mode shape tells you which nodes move and in what pattern relative to each other. It does not tell you how far they actually move during a real event.

To get actual displacements, stresses, and strains from modal data, you must run a response procedure — harmonic analysis for sinusoidal excitation, random vibration for broadband stochastic excitation, or Shock Response Spectrum for shock environments. Modal analysis alone cannot give you those results, no matter how many modes you extract or how accurate your model is.

This is one of the most persistent misunderstandings in the use of modal analysis, and the Learning Center content addresses it directly rather than assuming the analyst will discover it through painful experience.

Section 3 — Shock Analysis: Time Domain, Pulse Shapes, and MIL-STD

Shock analysis — labeled Transient Dynamic in Abaqus — simulates the time-domain structural response to a sudden impact or rapid acceleration event. Unlike modal analysis, which finds the structure's inherent character, shock analysis asks how the structure responds to a specific input.

The input is defined as a base acceleration time history — the ground motion applied to the support points of the structure. The structure is typically fixed at its mounting interface, and the analysis drives that interface with the prescribed acceleration pulse. The solver integrates the equations of motion forward in time, capturing how the structure deforms, where stresses develop, and how energy distributes through the assembly.

Pulse Shapes and Their Physical Meaning

The topic content covers three standard shock pulse shapes with their physical contexts, because the choice of pulse shape is not arbitrary — it reflects the nature of the physical event being simulated.

The half-sine pulse has the form: acceleration = peak × sin(πt/T), where t is time and T is the pulse duration. The acceleration starts at zero, rises smoothly to the peak, and returns smoothly to zero. This shape closely approximates what happens when a product drops onto a relatively compliant surface — a rubber pad, a carpeted floor. The smooth onset and offset produce a pulse with moderate high-frequency content. The classic benchmark is 100 G at 11 milliseconds, which is the standard for much consumer electronics drop qualification.

The terminal peak sawtooth pulse ramps linearly from zero to peak, then drops abruptly to zero at the end of the pulse. The abrupt termination introduces high-frequency content in the spectrum — more energy at higher frequencies than the half-sine of the same peak and duration. This shape is representative of pyroshock events: the firing of explosive bolts, stage separation in a launch vehicle, or any event with a sharp termination. More severe than the half-sine at the same nominal parameters.

The square wave pulse holds constant acceleration for the full duration, then drops instantly to zero. It is the most conservative of the three shapes — for a given peak G and duration, the square wave delivers the maximum velocity change, which is the time integral of acceleration. Used for worst-case analysis when the actual pulse shape is uncertain or when the specification demands the most demanding achievable input.

Velocity Change — The Physical Quantity

The topic content introduces velocity change — ΔV — as the physical quantity that characterizes shock severity more completely than peak G alone. Two shocks with the same peak G but different durations deliver different velocity changes and produce different structural responses.

Velocity change is the area under the acceleration-time curve — the integral of acceleration. A 100-G half-sine at 2 milliseconds delivers a smaller velocity change than a 100-G half-sine at 11 milliseconds, even though both have the same peak. The 11-millisecond pulse has five and a half times more area. This means it excites lower-frequency modes more strongly and produces larger structural deformations in flexible assemblies.

Understanding velocity change as the governing severity parameter — not just peak G — is the conceptual shift that separates engineers who can reason about shock environments from those who can only follow a specification number.

Section 4 — Shock Response Spectrum: From Time History to Frequency Summary

The Shock Response Spectrum topic is labeled Advanced for good reason. Understanding it requires synthesizing several concepts: natural frequencies from modal analysis, transient response from shock analysis, and the idea of a single-degree-of-freedom oscillator as a measuring instrument.

Here is the concept. Imagine a simple spring-mass system — one mass, one spring, and some damping — attached to a moving base. Subject the base to a shock pulse. The mass responds. Measure the maximum absolute acceleration experienced by the mass. Now change the spring stiffness so the system's natural frequency is different. Subject the base to the same pulse. Measure the new maximum acceleration. Repeat for many different natural frequencies.

Plot those maximum accelerations as a function of natural frequency. That plot is the Shock Response Spectrum (SRS) of the input pulse. It tells you: for a structure with a given natural frequency, what is the worst acceleration it will experience when subjected to this shock?

The SRS is not a measurement of the shock pulse itself — it is a summary of the shock pulse's effect on structures with different natural frequencies. Two shock pulses with very different time histories can produce very similar SRS curves if they are equally damaging to structures across the frequency range of interest. Conversely, two pulses that look similar in time can be dramatically different in the SRS domain if one has more high-frequency content.

In Abaqus, SRS analysis is a two-step procedure. Step one is modal analysis: extract the natural frequencies and mode shapes of the structure. Step two is the response spectrum step, which applies the spectrum loading and uses the modal superposition principle to compute peak responses. The response to each mode is computed from the spectrum value at that mode's frequency, then the modal responses are combined using a combination rule — typically SRSS (Square Root of the Sum of Squares) or CQC (Complete Quadratic Combination).

Because step two is a perturbation procedure — it uses linear superposition of modal responses — the contact restriction applies here too. All the warnings from the modal analysis topic carry over.

The topic content flags a specific practical issue for consumer electronics applications: the SRS is the standard method for qualifying equipment under MIL-STD-810 Method 516 shock and for analyzing pyroshock environments in aerospace. If you are working on hardware that needs to survive these environments, understanding the SRS is not optional.

Section 5 — Random Vibration: Statistical Energy in a Frequency Band

Random vibration analysis addresses a different class of loading than shock. Shock is a deterministic event — it has a specific time history, even if you have to approximate it. Random vibration is inherently statistical: the loading is described by its power spectral density (PSD), which gives the average energy content per unit frequency as a function of frequency, rather than as a time trace.

The physical scenarios that produce random vibration are environments where the driving source is stochastic: road surface roughness driving vehicle vibration, jet engine noise driving aircraft structure, rocket motor combustion driving launch vehicle structure, fans and pumps driving equipment enclosures. None of these have a fixed repeating waveform. They have statistical properties — a characteristic PSD — that remains roughly constant over time.

The Power Spectral Density is expressed in units of G²/Hz. The area under the PSD curve over a frequency band gives the mean square acceleration — the statistical average of the squared acceleration — in that band. The square root of the total area is the root mean square (RMS) acceleration, which is the single most commonly reported metric for random vibration severity.

In Abaqus, random vibration analysis is a linear perturbation procedure that uses the modal superposition framework. The structure's natural frequencies and mode shapes, extracted in the modal step, are combined with the input PSD through a mathematical operation called the frequency response function. The output is the PSD of the structural response — stresses, displacements, accelerations at every location in the model — as a function of frequency.

The results are statistical. A peak stress output from random vibration analysis is not the actual stress at a given instant — it is a one-sigma value, meaning it is exceeded with a probability determined by the statistical distribution of the response. For fatigue life prediction, you typically work with three-sigma values — three times the RMS stress — as the effective peak stress, based on the assumption of Gaussian response statistics.

This statistical nature is one of the reasons random vibration analysis is labeled Advanced. The numbers require interpretation through a probabilistic framework, not just a direct comparison to a yield strength. An analyst who reads a peak stress output from random vibration as if it were a deterministic result will draw incorrect conclusions.

Section 6 — Harmonic Response: Steady-State Under Sinusoidal Excitation

Harmonic response analysis — called Steady-State Dynamics in Abaqus — computes the structural response to a continuous sinusoidal excitation as a function of excitation frequency. The result is a frequency response function: amplitude and phase of the structural response at every frequency in the sweep range.

The physical scenario is a structure being driven by a sinusoidal source at a constant amplitude as that source's frequency is swept through a range. A motor with an imbalance. A fan blade at a harmonic of the rotation frequency. An acoustic cavity resonating a panel. These are the environments where harmonic response analysis is appropriate.

The analysis identifies resonance peaks — frequencies where the response amplitude is amplified — and shows whether any of the structure's natural frequencies fall within the operating frequency range of the excitation. It also shows the phase relationship between input and response, which matters for active vibration control design.

Damping plays a critical role in harmonic response in a way that it does not in modal analysis. In modal analysis, damping slightly shifts natural frequencies and affects the rate of decay in transient response, but the undamped natural frequencies are the primary output. In harmonic response, damping determines the peak amplification at resonance. Without damping, resonance produces infinite amplitude — a mathematical singularity. With damping, the amplification at resonance is limited to 1/(2ζ), where ζ is the damping ratio.

Defining damping correctly — and knowing where your damping values came from — is therefore critical for harmonic response analysis in a way it is not for modal extraction. The topic content addresses this and cross-references the modal analysis audiobook, which covers damping estimation in depth including how to derive damping without test data.

Like all perturbation procedures, harmonic response cannot use contact elements. The same tied-constraint substitution required for modal analysis is required here.

Section 7 — Jerk and Fragility: Beyond Peak G

The jerk and fragility topic is labeled Best Practices and Advanced. It extends the shock analysis framework to include a quantity that standard analysis ignores: jerk, the time derivative of acceleration.

Acceleration describes force per unit mass at a given instant. Velocity change describes the impulse — the integrated effect over the pulse duration. Jerk describes how rapidly the acceleration is changing.

Jerk matters because components with finite stiffness at their mounting interfaces respond to rates of change in the acceleration environment, not just to peak values. A connector, a solder joint, a delicate MEMS sensor — these components see stress proportional not just to the peak G but to how quickly the G reaches its peak. A sharp-onset pulse with high jerk is more damaging to fragile components than a smooth pulse with the same peak G.

Fragility in the engineering context refers to the maximum G-level a component can withstand without functional failure — a threshold, not a strength in the structural sense. Fragility assessment is the process of determining whether the input shock environment exceeds the fragility threshold of the most sensitive component in the assembly.

The topic content covers the relationship between velocity change, jerk, and fragility in terms of product drop height analysis. Given the drop height, you can estimate the velocity change at impact. Given the impact surface compliance and the system's mass, you can estimate the pulse duration and shape. From those, you can estimate peak G and jerk. From those, you can assess whether the fragile components in the assembly will survive.

This is a systems-level analysis, not just a finite element analysis. The value of including it in the Learning Center is that it places the FEA work in a broader engineering context. The simulation result — a peak stress or a peak acceleration at a component location — only has meaning when interpreted against the fragility threshold of that component. A simulation that produces an acceleration value without the analyst knowing the fragility limit of the device being assessed is technically complete but practically useless.

Section 8 — Output Requests and Post-Processing: What to Ask For and Why

The output requests and post-processing topic covers a practical gap that is surprisingly common: analysts who know how to run a simulation but do not fully understand what they are requesting in their output definitions, or who request too much and fill their ODB files with data they cannot use, or too little and miss the results they actually needed.

Field output is written to the ODB file at specified time intervals or increments. It captures the state of the entire model — stresses, strains, displacements, velocities, accelerations at every node and every element integration point — at those moments. For a long explicit dynamic analysis, requesting field output too frequently produces enormous ODB files. Requesting it too infrequently misses the peak stress state.

The guidance in the topic is to identify the temporal window of interest — for a drop event, the first contact and peak response period — and concentrate field output requests there. If the drop event is a 20-millisecond simulation and the structural peak response occurs between 5 and 15 milliseconds, there is no reason to write field output for the first five or the last five milliseconds at the same frequency.

History output is written at every increment and captures time traces of quantities at specific locations — a node's displacement, a section's reaction force, an element's stress component. History output is essential for the energy balance monitoring described in Part Three. ALLKE, ALLIE, ALLSE, ALLPD, and ETOTAL over the full simulation time are the minimum energy outputs for quality assessment.

The topic content also covers which variables to request and why. S — the Cauchy stress tensor — is the primary structural result. E and PE — total strain and plastic strain — are needed to identify yielding. U is displacement. V and A are velocity and acceleration — needed for dynamic response assessment and for validating that the shock input was applied correctly.

Post-processing guidance covers what to look at first — energy balance, then deformation, then stress distribution — and how to interpret results that are physically unreasonable. Stresses that exceed the ultimate strength by a factor of ten do not mean the part failed ten times over; they mean the mesh is too coarse in that region, or the boundary condition is causing a stress singularity, or the result is from a single highly distorted element that should be interrogated separately.

Section 9 — The Example INP Generator: Making Concepts Executable

The Generate Example INP button activates for the five analysis type topics: modal, shock, SRS, random vibration, and harmonic response. This is the most distinctive feature of the Learning Center — the ability to produce a working, runnable Abaqus input file configured around the choices you make in a guided dialog.

The philosophy behind it is direct. Reading about modal analysis produces one level of understanding. Running a modal analysis on a known geometry and verifying that the results match the analytical solution produces a fundamentally different level of understanding. The example generator closes the gap between reading and doing.

The Options Dialog

Clicking Generate Example INP opens a configuration dialog specific to the selected analysis type. Each dialog has a title, a brief description of what will be generated, and a set of option groups — typically three to five choices, each with a dropdown selector and a description panel.

The description panel is key. It does not just name the option — it explains what it means, when you would choose it, and what to expect from it. When you select Steel as the material, the description tells you: Young's modulus 200 GPa, Poisson's ratio 0.3, density 7,800 kg/m³, stiff structure with well-separated modes, good baseline for learning. When you select Aluminum, the description tells you that the lower stiffness-to-mass ratio shifts frequencies lower and that this is common in consumer electronics and aerospace. When you select Titanium, it notes the high strength-to-weight ratio and aerospace and medical applications.

The description updates every time you change a selection. You are not just picking from a menu — you are reading engineering context for each choice as you make it. This is the teaching aspect of the generator: the act of configuring the example is itself an educational experience.

Modal Analysis Options

The modal analysis generator offers four configurable parameters. Material — Steel, Aluminum, or Titanium. Element type — C3D8R reduced-integration hex, C3D8 full-integration hex, or C3D10 quadratic tet. Boundary condition — cantilever with one end fixed, or free-free with no constraints. Number of modes — ten, twenty, or fifty.

The element type descriptions explain the engineering tradeoffs directly. C3D8R is labeled the industry workhorse: fast, accurate for well-shaped elements, requires hourglass control. C3D8 full integration is labeled susceptible to shear locking in bending — stiffer response than reduced integration, good for comparison studies. C3D10 tet is labeled for complex geometry where hex meshing is impractical.

The cantilever boundary condition description notes that this is the classic textbook case with well-known analytical solutions for validation — and that is exactly the point. The generated model is a 100-mm cantilever beam with a 10×10 mm cross section. The expected first bending frequency is approximately 35 Hz, the second approximately 220 Hz, the third approximately 620 Hz. These are the analytical solutions from Euler-Bernoulli beam theory. When you run the example in Abaqus and compare your FEA results to these expected values, you are performing model validation.

The free-free boundary condition description explains the rigid body mode phenomenon: no boundary conditions means the structure floats in space. The first six modes are rigid body modes at zero hertz — three translations and three rotations. The elastic modes begin at mode seven. This is not an error; it is the correct physical behavior of an unconstrained structure. Understanding why those six zero-frequency modes appear, and how to count past them to the first elastic mode, is foundational dynamic analysis knowledge.

Section 10 — Shock Analysis Generator: Pulses, Units, and Amplitude Cards

The shock analysis generator produces a transient dynamic model with base excitation. The choices are material, shock pulse shape, peak G level, and pulse duration. The description panels explain the physical and standard-compliance context for each option.

The peak G options — 50, 100, 500, and 1,000 G — each carry descriptions of the physical environments they represent. 50 G is described as moderate shock typical of bench-level handling drops onto compliant surfaces. 100 G is described as the standard qualification level for many consumer and military products, noting specifically that MIL-STD-810 Method 516 commonly specifies 100 G at 11 milliseconds half-sine. 500 G covers vehicle crash environments and high-drop-height qualification. 1,000 G covers extreme environments including near-field pyroshock.

These descriptions connect the abstract simulation parameter to its physical and regulatory context. An analyst who knows that their product must comply with MIL-STD-810 can select the appropriate pulse and peak G directly, understanding what they are simulating and why.

The Unit System in the Generated INP

All example INP files generated by the Learning Center use the millimeter-tonne-second unit system. This is deliberate and documented in the file header of every generated example: units = mm-tonne-s, frequency in Hz.

The acceleration of gravity in this system is 9,810 mm/s² — not 9.81 m/s². This is the same unit trap described in Part One of this series. The generated shock examples use the correct value: 1 G = 9,810 mm/s². 100 G = 981,000 mm/s². The code contains a lookup table for peak G values in this unit system so the generated amplitude curve uses the correct numbers.

Every generated file includes a comment block at the top documenting exactly which unit system was used and what that implies for result interpretation. This is the principle from the unit detection system applied to generated examples: make the unit system explicit, never leave it implicit.

The Amplitude Card

The shock pulse in the generated INP is defined using Abaqus's *Amplitude keyword. The amplitude card tabulates time-versus-value pairs that define the shape of the loading function. The G level is then applied as a body load or base acceleration referencing this amplitude curve.

For the half-sine pulse, the generator numerically samples the sine function at fine intervals across the pulse duration, producing a tabulated amplitude curve that closely approximates the continuous half-sine shape. For the terminal peak sawtooth, the function is sampled as a linear ramp. For the square wave, it is a step function.

The time discretization used for the amplitude card is deliberately finer than the analysis time step. A coarse amplitude curve would produce a pulse that the solver cannot integrate accurately, especially for the sharp terminations in the sawtooth and square wave. The generator uses at least twenty sample points across the pulse duration to ensure the pulse shape is faithfully represented to the solver.

Section 11 — The Cantilever Beam: A Concrete Teaching Model

The geometry used for all generated examples is a cantilever beam: 100 mm long, 10 mm wide, 10 mm deep. This specific geometry is not arbitrary — it was chosen because it has well-known analytical solutions for natural frequencies, stress under bending loads, and resonant deflection amplitudes.

The node layout is explicit in the code: forty-four nodes arranged in a 4×11 grid forming ten hexahedral elements along the beam length. The node coordinates are hardcoded as floating-point values at regular 10-mm intervals. The element connectivity table is hardcoded as ten elements, each referencing its eight corner nodes by ID.

This is deliberately simple. The mesh is coarse — ten elements along 100 mm is not a production mesh quality. But for a teaching model, coarseness is acceptable, and the analytical frequency solutions are the verification target regardless of mesh quality. The point is not to get the most accurate frequency — it is to run the analysis, see the result, and understand why it is close to the analytical prediction.

The C3D4 Substitution for Tet Selection

When the user selects C3D10 quadratic tet as the element type in the modal generator, the code performs a substitution and generates a C3D4 linear tet mesh instead, with a comment in the file explaining why.

C3D10 requires midside nodes — nodes placed at the midpoint of each edge of the tetrahedron. The node grid used for the cantilever example does not have midside nodes. Generating a proper C3D10 mesh would require a different node layout, one that was never built into the example generator.

Rather than silently generating an incorrect mesh or crashing, the generator substitutes C3D4 linear tets using a standard hex-to-tet decomposition algorithm: each hexahedral element is split into five tetrahedra using a fixed connectivity pattern. The file header documents this substitution. The comment in the file states clearly that C3D10 requires midside nodes and that C3D4 is used for this simple example, and instructs the analyst that in practice they should always use C3D10 for tetrahedral meshes.

This is transparent and honest. The generated file works, it runs, it teaches the boundary condition and step structure correctly — and it tells the analyst exactly what limitation was made and what to do in a real model.

Section 12 — Best Practices Topics from the Module

The best practices topics contributed by the best_practices module follow a different content format than the analysis type topics. They are structured reference entries rather than educational walkthroughs. Each topic covers a specific practice, why it matters, what the failure mode is when it is not followed, and what to do instead.

The topics include the unit system traps — with particular attention to the grams-millimeters-milliseconds versus tonnes-millimeters-seconds ambiguity described in Part One of this series. The thin brittle materials topic covers the specific challenges of glass and ceramic simulation: extremely low failure strain, sensitivity to stress concentrators, the inadequacy of reduced-integration elements in bending. The millisecond time unit topic — called The Time Trap in the Learning Center — is the detailed treatment of why millisecond-based unit systems are used for drop and impact simulation, what the density values look like in each system, and how to verify you are in the right system.

Hourglass control covers what hourglassing is — the zero-energy deformation modes that reduced-integration elements can exhibit — how to detect it in results, and what controls to apply. Bulk viscosity covers the shock wave damping parameters and the recommended values for different impact scenarios. Mass scaling covers the accuracy-versus-speed tradeoff and the tests you should run to verify that your mass scaling factor does not corrupt the dynamics.

Each best practices topic connects to the FEA Best Practices audiobook series published at McFaddenCAE.com. The cross-references at the end of each topic entry name the specific volume and chapter in the audiobook series that covers the topic in more depth. This is how the tool and the audiobook series function as companions: the tool surfaces the issue in the context of your specific model, and the audiobook series provides the extended treatment.

Section 13 — Filtering, Display, and the UI Architecture

The topic list filtering system uses two independent controls applied simultaneously. The category dropdown selects between All, Analysis Types, and Best Practices. The difficulty radio buttons select between All, Beginner, Intermediate, and Advanced.

Both filters apply to the same underlying topic list. When you change either control, the filter_lc_topics function re-iterates through the full topic list, applies both conditions in sequence, and repopulates the listbox with only the topics that pass both filters. The listbox is rebuilt from scratch on every filter change — no incremental update, no caching. For the topic counts involved — typically fifteen to thirty entries — this is fast enough that the rebuild is imperceptible.

The difficulty icons — green circle, yellow circle, red circle — are prepended to each topic title in the listbox. These are Unicode characters, not images. This is consistent with the program's general approach to icons throughout the interface: use Unicode characters where they provide visual clarity without requiring image assets.

When a topic is selected, the show_lc_topic function first determines which topics are currently visible after filtering, then maps the listbox selection index to the correct topic from that filtered list. The title label at the top of the right panel updates to show the selected topic's name. The Generate Example INP button is enabled or disabled based on whether the selected topic has an INP generator attached — the has_inp_generator flag in the topic dictionary.

The content area is a scrolled text widget. Topic content is inserted as a single text block. The widget is not read-only in the tkinter sense — it is displayed in normal state, which means the user can select and copy the text. This is intentional: if you want to copy the governing equation from the modal analysis topic, or copy the expected frequency values for manual verification, you should be able to do that without any export step.

Section 14 — The McFaddenCAE.com Connection

The Learning Center's welcome message identifies it explicitly as the companion resource to the FEA Best Practices audiobook series at McFaddenCAE.com. Understanding this relationship clarifies what the Learning Center is and is not trying to be.

The audiobook series — four volumes, covering topics from unit systems through modal analysis in depth — is the extended educational resource. It is narrated, searchable, and produced to a standard that allows someone to learn from it during a commute, at a gym, or any time they are not at a computer. The total running time is nearly one hundred minutes of core content, plus expanded discussions in companion reader documents.

The Learning Center inside the tool is the quick reference. You are looking at a model. You notice a keyword you do not recognize. You wonder what the correct unit system is for the density value you are seeing. You need to understand what hourglass control does before you act on the recommendation in the Recommendations tab. The Learning Center answers those questions in the context of your active session.

The cross-reference structure — topic content ending with a reference to the audiobook volume and chapter — is the bridge. The tool sends you to the audiobook for the deep treatment. The audiobook references the tool for practical application. Neither is complete without the other, and neither tries to be.

This is the multi-channel educational philosophy that runs through all of the work at McFaddenCAE.com. Different people learn through different media. Some need to hear something explained before they can read the technical detail. Some need the hands-on example before the explanation makes sense. The combination of audiobook, companion reader, and working tool with integrated reference material attempts to serve all of those learning styles from a single coherent body of content.

Section 15 — The Complete Learning Center Pipeline, End to End

Final numbered summary.

1.  The Learning Center tab is built at program startup. The topic list is populated from two sources: built-in analysis type topic dictionaries defined in the main program, and the best practices module if it is importable.

2.  Each topic is a dictionary with keys: ID, title, category, difficulty, has_inp_generator flag, and content string. Analysis type topics have the generator flag set to true. Best practices topics have it set to false.

3.  The filter_lc_topics function applies category and difficulty filters simultaneously, rebuilding the listbox from the full topic list on every change.

4.  Selecting a topic populates the content area with the topic's content string, updates the title label, and enables or disables the Generate Example INP button based on the has_inp_generator flag.

5.  Clicking Generate Example INP opens a configuration dialog for the selected analysis type. Each dialog presents option groups with dropdown selections and live-updating description panels that explain the engineering context of each choice.

6.  When the user confirms options and clicks Generate, the dialog calls the appropriate generator function — generate_modal_example, generate_shock_example, and so on — passing the options dictionary.

7.  The generator function builds the INP content as an f-string, substituting the selected material properties, element type, boundary condition block, amplitude curve, and step parameters into a template structure that follows the correct Abaqus CAE block order.

8.  The generated INP content is written to disk at the user-selected path with UTF-8 encoding. A success message confirms the save location.

9.  The analyst opens the generated file in Abaqus, runs the job, and compares results to the expected analytical values documented in the topic content.

That is the complete Learning Center pipeline — from a topic selection to a runnable simulation with known expected results, designed to close the loop between understanding a concept and executing it.

Closing — The Purpose of Worked Examples

In engineering education, there is a well-known gap between conceptual understanding and practical execution. A student can understand Newton's second law and still struggle to set up the free body diagram for a non-trivial problem. An analyst can understand that natural frequency depends on stiffness over mass and still not know how to set the boundary conditions, choose the eigensolver, or interpret why they are seeing six modes at zero hertz.

Worked examples bridge that gap by making the abstract concrete. When you configure a modal analysis example, select your material, choose your boundary condition, generate the file, run it, and see that the first bending frequency is 35 Hz rather than an unexpected value — you have just done something that no amount of reading could fully replicate. You have closed the loop. The concept and the execution are now the same thing in your experience.

The critical thinking application goes further. Once you have a working baseline — a model you trust because it matches a known answer — you have a tool for systematic exploration. What happens to the frequency if I change the material to aluminum? The theory says it should decrease. Does it? What happens if I change the boundary condition from cantilever to free-free? The first six modes should go to zero. Do they? What happens if I cut the mesh from ten elements to two? How much does the frequency change? That is a mesh convergence study, run in minutes on a model you built yourself.

This is the Holistic Analyst approach. Not trusting a number because it came from a simulation. Trusting a number because you understand the model, you have validated it against a known case, you have tested its sensitivity to key parameters, and the result is consistent with your engineering judgment at every step.

This series will continue. There is more to cover — the penetration check system, the part relationship analysis, the nearest parts search, and the full Learning Center topic library.

Source code, audiobooks, and all companion readers are at McFaddenCAE.com.

End of Part 5 — The Learning Center, Topics, and the Example INP Generator

Next: Part 6 — Part Relationships, Penetration Checks, and the Nearest-Parts Search

© 2026 Joseph P. McFadden Sr. All rights reserved.  |  McFaddenCAE.com

Part 6

ABAQUS INP COMPREHENSIVE ANALYZER

Under the Hood  —  A Deep-Dive Series

PART 6

Part Relationships, Penetration Checks,

and the Nearest-Parts Search

Spatial Intelligence — How Parts Relate in Space and Structure

Joseph P. McFadden Sr.

McFaddenCAE.com  |  The Holistic Analyst

© 2026 Joseph P. McFadden Sr. All rights reserved.

Setup — Why Assembly Relationships Matter

An assembly model is not a collection of independent parts sitting in the same file. It is a system — parts that touch, constrain, load, and influence each other. The structural behavior of any one component is inseparable from the constraints its neighbors impose on it.

The first five parts of this series described how the program reads the model, processes geometry, analyzes materials, exports sub-assemblies, and educates the analyst. All of that work treats parts as individual entities. Part Six is about the connections between them.

Three analysis tools in the Parts tab address those connections directly. The nearest-parts search tells you which parts are geometrically closest to the one you are looking at, and how far away they are. The interacting-parts search tells you which parts are explicitly connected by constraint definitions in the file. The penetration check tells you whether any parts are actually overlapping — occupying the same space — which would corrupt any simulation that runs on the model.

Together, these three tools give you a spatial and topological picture of the assembly that no amount of looking at a node table or element list can provide.

Section 1 — The Relationship Graph: What Was Built During Processing

In Part One of this series, we described the build_part_relationships function that runs at the end of model processing. That function produced a relationship graph — a data structure recording what the program could determine about how parts connect.

The graph has two inputs. First, the interface nodes dictionary: which node IDs are shared between which pairs of parts. Two parts that share nodes at their boundary are physically bonded at those nodes — they move together. The number of shared nodes is a proxy for the contact area between parts. Second, the interactions dictionary: the parsed record of every TIE constraint, contact pair, coupling constraint, and MPC definition in the file.

The graph structure is a nested dictionary. For each part name, there is a dictionary of related parts, and for each related part, a record of how they relate: whether they share nodes, how many, and whether they appear together in any interaction definition.

This graph is built once during processing and stored on the application object. The three relationship tools in the Parts tab query it, supplement it with live geometry calculations, and display the results. The stored graph is the fast path for known structural relationships. The live geometry calculations — nearest-parts distance and penetration check — go beyond what the graph can provide.

Section 2 — The Nearest-Parts Search: Count Mode versus Distance Mode

The nearest-parts search answers the question: given a selected part, which other parts are geometrically closest to it, and how far are they?

This is a purely geometric query — it does not depend on what the file says about which parts are connected. It computes distances from the actual node coordinates. Two parts with no constraint definition between them can still be physically adjacent. The nearest-parts search finds that adjacency whether or not the file records it formally.

The search has two modes, selectable with radio buttons in the Parts tab. Count mode returns the N closest parts, where N is a number you specify. Distance mode returns all parts within a specified distance threshold, measured in whatever unit system the model uses.

Count Mode

Count mode is appropriate when you want a ranked list regardless of how spread out the assembly is. Asking for the ten nearest parts gives you the ten closest parts by minimum surface-to-surface distance, regardless of whether the nearest one is 0.1 mm away or 50 mm away.

This mode is useful for assembly review: you want to see what surrounds a component of interest, who its neighbors are, and in what order of proximity they fall. The output is a ranked table with part names and distances, showing a touching indicator — distance approximately zero — for parts that share a surface.

Distance Mode

Distance mode is appropriate when you have a physical threshold in mind — a clearance tolerance, an interference fit specification, a minimum gap requirement. Asking for all parts within 0.5 mm returns only those parts that violate a 0.5-mm clearance around the selected part.

When distance mode returns zero results, the output message tells you what the nearest part actually is and how far it is. This prevents the frustrating experience of getting an empty result with no guidance on how to interpret the absence.

The results panel also stores the found part list internally so the action buttons activate: Select Results in Parts List loads all found parts into the multi-selection in the Parts tab listbox, and Select and View in 3D immediately renders the selected part plus all its neighbors in the 3D viewer as a color-coded assembly view. This connect-results-to-action pattern means a nearest-parts query is not just informational — it is the first step of a multi-part visualization or export workflow.

Section 3 — The Geometry of Distance: Surface Nodes and the K-D Tree

Computing the minimum distance between two parts sounds straightforward, but the implementation choices matter enormously for performance.

Surface Nodes, Not All Nodes

The first decision is which nodes to use for the distance calculation. A solid part with one hundred thousand elements has many interior nodes — nodes that are buried in the material and have no spatial relationship to the part's exterior surface. Computing distances from interior nodes to another part's interior nodes produces meaningless results: the interior of one part cannot physically interact with the interior of another unless they are actually overlapping.

The correct approach is to compute distances using only the surface nodes of each part — those nodes that lie on the exterior faces identified by the face counting algorithm from Part Two.

The find_surface_nodes function retrieves the exterior node set for a part. For parts where the face extraction has already been run — if you have previously viewed the part in 3D — the surface nodes may already be available. For parts not yet tessellated, the function computes the exterior faces on demand. The result is a set of node IDs that represent the part's outer boundary.

The Brute-Force Problem

Consider the naive approach. Take every surface node of part A — call that set M nodes. Take every surface node of part B — call that set N nodes. For every node in A, compute its distance to every node in B. The closest distance is the part-to-part distance.

The number of distance calculations is M × N. If both parts have ten thousand surface nodes, that is one hundred million calculations for a single part pair. For a ten-part assembly with ten pairs to check, that is one billion calculations. In Python, each of those is a floating-point square root operation. This approach is technically correct but practically unusable for any real assembly.

The K-D Tree Solution

The program uses a K-D tree — provided by the cKDTree class from scipy.spatial — to make this tractable. A K-D tree is a binary space partitioning structure that organizes points in k-dimensional space — three dimensions, in our case — such that nearest-neighbor queries can be answered in logarithmic time rather than linear time.

The tree is built from the node coordinates of part B. This construction takes O(N log N) time — where N is the number of nodes in B — and requires a one-time upfront cost. Once the tree is built, querying the nearest neighbor of any arbitrary point in three-dimensional space takes O(log N) time per query.

The key optimization is the batch query. Instead of querying one node from part A at a time, the function passes all M nodes from part A as a two-dimensional NumPy array in a single call to tree.query. The K-D tree processes all M queries simultaneously — or as close to simultaneously as the vectorized NumPy implementation allows — and returns an array of M minimum distances in one operation.

The result is then filtered: any distance below the tolerance threshold is flagged as a close node. The entire nearest-neighbor computation for one part pair — what would have been M × N scalar operations — is reduced to one vectorized batch query. On large assemblies with thousands of surface nodes per part, this is the difference between seconds and hours.

When scipy is not installed, the program falls back to a brute-force implementation capped at the first one hundred surface nodes of part A for sampling. The fallback produces an approximate result — the sample may not include the closest actual node — and logs a warning to the console. The result is still directionally useful, but the analyst is told explicitly that a slower, approximate method was used.

Section 4 — The Interacting-Parts Search: Reading the File's Explicit Connections

The nearest-parts search is a geometric query. The interacting-parts search is a structural query. It asks: what does the file actually say about how this part connects to others?

Three types of Abaqus interaction definitions are scanned: TIE constraints, contact pairs, and coupling constraints.

A TIE constraint bonds two surfaces together so that matching nodes on the surfaces move identically. The master and slave surface names are the identifiers in the file. The program checks whether the selected part's name appears as a substring in either surface name. A surface named Housing-1_TOP is likely the top surface of the Housing part. A surface named PCB-1_BOTTOM connects to the PCB.

Contact pairs define a potentially sliding or separating interaction between two surfaces. The same name-matching logic applies. The result shows the interaction type — TIE or CONTACT — the constraint name, and the connected surface name.

Coupling constraints connect a surface to a reference node, typically the center of a bolt hole or a connector attachment point. When the selected part's surface name appears in a coupling definition, the coupling's reference node is reported as the connected entity.

The name-matching approach is a practical necessity. Abaqus surface names are free-form strings — the file's author assigns them. There is no enforced convention linking a surface name to the part it belongs to. The program uses substring matching with case insensitivity as the best available heuristic: if the part name appears anywhere in the surface name, the interaction is considered relevant.

This will miss connections where the surface name bears no resemblance to the part name — a surface named SURF_001 belonging to the Housing part will not be found when searching for Housing interactions. The program acknowledges this limitation in the results display: when no interactions are found, the output tells you how many TIE, contact, and coupling definitions were scanned, so you know whether the absence of results reflects a genuinely unconnected part or an unresolvable naming convention.

The results panel also queries the stored relationship graph for any shared-node relationships that were built during processing. If two parts share interface nodes, that is reported here as a SHARED type interaction with the node count. This catches the bonded-mesh case — parts whose mesh nodes are literally the same nodes — even when no constraint keyword appears in the file.

Section 5 — The Common-Node Search: Set Intersection as Connectivity Proof

The common-node search is the most direct of the three relationship tools. It asks the simplest possible question: do any node IDs appear in both this part and that part?

In a well-meshed assembly, when two components are bonded — glued, welded, perfectly constrained — the mesher typically creates a conformal mesh at the interface: the two parts share the exact same nodes at their common surface. The node at the corner of the bond interface has the same ID in both parts' element connectivity tables.

The common-node search exploits this directly. It collects the full set of node IDs for the selected part — from all elements, not just the surface — and does the same for every other part. A Python set intersection — the & operator — returns the nodes present in both sets. If that intersection is non-empty, the two parts share nodes and are therefore directly meshed together.

The results are sorted by the number of common nodes in descending order, so the most strongly connected parts appear first. Each result shows the part name, the common node count, and the percentage of the selected part's total nodes that are shared — which gives a sense of what fraction of the part's boundary is bonded to each neighbor.

The top match also shows a sample of the first ten shared node IDs. This is useful for debugging: if you want to verify that the shared nodes are at the expected location in the model, you can look up those node IDs in the summary data and verify their coordinates.

The common-node search is most powerful for conformal meshes and orphan mesh assemblies where parts were meshed together with shared nodes at interfaces. For assemblies where parts were meshed independently and connected with TIE constraints or contact pairs — where the nodes at the interface belong to one part or the other but not both — the common-node search will correctly report no shared nodes. In that case, the interacting-parts search is the right tool.

Knowing which tool to use for which model type is part of the critical thinking framework this series is building. The tools are not interchangeable — each one addresses a specific connectivity model.

Section 6 — The Penetration Check: When Parts Occupy the Same Space

The penetration check is the most computationally intensive operation in the entire program. It addresses a failure mode that no amount of mesh quality checking or material verification can catch: two or more parts that physically overlap in space.

A geometric penetration means that nodes from one part are positioned inside the volume of another part. In physical reality, two solid bodies cannot occupy the same space. In a simulation model, they can — the finite element solver has no inherent protection against this. The elements of the overlapping region will be assigned conflicting material stiffnesses, contact algorithms will behave erratically, and the simulation will produce results that bear no relationship to physical reality.

Penetrations occur for several reasons. The most common is imprecise positioning during model assembly: two parts were placed with a nominal clearance of zero, but numerical rounding in the translation or import process moved one slightly into the other. Another common cause is user error in defining assembly transformations. A third is deliberate interference fits that were meant to be represented with contact but were accidentally set up as tied surfaces instead.

The penetration check detects these overlaps by finding nodes from one part that are within a tolerance distance of nodes from another part. The tolerance is set at 0.1 model units by default — this is not zero, because zero would miss near-tangent surfaces that are so close they might as well be touching, and it would miss meshing artifacts where nodes are at nominally identical positions but differ by floating-point precision.

Section 7 — The Penetration Check Architecture: Threading, Queues, and Heartbeats

The penetration check is architected as a fully threaded, cancellable, progress-reporting operation. This is the most sophisticated UI-concurrency implementation in the program.

Why Threading Is Non-Optional Here

For a ten-part assembly, the check requires 45 pair comparisons — the combinatorial count of choosing two items from ten. For a twenty-part assembly, 190 pairs. For a fifty-part assembly, 1,225 pairs. Each pair comparison involves building a K-D tree and running a batch nearest-neighbor query. On a large assembly with high node counts, this can take minutes.

If this computation ran on the main thread — the same thread that draws the interface — the entire window would freeze for the duration. The mouse cursor would stop responding. The operating system would eventually mark the application as unresponsive. The user would have no way to cancel.

The solution is to move the computation to a background daemon thread. The main thread stays free to redraw the interface, respond to mouse events, and — critically — receive progress updates and handle the Cancel button.

The Queue-Based Communication Pattern

The background thread needs to communicate with the main thread. It cannot update the UI directly — tkinter is not thread-safe. Attempting to call any tkinter widget method from a background thread can produce crashes or rendering corruption.

The program uses a Python queue as the communication channel. The background thread puts messages into the queue. The main thread reads from the queue on a scheduled timer — every one hundred milliseconds — and dispatches any pending messages to the appropriate UI update calls.

Three message types flow through the queue. A progress message carries the current pair number, total pair count, the names of the two parts being compared, and a time-remaining estimate. The main thread uses this to update the progress bar value and the status label text. A done message carries the complete penetration results. The main thread closes the progress dialog and opens the results dialog. An error message carries the exception string for any unexpected failure in the worker.

The Heartbeat Timer

There is a second timer running alongside the progress polling. The heartbeat timer fires every one second and updates a small gray label at the bottom of the progress dialog: elapsed seconds and pairs checked so far. This is deliberately separate from the main progress updates.

The reason is reliability. The progress queue updates come from the worker thread and depend on the worker producing updates at a sufficient rate. For very large pair comparisons — a single pair with millions of nodes on each side — the worker might be silent for a full second while running one batch K-D tree query. During that silence, the progress label would freeze, and the user would not know if the program was working or stuck.

The heartbeat has no dependency on the worker thread. It runs entirely in the main thread via tkinter's after method — the same interrupt-driven scheduling used for the processing progress dialog in Part One. The elapsed counter increments every second regardless of what the worker is doing. As long as the heartbeat ticks, the application is alive.

This is the interrupt-driven philosophy applied to user feedback. Do not wait for the worker to signal; instead, provide an independent heartbeat that cannot be blocked by worker slowdowns.

Section 8 — The Pre-Built Element Dictionary: O(1) Lookups

Before the penetration check worker thread starts, the main thread calls a function called build_element_dict. This function builds a dictionary keyed by element ID, mapping each ID to the element record. This pre-build step happens on the main thread, synchronously, before the worker starts.

Why does this matter? Because the worker thread needs to find elements by ID many thousands of times during the check. Without the pre-built dictionary, each lookup would require scanning the entire elements list — which might have tens of thousands of entries — until it finds the one with the matching ID. That is an O(N) operation per lookup.

With the pre-built dictionary, each lookup is a Python dictionary key access — O(1), constant time regardless of how many elements are in the model. The difference between O(1) and O(N) matters enormously when you are doing thousands of lookups inside nested loops.

The dictionary is built once and stored on the application object. It is cleared when a new file is loaded. If it already exists when build_element_dict is called, the function returns immediately without rebuilding — there is a guard check at the top. This means the first call to any function that needs element lookups pays the build cost; subsequent calls reuse the cached result.

This lazy caching pattern — build on first demand, reuse on subsequent calls — appears throughout the program for expensive one-time computations. It avoids the cost on startup while ensuring the result is always available when needed.

The element dictionary uses the same lookup that the node collection function uses: for each element ID in the part's element list, retrieve the element record from the dictionary, then collect the node IDs from the connectivity field. This is the O(1) path described in the code comments. The alternative — scanning the elements list for each ID — would make the node collection O(N) per element, producing O(N²) total for a part with many elements.

Section 9 — The Three-Layer Penetration Check Filter

The penetration check does not run the expensive K-D tree computation blindly for every pair of parts. It applies a three-layer filtering strategy that eliminates the vast majority of pairs before they reach the expensive computation.

Layer One — Node Count Guard

Before the worker thread starts, the total node count of all selected parts is computed. If it exceeds one hundred thousand, the user is warned and asked to confirm. This is not a hard limit — the user can proceed — but it is a signal that the computation may take several minutes and that a more targeted approach — using Suggest Pairs first to identify the likely problem pairs — would be faster.

Layer Two — Empty Set Skip

Inside the worker loop, before doing anything with a pair of parts, the function checks whether either part has zero nodes from the cache. This handles parts that were in the selection but have no geometric data — purely structural parts like MASS elements, or parts that failed node retrieval for any reason. Zero-node parts cannot penetrate anything and are skipped immediately.

Layer Three — Bounding Box Pre-Filter

The most important filter is the bounding box overlap test. For each part, the bounding box is computed: the minimum and maximum X, Y, and Z coordinates across all the part's nodes. The bounding box is the smallest axis-aligned rectangular box that completely contains the part.

Two parts whose bounding boxes do not overlap cannot possibly have penetrating nodes. Their closest points are on the surfaces of their bounding boxes, and if those boxes do not overlap — even with a tolerance padding — the actual parts are farther apart than the tolerance.

The bounding box overlap test is six comparisons — one per pair of faces in each axis direction. It runs in constant time regardless of how many nodes either part has. The K-D tree computation it avoids is orders of magnitude more expensive.

In a typical assembly with many parts spread across a volume, most part pairs are far apart. Their bounding boxes clearly do not overlap. The bounding box filter eliminates these pairs without touching the K-D tree, leaving only the small fraction of geometrically adjacent pairs for the expensive computation.

Section 10 — The Suggest Pairs Workflow: Bounding Boxes as a Pre-Screening Tool

The Suggest Pairs button is a standalone pre-screening tool that uses bounding box analysis to identify which part pairs are worth checking for penetrations, before running the full node-level check.

The motivation is practical. For a one-hundred-part assembly, the full penetration check examines 4,950 part pairs. Even with the bounding box filter running inside the check, this requires computing one hundred bounding boxes and evaluating 4,950 overlap tests. Then for the pairs that pass, K-D tree queries. On a large model this can take minutes.

The Suggest Pairs workflow separates the fast bounding box screening from the slow node-level analysis. It runs the bounding box overlap test across all pairs as a pre-computation, presents the list of potentially close pairs sorted by center-to-center distance, and lets you select which specific pairs to check in detail.

This workflow also runs in a background thread — it is not instantaneous for large assemblies since it has to build bounding boxes for all parts — but it is much faster than the full penetration check because it stops after the bounding box test.

The results dialog shows the close pairs with their center-to-center distances and offers a Select Top Five Pairs button that populates the Parts tab multi-selection with the parts from the five highest-priority pairs. One click goes from suggestion to selection. From there, clicking Check Penetrations runs the full node-level analysis on only those selected parts — a much smaller and faster computation than checking everything.

The critical thinking lesson here is about computational workflow design. The problem is too large to solve in one step efficiently, but it can be solved in two steps: first a cheap approximation that filters the search space, then an expensive exact computation on only the candidates that survived the approximation. This two-stage strategy — cheap filter followed by exact verification — appears throughout computational geometry and data science. Learning to recognize when it applies is a transferable skill.

Section 11 — Reading the Penetration Results

When the penetration check completes, the results dialog shows a header: either a green checkmark and No Penetrations Detected, or a red warning triangle and the count of part pairs with detected penetrations.

The summary panel shows: the number of parts checked, the distance tolerance used, the number of part pairs analyzed, and the total penetration count.

For each penetrating pair, the results show the two part names, the number of close nodes found, and the minimum distance between any node from part A and any node from part B. A list of up to ten sample node IDs from the penetrating region is shown.

Reading these results correctly requires understanding what they mean in context. A node count of one or two close nodes at a minimum distance near zero does not necessarily mean the parts are penetrating in a problematic way. It may mean that the parts share a common surface node at a corner — which is a conformal mesh, not a penetration. It may mean that two surfaces are tangent and the nearest nodes from both parts are at the tangent point.

A penetration is genuinely problematic when many nodes are close and the minimum distance is zero or negative across a spatially distributed set of nodes — when the overlap covers a region, not just a point. The sample node IDs are provided so you can look up those nodes' coordinates, verify where in the model they are, and make a judgment call.

This is the anti-black-box philosophy applied to the interpretation of results. The program tells you the numbers. It even tells you what the numbers likely mean — touching versus overlapping. But it does not make the final engineering judgment for you. You have the coordinates. You have the node IDs. You can verify.

Section 12 — Algorithmic Complexity: A Framework for Reasoning About Performance

This part of the series has introduced several algorithmic complexity concepts: O(1), O(N), O(N log N), O(N²). The following consolidates these into a framework, because understanding complexity is one of the most transferable skills in computational engineering.

Big-O notation describes how the running time of an operation grows as the input size N grows. It is not about the exact time for a specific input — it is about the growth rate.

O(1) — constant time. A dictionary lookup is O(1): it takes the same amount of time whether the dictionary has ten entries or ten million. This is the gold standard.

O(N) — linear time. Scanning a list of N elements to find a match is O(N): doubling the list size doubles the time. This is acceptable when N is small.

O(N log N) — linearithmic time. Building a K-D tree from N points is O(N log N). Sorting a list of N items is also O(N log N). The log factor grows slowly — log of one million is about twenty. So a million-node tree build takes roughly twenty million operations, not a billion.

O(N²) — quadratic time. Comparing every node in set A to every node in set B — brute-force distance search — is O(M × N). For two ten-thousand-node sets that is one hundred million operations. Quadratic scaling is dangerous: doubling the input size quadruples the running time.

The penetration check's performance story is entirely about avoiding O(N²). The element dictionary pre-build replaces O(N) list scans with O(1) lookups. The bounding box filter eliminates most pairs before they reach the O(N log N) K-D tree construction. The batch K-D tree query replaces an O(M × N) brute-force loop with an O(M log N) vectorized operation.

Every one of these optimizations was added in response to a real performance problem observed on a real model. The code comments in the penetration check section document the original O(N × M) performance characterization and the optimizations applied. Reading those comments alongside this explanation gives you the complete trace from problem to solution.

Section 13 — The Stop Flag Pattern: Cooperative Cancellation

Both the Suggest Pairs worker and the penetration check worker support cancellation via a Cancel button. The implementation uses cooperative cancellation — the worker checks a flag and decides to stop, rather than being forcibly killed.

The stop flag is a single-element dictionary: stop_flag = {'value': False}. The dictionary wrapper is used instead of a plain boolean because Python's scoping rules prevent a nested function from reassigning a variable from the outer scope. A mutable object like a dictionary can be modified from any scope, so setting stop_flag['value'] = True inside the cancel callback works correctly.

At the top of every major loop iteration in the worker — before processing a new part, before processing a new pair — the worker checks: if stop_flag['value'] is True, break. This check costs essentially nothing — it is a dictionary lookup followed by a boolean test. But it allows the Cancel button click to propagate into the running computation within at most one loop iteration's delay.

When the stop flag is set, the worker sends a cancelled message through the queue and returns. The main thread receives the cancelled message and closes the progress dialog without opening a results dialog. A brief informational message tells the user that the check was cancelled.

Forcible thread termination — which Python does not support cleanly — or OS-level process signals would produce unpredictable cleanup behavior. Cooperative cancellation via a shared flag is the correct pattern for cancellable background computations in tkinter applications.

Section 14 — The Complete Relationship Analysis Pipeline, End to End

Final numbered summary.

1.  During model processing, build_part_relationships assembles the relationship graph from interface nodes and parsed interaction definitions. This graph is stored and available for immediate queries.

2.  The user selects a part in the Parts tab and chooses a relationship tool.

3.  For nearest-parts search: find_surface_nodes retrieves the exterior node set for the selected part and each candidate part. Node coordinates are collected from the node coordinate dictionary. A K-D tree is built from the candidate part's surface node coordinates. The batch query computes minimum distances from all selected-part surface nodes to the tree. The minimum of those minimums is the part-to-part distance. All candidate parts are ranked by this distance, then filtered by count or distance threshold. Results are stored for the select-and-view action buttons.

4.  For interacting-parts: the interactions dictionary is scanned for TIE, CONTACT, and COUPLING entries. Substring matching against part names identifies relevant entries. The relationship graph is also queried for shared-node relationships. All found interactions are displayed with type, constraint name, and connected entity.

5.  For common-node: all node IDs from the selected part and each other part are collected into sets. Python set intersection finds shared IDs. Results are sorted by shared node count descending. The top match includes a sample of shared node IDs.

6.  For Suggest Pairs: a background thread builds bounding boxes for all parts. Overlap tests are run for all part pairs with tolerance. Close pairs are sorted by center-to-center distance and displayed. The Select Top Five Pairs action loads the Parts tab selection.

7.  For penetration check: the element dictionary is pre-built on the main thread. The background worker starts with a node cache pre-population step. For each part pair, the bounding box filter runs first. Pairs that pass the filter proceed to the batch K-D tree query. Close nodes — those within the tolerance distance — are flagged as penetrations. The heartbeat timer fires independently every second. Progress messages flow through the queue to the main thread. The cancel button sets the stop flag, which the worker checks at each iteration. Results or cancellation notification are sent via the done or cancelled message.

That is the complete relationship analysis pipeline — from the stored graph built at processing time through the live geometry queries that extend beyond what the file explicitly records.

Closing — Relationships as the Missing Dimension

A model made of parts without relationships is not an assembly. It is a collection.

The structural behavior of an assembly emerges from the interactions between its components — the load paths through the interfaces, the constraint forces at the joints, the contact pressures at the surfaces. A simulation that models each component correctly but gets the interface wrong is wrong in the most consequential way possible.

The tools in this part of the series — nearest-parts, interacting-parts, common nodes, penetration check, Suggest Pairs — are the spatial intelligence layer of the program. They answer questions that cannot be answered by reading keyword lists or property tables. They answer questions about how the assembly exists in space, which parts are next to each other, and whether the model's geometry is physically consistent before any solver ever sees it.

The computational techniques behind them — K-D trees, bounding box filtering, batch vectorized queries, cooperative thread cancellation, the pre-built element dictionary — are not esoteric algorithms. They are standard tools in computational geometry and scientific computing that anyone building tools in this space should know. They are described here not to show off the implementation, but because understanding why they are needed, and what they replace, is part of the critical thinking framework.

Part Seven covers the program's interface architecture — how the tabbed layout was designed, how the resizable panels work, how color themes are implemented, how font preferences are stored, and how the entire program is packaged for distribution as a standalone application using PyInstaller.

Source code, documentation, and all companion readers are at McFaddenCAE.com.

End of Part 6 — Part Relationships, Penetration Checks, and the Nearest-Parts Search

Next: Part 7 — Interface Architecture, Color Themes, Preferences, and PyInstaller Distribution

© 2026 Joseph P. McFadden Sr. All rights reserved.  |  McFaddenCAE.com

Part 7

ABAQUS INP COMPREHENSIVE ANALYZER

Under the Hood  —  A Deep-Dive Series

PART 7

Interface Architecture, Color Themes,

Preferences, and PyInstaller Distribution

The Systems Between the Computation and the Person Using It

Joseph P. McFadden Sr.

McFaddenCAE.com  |  The Holistic Analyst

© 2026 Joseph P. McFadden Sr. All rights reserved.

Setup — The Other Half of the Program

The first six parts of this series went deep into what the program does with your data — parsing, geometry, materials, recommendations, exports, relationships. All of that is computation: algorithms operating on numbers and structures.

This part covers everything that sits between that computation and the person using it: the interface architecture, the theming system, the preferences machinery, and the packaging that lets the program run on a machine with no Python installed.

These are the systems that most technical users ignore until something goes wrong — a font that is too small on a high-resolution screen, a color scheme that is unreadable in their office lighting, a preference that does not save between sessions. Understanding how they work means understanding how to fix them when they need it, and how to extend them when a new capability is needed.

Section 1 — The App Class: A Window That Knows Itself

The entire program lives inside a single Python class called App. That class inherits from tk.Tk — which is tkinter's root window class. This is not the usual pattern for tkinter applications, which more commonly create a separate root window and then build an application object on top of it. Inheriting directly from tk.Tk makes the application class and the root window the same object.

The consequence is that the App instance is the window. When you call self.configure, you are configuring the main window. When you call self.after, you are scheduling a callback on the main event loop. When you call self.geometry, you are setting the window size. Everything related to the window is a method call on the same object that holds all the parsed model data and all the analysis logic.

This tight coupling makes the code simple — there is no layer of indirection between the window and the application — and it means any method anywhere in the class has direct access to both the UI and the data without passing anything around.

Startup Sequence

When App's init method runs, it executes in a specific order. First it calls the parent tk.Tk initializer to create the window. Then it sets the title bar text. Then it calculates an initial geometry — 1,400 by 800 pixels — and adjusts it to fit the screen, centering it and accounting for the taskbar height.

Then preferences are loaded. If a saved window geometry exists in the preferences file, that geometry is applied, restoring the window to exactly the size and position the user left it at. If the saved state was maximized, the zoomed state is applied. If the preferences file does not exist or cannot be read, the default geometry is used.

Then the two font objects are created — one for text areas and one for listboxes — using the font families and sizes from the loaded preferences. Then the style engine is initialized, the color theme is applied, and finally build_ui is called to construct the entire interface.

The ordering matters. Fonts must exist before the widgets that use them are built. The theme must be applied before the notebook tabs are constructed, or the tab styling will not be correct. Preferences must be loaded before fonts and themes are initialized from them. This is a dependency chain, and the init method respects it.

Section 2 — Building the UI: Menu Bar, File Bar, and the Notebook

The build_ui method constructs the entire visible interface in one pass. It runs once at startup and produces the complete window layout.

The Menu Bar

A tkinter menu bar is created and attached to the window with self.config(menu=menubar). Three menus are added: View, Tools, and Help.

The View menu contains Font Settings and Color Theme, plus a Reset to Defaults option. These are the only items under View — everything in this menu is about how the interface looks, not about what it does.

The Tools menu contains Unit System, Check Unit Consistency, Analyze Simulation Intent, and Debug Console Output. The Debug Console Output item is dynamic — its label changes between ON and OFF depending on the current state, updated every time it is toggled. The menu item index is stored when the menu is built so the label can be updated later without rebuilding the entire menu.

The Help menu contains About, which opens a small dialog with the program version, author, contact, and copyright notice.

The File Selection Bar

Below the menu bar, a horizontal frame contains the file selection controls. A label, a wide entry widget bound to a string variable called path_var, a Browse button, and a Process button. The Process button starts in the disabled state and is only enabled when a file path is populated.

A ttk Separator — a thin horizontal line — sits below the file bar, visually separating it from the notebook area below.

The Notebook

The main content area is a ttk.Notebook — the tabbed panel widget. It is placed inside a container frame with a groove border style, which draws a subtle three-dimensional border around the tab area.

The nine tabs are built in order by calling their respective builder methods: build_tab_summary, build_tab_materials, build_tab_properties, build_tab_sections, build_tab_plotting, build_tab_parts, build_tab_recommendations, build_tab_edits, and build_tab_learning_center. Each builder method creates all the widgets for that tab and adds them to the tab's frame.

The call to setup_initial_sash_positions is scheduled with after(100) — meaning it runs 100 milliseconds after the UI is fully rendered. This delay is necessary because the paned windows need to be visible and sized before their sash positions can be set. Calling sashpos before the window is rendered has no effect. The 100-millisecond delay guarantees the window is drawn before the sash adjustment runs.

Section 3 — The Widget Tracking System

One of the quieter but more important architectural decisions in the interface is the widget tracking system. Every text area — every ScrolledText widget — in the interface is appended to a list called self.text_widgets at the time it is created. Every listbox is appended to self.list_widgets.

These two lists are the mechanism that makes program-wide font and theme changes work without rebuilding any widgets.

When you open Font Settings and click Apply, the apply_fonts method reconfigures the two font objects — text_font and list_font — with the new family and size. Then it loops through text_widgets and calls widget.configure(font=self.text_font) on every entry. Then it loops through list_widgets and applies list_font to every listbox.

One call per widget. No conditional logic, no tab-specific code. Every text area in the Summary tab, the Materials tab, the Property Viewer, the Parts tab, the Recommendations tab — they all update simultaneously because they all registered themselves at build time.

The apply_theme method works the same way for colors. It configures the ttk.Style for the notebook, tabs, frames, labels, radio buttons, and checkboxes — all the themed widgets managed by the ttk style engine. Then it loops through text_widgets and applies the theme's text background, foreground, and selection colors. Then through list_widgets for the same.

The approach is registration at construction time, bulk application at change time. This is a clean and scalable pattern. When a new tab is added — like the Learning Center was added in a later version — it just needs to append its widgets to the existing lists. Theme and font support is automatic.

Section 4 — Paned Windows and the Sash Position Problem

Every tab in the program that has a left-right split — and that is most of them — uses a ttk.PanedWindow widget. A paned window is a container that holds two or more child frames separated by a draggable divider called a sash. The user can drag the sash left or right to adjust how much space each side gets.

The challenge is defaults. By default, a paned window splits its space equally between its children — fifty percent left, fifty percent right. For this program, that is almost never ideal. The left panels — the material list, the parts list, the section list — are narrow navigation panels. The right panels — the detail text areas — are where the content lives and need to be wider.

The setup_initial_sash_positions method addresses this by explicitly positioning each sash after the window renders. The Materials tab sash is set to 200 pixels from the left. The Sections tab gets 250. The Property Viewer gets 180. The Plotting tab gets 220. These specific values were determined by trial and measurement — the narrowest useful width for the left panel in each tab.

The scheduling via after(100) is critical here. The tkinter widget model has a fundamental constraint: geometry is not calculated until the widget is actually rendered on screen. If you call sashpos(0, 200) on a paned window before it has been drawn, the paned window does not know its own size yet and the position has no meaningful reference. The 100-millisecond delay puts the sash adjustment after the first render pass, when widget dimensions are known.

This pattern — schedule a geometry adjustment after a short delay — appears in several places in the program's UI code. It is a workaround for a fundamental aspect of how immediate-mode GUI toolkits work: you can create widgets before they have a size, but you cannot position things relative to their size until they have been drawn at least once.

Section 5 — The Color Theme System

The program offers eight color themes. Each theme is defined as a dictionary with nine keys: background color, foreground color, text area background, text area foreground, selection background, selection foreground, tab background, selected tab background, and tab foreground text.

The eight themes are: Default — a standard light gray interface. Dark Mode — a dark charcoal interface with light gray text, similar to dark mode in modern code editors. Ocean Blue — a blue-tinted light theme with navy text. Forest Green — a green-tinted light theme. Warm Sand — a warm beige tone. Purple Dusk — a purple-tinted light theme. High Contrast — a pure black background with bright green text, designed for maximum visibility in challenging lighting conditions. Slate Gray — a cool gray professional tone.

The theme dictionary keys map directly to specific widget configuration parameters. When apply_theme runs, it reads those keys and passes them to the style engine and widget configuration calls. There is no color calculation, no inheritance, no derivation. Every color in every theme is explicitly stated. This is verbose but transparent — you can read the theme definition and immediately know exactly what every element will look like.

The ttk.Style Engine

tkinter has two widget families: the classic tk widgets and the themed ttk widgets. The ttk widgets are styled through a centralized ttk.Style object rather than per-widget configuration calls.

The style object is initialized once in the App init method. apply_theme calls configure and map methods on the style to set tab appearance, frame backgrounds, label colors, and checkbox and radio button backgrounds. The configure method sets static properties. The map method sets state-dependent properties — for example, a tab has one background color when it is not selected and a different color when it is selected. The map method handles that conditional styling.

Classic tk widgets — the Text widget, the Listbox — do not respond to the ttk style engine. Their colors are set directly via the bg, fg, selectbackground, and selectforeground configuration parameters. That is why apply_theme loops through text_widgets and list_widgets explicitly — these widgets are outside the ttk styling system and need direct configuration.

Section 6 — The Font System: Two Fonts, One Policy

The program uses exactly two font objects: text_font and list_font. This is a deliberate simplification.

text_font is the font used in all scrolled text areas — the Summary tab output, the material detail panels, the property data viewer, the recommendations detail area, the edit preview. It defaults to Courier at 10 points. Courier is a monospace font, meaning all characters have the same width. Monospace is the correct choice for tabular data — columns stay aligned regardless of whether a line contains mostly narrow characters like i and l or wide characters like w and m.

list_font is the font used in all listboxes — the materials list, the parts list, the sections list, the dataset list, the recommendations list, the topic list. It defaults to TkDefaultFont at 9 points. TkDefaultFont is the operating system's default UI font — on Windows that is Segoe UI, on macOS San Francisco, on Linux it varies. Using the system default ensures listboxes look native to the platform.

Font objects in tkinter are mutable. When you call font_object.config(family='Helvetica', size=12), the change propagates immediately to all widgets that use that font object — without any explicit widget update required. This is why the apply_fonts method is so short: reconfigure the two font objects, and all registered widgets update automatically through the font binding.

The Font Settings Dialog

The Font Settings dialog opened from the View menu has two sections: one for the text areas font and one for the lists font. Each section has a dropdown for font family — populated from the fonts currently installed on the system — and a spinner for font size.

A live preview panel at the bottom of the dialog shows sample text rendered in whatever font and size the text-area controls currently show. The preview updates in real time as you change the dropdowns and spinners, using a variable trace — a tkinter mechanism that calls a function whenever a variable's value changes. You can audition dozens of fonts without committing to any of them until you click Apply.

When Apply is clicked, the preferences dictionary is updated, the preferences file is saved, and apply_fonts is called to push the changes to all widgets. The dialog closes.

Section 7 — The Preferences System: Persistence Across Sessions

The program remembers your settings between sessions. This is handled by a JSON preferences file stored in the user's home directory. The file path is constructed using os.path.expanduser('~/') — which resolves to the user's home directory on all platforms — combined with the filename .abaqus-analyzer-config.json.

JSON was chosen over other formats specifically for its human readability. The preferences file is plain text that you can open in any editor. If you need to reset a specific preference without running the program, you can edit the file directly. If the file gets corrupted, you can delete it and the program will create fresh defaults on next launch.

What Is Stored

The preferences dictionary contains: the config version number, used for future migration when the format changes; the text font family and size; the list font family and size; the color theme name; the last window geometry as a position-and-size string; the window state — normal or zoomed; the last directory used in the file browser; a debug console toggle; and a dictionary of custom part colors, capped at fifty entries.

The part colors dictionary maps part names to their user-selected colors. When you choose a custom color for a part in the 3D viewer and then close the program, that color association is remembered. Next time you view that part, it uses the same color. The fifty-entry cap prevents the preferences file from growing indefinitely in projects with large part counts.

The Load and Save Functions

The load_preferences function first defines a defaults dictionary — every preference key with its default value. If the config file exists and can be parsed as valid JSON, the saved values are merged onto the defaults: a new dictionary is created from defaults with the saved preferences layered on top. Any key present in the file overrides the default; any key absent in the file gets the default. This merge pattern handles version changes gracefully — if a new preference key is added in a future version, existing config files without that key simply get the new default.

If the config file does not exist, cannot be read, or contains invalid JSON, the except block catches the error silently and returns the defaults. The program starts cleanly with defaults rather than crashing on a bad config file.

The save_preferences function serializes the preferences dictionary to JSON with indent=2 — producing a nicely formatted, human-readable file. It writes to the config file path with UTF-8 encoding. If the write fails — a permissions error, a full disk, a network drive issue — it catches the exception and prints a console message. The failure to save preferences is not a fatal error.

Section 8 — Window State Persistence

When you close the program, the on_closing method runs — registered as the handler for the WM_DELETE_WINDOW event, which is the event tkinter receives when you click the window's close button or use Alt-F4.

On closing, three things are saved to preferences before the window is destroyed. First, the current window geometry — the result of calling self.geometry() with no arguments, which returns the window's current size and position as a formatted string. Second, the window state — normal, or zoomed if maximized. Third, the current color theme, identified by comparing the current theme dictionary against all named themes in the COLOR_THEMES dictionary and recording the matching name.

After saving, save_preferences is called to write the file, and then self.destroy() closes the window and exits the program.

On the next launch, the init method reads those saved values and restores them. The window appears at the same size and position it was when closed. If it was maximized, it reopens maximized. If it was at a specific position on a secondary monitor, it reopens there.

This round-trip — save on close, restore on open — is what makes the program feel persistent. It is not a significant technical achievement, but it is one of the details that distinguishes a tool someone built for themselves from a tool someone built for other people to use day after day.

Section 9 — Debug Mode

The program has a built-in debug mode toggled from the Tools menu. When debug mode is on, the program writes detailed console output — verbose logging of what it is doing at each step of parsing, part identification, volume calculation, and all other major operations.

Debug output is handled by a module-level function called dprint. Every place in the code where diagnostic information might be useful, the code calls dprint rather than the Python built-in print. When debug mode is off, dprint is a no-op — it returns immediately without producing any output. When debug mode is on, dprint calls print, and the message appears in the console.

The set_debug function toggles the behavior. When debug is enabled, set_debug replaces the dprint function with a version that calls print. When disabled, it replaces it with a version that does nothing.

This pattern — conditional dispatch via function replacement — is more efficient than checking a flag inside every dprint call. With millions of potential dprint calls in a large analysis, the overhead of checking a boolean flag each time would be measurable. Replacing the function itself means the disabled path has zero cost: the no-op function is called and returns immediately without any conditional logic.

The debug toggle's menu label changes between DEBUG CONSOLE OUTPUT: ON with a checkmark and DEBUG CONSOLE OUTPUT: OFF whenever the item is clicked. The label update uses the stored menu reference and item index to reconfigure just that one menu entry without rebuilding the menu.

For developers working on extensions to the program: dprint is your friend. Add a dprint call wherever you are tracking state or diagnosing unexpected behavior. The output appears only when the user has explicitly turned debug mode on, so it adds no noise during normal use.

Section 10 — Graceful Degradation: Optional Dependency Architecture

The program is designed to run on a minimal Python installation. The core features — parsing, material display, recommendations — require nothing beyond Python's standard library plus tkinter. Everything else is optional.

Every optional dependency is imported inside a try-except block at the module level. If the import succeeds, a boolean availability flag is set to True and the imported functions are stored in module-level variables. If the import fails, the flag stays False and the functions are set to None.

Throughout the code, before calling any optional function, the corresponding availability flag is checked. If it is False, the UI element for that feature is disabled — greyed out — and a message explains what package would enable it.

The optional dependencies and what they enable: scipy.spatial provides the K-D tree for the nearest-parts search and the penetration check — without it, a slower brute-force fallback runs. NumPy provides vectorized volume calculation — without it, element-by-element calculation runs. Matplotlib provides the 3D viewer and the material property plots — without it, the View in 3D button and the plot buttons are disabled. The STL exporter module provides STL export. The STEP exporter module, which requires PythonOCC and OpenCASCADE, provides STEP export — without it, the STEP button is disabled.

The best practices module, the simulation intent classifier module, and the volume-mass calculator module are all handled the same way. If present, they load and contribute their capabilities. If absent, the program continues without them and their features are silently unavailable.

This architecture has a specific benefit for distribution: you can ship different tiers of the program depending on what dependencies are available on the target machine. A minimal install gives you parsing, materials analysis, and recommendations. A full install adds visualization, STL export, and all the spatial analysis tools. The same codebase, the same executable — just different results from the dependency check at startup.

Section 11 — PyInstaller: Packaging for Distribution

Python programs typically require Python to be installed on any machine that runs them. For a tool intended for use across an engineering team — where not everyone has Python, where IT policies may restrict software installation, where the program needs to run on machines without internet access — this is a significant barrier.

PyInstaller solves this by bundling the Python interpreter, all required packages, and the program's own source files into a single directory or a single executable file. The result is a standalone application that runs on any Windows machine — or macOS or Linux, depending on where PyInstaller runs — without any Python installation required.

How PyInstaller Works

PyInstaller analyzes the program's import tree — starting from the main script, it follows every import statement and collects the files needed for every imported module. It then copies the Python interpreter itself, all the module files, and any data files specified in the build configuration into an output directory. When the resulting executable runs, it extracts those files to a temporary location and runs the program against the bundled Python interpreter.

The key distinction is between a single-directory build and a single-file build. A single-directory build produces a folder — typically named dist/program-name — containing the executable plus dozens or hundreds of support files. A single-file build packages everything into one executable that extracts itself to a temporary directory at runtime. Single-file is more convenient to distribute but slower to start up, because extraction takes time on each launch.

The Frozen Check

When a PyInstaller-packaged program runs, Python's sys module has a special attribute: sys.frozen is set to True. When running as a normal Python script, sys.frozen does not exist.

The program checks this at the very top of the file, before any other imports, using getattr(sys, 'frozen', False). If it evaluates to True, the program is running as a compiled executable and needs to handle one specific difference from the normal Python environment: the matplotlib configuration directory.

Matplotlib writes configuration and cache files to a directory it expects to find in a writable location. In a normal Python installation, this directory is somewhere in the user's home folder. In a PyInstaller bundle, the program files are extracted to a temporary directory that may not be writable, or that gets cleaned up between runs.

The fix is to redirect matplotlib's configuration directory to a location that is guaranteed writable and persistent. The frozen check sets the MPLCONFIGDIR environment variable to a directory called mpl_config sitting next to the executable — in the same folder as the packaged application. This directory persists between runs, and the user has write access because they installed the application there.

The check runs before the matplotlib import. This ordering is critical — if matplotlib is imported before MPLCONFIGDIR is set, matplotlib will have already chosen its configuration directory and changing the environment variable afterward has no effect.

The Spec File

PyInstaller builds are controlled by a spec file — a Python script that specifies which files to include, what the executable name should be, whether to produce a single file or a directory, and how to handle hidden imports — modules that PyInstaller's static analysis does not discover automatically because they are imported dynamically at runtime.

The program's optional dependencies — the STL exporter, the STEP exporter, the volume calculator, the best practices module — are all separate Python files that live alongside the main script. The spec file needs to explicitly include these as data files or hidden imports so they are bundled into the distribution. Without this, the packaged executable starts up and all the try-except import blocks fail, leaving all optional features disabled.

When packaging the program, verifying each optional feature by running the packaged version is essential. The availability flags printed to the console at startup — lines like 'STL exporter loaded successfully' or 'Best practices module loaded successfully' — confirm that each module was found by the bundled Python interpreter.

Section 12 — The _MEIPASS Path and Resource Location

There is a second PyInstaller-specific detail that matters for any program that reads files at runtime — not imports Python modules, but reads files like images, data files, or reference databases.

When a PyInstaller single-file executable runs, it extracts its bundled files to a temporary directory. The path to that temporary directory is stored in sys._MEIPASS. When running as a normal Python script, sys._MEIPASS does not exist.

Any code that opens a file with a path relative to the script's location — using something like os.path.dirname(__file__) — will work correctly when running as a script but fail when running as a packaged executable, because file in the packaged version points to the temporary extraction directory, not the original source directory.

The standard pattern for handling this is a resource path function: try to get sys._MEIPASS and join the requested relative path to it; if sys._MEIPASS does not exist, fall back to the directory containing the script. This function is used anywhere the code needs to locate a file that was bundled with the program.

The material library data, the unit system definitions, and similar reference files need this treatment if they are stored as separate files rather than embedded in the source code as Python dictionaries. In this program, the material library and unit systems are defined directly in the unit_detection module as Python data structures, so they are handled by the normal module bundling mechanism and do not need the resource path treatment.

Section 13 — The Complete Interface Startup Sequence

The ordered startup sequence from launch to first-use-ready state.

1.  The sys.frozen check runs before any import. If frozen, MPLCONFIGDIR is redirected. Matplotlib is then imported and configured to use the TkAgg backend — the backend that renders matplotlib figures inside tkinter windows.

2.  All optional modules are imported inside try-except blocks. Each availability flag is set. Modules that loaded successfully print confirmation messages to the console.

3.  Module-level constants are defined: the config file path, the COLOR_THEMES dictionary, the KNOWN_PROP_HEADERS dictionary, the element type sets, the regex patterns.

4.  App.__init__ runs: the window is created and sized, load_preferences is called, the saved window geometry and state are applied, font objects are created from preferences, the ttk.Style is initialized, the current theme is loaded and apply_theme is called, and build_ui constructs the complete interface.

5.  The after(100) callback fires and setup_initial_sash_positions sets the divider positions in all paned windows.

6.  The event loop starts. The window is visible and responsive. The Process button is disabled, waiting for a file selection.

7.  The user selects a file. The Process button enables. Analysis runs in a background thread. Dialogs surface decisions. Tabs populate. The interface is fully operational.

That is the complete path from a Python file on disk — or a packaged executable — to a running analysis session.

Closing — The Interface Is Part of the Engineering

Software interface design is not decoration. It is engineering.

The decision to track widgets in lists so font and theme changes propagate uniformly — that is an engineering decision. The decision to schedule sash positions after rendering rather than before — that is debugging the behavior of a GUI toolkit. The decision to use JSON for preferences because it is human-readable and recoverable — that is making a considered choice about failure modes. The frozen check for matplotlib configuration — that is understanding how a packaging tool changes the runtime environment and addressing it before it breaks things.

Every one of those decisions is as deliberate as any decision in the parsing logic or the geometry engine. The interface layer deserves the same analytical attention as the computation layer. Users encounter the interface on every interaction. They encounter the parsing logic only when something goes wrong.

This completes the Under the Hood series for version 15.7 of the Abaqus INP Comprehensive Analyzer. Seven parts covering model processing, the geometry engine, materials and recommendations, the export pipeline, the learning center, part relationships and spatial analysis, and this final part on interface architecture and distribution.

The program continues to develop. Future parts of this series may cover the STEP integration when it is fully bridged into the main tool, the injection mold tooling validation capabilities, and additional analysis in unit detection and material library expansion.

All source code, documentation, and companion readers for this series are at McFaddenCAE.com.

End of Part 7 — Interface Architecture, Color Themes, Preferences, and PyInstaller Distribution

This completes the Under the Hood series for V15.7

© 2026 Joseph P. McFadden Sr. All rights reserved.  |  McFaddenCAE.com