Cannot read data of a complex custom type field

[ecottanceau]

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

I am creating a complex custom type field but then I cannot read the data. It seems that is an issue in C type/np.complex128 conversion

Steps To Reproduce

Run the attached script

Which Operating System causes the issue?

Windows

Which DPF/Ansys version are you using?

Ansys 2026 R1

Which Python version causes the issue?

3.13

Installed packages

ansys-api-platform-instancemanagement==1.1.3
-e git+https://github.com/ansys/pydpf-core.git@7bb2160d1fed4a5369b0589d54f3515926d4983f#egg=ansys_dpf_core
ansys-platform-instancemanagement==1.1.2
asttokens==3.0.0
cachetools==6.1.0
certifi==2025.6.15
chardet==5.2.0
charset-normalizer==3.4.2
colorama==0.4.6
comm==0.2.2
contourpy==1.3.2
coverage==7.8.2
cycler==0.12.1
debugpy==1.8.14
decorator==5.2.1
distlib==0.3.9
executing==2.2.0
filelock==3.18.0
fonttools==4.58.4
graphviz==0.21
grpcio==1.73.1
idna==3.10
imageio==2.37.0
imageio-ffmpeg==0.6.0
importlib_metadata==8.7.0
iniconfig==2.1.0
ipykernel==6.29.5
ipython==9.3.0
ipython_pygments_lexers==1.1.1
jedi==0.19.2
jupyter_client==8.6.3
jupyter_core==5.8.1
kiwisolver==1.4.8
matplotlib==3.10.3
matplotlib-inline==0.1.7
nest-asyncio==1.6.0
numpy==2.2.4
packaging==25.0
parso==0.8.4
pillow==11.2.1
platformdirs==4.3.8
pluggy==1.6.0
pooch==1.8.2
prompt_toolkit==3.0.51
protobuf==6.31.1
psutil==7.0.0
pure_eval==0.2.3
Pygments==2.19.2
pypandoc_binary==1.15
pyparsing==3.2.3
pyproject-api==1.9.1
pytest==8.3.5
pytest-cov==6.1.1
pytest-order==1.3.0
pytest-rerunfailures==15.0
python-dateutil==2.9.0.post0
pyvista==0.45.2
pywin32==310
pyzmq==27.0.0
requests==2.32.4
scooby==0.10.1
setuptools==80.9.0
six==1.17.0
stack-data==0.6.3
tornado==6.5.1
tox==4.27.0
tox-uv==1.26.1
tqdm==4.67.1
traitlets==5.14.3
typing_extensions==4.14.0
urllib3==2.5.0
uv==0.7.15
virtualenv==20.31.2
vtk==9.4.2
wcwidth==0.2.13
zipp==3.23.0

manual_test.txt

[PProfizi]

Hello @ecottanceau,

as discussed together, the error comes from the fact that there is no ctypes equivalent to the numpy.complex128 dtype or Python's complex built-in type used underneath.
The error raised NotImplementedError("Converting dtype('complex128') to a ctypes type") actually comes from NumPy.
From what I have seen, anytime someone wants to deal with complex numbers using ctypes, you have to use two floating-point numbers: one for the real part, one for the imaginary part.
This way you fall back to the usual way we describe complex fields in DPF: as a collection of two fields (a FieldsContainer) with the complex label to mark one field as the real part and another as the imaginary part.

Still an issue remains as to why this did not fail at the setter level.

[PProfizi]

Hi @ecottanceau I just merged a PR to correctly raise an error if the type is not supported due to not being convertible to a ctype by numpy.
For complex fields, I invite you to take a look at how they are managed in the examples, which is byhaving a collection of two fields, one for the real part and one for the imaginary part, labeled accordingly.