![](https://www.digitalengineering247.com/images/article/pyansys_image.png)
Left: An exhaust manifold mesh post-processing using PyFluent. Right: PyFluent post-processing showing an iso-surface of the velocity of flow in an exhaust manifold. Images courtesy of Ansys.
November 30, 2022
Configuring and running simulations, and then sharing the results, can be a time-consuming process. For engineers involved in projects like autonomous vehicle development that may involve thousands of simulations, manually managing those tasks would be impossible.
Ansys developers have addressed this challenge using PyAnsys, a family of Python packages that let engineers script multiphysics simulations, as well as scripting workflows and other automated operations that incorporate multi-physics simulations.
PyAnsys emerged from the Ansys end user community thanks to Python developer and Ansys MAPDL user Alex Kaszynski. Ansys not only hired Kaszynski, but has greatly expanded its support of Python across multiple products and offering PyAnsys packages on GitHub. We recently spoke to Chris Harrold, Developer Experience Program Director at Ansys, about the companys expanding support for Python. You can also read more about PyAnsys in this recent blog.
DE: PyAnsys allows developers to integrate Ansys-based simulation into Python projects. How does this benefit your customers? What problems does this solve for them
Harrold: That falls into two buckets. There is a workflow where you are creating an enhancement or extension. Very rarely are you doing a single set of physics per simulation, and there is a need to extend that workflow or that multiphysics capability to pass data among different simulation engines. You want to control that or manage that in a bespoke way for your specific set of criteria or workflows.
Second, you can also start thinking about the ability to do more programmatic-driven simulation. If you want to simulate a thing thousands of times, if you do not have that programmatic access to set up the parameters and set up the simulation so you can just hit go and walk away, it becomes prohibitive to get the volumes of data you want.
Across all PyAnsys users right now, this is just a scale thing, a sheer volume problem that they cannot possibly cram enough simulations into 24 hours without that programmatic approach.
DE: PyAnsys emerged organically from the user base, right?
Harrold: It actually started with a group of developers, both internal and external, who are now all internal. We had the good fortune to hire some of the external folks. It really started from that need to share data between Ansys products, and to manipulate data and enable scripted/programmatic simulation.
From there, it's just such a logical next step for our company's evolution that we have committed to it whole hog. It is happening across all of our products.
The guy who was ground zero for this, who works for us now, was Alex Kaszynski. He really gets open source, and gets how to engage the developer community around this stuff, and then build tools that solve these challenges in between what our products are already really good at.
It has been a really interesting, collaborative effort with customers, with partners, with academic users, and with internal developers.
DE: What types of applications or workflows does this enable?
Harrold: What I have seen from customers is that this makes the workflow fit what they need to achieve. It is not that our products were not solving the physics; they were doing that. But the customers want to go from step one to two to three in a more seamless fashion, and transfer data between two disparate products, which is not always the easiest thing to do. They are creating a platform across products that enables a nice, smooth workflow.
Another thing is just having enough people to do the work. We have got to make simulation more accessible to a broader consumer or user base, and one of the really powerful things that people are using PyAnsys for is opening up simulation capabilities to people who are not specialist engineers. They may not have been using Ansys for 20 years. This is about opening up that access so our users can apply more resources as seamlessly as possible.
The engineer can help build a workflow and make sure it is performing, but they can push that down to the design level so the designer does not have to wait for an engineer to perform the simulation and come back with the results.
DE: At the recent ASSESS Congress, there was a lengthy discussion about interoperability between tools, which can be difficult even with different tools within the same vendor suite. Does PyAnsys help address interoperability?
Harrold: Ansys has been very smart in our approach to this, and there are also a lot of things we are doing on the platform side with our cloud offerings. There are people who are not interested in cloud, but it is an extremely useful tool for some of these types of approaches, especially when you talk about letting someone who is not a simulation expert accessing these tools through custom workflows.
As we push our cloud program forward, as we push that platform capability forward, these developer tools become more important in terms of making that cloud platform more accessible. We have taken a hybrid approach; we have customers that do not necessarily want to push everything through the cloud, but they want a cloud-like experience. They want that programmatic ability to spin up and spin down resources.
All of these efforts feed into that. And when you talk about interoperability, having a platform approach and portability of data is important. We are using a common lingua franca for exchanging data. This is an ecosystem, but you have to get the workflows where they need to be to really unlock the potential within those initiatives.
What is in store for PyAnsys in the future?
Harrold: We are continuing to expand the PyAnsys reach across other products. There will be additional libraries produced.
In terms of the larger developer ecosystem, we have a developer portal that is in soft launch right now and we are letting our internal folks kick the tires on that before we bring it out.
Next year our customers will see a big focus on developer enablement, developer engagement, and bringing all these folks that are part of our larger ecosystem together and enabling workflow growth paths that customers are trying to achieve.
We are really invested in the PyAnsys program. It is not the only set of tools we have, but Python and scientific computing go hand in hand, so it makes a ton of sense to leverage Python for this type of critical phase of adoption.You will see more investment from Ansys in that in an ongoing way, and really bringing our ecosystem to consumers across the board in a more meaningful way starting in the back half Q1 next year (2023).
More Ansys Coverage
Subscribe to our FREE magazine,
FREE email newsletters or both!About the Author
![Brian Albright's avatar](https://www.digitalengineering247.com/images/avatars/avatar_9.jpg)
Brian Albright is the editorial director of Digital Engineering. Contact him at [email protected].
Follow DERelated Topics
![](http://scg-de.s3.amazonaws.com/images/made/images/article/Ansys_Access_350_170_bor1_b9b3be_s_c1.png)
![](http://scg-de.s3.amazonaws.com/images/made/images/article/DesktopMetal_Studio_5_350_170_bor1_b9b3be_s_c1.png)
![](http://scg-de.s3.amazonaws.com/images/made/images/article/Coreform_Nuclear_Product_350_170_bor1_b9b3be_s_c1.png)
![](http://scg-de.s3.amazonaws.com/images/made/images/article/Authentise-image-1_600_350_170_bor1_b9b3be_s_c1.jpg)