Bug located in Ansys 2024.2, when loading PyAedt

[AlfVII]

Before submitting the issue

• I have searched among the existing issues
• I am using a Python virtual environment

Description of the bug

I have installed PyAedt in a fresh intallation of Ansys 24.2, and when trying to create a project it block forever, so I have tried to do the same from the GUI, and when I click on "PyAEDT Console", a console window opens, but gets blocked for a long time as shown in the picture.

If I wait enough (10 minutes or similar) I get:

Steps To Reproduce

Just install PyAedt in 24.2 and try to open the "PyAEDT Console"

Which Operating System are you using?

Windows

Which Python version are you using?

3.8

Installed packages

annotated-types==0.7.0
ansys-pythonnet==3.1.0rc3
attrs==24.2.0
cffi==1.17.0
clr-loader==0.2.6
defusedxml==0.7.1
fonttools==4.53.1
fpdf2==2.7.9
importlib-resources==6.4.4
jsonschema==4.23.0
jsonschema-specifications==2023.12.1
numpy==1.24.4
pandas==2.0.3
pillow==10.4.0
pkgutil-resolve-name==1.3.10
plumbum==1.8.3
psutil==6.0.0
pyaedt==0.9.0
pycparser==2.22
pydantic==2.8.2
pydantic-core==2.20.1
pyedb==0.26.1
python-dateutil==2.9.0.post0
pytomlpp==1.0.13
pytz==2024.1
pywin32==306
PyYAML==6.0.2
referencing==0.35.1
rpds-py==0.20.0
rpyc==6.0.0
Rtree==1.3.0
scikit-rf==1.3.0
scipy==1.10.1
six==1.16.0
toml==0.10.2
typing-extensions==4.12.2
tzdata==2024.1
zipp==3.20.1

[Samuelopez-ansys]

Hi @AlfVII ,

Did you use the PyAEDT installer? You said you were using Python 3.8, but the installer is installing 3.10.

Please could you delete the folder Toolkits from your PersonalLib and also the virtual environment created in %appdata% ?

Then try to follow these steps:

https://aedt.docs.pyansys.com/version/stable/Getting_started/Installation.html

Please read this Discussion if you need more info regarding this script:

#4963

I tried PyAEDT 0.10.1 and python 3.10 and is working for me.

[AlfVII]

About the versions, I am running Python 3.8 from the Powershell when trying to access PyAedt as a library, which gets blocked.

Then, when trying to open the console from the Ansys 24.2 GUI, it runs in 3.10 (which I guess is Ansys's version)

Funny enough, I also have installed 23.2, and if I open the console from its GUI, it works. But if I run it from a script in powershell, it gets blocked.

Just a crazy idea, is it possible that installing first Ansys 24.2, and then 23.2, could have fucked up something?

Also, I have tried deleting everything in Toolkits and %appdata%, and reinstalling (always from your script pyaedt_installer_from_aedt.py)

[Samuelopez-ansys]

@AlfVII It should be independent... but who knows? Software is sometimes black magic :)

I will check python 3.8 just in case because all PyAEDT unit tests are only running in 3.10 for now.

I would use 3.10 always if possible. Not only for PyAEDT, also because some libraries are deprecating 3.8 and 3.9.

[AlfVII]

I'd love to, but the FreeCAD guys only support 3.8 in Windows...

Anyway, I'll try 3.10 and come back

[AlfVII]

It didn't work with everything on Python 3.10, same errors.

Funny enough, it I launch Ansys from the script and use GUI mode, it open Ansys normally, but PyAedt is not loaded (its button doesn't appear on the Automation view).

[clguenthe]

Maybe it helps the discussion here: I have the same issue on a Windows VDI machine. Starting a pyaedt.Desktop() from powershell/terminal fails with exactly the same behavior as reported here for 24R2 and 23R2, for various pyaedt versions (tested
a couple of versions from 0.7.something to 0.10.1). I'm using Python 3.10.9 on Windows and have pyaedt installed in my own .venv (using pip install, not from the AEDT installation). The same works fine on my local laptop.

Some more insights that I already gathered:

• It fails only in GRPC mode. In COM mode, it's working fine.
• The AEDT window is started fine and the app seems functional. However, pyaedt seems to fail to connect to it or retrieve the success response from starting.
• Not only starting a fresh Desktop() fails, but also attaching to an already running session (with new_desktop = False) shows the same behavior.
• Unfortunately, I can't tell if it ever worked on that virtual machine (prior to installing 24R2) since we're usually working in COM mode and I don't remember if I ever tested GRPC mode on that machine.
• It works fine for a colleague who has a similarly set up VDI machine.

-> I'll try to install the pyaedt venv with the pyaedt installer (recommended by @gmalinve) to see if the behavior changes with that venv and will give you an update here.

[SMoraisAnsys]

Hi @AlfVII and thanks for the feedback.

I'm a bit confused by the problem you are currently facing. I've just tried to use pyaedt (dev version) with CPython3.8 and it worked fine. Here is what I did:

1. install CPython3.8 with hatch (fresh installation without anything) :
2. create a virtual environment using the installed CPython3.8
3. install pyaedt dev version
4. from within python running the following code

import pyaedt

d = pyaedt.Desktop()

I think that the problem you are facing is related to your machine environment. The first idea coming to my mind is that you are trying to use grpc while being on a network where you have configured a proxy. This would explain the problem of being stuck as you described. Could you check if that is your case ?

[SMoraisAnsys]

After a discussion with @clguenthe and some work, here is what we found. The problem might be related to the proxy configuration if you have one that is setup in your machine environment. Here could be the source of the problems:

1. Having environment variable HTTPS_PROXY set up with an http:// URL. If that's not your case, GRPC should ignore HTTPS proxies so that shouldn't be the source of your problem. However, if that's your case, this can be why the GRPC call is stuck. Here is an interesting article related to that situation.
2. Having environment variable NO_PROXY set up without 127.0.01. Including localhost in NO_PROXY seems to not be sufficient as no DNS lookup is performed and it isn't converted into an IP. However adding 127.0.0.1 should make things work correctly since we are talking to the IP.

[Samuelopez-ansys]

@AlfVII Any feedback?

[AlfVII]

Having environment variable HTTPS_PROXY set up with an http:// URL. If that's not your case, GRPC should ignore HTTPS proxies so that shouldn't be the source of your problem. However, if that's your case, this can be why the GRPC call is stuck. Here is an interesting article related to that situation.

This worked like a charm!
Thanks a lot!