After 4 Years and 1,000 Model Iterations, I Lost Everything — So I Built a Fix
After 4 Years and 1,000 Model Iterations, I Lost Everything — So I Built a Fix
When BEV3 project wrapped up after four years, I sat down to clean up my hard drive.
What I found was a graveyard.
Thousands BDF files. Names like BIW_v3.bdf, BIW_V11.bdf, front_knuckle_v10.bdf. Some folders dated back to year one, containing models I had completely forgotten about. Storage was running low, so I did what every engineer eventually does: I started deleting.
And as I dragged files to the trash, I felt something uncomfortable — I wasn’t just freeing up disk space. I was erasing four years of engineering decisions.
The Real Cost Nobody Talks About
Every one of those files represented a question someone had asked, a hypothesis someone had tested, a failure someone had learned from.
Why did we increase the shell thickness here? When did we add a feature there? Which mesh density did we benchmark against the test data?
Nobody could answer those questions anymore. Not because the models were gone — many of them weren’t — but because without context, a BDF file is just a text file. There’s no timestamp on a decision. No record of intent. No way to compare version 47 against version 312 without opening both files side by side.
These weren’t just files. They were intangible assets — the kind that take years to accumulate and seconds to lose. And in an industry where simulation know-how is a competitive advantage, losing that institutional knowledge quietly is an enormous cost that never shows up on any project budget.
The Inspiration Came from an Unlikely Place
I’m a structural engineer by training. But I’ve spent enough time around software developers to notice something: they solved this problem decades ago.
It’s called version control. Git, specifically.
When a developer changes a line of code, that change is recorded — what changed, when, who made it, and why, if it is documented well. You can travel back to any point in the project’s history. You can compare two versions side by side and see exactly what’s different. You can branch off to test an idea without corrupting the main model.
FEA models are, at their core, just structured text files. A Nastran BDF is a sequence of cards — GRID, CQUAD4, PSHELL, MAT1 — all human-readable, all diffable. So why weren’t we treating them like code?
The answer, I think, is that no one had built the right tool. Generic Git works on BDF files technically, but git diff on a BDF gives you raw line changes — not “node 1042 moved 2.3mm in the Z direction” or “shell thickness changed from 1.5mm to 2.0mm on part SKIN_UPPER”. The semantics are lost.
So I decided to build something that understood BDF files the way a structural engineer does.
Building bdfDiff: Where Domain Knowledge Meets Code
I’ll be honest: I’m not a software engineer. Four years ago, building a full-stack web application would have been far outside my reach.
What changed is AI-assisted development. With tools like Claude, I could move from idea to working prototype at a pace that matched my thinking. The domain expertise — understanding what a BDF card means, what makes a mesh change structurally significant, how engineers actually review model differences — that was mine. The AI helped me express that knowledge in code.
The result is bdfDiff: a Git-inspired visual diff tool for Nastran BDF files.
It does a few things I always wished I had during that four-year project:
Card-level comparison. Not just line diffs — actual semantic understanding. It tells you that PSHELL 12 had its thickness modified, or that 47 new GRID nodes were added in the left wing region.
Git integration. Connect it to a repository of BDF files and browse the full commit history. Every model iteration becomes a traceable, searchable record with a timestamp and a commit message.
Visual side-by-side diff. Color-coded comparison of two model versions, filterable by card type. Spot a GRID change without scrolling through thousands of lines.
3D visualization. See where nodes moved, which elements were added or deleted — spatially, not just textually.
What This Actually Changes
Imagine ending a four-year project and being able to answer:
- “Here’s the exact commit where we changed the boundary conditions after the first test failure.”
- “We evaluated three different mesh densities — here are the comparison reports.”
- “The decision to switch materials in subcomponent B was made in month 18, documented here.”
That’s not just convenient. That’s institutional knowledge made permanent. It’s a project debrief that writes itself. It’s onboarding material for the next engineer who inherits the model. It’s a record that has real value to the company long after the project closes.
The 1,000 files don’t need to be a burden. With the right tooling, they become an archive.
What I Learned Building This
The engineering insight wasn’t hard — I’d lived the problem for many years. What surprised me was how transferable the concept is. Version control is a solved problem in software. The gap was just a bridge layer that understood the domain.
bdfDiff is still a work in progress — it handles small to medium models well, and I’m treating it as a learning project for now. But the core idea is solid, and the pain it addresses is real.
If you’ve ever deleted a BDF file you later wished you hadn’t, you know exactly what I mean.
The project is open source. You can find it on GitHub. I’d genuinely like to hear how other FEA engineers manage model versions