Why there is 2332 elements missing in pyDPF compared to APDL?

APDL shows 55098 elements. PyDPF shows 52766 elements. There are 2332 elements missing in pyDPF. Why is that?

meshed_region = model.metadata.meshed_region
print(meshed_region.elements.scoping)

This is seen in scoping from Named Selection:
NS_elem_scoping_op = dpf.operators.scoping.on_named_selection(
requested_location = 'elemental',
named_selection_name = NS,
int_inclusive = 0,
streams_container = sc)

NS_elem_scoping = NS_elem_scoping_op.outputs.mesh_scoping()

PyDPF returns 474 elements. Both Mechanical and APDL returns 507 elements. This is carried over my contact pressure results - specifically SMISC #1, #2, #3 and #4 (contact pressure of corned nodes). After some processing, the values calculated from SMISC from pyDPF agrees with Mechanical output. This is true for nodes of elements that are read by pyDPF. However, because some elements are missing, the averaged results do not agree.

Please advise.
If ANY info regarding how Mechanical calculates averaged contact pressure, I would love to see it. I think I am on a right track but pyDPF misses some elements.

Find more posts tagged with

PyDPF

DPF

Accepted answers

All comments

Mike.Thompson

I am confused. You seem to have a couple different examples going on in this post of APDL/Mechanical not having the same element IDs as PyDPF when you expect them to be the same.

Can you please provide a single, specific example where PyDPF has a different element set for the scoping including how exactly you are getting the mesh scoping in PyDPF? Is the data source a results file? What type of elements are in the Named Selection/Component? Etc..

In one example above you allude to mesh scoping from a named selection where mechanical has 507 elements, but then allude to contact pressure. Since Mechanical does not have the contact elements (they are created at input file creation), I am not sure what exactly is being compared.

total_obliteration

Could it be related to the trimming operation in Contacts?

Mike.Thompson

I doubt that. Please specify how you are using APDL and/or mechanical vs PyDPF.

Mike Rife

Hi @Mike.Thompson and @total_obliteration
t_o we do need to see some details as MT said. To add to what MT mentioned about WB Mechanical not being 'aware' of contact elements in the model, as they are created when the input file is written, there are other instances of this; remote boundary conditions, joints, some applied loads like pressure (that use a surface effect element), point mass, etc.
One other option that occured to me is how are you checking the MAPDL element count? After resuming a database or after reading in a result file? The nonlinear adaptivity and geometry based adaptivity could result in the element count mismatch. If the MAPDL db was created prior to the solve then it would have the original mesh while the result file could have 2 or more FEMs (assuming a remesh did take place). The Named Selection could have also been redefined to the updated mesh and so would not match the initial mesh from WB Mechanical nor the MAPDL db mesh.

Just my 2 cents....
Mike