Inconsistency issue

[koubaa]

See related PyMechanical issue

For this user, get_mechanical_path(False) poins to v212

ansys.tools.path.get_mechanical_path(False)
'C:\Program Files\ANSYS Inc\v212\aisol\bin\winx64\AnsysWBU.exe'

But,

ansys.mechanical.core.find_mechanical()[0].

apparently points to a newer installation.

[Gryfenfer97]

According to the documentation, these functions do two different things
get_mechanical_path:

Acquires Ansys Mechanical Path from a cached file or user input

find_mechanical:

Search for the Mechanical path in the standard installation location.

[koubaa]

@Gryfenfer97 @samigithub2022 I see. I think the problem here is that the user did this:

Install and try to use PyMechanical, which runs find_mechanical and then caches the location in appdata. Then, the user gets an error message about requiring 232+, so they install it. But then when they try to use PyMechanical it tries to use the cached version.

I think we most probably have to make sure that trying to use PyMechanical with an older version of Mechanical installed does not cause any artifact to be produced in the user's appdata pointing to that older version.

@Gryfenfer97 on another note - is there a quick API to wipe the config of ansys.tools.path? In the linked bug, I asked the user to use platformdirs directly, but its not so convenient

[Gryfenfer97]

_clear_config_file.
But it is not exposed in the __init__.py so he will have to call it using from ansys.tools.path.path import _clear_config_file.

I think we should expose it. From the docstring:

"""Used by tests. We can consider supporting it on the library"""

[koubaa]

The takeaway for me is that we should (1) support clear_config_file (imo the name be different, config file is an implementation detail that we shouldn't necessarily expose) and (2) fix the scenario where this might happen in PyMechanical or other applications or (3) add some minimum version argument to things like get_mechanical_path so that it ignores the config file if the cached version is too old, and maybe even adds multiple versions to the config file.

[koubaa]

The correct way for client libraries is to use "get" first, then use "find" if its not available in "get", but never to save unless the user explicitly does so. We need to make sure that PyMechanical does it that way

[koubaa]

Actually, get_* doesn't do what it is documented, it also does a find. For dyna at least, we need a flag that says controls whether get can do a find