DPF scoping creation using Numpy arrays in Numpy2

[JimmyHe0527]

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 creating a scoping from Numpy arrays in DPF, there is a significant difference in behavior in Numpy 1 vs. Numpy 2. A minimum example is as follows:

from ansys.dpf import core as dpf
import numpy as np

nids = np.array([1,2,3,4],dtype=int)
scop = dpf.Scoping(ids=nids, location= dpf.locations.nodal)
print(nids)
print(scop.ids)

Using Numpy 1 (1.26.4):

Using Numpy 2 (2.2.2, the default version when installing DPF 0.13.4 today):

One can see that the scoping generated from Numpy2 array is incorrect (it adds 0 padding every other entry), while this is correct in Numpy 1. This is a dangerous behavior since if a new user installs DPF in a fresh virtual environment, it automatically pulls the latest version of Numpy.

Steps To Reproduce

1. Install DPF and Numpy2 in virtual environment
2. Run the following example code

from ansys.dpf import core as dpf
import numpy as np

nids = np.array([1,2,3,4],dtype=int)
scop = dpf.Scoping(ids=nids, location= dpf.locations.nodal)
print(nids)
print(scop.ids)

Which Operating System causes the issue?

Windows

Which DPF/Ansys version are you using?

Ansys 2025 R1

Which Python version causes the issue?

3.10, 3.13

Installed packages

The working version:
ansys-dpf-core==0.13.4
cachetools==5.5.1
certifi==2024.12.14
charset-normalizer==3.4.1
colorama==0.4.6
google-api-core==2.24.0
google-api-python-client==2.159.0
google-auth==2.38.0
google-auth-httplib2==0.2.0
googleapis-common-protos==1.66.0
grpcio==1.70.0
httplib2==0.22.0
idna==3.10
importlib_metadata==8.6.1
numpy==1.26.4
packaging==24.2
proto-plus==1.25.0
protobuf==5.29.3
psutil==6.1.1
pyasn1==0.6.1
pyasn1_modules==0.4.1
pyparsing==3.2.1
requests==2.32.3
rsa==4.9
tqdm==4.67.1
uritemplate==4.1.1
urllib3==2.3.0
zipp==3.21.0

The default:
ansys-dpf-core==0.13.4
cachetools==5.5.1
certifi==2024.12.14
charset-normalizer==3.4.1
colorama==0.4.6
google-api-core==2.24.0
google-api-python-client==2.159.0
google-auth==2.38.0
google-auth-httplib2==0.2.0
googleapis-common-protos==1.66.0
grpcio==1.70.0
httplib2==0.22.0
idna==3.10
importlib_metadata==8.6.1
numpy==2.2.2
packaging==24.2
proto-plus==1.25.0
protobuf==5.29.3
psutil==6.1.1
pyasn1==0.6.1
pyasn1_modules==0.4.1
pyparsing==3.2.1
requests==2.32.3
rsa==4.9
tqdm==4.67.1
uritemplate==4.1.1
urllib3==2.3.0
zipp==3.21.0

[PProfizi]

Hi @JimmyHe0527 I figured it out.

The issue is that numpy 2 changed the default integer type to 64 on Windows (see here).
This means that when declaring
nids = np.array([1,2,3,4],dtype=int)
there is a difference between numpy1 where the equivalent is:
nids = np.array([1,2,3,4],dtype=int32)
and numpy2 where the equivalent becomes
nids = np.array([1,2,3,4],dtype=int64).

It turns out the the Scoping.ids setter expects int32 values, so the new behavior creates intermediate null values due to being fed int64.
You can see the behavior is fixed by providing explicitly int32 values.

This is however very problematic so I'll mark this as a bug for the Scoping.ids setter.
I am really surprised this did not show up in testing so we'll also add a test for that.

Thanks for the catch!