Bug located in scdocx files generated by geometry service.

ansJBoly commented 9 months ago

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] 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.0

RobPasMue commented 9 months ago

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?

RobPasMue commented 9 months ago

Pinging @b-matteo and @jonahrb for visibility

ansJBoly commented 9 months ago

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?

RobPasMue commented 9 months ago

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?

RobPasMue commented 9 months ago

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?

asbfall commented 9 months ago

@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.

RobPasMue commented 9 months ago

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

asbfall commented 9 months ago

@RobPasMue using PyVista in our use case is not an option.

RobPasMue commented 9 months ago

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

asbfall commented 9 months ago

I do not believe it has anything to do with the pygeometry layer. I'll take it with @b-matteo

b-matteo commented 9 months ago

@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.

ansys / pyansys-geometry