PyMAPDL Fails to Launch After Switching to Python 3.10

[AltoAuto]

Hi guys
I recently changed my Python version from 3.13 to 3.10 to support cadquery + OCP. After setting up a new virtual environment and reinstalling the required packages, I now get the following error when launching MAPDL via launch_mapdl():

MapdlConnectionError: Unable to connect to MAPDL gRPC instance at dns:///127.0.0.1:50055.
Reached either maximum amount of connection attempts (5) or timeout (45 s).
The MAPDL process has died PID: XXXXX.

Component | Version -- | -- Python | 3.10.13 ansys-mapdl-core | 0.70.1 Ansys | 2025 R1 OS | Windows 11

What I’ve Tried
Created a fresh virtual environment
Installed correct version: ansys-mapdl-core==0.70.1
Confirmed Python version is 3.10
MAPDL 2025 R1 is working standalone
Works fine in Python 3.13 using same code

Question?
What could be causing the MAPDL gRPC connection to fail in Python 3.10 but work in 3.13?
Any known compatibility issues between ansys-mapdl-core and Python 3.10 in latest Ansys 2025 R1?

from ansys.mapdl.core import launch_mapdl

mapdl = launch_mapdl()  # ← crashes here

[germa89]

MAPDL 2025 R1 is working standalone

I guess you mean interactively?

Please try:

from ansys.mapdl.core import LOG

LOG.setLevel("DEBUG")
LOG.log_to_file("mylog.log")

from ansys.mapdl.core import launch_mapdl

mapdl = launch_mapdl(loglevel="DEBUG")

Then you can see the following lines:

...
Running an MAPDL instance
Location:
/tmp/ansys_sdpixywyij
Command:
/ansys_inc/v252/ansys/bin/ansys252 -j file -np 2 -port 50052 -grpc
Env vars:
{'SHELL': '/bin/bash', 'COLORTERM': 'truecolor', ...
...

Try to execute the command from a terminal in a termporary file and let me know the output. Also it is worth reading: https://mapdl.docs.pyansys.com/version/stable/user_guide/troubleshoot.html#testing-mapdl-launching

[AltoAuto]

Thanks @germa89 for the response, I really appreciate the help. I tried your suggestion and attached the mylog.log file below. It looks like the gRPC connection fails after five attempts, and I suspect it might be related to the student license setup.

At the moment, I'm using start_instance=False and launching MAPDL manually, which seems to work fine. Just wanted to ask, are there any potential limitations or drawbacks to relying on this method (e.g., missing features, reduced control, or issues with automation)?
mylog.log

Thanks again for your time and support!

[AltoAuto]

Thanks again @germa89 just wanted to give you an update.

After a few failed attempts earlier, we tried again today without setting start_instance=False, just using a standard launch_mapdl() call — and strangely, it worked this time without error. We didn’t change anything significant in the environment, so we're a bit confused why it suddenly launched successfully now when it consistently failed before (log attached again just in case).
mylog.log

Is it possible the gRPC port was blocked earlier? Or could it have been a temporary license or background process issue? Either way, thanks for your help we’re trying to make this workflow stable for students and package it into an EXE, so any insight into what might be causing the inconsistency would be appreciated.

[germa89]

you didnt mention start_instance=False earlier. That argument makes PyMAPDL trying to connect to an already live MAPDL instance. If that does not exist, it will show the error you mentioned.

If you haven't started MAPDL manually using the command line, or you are not connecting to a remove MAPDL instance; you should use start_instance=True .... Watch out also for the PYMAPDL_START_INSTANCE environment variable which has the same effect.

[AltoAuto]

Thank for the respond German, and sorry for the confusion.

I’ve been testing PyMAPDL versions 0.67 to 0.70, and I’ve noticed something I wanted to confirm:
for version 0.69.0 and 0.70.1 If MAPDL hits a runtime error, the Python script throws an exception, but MAPDL itself doesn’t exit. The process stays alive in the background. When I run the script again, launch_mapdl() fails unless I set start_instance=False. But then it just tries to connect and throws a connection error if no MAPDL instance is running. This eventually causes port lock issues and memory build-up if I run simulations in a loop or in batch. This didn’t seem to happen in 0.68 (it exited cleanly after the run, though that version had some other quirks like breaking numpyn), and 0.67 is a more stable one and it could launch many times and exit on itself.

My question is: Is this the intended behavior in newer versions? Or is there a proper way we should be handling exit and error recovery that we’re missing?

Thank you