There's a particular kind of frustration that shows up in hardware engineering and almost nowhere else. You can see the problem. You understand the physics. You could sketch the answer on a whiteboard and defend it in a design review. And you still can't get the number, because getting the number means driving a simulation tool you've never had six uninterrupted months to learn. It is a familiar ritual for any engineering team: managing four separate simulation packages, where each domain requires its own specialized dialect of technical expertise just to work through the different simulation products.

Steve Markus, a staff mechanical engineer at Peak Energy, described it more precisely than most:

"Even though I can explain in plain English what I want to do, and I can actually interrogate simulation results, I can picture everything in my head, but there's a barrier to entry with simulation that is a very high barrier."

Peak Energy is building grid-scale battery storage on sodium-ion chemistry, chasing a goal Steve states without hedging: "We are building the cheapest electron to store on the market." Steve owns the battery module. Depending on where the program sits, his week is design work, simulation, testing, or supporting the production ramp, which means he runs into every constraint in the development cycle personally, usually more than once.

This is the story of one of those constraints, and what happened when it came down.

TLDR:

• Generalist engineers at hardware startups routinely skip complex simulations, not because the physics is unclear, but because tool setup is a specialist skill

• Simulation demand is peaky: high during development, low during production ramp, which makes hiring more analysts a hard case to defend

• A two-stage thermal-then-structural simulation, chained and run in plain English, cut setup time from 1-2 weeks to 1-2 days

• Pre-test simulation on runs costing tens of thousands of dollars changes the odds you're taking before committing budget and schedule

• Cosmon gives Peak Energy's generalist mechanical engineers access to multi-physics simulations they previously could not attempt, across Ansys, Abaqus, COMSOL, and Star-CCM+

Two kinds of engineer, one queue

Peak Energy's mechanical engineering org splits, as most do, into generalists and simulation specialists. The generalists are fluent in the physics. What they aren't fluent in is the software.

"Usually the rigor level of generalist mechanical engineers in simulation is pretty low. Like, I could run a basic FEA simulation on a snap fit or something like that. But to do anything more complicated would either take me a lot of time to learn, or just be simply impossible."

That gap produced exactly two outcomes, and Steve is blunt that neither was acceptable:

"The result of that was either the engineering or simulation work was not done, or it was put on one of those simulation analysts or experts, which increases demand for them, reduces their bandwidth."

Worth pausing on the first iteration. It’s just NOT DONE. Not delayed, not simplified; skipped. Analysis that would have improved a design quietly never happened, because the cost of getting it was too high relative to the analyst's calendar. That's the invisible tax, and it doesn't show up on any dashboard.

The second branch has its own arithmetic. Every generalist question routed to a specialist consumes specialist bandwidth that was supposed to be spent on genuinely hard problems. The queue lengthens. The hard problems wait.

And this isn't a seniority issue that fixes itself as engineers mature:

"Whether you're a new grad, generalist mechanical engineer, or a pretty senior one, often they are all on the same playing field in terms of FEA. So I think it's equally applicable across every experience level."

You can't hire your way out of a peaky problem

The obvious fix is more analysts. It breaks down when faced with the realities of startup or large organization budgets and the natural flow of the work.

"Especially in a resource-constrained startup environment like we're in, and many other hardware companies are in, there's a constant tension between bringing on more analysts and just having engineers do work, or testing, or finding some other way around running extra simulations."

Then he named the thing that makes the headcount math impossible:

"The simulation work is often peaky. A lot of time in upfront development you need a lot of horsepower for a simulation, but maybe in production you don't need it as much. So it's hard to defend a full-time headcount for that."

Peaky. Demand spikes hard during development and falls away during ramp. You can staff for the peak and carry expensive idle capacity through production, or you can staff for the trough and ration analysis exactly when the program is deciding everything that matters. Most hardware teams pick the second, then live with it.

Steve was clear this isn't a Peak Energy quirk: "We're definitely not alone in that, and we were looking for a solution."

The trial

The requirements list was refreshingly short. Steve wanted "performance and hands-off ability, plain English interface," and above all ease of adoption. What separated it from the alternatives was that it met the team where it already worked. Peak Energy runs Ansys as its primary tool, with Comsol, Abaqus and Star-CCM+ across other domains, and Steve's read was simple: "There was no tool that could better plug and play with our existing simulation suite."

The rollout was less of an event than these things usually are:

