India validates its engineering decisions on software India does not own.

Walk into the engineering department of any serious Indian manufacturer and you will find people running structural, thermal or fluid analysis. Ask what they run it on and the answer is Ansys, or Abaqus from Dassault, or Simcenter from Siemens, or Altair, or Comsol.

All of those are American, French or German. There is no Indian equivalent at commercial scale.

I want to be careful here, because the strong version of this claim is false and gets repeated anyway. India does write solvers. ISRO, DRDO laboratories, NAL and several IITs have developed in-house computational fluid dynamics and finite element codes, some of them good and some in continuous use for decades on real programmes. The accurate statement is narrower: India has essentially no commercial simulation software industry, and the internal codes that exist have not become products used outside the organisations that wrote them.

That distinction is where the interesting question lives.

The market shape

The computer-aided engineering market is around 12 billion dollars in 2025 and projected to reach roughly 20 billion by 2030 at about 10 percent compound growth. The leading vendors, Ansys, Dassault Systèmes, Siemens, Altair, Hexagon and MathWorks, account for somewhere in the region of half the total between them.

Twelve billion dollars is small next to the industries that depend on it. Every aircraft, car, turbine, chip package and building designed in the last thirty years passed through this software. It is a small industry sitting at a chokepoint of very large ones, which is the same structural position as EDA in semiconductors, and it produces the same strategic exposure.

What building one actually takes

The reason there is no Indian Ansys is not that nobody can write a finite element solver. Plenty of people can. A graduate student can write one in a semester.

The distance from that to a product is where it stops.

The numerics have to be right for cases you did not anticipate. A solver that converges on your test problems and diverges on a customer’s geometry is worthless. Robustness across the space of real inputs comes from years of exposure to real inputs, which requires customers, which requires a product. This is a genuine chicken and egg problem and it is the main one.

The element and model libraries are enormous. Commercial codes carry decades of accumulated element formulations, material models, contact algorithms, turbulence closures and failure criteria. Each one exists because a customer needed it. This library is the actual asset and it cannot be shortcut.

Validation against physical test data is the whole credibility argument. A vendor’s benchmark suites are built from decades of correlating predictions against real experiments. Without that history nobody will certify a part on your output, and in aerospace or nuclear that is not a preference, it is a regulatory position.

Pre and post-processing is most of the user’s time. Meshing in particular. A brilliant solver with a bad mesher is unusable, and robust automatic meshing of arbitrary dirty CAD geometry is one of the genuinely hard unsolved problems in the field.

Integration. The solver has to read the CAD formats customers actually use, run on their hardware, fit their workflow, and interoperate with the rest of the toolchain.

The solver core, the part that is intellectually interesting and that an academic group can produce, is a small fraction of a product. The rest is the unglamorous phase that no research grant funds and no paper rewards, sustained for a decade. That is a capital problem before it is a technical one. A decade of unglamorous work needs somebody who will underwrite a decade, and India has almost nobody in that position pointed at this category.

Why the in-house codes stayed in-house

This is the part I find genuinely instructive.

The institutional codes were written to solve specific problems for specific programmes. They were validated for those regimes, documented for the people who wrote them, and maintained by whoever remained. That is entirely reasonable engineering.

Turning one into a product means generalising beyond the validated regime, writing documentation for strangers, building a mesher and a user interface, and committing to support and versioning for years. None of that advances the mission of a research laboratory, and no funding line exists for it. So the codes remain excellent internal tools, and the knowledge of how to build one stays inside the institutions rather than compounding into an industry.

The result is that India has repeatedly demonstrated the capability without accumulating it.

What the dependence actually costs

The licence fee is real and is not the point. Seat costs run into lakhs annually and constrain who can do simulation at all, which pushes small manufacturers and most colleges toward doing less of it than they should. That is a genuine cost and it is the visible one.

The larger costs are structural.

Export control exposure. Simulation software is dual-use and subject to export restrictions. Certain solvers and certain capabilities are not available for certain applications, and the availability is a policy decision made in another jurisdiction. What happened to Chinese access to EDA tools is the demonstration of what this looks like when it is exercised.

The physics you cannot modify. Using a commercial solver means accepting its models. If your problem needs a constitutive model, a material behaviour or a coupled physics the vendor did not implement, you either wait for them to want it or you work around it. For anything genuinely novel, and defence and space are full of genuinely novel, this is a hard ceiling. You cannot simulate a phenomenon your tool does not model, and you cannot see inside the tool to find out exactly what it did.

Capability that does not compound. A country that licenses tools accumulates users. A country that builds them accumulates people who understand numerical methods, discretisation, solver architecture and validation deeply enough to extend them. That second population is what lets you attack a problem nobody has a product for. It is built by writing solvers and by nothing else.

What would change it

Not a national mission to build an Ansys competitor. That fails for the reasons above.

Something narrower has a chance. Pick physics regimes where the commercial tools are weakest and the domestic need is strongest, which usually means coupled multiphysics, high-speed flows, specialised material behaviour, or the plasma and hypersonics regimes. Build there, where the incumbent library advantage is smallest.

Fund productisation as its own activity, distinct from research. The meshers, the documentation, the validation suites, the decade of support. This is the missing funding line and it is not a research grant.

Use the open ecosystem seriously. OpenFOAM, FEniCS, deal.II, Elmer, Code_Aster and others are real codes with real users, and contributing to them builds exactly the population of engineers described above at a fraction of the cost of starting over. The competitive gap is smallest here and the learning is the same.

And create the first customer. Every simulation vendor that survives had an anchor customer willing to tolerate an immature product because they needed the capability. In India that means defence, space or a public sector manufacturer deciding to use a domestic code on a real programme and accepting the friction.

The gap is not talent and it is not the solver core. It is the ten years after the solver core works, and the fact that nobody in the country is currently willing to fund them.

Related: