ansys
Mesh exported as CDB cannot be loaded into Mechanical via External Model
🔍 Before submitting the issue
- [X] I have searched among the existing issues
- [X] I am using a Python virtual environment
🐞 Description of the bug
When importing a CDB file exported from PyPrimeMesh into Mechanical via the External Model component in Workbench, the following error occurs (when refreshing the Mechanical Model cell):
-
The model can be loaded into MAPDL, and after being exported from there via
ALLSEL CDWRITE,ALL,<FILENAME>,CDBthe import to Mechanical via External Model works.
-
It's unclear to me whether the problem lies within PyPrimeMesh (generating an invalid CDB), or External Model / Mechanical.
-
The following Workbench archive (renamed to
.zipdue to Github's restrictions) contains these two cases:- systems A & B: CDB directly from PyPrimeMesh (doesn't work)
- systems C & D: CDB converted via MAPDL (works)
📝 Steps to reproduce
- Run the bracket example, keeping the generated
.cdbinstead of discarding it - Create a new Ansys Workbench project, adding an "External Model" component
- Load the
.cdbinto the External Model component - Connect the External Model component to a "Mechanical Model" component as follows
- Update the project
💻 Which operating system are you using?
Windows
📀 Which ANSYS version are you using?
Tested on 2024R1, and 2025R1 (daily build)
🐍 Which Python version are you using?
3.10
📦 Installed packages
aiohttp==3.9.5
aiosignal==1.3.1
ansys-api-meshing-prime==0.1.2
ansys-meshing-prime==0.5.1
anyio==4.4.0
appdirs==1.4.4
argon2-cffi==23.1.0
argon2-cffi-bindings==21.2.0
arrow==1.3.0
asttokens==2.4.1
async-timeout==4.0.3
attrs==23.2.0
beautifulsoup4==4.12.3
bleach==6.1.0
certifi==2024.6.2
cffi==1.16.0
charset-normalizer==3.3.2
colorama==0.4.6
comm==0.2.2
contourpy==1.2.1
cycler==0.12.1
debugpy==1.8.1
decorator==5.1.1
defusedxml==0.7.1
exceptiongroup==1.2.1
executing==2.0.1
fastjsonschema==2.19.1
fonttools==4.53.0
fqdn==1.5.1
frozenlist==1.4.1
grpcio==1.64.1
idna==3.7
ipykernel==6.29.4
ipython==8.25.0
ipywidgets==8.1.3
isoduration==20.11.0
jedi==0.19.1
Jinja2==3.1.4
jsonpointer==2.4
jsonschema==4.22.0
jsonschema-specifications==2023.12.1
jupyter-events==0.10.0
jupyter_client==8.6.2
jupyter_core==5.7.2
jupyter_server==2.14.1
jupyter_server_proxy==4.1.2
jupyter_server_terminals==0.5.3
jupyterlab_pygments==0.3.0
jupyterlab_widgets==3.0.11
kiwisolver==1.4.5
MarkupSafe==2.1.5
matplotlib==3.9.0
matplotlib-inline==0.1.7
mistune==3.0.2
more-itertools==10.2.0
msgpack==1.0.8
multidict==6.0.5
nbclient==0.10.0
nbconvert==7.16.4
nbformat==5.10.4
nest-asyncio==1.6.0
numpy==1.26.4
overrides==7.7.0
packaging==24.0
pandocfilters==1.5.1
parso==0.8.4
pillow==10.3.0
platformdirs==4.2.2
pooch==1.8.1
prometheus_client==0.20.0
prompt_toolkit==3.0.46
protobuf==3.20.3
psutil==5.9.8
pure-eval==0.2.2
pycparser==2.22
Pygments==2.18.0
pyparsing==3.1.2
python-dateutil==2.9.0.post0
python-json-logger==2.0.7
pyvista==0.43.8
pywin32==306
pywinpty==2.0.13
PyYAML==6.0.1
pyzmq==26.0.3
referencing==0.35.1
requests==2.32.3
rfc3339-validator==0.1.4
rfc3986-validator==0.1.1
rpds-py==0.18.1
scooby==0.10.0
Send2Trash==1.8.3
simpervisor==1.0.0
six==1.16.0
sniffio==1.3.1
soupsieve==2.5
stack-data==0.6.3
terminado==0.18.1
tinycss2==1.3.0
tornado==6.4
traitlets==5.14.3
trame==3.6.2
trame-client==3.1.0
trame-server==3.0.1
trame-vtk==2.8.8
trame-vuetify==2.5.0
types-python-dateutil==2.9.0.20240316
typing_extensions==4.12.1
uri-template==1.3.0
urllib3==2.2.1
vtk==9.3.0
wcwidth==0.2.13
webcolors==1.13
webencodings==0.5.1
websocket-client==1.8.0
widgetsnbextension==4.0.11
wslink==2.0.4
yarl==1.9.4
From my understanding, #669 should be fixed with recent 2025R1 builds, whereas I still observed the described error.
