Disclosure: Shawn Wasserman is a former employee of Ansys Inc. who owns minor Ansys company stock.

A recent Ansys Blog post announced PyAnsys, a family of open-source Python scripts, available on GitHub, which are capable of interfacing with the proprietary stack of much of Ansys’ portfolio.

According to an Ansys spokesperson, “PyAnsys gives the Python developer ecosystem the ability to access simulation software from Ansys in new ways. There are already great examples of how Python is being employed within the broader scientific community—this presentation (linked here) from an outside speaker gives a good overview of some different use cases. This technology has also proven useful in key areas like Machine Learning and Artificial Intelligence which are increasingly important in the simulation space.”

A stress plot shown on the PyAnsys GitHub documentation site. (Image courtesy of Ansys.)

If this software family was being shared across the Ansys community, I likely wouldn’t be talking about it. It isn’t unusual for companies to produce new ways for third party software to interface with their proprietary software—which is the clear goal behind PyAnsys. This is the whole reason why application programming interfaces (APIs) exist—they help different software talk to each other.

“The approach behind PyAnsys has always been to plug into the Python ecosystem and enable the customer to use ‘the best of both worlds,’” said the Ansys spokesperson. “The intention is to extend powerful Python tools by allowing customers to pick and choose the machine learning, data visualization, post-processing

and optimization libraries that have really inspired the scientific, and now the engineering community. The goal of PyAnsys has never been to replace our products but to extend them in the most helpful way possible; making them adaptable to the unique needs of our customers.”

Engineers comment on the features of PyAnsys. (Image taken from LinkedIn on 10/21/2021).

However, the fact that the software is being shared on GitHub, and is labeled as open-source, has sparked a heated debate between engineering professionals about the nature of open-source software, and the niches engineers can fill to democratize simulation technology.

The Open-Source Debate Rooted in the PyAnsys Announcement

So, what is open-source and why should simulation experts care? According to Red Hat, known for their version of the open-source Linux operating system, “open-source is a term that originally referred to open-source software (OSS). Open-source software is code that is designed to be publicly accessible—anyone can see, modify and distribute the code as they see fit.”

Engineers debate the open-source nature of PyAnsys. (Image taken from LinkedIn on 10/21/2021).

Red Hat argues that because open-source software is decentralized and collaborative, a.k.a. made by a community instead of a company, it is often cheaper, more flexible and has a longer lifespan. In that sense, open-source is less about the software itself and more about an ideology.

“Open-source has become a movement and a way of working that reaches beyond software production,” Red Hat argues. “The open-source movement uses the values and decentralized production model of open-source software to find new ways to solve problems in their communities and industries.”

Engineers continue to debate the open-source nature of PyAnsys. (Image taken from LinkedIn on 10/21/2021).

Open-source software has become the backbone to many of the cloud and HPC tools used within the simulation toolbox. There are also open-source simulation software options available—perhaps most famously OpenFOAM.

Engineers debate how PyAnsys competes with OpenFOAM. (Image taken from LinkedIn on 10/21/2021).

The major stumbling block within the online debate seems to be that, though PyAnsys is being defined as open-source—in that it’s code is open to view, use and modify as engineers need—the fact remains that the only way to make PyAnsys useful is to purchase closed-source software by Ansys. This bumps up against the philosophy held by much of the open-source community, especially when there are already fully open-source simulation software options available, such as ESI-OpenCFD’s OpenFoam.

Engineers argue if PyAnsys is worth it. (Image taken from LinkedIn on 10/21/2021).

Know Thy Audience: Who is PyAnsys For? Will They Use It?

Alex Kaszynski (seen within the online debate) is the driving force behind PyAnsys. In 2016, he was an Ansys user who shared Python language to the open-source community which used Python to pilot the Mechanical APDL solver. Now he’s working for Ansys and is part of PyAnsys team working on:

PyMAPDL: a Python interface to Ansys’ multiphysics solvers.
PyDPF-Core: a data-processing framework that can read and transform simulation data.
PyDPF-Post: a tool to assess simulations using a simplified post-processing interface.
PyAEDT: a Python library that interacts directly with Ansys Electronic Desktop (AEDT) API.

Clearly, with Kaszynski on the team, this project has its start in the open-source world. With the life of this project beginning in the open-source community, there must be some hunger for these types of tools.

That hunger shows itself within the debate online, as there was clear excitement from some users about using PyAnsys as a means for the open-source community to optimize the Ansys workflow.

There is interest in the use PyAnsys to improve the Ansys Workflow. (Image taken from LinkedIn on 10/21/2021).

However, I think there is a good chance that this niche area of the open-source community will be the only users of PyAnsys. Without access to the Ansys suite of solvers, which requires a valid license to its closed-source technology, there isn’t much of a use for this open-source code.

For those within that niche community, though, PyAnsys could be the first step towards a community of developers creating custom simulation solutions for specific tools and tasks. The closest example in the industry I can think of is the COMSOL App Builder, which is a tool engineers can use to ‘appify’ their simulations so that non-simulation experts can utilize them.

COMSOL’s solution has streamlined the creation process of these apps, making it easier for non-programming experts to produce simulation tools that tap into COMSOL solver technology. In contrast, PyAnsys offers engineers all the freedom of Python with the trade-off that developers need to know how to code to produce what they want.

Another difference between the two options is that the COMSOL App Builder enables engineers to package their apps in a way that the end user doesn’t have to be a COMSOL user. In other words, people who use the app may not need any licenses for COMSOL software. Ansys, however, has chosen to limit the scope of the people who can utilize the applications produced using PyAnsys to those that already have Ansys licenses.

Will this hold the technology back? Probably, to a certain extent. But at the end of the day, there will be users interested in molding Ansys workflows to their own preferences and niche applications. Perhaps this will even help democratize simulation so that others without much simulation experience can also use the technology.

The question remains, will limiting the scope of PyAnsys’ users prevent the critical mass needed to keep a healthy community on GitHub? Share your thoughts in the comments below.