A simulation engineer spends an afternoon trying to automate a repetitive meshing or boundary-condition task — something they've done manually fifty times — and discovers that doing it programmatically requires writing TCL or Python against an undocumented API, reading forum posts from 2011, and reverse-engineering what a recorded macro actually did. That's the moment they start searching for a better path.
The gap persists because CAE vendors sell to enterprise procurement teams, not to the individual engineers who fight with macros daily. The vendor's incentive is to add simulation physics features that justify license renewals — scripting ergonomics are an afterthought. And because the users who suffer most (mid-level FEA or CFD engineers) aren't the ones signing the checks, their complaints don't carry budget weight. So the documentation stays thin and the macro syntax stays arcane.
What's actually missing is a layer that sits between the user's intent and the raw scripting interface: something that records actions as reusable, editable steps — not as opaque generated code — and lets engineers parameterize those steps (swap load values, change materials, loop over geometries) without writing a single line. The complaints about 'lesser element level control' and 'interpolation functions not so easy' point to a deeper issue: users want to automate at the level of concepts (apply this pressure to these face groups, iterate over these thicknesses), not at the level of API calls.
This is a business and not a feature because the need recurs every time a new project starts, every time a junior engineer joins a team, and every time a workflow needs to be handed off. Without it, teams either waste hours each week re-doing manual steps or hire a dedicated scripting specialist — a real, measurable cost that shows up in project timelines.
What to build
Build a desktop application that sits alongside Ansys Mechanical and Altair HyperMesh, records user actions into named, parameterizable workflow steps (not raw script), lets engineers edit those steps in plain language with a visual parameter table, and exports runnable macros in the target tool's native scripting language.
Where to start
Start with Ansys Mechanical specifically, where APDL is the known baseline and users explicitly complain that newer interfaces are harder to script than the legacy system — that's a named, searchable frustration with an existing community of engineers actively looking for relief.
The hard part
Each CAE tool has its own undocumented or partially documented scripting API, so supporting even two tools properly requires deep reverse-engineering work on each one — the first version will feel incomplete to any user who works across tools.
How it makes money
Annual per-seat license priced below a single day of consultant time (roughly $400–900/year), with team plans that add shared macro libraries and version history.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Simulation & CAE.
More ideas in Simulation & CAE