I’ll be honest, I didn’t wake up one day and decide I wanted to be a simulation engineer. It happened the way most good things in a career do: gradually, then all at once.
It started with a genuine obsession with understanding why things break. Not just that they break, but the exact moment, the exact location, the exact reason. I studied Mechanical Engineering at the University of Utah, and somewhere between the stress-strain curves and the fluid dynamics coursework, something clicked. The math wasn’t abstract to me. It was a window into what was actually happening inside a part under load, inside a channel with flow moving through it, inside a system being pushed beyond what its designer intended.
My early career was spent in the trenches, helping engineers run studies, troubleshoot models, and figure out why their results didn’t match reality. And that’s where the real education happened. Not in a classroom. In the grind of real problems, real deadlines, and real consequences, when the analysis was wrong.
Later, working in the medical device world on products like Inovio’s CELLECTRA 3PSP, an electromechanical device at the front lines of some serious clinical work, I felt the full weight of what simulation actually means. When the device you’re analyzing is going to be used on a patient, “good enough” doesn’t exist as a concept. Every boundary condition matters. Every material property has to be validated. Every assumption you make needs to be documented and defensible. That experience changed the way I think about simulation permanently.
And all of that, every late night, every convergence failure, every moment of getting it right, is what eventually brought me to Dassault Systèmes, where I now work as a Senior Industry Process Consultant for Simulation. These days I don’t just run simulations. I make content, help engineers, sales teams, and partners understand how to think about simulation, use it effectively, and get the most out of the tools that make it possible.
The Morning Ritual: One Dashboard, Many Worlds
My day doesn’t start with emails. It starts with the 3DEXPERIENCE Platform.
I open my dashboard and within about thirty seconds I have a real pulse on everything happening. Demos I’m building, customer engagements in progress, partners who need technical enablement, content I’m developing for the field. There might be a sales engineer who needs backup on a structural simulation pitch. A partner working through a non-linear FEA problem with a customer. A medical device company trying to figure out how simulation fits into their design validation workflow. It’s all there, visible, connected, in one place.
That might sound like a small thing. It’s not. Before platforms like this existed, that same morning would have started with 15 emails, 3 different file locations, and genuine uncertainty about which version of anything was current. The 3DEXPERIENCE Platform doesn’t just organize your work, it changes how you think about collaboration, because the chaos that used to eat the first hour of every day just… isn’t there anymore.
What the Day Actually Looks Like
People who haven’t worked in simulation sometimes picture it as punching in some numbers and watching a colorful stress plot appear. I wish. The reality is that simulation is one of the most deliberate, judgment-heavy disciplines in engineering, and I mean that as a compliment.
A typical morning might start with setting up a linear static analysis. Sounds straightforward. But the setup is everything. You’re choosing how to represent real-world constraints mathematically. You’re deciding what simplifications are valid and which ones will corrupt your results. You’re making mesh decisions that balance solve time against accuracy. Too coarse and you’ll miss the stress concentrations that actually matter. Too fine and you’ve burned an hour of compute time to get the same answer you could have gotten with a smarter approach. Every decision has a reason, and a good simulation engineer knows what that reason is before they make it.
By mid-morning, it might shift into non-linear or dynamic territory, contact between mating parts, impact criteria, large deformation in a flexible component, and material behavior past the yield point. Non-linear analysis is a different beast. The solver doesn’t just solve; it iterates, and you have to manage that process. Understanding when a solution is struggling to converge and why, knowing which solver settings to adjust and which to leave alone, recognizing when your model setup is the problem versus the physics being genuinely complex, that’s the kind of thing that takes years to develop and can’t really be taught from a manual.
In the afternoons, I often shift into my CFD zone. I’ve run flow simulations across wildly different applications, from electronics cooling to fluid delivery in medical devices to aerodynamic studies in motorsport. What SOLIDWORKS Flow Simulation does well is make that transition accessible and easy. The tight integration with the CAD geometry means changes propagate naturally. You’re not re-importing, re-meshing from scratch, re-defining boundary conditions every time a designer tweaks a channel width. The parametric link is live. And now, with the SOLIDWORKS CFD Engineer role on the 3DEXPERIENCE Platform, that workflow has genuinely leveled up. The guided setup experience changes how you approach a fluid problem, especially when you’re under deadline pressure. And with the high-powered cloud-computing power behind it, you’re not constrained by the machine under your desk anymore.
By late afternoon, the simulation tools have shifted again. If there’s a plastics project in the queue, I’m in SOLIDWORKS Plastics, analyzing how molten material fills a mold cavity, where weld lines are forming, whether sink marks are going to show up on a cosmetic surface, whether the gate location makes sense or if we’re setting the manufacturing team up for a headache they won’t discover until the first tool trial. Injection molding has a reputation for being unpredictable, but a well-run plastics simulation takes a lot of that mystery out of the equation before a single dollar is spent on tooling.
And if the afternoon has a little breathing room? I’m probably on YouTube. Not just watching, but also creating. A quick screen capture walkthrough of a SOLIDWORKS Plastics workflow, a quick tip on reading a fill analysis result, something that a design engineer who’s never thought about gate design might stumble across and suddenly find incredibly useful. That kind of content doesn’t take long to make, but it has a reach that a demo in a conference room never will. There’s something deeply satisfying about putting something out into the world that helps an engineer somewhere solve a problem they didn’t even know simulation could address. That’s the job too, maybe more than people realize.
The Part Nobody Talks About: Being Organized Before You’re Right
Here’s something they don’t put in the job description but absolutely should: before a single solver iteration runs, a simulation engineer has to be ruthlessly, almost obsessively organized.
The setup is the work. Get that wrong, and the most powerful compute cluster in the world will confidently hand you the wrong answer. And the scary part? It’ll look completely believable.
So before I hit solve on anything, there’s a mental checklist that runs. Are units consistent throughout the study? Are the material properties from a validated source, or did someone paste in a number from a datasheet without tracking its source? Are the fixtures actually representative of how this part behaves in the real world, or did I over-constrain it because it was easier? Is the load applied to the right face, the right direction, the right magnitude? Did I run a mesh convergence study, or am I just trusting the default and hoping for the best?
These aren’t edge cases. These are the questions that separate a simulation that means something from one that looks convincing but quietly lies to you.
Organization also means keeping studies named, structured, and annotated so that six months later, or when someone else picks up the file, the intent is still obvious. What was the load case? What was being validated? What was the conclusion and why? A simulation study with no context attached is almost as dangerous as no simulation at all.
And when something does go wrong, when results look off, when the model won’t converge, when the stress plot is screaming at a location that makes no physical sense, the organized engineer has a trail to follow. They can isolate variables. They can rule things out one by one. Troubleshooting a simulation without that discipline is like debugging code with no comments, in the dark, under pressure.
But when you’ve done it all right, when the boundary conditions are solid, the mesh is dialed in, the material data is verified, the study is clean and fully traceable, that’s when it happens. The solver runs, the results come in, and everything just makes sense. The deflection goes exactly where physics said it should. The stress concentrations appear right where your gut told you to look. The flow separates at precisely the geometry feature you suspected. That moment, that quiet confirmation that the virtual world and the real world are aligned, is the sweet symphony every simulation engineer is chasing. And I’ll tell you, after all these years, it never gets old.
The Conversations That Matter Most
A big part of what I do now is still running simulations, but I also help people understand how to think about them in product development.
That might mean sitting with a sales engineer and translating deeply technical FEA capability into language that resonates with a VP of Engineering who has a product launch in six months and a budget conversation next week. What does catching a failure mode in simulation, before tooling is cut, actually mean for the business? What does a 20% reduction in physical prototypes do to a development timeline? These are the questions that connect the technology to the decision.
It might also mean working with a customer’s engineering team who are technically strong but new to the 3DEXPERIENCE environment, helping them build workflows that fit how they actually work rather than forcing them to change everything at once. The platform is powerful, but the value only shows up when the workflow makes sense for the people using it.
What makes those conversations work is having actually done the work. Having made the wrong assumption about a boundary condition. Having run a study that looked great and was fundamentally broken. Having been in the room when simulation results caught something that would have been catastrophic downstream. That lived experience is what makes the technical credible and the business case real.
Where This Is All Heading?
The simulation landscape is moving faster right now than at any point in my career. AI-assisted meshing, cloud-based HPC that puts serious compute in the hands of teams that never could have afforded an on-premise cluster, generative design workflows that use simulation as the optimization engine rather than the validation step at the end — these aren’t things on a roadmap. They’re here.
What excites me most is that the barrier to doing genuinely good simulations is coming down. Not because the engineering rigor is being bypassed — if anything, the expectations are higher — but because the platform handles so much of the infrastructure and workflow complexity that used to consume an engineer’s time before they could even get to the interesting physics.
The tools are smarter. The platform is more connected. And the engineers who learn to use them with the same precision and discipline the work demands are going to build things that simply weren’t possible before.
That’s still the part of this that gets me going every morning. And honestly, I don’t see that changing anytime soon. Learn more by clicking the banner below.