"What was pleasantly surprising is how easy it was to adopt. It's an LLM interface, so at worst, if you don't know how to do something, you can talk to it and it would explain. That eliminates the need for a giant how-to guide. You gave us a walkthrough, maybe that was an hour at most, and we were kind of off to the races."

Two weeks later the question had answered itself: "After a the two-week trial it was pretty clear that it could provide value, and ever since then everybody's been using it."

Steve brought it in himself, folding it into an existing company effort to find AI tools worth keeping, and he applies a filter to that category that's worth quoting in full, because it's the filter every engineering team should be applying:

"AI is really cool, but what AI tools actually make practical impact on our day-to-day operations? What can save me days or weeks? A lot of tools sound really cool… but something like this can both save me time and actually meaningfully de-risk our program."

Simulating twenty years of cycling

The idea is to compress two decades of battery cycling in the field into a window short enough to learn from. These tests are, in Steve's words, "really heavy and expensive tests to run. Resource-intensive tests to run, I should say, whether it be people or time or cost."

Which creates a nasty ordering problem:

"It's often the test that lags most, which leaves you open to serious risks."

The test that would tell you whether your design survives twenty years is the one that arrives last. Until it lands, the risk just sits there, accumulating against a delivery date.

Running the two-stage simulation

The failure mode Steve needed to understand was a busbar cracking under repeated thermal expansion and contraction. Answering that question in simulation is not a matter of pressing a button. It means chaining two physics domains: running the thermal problem first, matching that stage against real test data so you can trust it, then feeding the result into a structural analysis to see what the mechanical stresses actually do.

"I was able to run a part-level thermal test to understand: okay, what does the heat map on this part look like in our cycles? And then I was able to have Cosmon run this two-part simulation where it first cycled to the current levels I was seeing, and I was able to match just that thermal cycling, the temperature aspect of this simulation, to the tests. So I had a matched stage one. And then stage two was: okay, look at the mechanical stresses that come as a result."

And then the line that explains the whole thing:

"That's something where I knew exactly what I was looking for. I knew all the inputs, the outputs I wanted. I just wouldn't know where to start in actually setting up a simulation like that that's thermal, then structural."

The engineering judgment was never missing. Steve knew the load case, the material, the failure mode, and what a trustworthy answer would look like. What he lacked was the tool fluency to translate that into a matched multi-stage simulation, and that turns out to be a substitutable skill in a way engineering judgment never is.

What it looks like day to day

Every generalist mechanical engineer at Peak Energy has access now, alongside the specialists. Steve splits his own usage down the middle:

"We either use it as a quick way to upstart a simulation that maybe we could do ourselves otherwise, but it just minimizes the button clicking, all the setup, things like that… I'd say 50/50-50% of the time it's that, 50% of the time for me it's actually starting up a simulation that I've never been able to do before."

That second half is the interesting one. It isn't acceleration, it's access. Work that previously had no path at all now has one.

Around those two modes, other habits have formed. He debugs existing simulations with it. He runs quick theoretical iterations, generating a fuse curve, taking mass out of a part, where before "the iterations would be slow churning manual simulations." And he's found it unexpectedly good at failure analysis: when a die-cast part started showing porosity partway through a production batch, he worked the problem conversationally, walking through the environment, the material, how the part is made, and which process parameters might be driving it. Having the load case already in context is what makes that different from a generic chat window: "with the context of the load case, in Cosmon's case, that's especially helpful."

The capability he's most curious about is the newest one, the agentic desktop experience, where the tool iterates on a simulation on its own:

"That's been really, really nice, to just be like, explain to it in plain English what the simulation is, and be hands-off until you see results."

What actually changed

Ask Steve for numbers and he's careful, which is what makes the ones he does give worth something.

On time:

"I can run simulations with Cosmon's help in a day or two that might take me a week or two at least to run if I had to try it on my own. So I totally believe it could save weeks of engineering time."

On who does the work:

"It does democratize the ability to run simulations, so our experts can spend more time working on truly expert-level challenges, whereas the lower, medium or lower level simulations can now be executed by generalists. That relieves the time pressure on our experts to take care of everything."

He hesitated on that word. "I hate the word democratize," he said, before using it anyway, because it's the accurate one. The queue didn't get faster. The queue got shorter, because most of what was in it left.

The step change, in one sentence:

"Now it's common for any generalist to be able to run a simulation that they wouldn't have been able to do a few months ago."

Schedule and cost impact

