Extracting stresses on a shell model, and using component selector

[pmaroneh]

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 extracting stress tensor on a model that contains a single SHELL281 element.
I cannot make sense of the length of data obtained, and component selector does not seem to be working.

• Using result.stress and not providing requested location: returns a length of 12
• Using result.stress and providing nodal location: returns a length of 24
• Using result.stress and using component selector to obtain X stress only : returns same values as above.
  As this is a 8 node element and there are 6 stress values per node, I would expect 48 values to be returned for the complete stress tensor, and 8 values for SX tensor.

Steps To Reproduce

Use code and model attached.

file_shell281.zip

Which Operating System causes the issue?

Windows

Which DPF/Ansys version are you using?

Ansys 2025 R2

Which Python version causes the issue?

3.10

Installed packages

ansys-dpf-core==0.14.2
asttokens==3.0.1
certifi==2025.11.12
charset-normalizer==3.4.4
colorama==0.4.6
comm==0.2.3
contourpy==1.3.2
cycler==0.12.1
debugpy==1.8.17
decorator==5.2.1
exceptiongroup==1.3.1
executing==2.2.1
fonttools==4.61.0
grpcio==1.76.0
idna==3.11
importlib_metadata==8.7.0
ipykernel==7.1.0
ipython==8.37.0
jedi==0.19.2
jupyter_client==8.6.3
jupyter_core==5.9.1
kiwisolver==1.4.9
matplotlib==3.10.7
matplotlib-inline==0.2.1
nest-asyncio==1.6.0
numpy==2.2.6
packaging==25.0
parso==0.8.5
pillow==12.0.0
platformdirs==4.5.0
pooch==1.8.2
prompt_toolkit==3.0.52
protobuf==6.33.1
psutil==7.1.3
pure_eval==0.2.3
Pygments==2.19.2
pyparsing==3.2.5
python-dateutil==2.9.0.post0
pyvista==0.46.4
pyzmq==27.1.0
requests==2.32.5
scooby==0.11.0
six==1.17.0
stack-data==0.6.3
tornado==6.5.2
tqdm==4.67.1
traitlets==5.14.3
typing_extensions==4.15.0
urllib3==2.5.0
vtk==9.5.2
wcwidth==0.2.14
zipp==3.23.0

[ricardopeixotocoelho]

Hello @pmaroneh,

Using result.stress and not providing requested location: returns a length of 12
-> stress result is returned on corner nodes (4) for every layer (3: TOP/BOTTOM/MID), so you have 12 * 6 components

Using result.stress and providing nodal location: returns a length of 24
-> The element has 8 nodes and 3 layers (TOP/BOTTOM/MID), so you have 24 (= 8*3) entities with 6 components each

Using result.stress and using component selector to obtain X stress only : returns same values as above.
-> On my side, it seems to work fine. I have 12 values, one for each node for each layer

Could you please tell if this seems ok to you?

[pmaroneh]

Hi @ricardopeixotocoelho,
Thanks for looking into this.
I see two issues here:

• It needs to be documented what stresses we are retrieving. Indeed, there is no way for a user to understand that not providing the location returns the results on nodes but only the corner ones, and that providing a nodal location returns the returns on corner and midside nodes....
• I'm afraid I still don't understand the number of values we're getting:
• • If result.stress returns results on only the corner nodes for every layer, as there are 6 stress components we should get 436 = 72 values
• • If providing nodal location enables to retrieve values on the midside nodes too, we should get 836 = 144 values
• • etc.
    I've also noticed from my code, the following behavior:

so it seems that at the FC level we have the correct number of values, but not when extracting the data ...

[pmaroneh]

Moreover, I thought that to extend to midside nodes, we had to use dpf.operators.averaging.extend_to_mid_nodes_fc() ? So I don't get why we would get midside nodes...