Coordinate offset when importing stl file

chripasch · October 8, 2014, 09:07

Hello all together.

I would appreciate if somone could help me with the following problem:

I am drawing a geometry with CAD (AutoCAD Civil 2D 2013) ansd am exporting it as stl-file to import it to FLOW-3D.
With version 9, there was no problem. Since version 10, I got an offset in the point of origin. For example, in CAD the point is (x,y,z) = (0,0,0). Importing it to FLOW-3D, it is moved very little in the range of e-07. With version 10, I just used the option of translating the component in the other direction with the same value and obtained a zero. That does not work with version 11. Using the "method" described above, the offset then changes prefix and reaches an even smaller value.

I attached a screenshot where you can ee the offsets in x-, y- and z-direction. It is not geometry-dependent, I have the problem with all stl-files I create / use.

Thank you very much for your help.

JBurnham · October 14, 2014, 19:34

The offsets are numerical and are related to significant number of digits in the computer. They may be appearing just in the user interface, and not in the solver, and if they appear in both the offset will be different in the user interface vs. the solver.

Therefore you don't want to try to fix the offset reported when it's E-7 or less. If that amount of difference matters, use a different unit system.

Make sure you're using binary-format .stl files. Not only are they smaller, but they have a set number of significant digits for each coordinate, so they are less likely to show the offset. ASCII-format .stl files can have too many digits in them and sometimes caused significant offset effects prior to FLOW-3D v11.

chripasch · October 17, 2014, 09:46

Hello Jeff

Thank you for your helpful reply.
True, tchnically the minimal offset is not a problem. But I wasn't sure if it could lead to problems for the solver if there is a minimal gap. Szenario: I want to place the Xmin-BC to x = 0 (which should coincide with x = 0 of the geometry). If the software "thinks" the geometry starts at x = 0.00001 for example, there is a small gap which could possibly (!) cause problems.

Anyhow, I tested the export as binary- ans ASCII-STL file. They both lead to the same offsets.

From my point of view, the question can be "closed".
Thanks again.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
wmake compiling new solver	mksca	OpenFOAM Programming & Development	14	June 22, 2018 07:29
[OpenFOAM] Annoying issue of automatic "Rescale to Data Range " with paraFoam/paraview 3.12	keepfit	ParaView	60	September 18, 2013 04:23
[swak4Foam] swak4Foam-groovyBC build problem	zxj160	OpenFOAM Community Contributions	18	July 30, 2013 14:14
[swak4Foam] funkySetFields compilation error	tayo	OpenFOAM Community Contributions	39	December 3, 2012 06:18
Version 15 on Mac OS X	gschaider	OpenFOAM Installation	113	December 2, 2009 11:23

October 14, 2014, 19:34		#2
JBurnham Senior Member Jeff Burnham Join Date: Apr 2010 Posts: 204 Rep Power: 17	The offsets are numerical and are related to significant number of digits in the computer. They may be appearing just in the user interface, and not in the solver, and if they appear in both the offset will be different in the user interface vs. the solver. Therefore you don't want to try to fix the offset reported when it's E-7 or less. If that amount of difference matters, use a different unit system. Make sure you're using binary-format .stl files. Not only are they smaller, but they have a set number of significant digits for each coordinate, so they are less likely to show the offset. ASCII-format .stl files can have too many digits in them and sometimes caused significant offset effects prior to FLOW-3D v11.

October 17, 2014, 09:46		#3
chripasch Member Chris Join Date: Jun 2014 Posts: 39 Rep Power: 12	Hello Jeff Thank you for your helpful reply. True, tchnically the minimal offset is not a problem. But I wasn't sure if it could lead to problems for the solver if there is a minimal gap. Szenario: I want to place the Xmin-BC to x = 0 (which should coincide with x = 0 of the geometry). If the software "thinks" the geometry starts at x = 0.00001 for example, there is a small gap which could possibly (!) cause problems. Anyhow, I tested the export as binary- ans ASCII-STL file. They both lead to the same offsets. From my point of view, the question can be "closed". Thanks again.