Inconsistent 'elshape' labeling

[fborges209]

The following code is used to get the stress results (*.rst file) from a named selection previously created using APDL:

corresponding_ns = "Surface_node_selection"
stress = model.results.stress.on_last_time_freq.on_named_selection(corresponding_ns).eval()
available_ids = stress.get_available_ids_for_label("elshape")
fields_container = stress.get_field({"time": 1, "elshape": available_ids[-1]} )

The “available_ids” list for the elshape attribute is ordered differently for different runs and we therefore get two different results, although the results in the RST file are the same.

The named selection is based on a Surface coating with element type SHELL281. The node numbers for the surface coating elements are the same as for the respective nodes of the volume elements.

Is there a logic behind the “elshape” attribute that can be used to determine the element type? Is there any other way to find out which field contains the SHELL281 elements?

[PProfizi]

Hi @fborges209,

From what I understand, in your case the RST reader call gives a fields_container (stress) with labels for time and elshape.
Your named selection thus contains both solid and shell elements, right?

You then want to get the field corresponding to the shell elements.

The value for elshape for shells should be 0 in every case, as defined here.
I am not sure why this Enum is currently marked as private. I think it is because it may be specific to results from RST files.
Can you please let me know if access to this Enum is enough to answer your question? If so, I'll see how to expose this properly.

[jefeenders]

Hi @PProfizi ,

I am working together with @fborges209 on this issue.
First of: We are using dpf==0.10
We had these doubts with the enum of elshape also due to a surprising behavior we observed when creating unit tests for testing our evaluation scripts. In the actual project we import the meshes as cdbs from an external meshing program, however for the unit test we use a mesh from the Ansys Mechanical internal mesher for convenience. In both cases surface elements are generated with the "Surface Coating" functionality in Mechanical.

• In the case of meshing inside Mechanical the shell elements correspond to the string "2" for elshape and solids to "1"
• In the case of a CDB import the shell elements correspond to "1" and solids to "0"
  To make the code work for both cases I chose to take the last index in the list (assuming that it was sorted). @fborges209 however informed me, that in some cases this list is also not sorted... Do you have an idea what we are observing here? From the code passage you shared with the enum, things should be very clear.

This screenshot is taken from the debugging of the unit test:

[PProfizi]

Hi @jefeenders,

The behavior you are describing is indeed strange.
Would it be possible to share a small example file for each case (.rst and .cdb)?

What I would also need to clarify is how you read the mesh from the CDB file.

FYI @rafacanton