Before submitting the issue

• I have searched among the existing issues
• I am using a Python virtual environment

Description of the bug

The logic in the MeshIcepak.MeshRegion.assignment property getter method

Then in the following for loop over all potential subregions (nonmodel objects), the check in line 912 all(p in p1 for p in parts) is not working properly, since it will always evaluate to "True" and thus it will assign the name of the first Subregion element it finds in the list:

This works for the first MeshRegion created, but for the 2nd and subsequent regions, it will erroneously assign always the name of the 1st created region and the, since it's a for-loop, continue to re-assign the name with the name of all other Subregion elements. This then fails since it already has a name that corresponds to an existing object, which leads to a warning message issued from the object3d name setter:

As a result, what the user sees in AEDT is a series of confusing warnings:

And the MeshRegion objects in the pyaedt datastructure are messed up:

In our workflow (EVDE), the mesh setup (mesh settings, and mesh subregions) in AEDT is correct nevertheless, so it is not an urgent issue for us right now, but for other workflows that rely more on the pyaedt mesh data structure for subsequent operations with the mesh this might cause serious issues.

I assume that the algorithm to find the correct name to assign can be significantly simplified in 24R2 (and possibly other releases) since the property "Assginment" of the AEDT Mesh object holds exactly the name that is required (below data is taken from the mesh object named "MeshRefinementRegion":

Steps To Reproduce

Our workflow is too complex to give a pyaedt script, but here are the steps that should reproduce this issue:

• Create a number of boxes in an AEDT Icepak project
• Assign a mesh region to the first box through the icepak_handler.mesh.assign_mesh_region() method (assignment: Box1, name: Box1Mesh)
• Assign a mesh region to the second box with the same command (assignment: Box2, name: Box2Mesh) and observe the behavior of the MeshIcepak.MeshRegion.assignment getter method.

We're currently using pyaedt 0.9.10, but the affected method did not change in the latest version.

Which Operating System are you using?

Windows

Which Python version are you using?

3.10

Installed packages

python -m pip freeze
annotated-types==0.7.0
ansys-pythonnet==3.1.0rc3
attrs==23.2.0
bottle==0.12.25
build==0.10.0
certifi==2024.7.4
cffi==1.16.0
cfgv==3.4.0
charset-normalizer==3.3.2
clr-loader==0.2.6
colorama==0.4.6
contourpy==1.2.1
coverage==7.6.0
cycler==0.12.1
defusedxml==0.7.1
distlib==0.3.8
exceptiongroup==1.2.2
filelock==3.15.4
fonttools==4.53.1
fpdf2==2.7.9
identify==2.6.0
idna==3.7
iniconfig==2.0.0
jsonschema==4.23.0
jsonschema-specifications==2023.12.1
kiwisolver==1.4.5
matplotlib==3.9.1
nodeenv==1.9.1
numpy==1.26.4
packaging==24.1
pandas==2.2.2
pillow==10.4.0
platformdirs==4.2.2
pluggy==1.5.0
plumbum==1.8.3
pooch==1.8.2
pre-commit==3.7.1
psutil==6.0.0
py==1.11.0
pyaedt==0.9.10
pycparser==2.22
pydantic==2.8.2
pydantic_core==2.20.1
pyedb==0.22.0
pyparsing==3.1.2
pyproject_hooks==1.1.0
pytest==7.2.2
pytest-cov==4.0.0
pytest-timeout==2.1.0
pytest-xprocess==0.22.2
python-dateutil==2.9.0.post0
pytomlpp==1.0.13
pytz==2024.1
pyvista==0.42.3
pywin32==306
PyYAML==6.0.1
referencing==0.35.1
requests==2.31.0
rpds-py==0.19.1
rpyc==6.0.0
Rtree==1.3.0
scikit-rf==1.1.0
scipy==1.14.0
scooby==0.10.0
six==1.16.0
toml==0.10.2
tomli==2.0.1
typing_extensions==4.12.2
tzdata==2024.1
urllib3==2.2.2
virtualenv==20.26.3
vtk==9.3.1
waitress==2.1.2