OSError on wrong output label when connecting two workflows

[ClappeB]

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

When connecting two workflows together, if specifying wrong output name for distant workflow to connect on local workflow input, the code will throw an "OSError: exception: access violation reading 0x0000000000000000".
For example, let be:

• Workflow1 with output "mesh_output"
• Workflow2 with input "mesh_input"

If doing Workflow2.connect_with(Workflow1, {"mesh_out": "mesh_input"}) and running the workflow, this will throw OSError (because "mesh_out" doesn't exist on Workflow1).

Value fix for below: USING PYTHON 3.11 (not available when creating the issue)

Steps To Reproduce

from ansys.dpf import core as dpf
from ansys.dpf.core import examples

workflow1 = dpf.Workflow()
mesh_provider = dpf.operators.mesh.mesh_provider(data_sources=dpf.DataSources(result_path=examples.find_multishells_rst()))
workflow1.add_operator(mesh_provider)
workflow1.set_output_name("mesh_output", mesh_provider.outputs.mesh)

workflow2 = dpf.Workflow()
skin_op = dpf.operators.mesh.skin()
workflow1.add_operator(skin_op)
workflow2.set_input_name("mesh_input", skin_op.inputs.mesh)
workflow2.set_output_name("skin_mesh", skin_op.outputs.mesh)

workflow2.connect_with(workflow1, {"mesh_out": "mesh_input"})   \# Wrong output name
workflow2.get_output("skin_mesh", dpf.types.meshed_region)

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

ansys-api-platform-==1.0.0b3
ansys-dpf-core==0.8.2.dev0
ansys-dpf-flowdiagram==0.1.0.dev0 D:\repos\flow-diagram\backend
ansys-dpf-gate==0.3.1
ansys-dpf-gatebin==0.3.1
ansys-grpc-dpf==0.7.1
ansys-platform-instancemanagement==1.1.1
anyio==3.6.2
cachetools==5.3.0
certifi==2022.12.7
charset-normalizer==3.1.0
click==8.1.3
colorama==0.4.6
contourpy==1.0.7
cycler==0.11.0
distlib==0.3.6
fastapi==0.95.1
filelock==3.12.0
fonttools==4.39.3
google-api-core==2.11.0
google-api-python-client==2.86.0
google-auth==2.17.3
google-auth-httplib2==0.1.0
googleapis-common-protos==1.59.0
grpcio==1.54.0
h11==0.14.0
httplib2==0.22.0
httptools==0.5.0
idna==3.4
imageio==2.28.1
importlib-metadata==6.6.0
kiwisolver==1.4.4
matplotlib==3.7.1
numpy==1.24.3
packaging==23.1
Pillow==9.5.0
ujson==5.7.0
uritemplate==4.1.1
urllib3==1.26.15
uvicorn==0.22.0
virtualenv==20.20.0
vtk==9.2.6
watchfiles==0.19.0
websockets==11.0.2
wheel==0.40.0
zipp==3.15.0

[rafacanton]

@BClappe I guess that the expectation here is to raise an explicit message alerting about the pin name, and not raise an OSError, right?

[BClappe]

@rafacanton Yes, it would be cool, this would help people finding what the error actually is (because it's really trivial) in a fast manner, instead of trying to find which operator they chose wrong, where in fact they just did a typo.

So raising a ValueError (or something like that) saying Pin [name] doesn't exist on workflow (or something like that), would be great!

[PProfizi]

I can confirm using a wrong input or output name implodes when trying to run the workflow.
I will raise errors during connect_with.