BUG: Object No. not in ResultTable

[MaartenBW]

Describe the bug When requesting a ResultTable from the Python API, the object number is not included in the dictionary that is returned.

When I request the NodesDeformation ResultTable using:

table = ResultTables.NodesDeformations(
    loading_type=CaseObjectType.E_OBJECT_TYPE_LOAD_COMBINATION, 
    loading_no=14, 
    include_base=True,
)

The Node no. is not included in the table. In RFEM, the table looks like this:

But the returned dictionary looks like this:

[
  {
    "description": null,
    "no": 1.0,
    "displacement_x": -6.383599975379184e-05,
    "support_forces_p_y": 0.0,
    "support_moments_m_y": 0.0,
    "support_forces_p_z": 0.0,
    "displacement_z": -0.16384199261665344,
    "rotation_y": -0.00569724477827549,
    "displacement_absolute": 0.16387487947940826,
    "rotation_z": 0.0002016020007431507,
    "support_forces_p_x": 0.0,
    "support_moments_m_x": 0.0,
    "rotation_x": 0.002009345917031169,
    "displacement_y": -0.003282942110672593,
    "support_moments_m_z": 0.0,
    "specification": null
  },
  {
    "description": null,
    "no": 2.0,
    "displacement_x": -0.0004903479712083936,
    "support_forces_p_y": 0.0,
    "support_moments_m_y": 0.0,
    "support_forces_p_z": 0.0,
    "displacement_z": -0.14803409576416016,
    "rotation_y": -0.011373580433428288,
    "displacement_absolute": 0.14807109534740448,
    "rotation_z": 0.0001382710033794865,
    "support_forces_p_x": 0.0,
    "support_moments_m_x": 0.0,
    "rotation_x": 0.008786758407950401,
    "displacement_y": -0.0032739699818193913,
    "support_moments_m_z": 0.0,
    "specification": null
  },
...
]

As you can see, the deformations of the first row match with the deformations shown in the first dictionary of the returned object, But the 'no' is set to 1.0 (the row number) but not the Node ID.

Expected behavior I would expect that the Node No. is included in the result table, because in post processing the node deformation results are matched with a actual nodes. This is now impossible since it is unknown what row belongs to what node. Next to the fact that the table is not starting at Node 1, the Node Numbers are also not continuous througout the table. This means that it is impossible to know what Node the results belong to.

I also think its weird that the field 'no' in the table is the row index and not the object id, since everywhere in the tool, 'no' is used for object ids.

Desktop (please complete the following information):

• Version of WIN11 OS: [WIN 11]
• Version of RFEM6.03.0003
• Version of tool: rfem_python_client: 1.18.0

[OndraMichal]

Hi @MaartenBW, this looks odd. I believe this should be added. The bug was reported (#135374). Thank you.

[MaartenBW]

HI, thanks for the response.

Another remark regarding this: The table that is returned is now dependant on the visibility settings in the GUI. I think it makes more sense to return the complete unfiltered table

[OndraMichal]

Hi, that makes sense.

[OndraMichal]

Hi @MaartenBW, the fix was done by returning only relevant results. So for NodesDeformations the request looks like this: ResultTables.NodesDeformations(CaseObjectType.E_OBJECT_TYPE_LOAD_CASE, 1, 20) Which specify the load case and node. Hence, adding ID of the node is no longer required. RESOLVED