Bug located in Ansys 2024.2, when loading PyAedt

AlfVII commented 1 week ago

Before submitting the issue

[X] I have searched among the existing issues
[X] 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 commented 1 week ago

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:

https://github.com/ansys/pyaedt/discussions/4963

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

AlfVII commented 1 week ago

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 commented 1 week ago

@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 commented 1 week ago

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

Anyway, I'll try 3.10 and come back

AlfVII commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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:

install CPython3.8 with hatch (fresh installation without anything) :
create a virtual environment using the installed CPython3.8
install pyaedt dev version
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 commented 1 week ago

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:

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.
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 commented 6 days ago

@AlfVII Any feedback?

AlfVII commented 6 days ago

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!

ansys / pyaedt