And on money and schedule, the part a CFO would care about:

"It gives us much higher confidence in our ability going into a test that may cost tens of thousands of dollars to run. So we make that money count more, and it's less risky money spent."

"It allows us to gain much more theoretical confidence in our designs working, or passing a test, before actually running the test. So that has a marked impact on our schedules, our risks going into tests, and ultimately our delivery timeline."

Read those two together and the value stops being about simulation at all. A physical test is a bet. Simulation before the test doesn't eliminate the bet, but it changes the odds you're taking. On a program where every test slot is contested and every slipped test pushes a delivery date, better odds compound.

Among every AI tool Peak Energy has evaluated, it's the one that stuck with the engineering team:

"We do have broader connectivity to all those ancillary services, whether it's Outlook, Jira, Confluence, you name it. But for mechanical engineers specifically, it's definitely the most impactful… it's the only AI tool we've consistently adopted, and it is extremely impactful."

What's next

Asked where he'd point this if he could point it anywhere, Steve didn't say faster solvers. He said DFMEA, the design failure mode and effects analysis that sits at the front of every hardware program and runs on nothing but human attention:

"If you've ever sat in a DFMEA, it's so many hours. That's the prime opportunity for humans to make errors, and that can have major impacts if you don't catch that error and it makes it through into production. So generating a DFMEA and running, whether it's simulations, or ingesting and managing a test campaign to verify these risks, that would be huge."

It's the same instinct that led him to the PTCE simulation. Find the place where the engineering thinking is sound but the mechanics are slow and error-prone, and take the mechanics off the human.

His summary of where the whole effort points:

"Hopefully it all leads to a faster and more reliable product development lifecycle… all of it's aimed at reducing the time, increasing the effectiveness, and reducing risk of the product development."

FAQ

Can a generalist mechanical engineer run a two-stage thermal-structural simulation in Ansys or Abaqus without specialist support?

Yes, provided the engineer already understands the physics and can specify the inputs and outputs they need. What Cosmon handles is the setup mechanics: chaining the thermal stage to the structural stage, configuring boundary conditions, and matching results against test data, so the engineer who knows the load case can run the analysis without needing specialist fluency in the software.

What's the fastest way to de-risk an expensive physical test on a battery module before committing budget?

Run a matched simulation first. At Peak Energy, Steve Markus ran a thermal-then-structural simulation in Cosmon that matched the thermal stage against real test data before passing results into the structural analysis, all in one to two days. That validated simulation gave the team higher confidence before committing to a physical test costing tens of thousands of dollars, which changes the odds on every test slot and every delivery date downstream.

How does Cosmon work across Ansys, Abaqus, COMSOL, and Star-CCM+ without requiring a separate tool for each?

Cosmon connects to each solver through a plain-English interface rather than replacing them, so it meets the team inside the tools they already run. Peak Energy's engineering org spans all four packages, and Steve's assessment was straightforward: no other tool could plug into their existing simulation suite across all of them.

Should I use Cosmon for simulation setup or failure analysis, or does it handle both?

Both, and the value compounds when they share context. At Peak Energy, Cosmon is used roughly half the time to accelerate simulation setup that engineers could eventually do manually, and half the time to run analyses that were previously out of reach entirely. For failure analysis, having the load case already in context, as Steve found when working through a die-cast porosity problem, is what separates it from a generic chat window.

How long does it take for an engineering team to get productive with Cosmon?

Peak Energy's team was running simulations after roughly an hour of walkthrough. Because the interface is conversational, engineers can ask it to explain an approach if they're unsure how to proceed, which removes the need for a training guide. Within two weeks of the trial, the team had a clear answer on whether it was worth keeping.

Before and after

We asked Steve to fill in the blanks: before Cosmon we were ___, now we're ___.

"Before Cosmon we were manual, with humans constantly in the loop. And after Cosmon, we are automated, fast-paced and de-risked."

Asked to compress the business impact into one line, he gave us four words: "Reduced schedule and risk."

And asked whether he'd tell an engineer at another hardware company it was worth it:

"Yeah, absolutely. Saves time and de-risks all of our design work."

His own headline for this story, offered unprompted, is better than anything we would have written:

"Level up your simulation capabilities and eliminate the barrier to entry of complex simulations."

Cosmon gives hardware engineers a plain-English interface to the simulation tools they already own, so the engineer who understands the problem is the one who can run the analysis. [Talk to us about your team's workflows.]