Ansys product compatibility#
As the different PyAnsys libraries evolve, backward and forward compatibility issues can occur. Some of the most common cases are:
An Ansys product has implemented certain features in its new server version that are not available in previous server versions. This causes backward incompatibility issues.
New server versions have suppressed support for certain operations after a a given version. This causes forward incompatibility issues.
Though there are different ways to handle these issues, some of the PyAnsys libraries, such as PyMAPDL and PyDPF-Core, handle them in the same way. To homogenize implementations in PyAnsys libraries, following their approach is recommended.
check_version.py module approach#
A version checking module determines whether the Ansys product server you are connecting
to provides support for certain operations. For implementation examples, see the
check_version.py files for the following PyAnsys libraries:
One of the easiest ways to keep track of the versions supported is setting up a
minimum version data structure, in which forward compatibility is ensured.
Server versions earlier than the minimum version do not have access to this
functionality. In the case of ansys/mapdl/core/check_version.py, this is the
Most Ansys products provide forward compatibility, meaning that features introduced in an earlier version are also supported in later versions. Suppressing a feature would lead to a backward compatibility issue.
Because the same type of issues can happen with the PyAnsys servers wrapping Ansys products, creating a similar data structure for a maximum version is is necessary. While there are no implementations yet of this feature, it should work in the same way as the minimum version mechanism works.
@version_requires decorator applies version logic to the different
functionalities and methods available in the client. You can see how this
decorator is used in ansys/mapdl/core/check_version.py and
ansys/dpf/core/check_version.py. Here is a generalized example:
class Client: def __init__(self): """Connect to a fake server.""" self._server = FakeServer() @version_requires((0, 1, 3)) # require 0.1.3 def meth_a(self): """Call method ``a`` on the server.""" return self._server.meth_a() @version_requires((0, 2, 3)) # require 0.2.3 def meth_b(self): """Call method ``b`` on the server.""" return self._server.meth_b()
client object is created and a call is made to any of its methods,
meth_a(), the decorator checks that the version is later than the one
specified in the decorator’s call. If it is not, a
VersionError is raised.
self._server member of the class is the server that the client is connected to. This
member is expected to have version information in its
attribute. The decorator uses this version information to determine if the version is
above the threshold.
You can create a
@max_version_supported decorator to implement this same
kind of logic for forward incompatibility. Changing the
@min_version_required is recommended.