Moving complex surfaces

Moderator: GiD Team

Post Reply
wilson
Posts: 2
Joined: Fri Jun 05, 2015 2:35 pm

Moving complex surfaces

Post by wilson »

Dear all,

am currently working on a (complex) geometry (only points, lines, surfaces), which I first created close to the origin of the coordinate system (0,0,~600). As an example please see the following image, which displays a part of the entire structure:
00_spillway_normalRendering_original.png
00_spillway_normalRendering_original.png (12.01 KiB) Viewed 4063 times
For some reason, I wanted to move it to its exact (metrical) geographical coordinates, say translating it to approximately x+500000.000m, y+3100000.000 and then rotating it by some 20 degrees. I noted that the geometry looked somwhow screwed up as shown here:
01_spillway_normalRendering.png
01_spillway_normalRendering.png (17.06 KiB) Viewed 4063 times
First, I did not pay attention to it and thought that it must be a rendering problem, but as the entire structure looked pretty arkward, I decided to check. I generated a mesh, exported it to stl and got this message:
02_spillway_mesh_smoothRendering_afterStlExport_message.PNG
02_spillway_mesh_smoothRendering_afterStlExport_message.PNG (108.72 KiB) Viewed 4063 times
Then I loaded the stl file into Paraview and fully surprised I took note that the entire geometry (and mesh) is just screwed. Here is a detail:
03_spillway_mesh_stl_paraview_detail.png
03_spillway_mesh_stl_paraview_detail.png (40.39 KiB) Viewed 4063 times
I use GiD x64 v.10.2.0d. I think the problem arised after the translation/rotation, but it might also been caused when I probably "undid" some last actions. However, is there a way to get the geometry repaired?

Unfortunately, my last correct backup is 5 days old and I lost 3 days. Therefore, I would be happy about any hint! Thank you very much in advance!

Best regards
Stefan
User avatar
escolano
Posts: 1918
Joined: Sun Sep 05, 1982 10:51 pm

Re: Moving complex surfaces

Post by escolano »

When you have translated your model to x+500000, y+3100000 (it seems typical UTM coordinates) then you are loosing some precision,
this is already not a problem for the GiD model and its preprocess mesh, because we store them with double precision variables (8 Bytes)
but drawing it you will note the related 'staircase artifacts', because OpenGL use float variables (4 Bytes single precision).

a float real has about 7 significative digits (a double has about 15),
in this case the y=3.1e6 is the main problem because it is close to reach this limit and then the truncation could be graphically seen as 'stairs' (and graphical selection will be problematic also)

Dont' worry about the backup. The internal double precission of your model is good enough, and if do you translate again your model close to the origin (0,0,0) the graphical artifacts will disappear.

About the export to STL.
The GiD warning say that according with the STL specification, a valid STL must be a collection of triangles that your enclose a single volume, and your model don't match this definition (e.g. surfaces don't close any volume, or do you have more than one!!)
But the triangles could be written to the STL file.

Usually STL are ASCII files, and number are written as text with an additional truncation of the internal (double) representation,
depending on the format (fixed of exponential and the number of decimals to write) you will lost some precission that is relevant in your example.

It seems that you have exported the STL triangle mesh with
Files->Export->Using template->STL
This is using a simple template (file STL.bas located in the \templates GiD folder), that is currently using this C/C++ format for the coordinates.
*realformat "%15.9g"
You can change it editing the STL.bas, but it seems a big enought format.

Maybe the STL file written it too truncated, or maybe Paraview (that also uses OpenGL as graphic library) is experiencing the same truncation problems as GiD drawing 'too big (>1e7) coordinates.

In any case is a bad idea to work with big coordinates, if to you do a numerical simulation you must be careful with the amount of decimals of input/output files, and internally maybe the rounding errorr could affect so much the solution. It is better to work with a translated and/or scaled model in appropiated units, and after revert this transformation.
wilson
Posts: 2
Joined: Fri Jun 05, 2015 2:35 pm

Re: Moving complex surfaces

Post by wilson »

Dear Escolano,

thank you very much for your quick and excelllent advice! I understood the problem and could roll back the model to a state in which all is working well. I will then follow your suggestion and continue to set the model up within a frame close to (0, 0, 0).

Best regards
Stefan
Post Reply