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

total_obliteration
total_obliteration Member Posts: 12
Name Dropper First Comment
**
in Structures

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.

Tagged:

Answers

  • Mike.Thompson
    Mike.Thompson Member, Employee Posts: 361
    25 Answers 100 Comments Second Anniversary 25 Likes
    ✭✭✭✭

    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
    total_obliteration Member Posts: 12
    Name Dropper First Comment
    **

    Could it be related to the trimming operation in Contacts?

  • Mike.Thompson
    Mike.Thompson Member, Employee Posts: 361
    25 Answers 100 Comments Second Anniversary 25 Likes
    ✭✭✭✭

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

  • Mike Rife
    Mike Rife Member, Employee Posts: 51
    Second Anniversary 10 Comments First Answer 5 Likes
    ✭✭✭✭

    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

Categories