CAE Learning Center, Introduction
THE HOLISTIC ANALYST
FEA Best Practices
Learning Center Companion Reader
Joseph P. McFadden, Sr.
The Holistic Analyst
Combating Engineering Mind Blindness
2026
Contents
Introduction
Analysis Types
1. Modal Analysis — Frequency Extraction
2. Shock Analysis — Transient Dynamic
3. SRS — Shock Response Spectrum
4. Random Vibration — PSD Analysis
5. Harmonic Response — Steady-State Dynamics
Best Practices
6. Unit Systems — Consistency and Common Mistakes
7. Element Types — When to Use What
8. Material Definition — Properties and Pitfalls
9. Energy Balance — Validation in Explicit Dynamics
10. Mass Scaling — When and How
11. Drop Test Workflow — End-to-End Simulation
12. Contact Formulations — General versus Pairs
13. Bulk Viscosity — Shock Wave Damping
14. Hourglassing — Detection and Control
15. Mesh Convergence — Systematic Quality Assurance
The Analyzer
16. Reverse Engineering Parts — Reconstructing Structure from an INP File
17. Drop Impact Parameters — Determining Simulation Intent
18. Jerk and Fragility Assessment — Beyond Peak G
19. Output Requests and Post-Processing — Getting the Data You Need
20. Modeling Thin Brittle Materials — Glass and Ceramics
21. Millisecond Unit Systems — The Time Trap
Introduction
For more than four decades I have worked at the intersection of simulation and reality — first as an engineer trying to understand why physical tests contradicted my models, and later as a mentor watching the same confusion repeat itself in the next generation of analysts. The patterns never changed. Smart people, powerful software, wrong answers. Not because they lacked intelligence, but because nobody had ever clearly explained the foundation beneath the calculations.
But before we talk about what goes wrong, I want to talk about something more fundamental — something that explains why we simulate at all, and why it matters so deeply that we do it with understanding rather than automation.
We Are Built to Poke at Things
There is something in human nature that compels us to probe the world around us. Long before we were engineers, we were organisms trying to survive, and survival required a very specific kind of intelligence: the ability to determine, quickly and reliably, whether the thing in front of us was friend or foe, food or predator, safe or dangerous. We could not simply wait and see. Waiting too long had consequences. So we evolved to poke — to apply a small, controlled disturbance to an unknown system and read the response. Tap the rock to see if it moves. Rattle the bush. Press on the surface to test its strength. The response to that poke tells you something the appearance alone cannot.
And we never stopped. Consider how far we are from the savanna now, and yet the instinct runs as cleanly as ever. I am willing to bet you have, at some point in your life, made a sharp or slightly-too-loud noise in a room — a pointed cough, a chair scrape, a book placed just firmly enough on a table — not because you needed to, but because you needed information. Specifically, you needed to know whether the person across from you was listening or had quietly departed into sleep. In my case, that person was my dear wife, who had been graciously enduring what I can only describe as an extended personal lecture on the neuroscience of prediction. The noise was small. Calibrated. Deniable. And the response — a micro-flinch, a flutter of eyelids, a reply that arrived about half a second too late to be entirely convincing — told me everything I needed to know.
That is a poke. Ancient, instinctive, and still running in conference rooms and living rooms and lecture halls everywhere. The predator-or-friend calculation simply operates on colleagues and spouses now instead of things with teeth. What makes it interesting is that the poke only works as a test if you already have a model of the system. You know roughly what an awake person sounds like versus an asleep one. You are not probing blind — you are running a hypothesis. You predict this level of disturbance will produce a response if the system is in one state and not another. The response either confirms or refutes. You update accordingly.
We are, at our core, predictive machines. The brain does not passively receive information and then react to it. It continuously generates predictions about the world, compares those predictions to incoming evidence, and updates its model when the evidence surprises it. Every time we poke at something, we are running a small experiment: we predict the response based on what we know, we observe the actual response, and we revise our understanding based on the gap between them. This is not a scientific method we invented. It is the architecture of cognition itself, shaped by hundreds of thousands of years of selection pressure that rewarded accurate prediction and punished overconfident assumption.
Computer aided engineering is, at its most fundamental level, a manifestation of exactly this instinct. A digital poking machine. We build a virtual representation of a structure — encoding what we believe we know about its geometry, its materials, its connections — and then we poke it. We apply a load, impose a motion, define an environment, and we watch how it responds. The response tells us something the design drawing cannot: it tells us how the structure actually behaves when the forces arrive. It tells us where it is weak, where it is stiff, where the stress concentrates, where the energy goes. Every simulation is a poke. Every result is a response. And the quality of what we learn depends entirely on how well we understand both what we asked and what we were told.
This framing matters because it changes how you think about what simulation is for. It is not a calculation engine that produces answers. It is a tool for interrogating the nature of a design — for asking questions of a virtual structure that we could not afford, or would not dare, to ask of the physical one. The value is not in the number the solver returns. The value is in the understanding that builds when you know enough to ask a good question, interpret the response correctly, and recognize when the answer does not make sense.
Simulation tools have become extraordinarily capable. The software can solve problems that would have seemed impossible thirty years ago. But that capability comes with a hidden cost: the easier the tool makes it to get an answer, the easier it becomes to trust that answer without truly understanding where it came from. I call this engineering mind blindness — the gradual loss of the critical instinct that asks, before acting on a result, whether the answer actually makes sense.
The Abaqus INP Comprehensive Analyzer was built precisely to restore that critical instinct. It does not run simulations. It reads the instruction files that drive them — the INP files — and helps analysts understand what they have actually built, not just what they intended to build. It surfaces the assumptions buried in material definitions, the risks hidden in element choices, the unit system mismatches that silently corrupt results, and the energy balance violations that invalidate everything downstream.
This companion reader collects the audiobook content from the tool's Learning Center into a single reference. Each chapter corresponds to a topic that I believe every finite element analyst should be able to discuss with confidence — whether you are a student encountering simulation for the first time, an experienced engineer working a new problem type, or a designer trying to understand what the simulation report in front of you actually means.
The Philosophy Behind the Approach
My teaching philosophy is grounded in a simple conviction: simulation is not a black box you feed geometry into and extract answers from. It is virtual prototyping — a disciplined exercise in translating physical reality into mathematical form, solving that mathematical problem with known tools, and then translating the answer back into physical meaning. Every step in that chain introduces assumptions, approximations, and potential errors. The analyst's job is to know what those are, control them, and communicate them honestly.
The neuroscience of learning reinforces this. We do not absorb technical knowledge by passive exposure. We build it by prediction — forming an expectation, testing it against evidence, and updating our mental model when the evidence surprises us. That is exactly what a good simulation workflow does: build a model, predict what it will tell you, run it, be surprised by the discrepancy, and learn from the gap. The goal of this series is to give you enough conceptual foundation that your predictions are informed, so your surprises are productive.
I have also learned, the hard way, that the gap between the model and the test is not a failure. It is the signal. It is where the learning lives. The analyst who chases perfect correlation has usually given up on learning anything new. The analyst who treats every discrepancy as a question worth answering is the one who becomes genuinely better over time.
How to Use This Document
Each chapter mirrors a Learning Center topic in the Analyzer. The chapters are sequenced to build on each other — analysis types first, covering what kind of simulation to run and when, then best practices covering how to run it correctly. A short glossary appears at the end of each chapter. These are working definitions of the specific terms used in that chapter, written the way an analyst would use them in conversation.
Two additional chapters near the end cover topics specific to the Analyzer itself: how it reconstructs part and assembly structure from raw INP files, and how it infers drop impact parameters from simulation content when that information was not documented explicitly. Those chapters are written for analysts who want to understand what the tool is doing and why — the same transparency the tool itself is trying to provide.
A note on software references: where specific software keywords and syntax are discussed, they refer to Abaqus/Standard and Abaqus/Explicit. In the audio recordings these are pronounced as "Abacus" for text-to-speech compatibility. In this printed document the proper spelling is used throughout.
McFadden@snet.net · www.McFaddenCAE.com
*** Full text, available for download: https://www.dropbox.com/scl/fi/5h0bkr5g4juekz64kh87y/FEA_LearningCenter_Reader_v4-McFadden-29March2026.pdf?rlkey=pnf0rgbxdeipx32qfe1qsmdyz&st=22gjx4m9&dl=0
