Starting servers with different ansys paths does not work as expected

[janvonrickenbach]

Before submitting the issue

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

Description of the bug

It looks like calling start_local_server twice with different ansys paths does not result in two different servers.

Steps To Reproduce

Start two servers with different ansys paths => both have the same version:

With inverted order (after restarting the kernel):

Which Operating System are you using?

Windows

Which DPF/Ansys version are you using?

Ansys 2023 R1

Which Python version are you using?

3.10

Installed packages

Package Version

---

ansys-dpf-composites 0.1.dev0
ansys-dpf-core 0.7.2
ansys-dpf-gate 0.3.0
ansys-dpf-gatebin 0.3.0
ansys-grpc-dpf 0.7.0
anyio 3.6.2
appdirs 1.4.4
argon2-cffi 21.3.0
argon2-cffi-bindings 21.2.0
arrow 1.2.3
asttokens 2.2.1
attrs 22.2.0
backcall 0.2.0
beautifulsoup4 4.11.1
bleach 5.0.1
cachetools 5.2.1
certifi 2022.12.7
cffi 1.15.1
charset-normalizer 3.0.1
colorama 0.4.6
comm 0.1.2
contourpy 1.0.7
cycler 0.11.0
debugpy 1.6.5
decorator 5.1.1
defusedxml 0.7.1
entrypoints 0.4
executing 1.2.0
fastjsonschema 2.16.2
fonttools 4.38.0
fqdn 1.5.1
google-api-core 2.11.0
google-api-python-client 2.73.0
google-auth 2.16.0
google-auth-httplib2 0.1.0
googleapis-common-protos 1.58.0
grpcio 1.51.1
httplib2 0.21.0
idna 3.4
imageio 2.24.0
ipykernel 6.20.2
ipython 8.8.0
ipython-genutils 0.2.0
ipywidgets 8.0.4
isoduration 20.11.0
jedi 0.18.2
Jinja2 3.1.2
jsonpointer 2.3
jsonschema 4.17.3
jupyter 1.0.0
jupyter_client 7.4.9
jupyter-console 6.4.4
jupyter_core 5.1.3
jupyter-events 0.6.3
jupyter_server 2.1.0
jupyter_server_terminals 0.4.4
jupyterlab-pygments 0.2.2
jupyterlab-widgets 3.0.5
kiwisolver 1.4.4
MarkupSafe 2.1.2
matplotlib 3.6.3
matplotlib-inline 0.1.6
mistune 2.0.4
nbclassic 0.4.8
nbclient 0.7.2
nbconvert 7.2.8
nbformat 5.7.3
nest-asyncio 1.5.6
notebook 6.5.2
notebook_shim 0.2.2
numpy 1.23.5
packaging 23.0
pandocfilters 1.5.0
parso 0.8.3
pickleshare 0.7.5
Pillow 9.4.0
pip 22.2.1
platformdirs 2.6.2
prometheus-client 0.15.0
prompt-toolkit 3.0.36
protobuf 4.21.12
psutil 5.9.4
pure-eval 0.2.2
pyasn1 0.4.8
pyasn1-modules 0.2.8
pycparser 2.21
Pygments 2.14.0
pyparsing 3.0.9
pyrsistent 0.19.3
python-dateutil 2.8.2
python-json-logger 2.0.4
pyvista 0.36.1
pywin32 305
pywinpty 2.0.10
PyYAML 6.0
pyzmq 25.0.0
qtconsole 5.4.0
QtPy 2.3.0
requests 2.28.2
rfc3339-validator 0.1.4
rfc3986-validator 0.1.1
rsa 4.9
scooby 0.7.0
Send2Trash 1.8.0
setuptools 63.2.0
six 1.16.0
sniffio 1.3.0
soupsieve 2.3.2.post1
stack-data 0.6.2
terminado 0.17.1
tinycss2 1.2.1
tornado 6.2
tqdm 4.64.1
traitlets 5.8.1
uri-template 1.2.0
uritemplate 4.1.1
urllib3 1.26.14
vtk 9.2.5
wcwidth 0.2.6
webcolors 1.12
webencodings 0.5.1
websocket-client 1.4.2
widgetsnbextension 4.0.5

[roosre]

Faced the same issue with version 0.13.0. I had to use python Process to ensure that separate (new) dpf servers are used for the calculations. server.shutdown() did not work as expected.

[PProfizi]

Hello @janvonrickenbach hello @roosre

I just checked and this is due to the default server config being InProcess when trying to start_local_server.

Since we can only have one InProcess server, the second command actually does not make sense.

The current behavior is that to properly get multiple servers, at least one of them must be Grpc.

This is due to the InProcess server loading the DPF binaries in the current Python process, so since there is only one current Python main process, there is only one DPF InProcess server.

So what I think the issue is here, is that the second command should switch to Grpc after checking that an InProcess server already exists, or it should throw a warning or an error.

What would you expect as users?

[PProfizi]

BTW, the current workaround for your script is to start at least one of them like so:

start_local_server(config=dpf.AvailableServerConfigs.GrpcServer)