ANSYS/PyAnsys version management
agrishin opened this issue · comments
From Costas Vogiatzis at Honeywell (Phoenix):
As we are starting to use PyAnsys for Methods work we are trying to determine the best way to support multiple ANSYS versions. For context, most of PyAnsys Methods work so far involves only MAPDL. We are using PyAnsys to read RST/RTH results and to a lesser extent drive MAPDL. Python literacy among ANSYS users is low so we are wrapping PyAnsys functionality in MATLAB code so users can perform these operations from within MATLAB without using Python/PyAnsys directly. These utilities are distributed as part of a larger, general purpose MATLAB library that I maintain.
We typically have users using releases going back up to 3-4 years and we also have archived data that go back even more. Depending on ANSYS version, users would need different PyAnsys module versions and possibly different Python versions. Often times the same user would need to work with multiple ANSYS versions depending on project. Managing dependencies for different ANSYS versions can be done with virtual environments and tools like pyenv for multiple Python versions. However that becomes too complex for a casual ANSYS user: users would need to be guided through Python and module installation and virtual environment use. Also, managing the environments is somewhat fragile because of version conflicts depending on what else the user has installed on that box.
This will be an issue with deployment of PyAnsys based utilities. The concern is that it will be complex for end users to manage and they will not work reliably. We would like to understand how ANSYS envisions multiple versions of ANSYS+PyAnsys would be managed on a single computer in a robust way. Ideally we would like everything relating to PyAnsys to be included in the MAPDL installation so users would not need to manage that.
A related issue is that per the docs the legacy RST reader will be phased out. However DPF does not seem to support older ANSYS versions. That will be an issue if we transition tools to PyAnsys and then find that we cannot use them with some earlier ANSYS result. We would like to understand what tool version can read what MAPDL result file version.
Regards,
Costas Vogiatzis
Aero & Mechanical Sciences
Honeywell Aerospace
Excellent points. I'm pulling information from internal shareholders and we're formulating a response. However, a few points I'd like to make first:
- It would be awesome to be able to MATLAB directly with a package hosted in our https://github.com/ansys organization as a semi-supported package that we also upload to the MATLAB file exchange. This isn't the first time a customer has used MATLAB with PyAnsys
- "A related issue is that per the docs the legacy RST reader will be phased out. However DPF does not seem to support older ANSYS versions." That does indeed need to be addressed, and if this is a customer request, we need to determine the best bast forward.
Hi @agrishin
The topics you are mentioning here are very interesting. I will drop my 2 cents with regard PyMAPDL perspective.
-
Matlab support. We had some requests about this, not sure how trivial will be to expose PyAnsys libraries to MAPDL. I guess it should be possible: https://www.mathworks.com/help/matlab/call-python-libraries.html
-
Regarding versions support. In PyMAPDL, we are aiming to have only one version of the python library, meaning that the latest version of PyMAPDL should work with any given Ansys version. PyMAPDL should be clever enough to detect the MAPDL version and act consequently. In that sense, the compatibility problems should be reduced. I believe the rest of PyAnsys libraries follow a similar approach. Documentation is another story.
-
Regarding documentation versioning. This is an on-going project and @akaszynski can probably give you more information. But I believe after finished we will have different versions of MAPDL documentation available online. In my opinion, and this is not yet fully agreed/decided, PyMAPDL documentation will reflect all MAPDL versions by using notes, warnings, deprecation messages, etc. Check the following links:
- https://numpydoc.readthedocs.io/en/latest/format.html#deprecation-warning
- https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-versionadded
But this is my opinion on a topic that it is still developing. It might change later. The easier will be probably have different documentation versions and the user needs to choose the correct one.
-
Managing multiple Ansys versions + PyAnsys. Because of the 'version support' point, I guess it should not be very difficult to manage different Ansys version with only one PyAnsys (PyMAPDL) library version. Furthermore, in PyMAPDL now you can choose your executable using an environment variable: ansys/pymapdl#1741
-
About PyAnsys end user complexity. I understand what you mean. For new Python users, some of the python nuances (i.e. virtual environments) seem complex. I don't think there are easy solutions for this. At end, it is how Python is built and we cannot change that much into this. We already shipped a python environment with Ansys installation, but still the user needs to activate it and properly use it. It might still be complex enough for some users. I think we should still work a bit more on this, but there are some limitations difficult to overcome.
-
Regarding legacy reader and DPF. DPF is shipped with last Ansys installer versions, but I believe it supports most of the available RST versions. @rlagha can confirm/deny this.
We will probably discuss it internally in the coming weeks. We shall let you know if some interesting points are raised in these internal meetings. Please ping us again in couple of weeks if we haven't get back to you.
I understand what you mean. For new Python users, some of the python nuances (i.e. virtual environments) seem complex. I don't think there are easy solutions for this. At end, it is how Python is built and we cannot change that much into this. We already shipped a python environment with Ansys installation, but still the user needs to activate it and properly use it. It might still be complex enough for some users. I think we should still work a bit more on this, but there are some limitations difficult to overcome.
We have an internal tool we can make public.
Hi @agrishin - just remembered we have this issue still open. As @akaszynski mentioned, we had an internal tool that we made public a couple of months ago-
It's this project here: the Ansys Python Manager
I recommend you to go through our docs in order to understand how to install it: https://installer.docs.pyansys.com/version/stable/installer.html
If you have any doubts, please let us know. We will try to help you out as much as possible.
This tool will allow you to install Python on your machines (in case you need it), handle the creation of virtual environments, and manage the installation of the public PyAnsys libraries. This tool is mostly for Windows. Let us know your feedback.
Closing the issue in the meantime