Bug located in scdocx files generated by geometry service.
Opened this issue · 11 comments
🔍 Before submitting the issue
- I have searched among the existing issues
- I am using a Python virtual environment
🐞 Description of the bug
In my saf-solution (using pydiscovery), I generate a scdocx file with the spaceclaim software and I can visualize it with a viewer on my saf-based solution UI.
Now, I would like to use pygeometry and geometry service to create a scdocx file instead of using pydiscovery and spaceclaim.
I succeeded to do that but the scdocx generated by the geometry service is not visualized by the viewer.
So I compared two scdocx files: one generated by spaceclaim and the second generated by the geometry service. They are not the same.
For example, the size of the one generated by spaceclaim is almost 3 times larger than the one generated by geometry service.
Please, So I need the scdocx generated by geometry service to be identical to the one generated by spaceclaim.
📝 Steps to reproduce
- Create a scdocx file with geometry service
- Create a scdocx file with spaceclaim
- Compare both scdocx files
💻 Which operating system are you using?
Windows
📀 Which ANSYS version are you using?
Spaceclaim 24.1
Pyegometry 0.4.dev0
🐍 Which Python version are you using?
3.10
📦 Installed packages
aiofiles==23.2.1
aiomysql==0.2.0
aiosqlite==0.19.0
annotated-types==0.6.0
ansi2html==1.8.0
ansys-api-dbu==0.2.1
ansys-api-geometry==0.3.2
ansys-api-platform-instancemanagement==1.0.0
ansys-dash-treeview==0.0.1.dev0
ansys-geometry-core @ git+https://github.com/ansys/pyansys-geometry.git@d5ddc6cd091c8370448e9c5f4c31db555cee4d04
ansys-platform-instancemanagement==1.1.2
ansys-saf-glow==0.4.0
ansys-saf-portal==0.5.dev1
ansys-solutions-3d-viewers @ git+https://github.com/Solution-Applications/ansys-solutions-3d-viewers.git@dfb393aecdc4fc2f79487042f62bc9a23c23c2a2
ansys-solutions-dash-lib==0.4.7
-e git+https://github.com/Solution-Applications/pygeometry_poc.git@f9bd1d22b3260cc39747f6c7b2446a5e7b3924d5#egg=ansys_solutions_pygeometry_poc
ansys-tools-path==0.3.2
anyio==4.0.0
asgiref==3.7.2
async-timeout==4.0.3
backoff==2.2.1
beartype==0.16.4
bottle==0.12.25
bson==0.5.10
cachelib==0.9.0
cachetools==5.3.2
certifi==2023.7.22
cffi==1.16.0
chardet==5.2.0
charset-normalizer==3.3.1
click==8.1.7
clr-loader==0.2.6
colorama==0.4.6
contourpy==1.1.1
cryptography==41.0.5
cycler==0.12.1
dash==2.14.0
dash-bootstrap-components==1.5.0
dash-core-components==2.0.0
dash-extensions==0.1.13
dash-html-components==2.0.0
dash-iconify==0.1.2
dash-table==5.0.0
dash-uploader==0.6.0
debugpy==1.8.0
Deprecated==1.2.14
distlib==0.3.7
EditorConfig==0.12.3
exceptiongroup==1.1.3
fastapi==0.100.1
filelock==3.12.4
Flask==2.2.5
Flask-Caching==2.0.2
fonttools==4.43.1
google-api-core==2.12.0
google-api-python-client==2.105.0
google-auth==2.23.3
google-auth-httplib2==0.1.1
googleapis-common-protos==1.61.0
greenlet==3.0.1
grpcio==1.59.0
grpcio-health-checking==1.48.2
h11==0.14.0
httpcore==0.16.3
httplib2==0.22.0
httpx==0.23.3
idna==3.4
importlib-metadata==6.8.0
itsdangerous==2.1.2
Jinja2==3.1.2
jsbeautifier==1.14.9
kiwisolver==1.4.5
MarkupSafe==2.1.3
matplotlib==3.8.0
more-itertools==9.1.0
nest-asyncio==1.5.8
networkx==3.2
numpy==1.26.1
opentelemetry-api==1.20.0
opentelemetry-exporter-otlp==1.20.0
opentelemetry-exporter-otlp-proto-common==1.20.0
opentelemetry-exporter-otlp-proto-grpc==1.20.0
opentelemetry-exporter-otlp-proto-http==1.20.0
opentelemetry-instrumentation==0.41b0
opentelemetry-instrumentation-asgi==0.41b0
opentelemetry-instrumentation-fastapi==0.41b0
opentelemetry-instrumentation-flask==0.41b0
opentelemetry-instrumentation-httpx==0.41b0
opentelemetry-instrumentation-logging==0.41b0
opentelemetry-instrumentation-wsgi==0.41b0
opentelemetry-proto==1.20.0
opentelemetry-sdk==1.20.0
opentelemetry-semantic-conventions==0.41b0
opentelemetry-util-http==0.41b0
packaging==23.2
pandas==2.1.1
Pillow==10.1.0
Pint==0.22
platformdirs==3.11.0
plotly==5.17.0
pluggy==1.3.0
pooch==1.8.0
protobuf==3.20.3
proxy-tools==0.1.0
psutil==5.9.6
pyasn1==0.5.0
pyasn1-modules==0.3.0
pycparser==2.21
pydantic==2.4.2
pydantic-settings==2.0.3
pydantic_core==2.10.1
PyMySQL==1.1.0
pyparsing==3.1.1
pyproject-api==1.6.1
pyshortcuts==1.9.0
python-dateutil==2.8.2
python-dotenv==1.0.0
python-json-logger==2.0.7
python-multipart==0.0.6
pythonnet==3.0.3
pytz==2023.3.post1
pyvista==0.42.3
pywebview==4.3.3
pywin32==306
PyYAML==6.0.1
requests==2.31.0
retrying==1.3.4
rfc3986==1.5.0
rsa==4.9
scipy==1.11.3
scooby==0.9.2
setuptools-scm==8.0.4
six==1.16.0
sniffio==1.3.0
SQLAlchemy==2.0.22
starlette==0.27.0
tenacity==8.2.3
toml==0.10.2
tomli==2.0.1
tox==4.11.3
typing_extensions==4.8.0
tzdata==2023.3
uritemplate==4.1.1
urllib3==2.0.7
uvicorn==0.23.2
virtualenv==20.24.6
vtk==9.2.6
Werkzeug==2.2.3
wrapt==1.15.0
zipp==3.17.0Seems to me like it is an issue on the side of the viewer, right? Have you tried opening the SCDOCX file with a common product such as Ansys Discovery or SpaceClaim on your local, and check the differences?
Seems to me like it is an issue on the side of the viewer, right? Have you tried opening the SCDOCX file with a common product such as Ansys Discovery or SpaceClaim on your local, and check the differences?
Yes, I tried opening the SCDCOX file with spaceclaim.
-
What I see when I open the scdocx file generated with geometry service
-
What I see when I open the scdocx file generated with spaceclaim
Is the difference in the license used?
They seem to be exactly the same to me... Geometry Service and Discovery use the same license.
Have you tried opening the SCDOCX from the Geometry Service with Ansys Discovery?
My point in all this is that the SCDOCX that comes out seems to be the same... Might be an issue on the way you are reading the file on your SAF app?
@RobPasMue SAF app is not reading any scdocx file and has no way to read a scdocx. In Ansys, we have an AVZ viewer that is used by some of our customers to visualize and manipulate the geometries on web-client app. What we are reporting here is that depending on whether this geometry is generated directly from SpaceClaim 24R1 or the geometry service (docker container) the scdoc file is readable or not by the viewer.
Can't you use PyVista directly from your app? You can ask for a plot and represent it in your application. That way you get the tesselated object
@RobPasMue using PyVista in our use case is not an option.
I'll leave it up to @b-matteo in that case but I don't see an easy solution really... and it doesn't seem to be an issue with the PyAnsys Geometry library
I do not believe it has anything to do with the pygeometry layer. I'll take it with @b-matteo
@RobPasMue, @asbfall i spoke with my team, the difference comes from the lightweight format we chose for the geometry service, more fit for a remote usage. Lightweight means that all the geometrical information are in there, but not the preview ones. I can plan to add an option to the ApiServer download method to be able to ask for a complete file DL. That will imply some work on the GeometryService itself too.