[AeroIQ]

A company I am associated with has been experimenting with simulating water flow resistance coefficients for large passenger ships, in full scale. To obtain a mesh with y+ ~ 1 under these conditions would require first layer thickness of 4e-6 m. However the geometry domain would have to extend up to 1000 m in length and 200 m in width. Including small features in a large domain is a well-known challenge in meshing, and pushes both the limits of double precision accuracy and the memory capacity of the computers used for meshing (mesh size).

In an attempt to understand the limitations for the above application, I ran into a strange issue in Pointwise V17.2 R2. I created a 2D 2-cell domain as depicted in the attached mesh.png (dimensions 10 x 1). The nodal points are hand-placed at x=0 and x=10 (no decimals). The segment division is set to 3. Then the mesh is extruded in the y-direction.

Now, when I exported it to a Fluent .cas file, this is how the node coordinates looked like in the .cas file:

(0 "Zone : 1 Number of Nodes : 6")
(10 (1 1 6 1 2)(
0.000000000000000e+00 0.000000000000000e+00
5.000000000000000e+00 0.000000000000000e+00
1.000000000000000e+01 0.000000000000000e+00
-4.509013245978244e-04 9.989873815144565e-01
5.000000000000000e+00 9.998741695160515e-01
1.000045090132460e+01 9.989873815144564e-01
))

What strikes me is the low accuracy in the precision of the nodal coordinates. The coordinates should in theory be (0,0), (5,0), (10,0), (0,1), (5,1) and (10,1).

Why does this happen? And if this happens in such a simple geometry model, then what should be done to avoid it in a real application with a large domain and small features?

I am also attaching the tolerances I used.

[cnsidero]

The range of scales you indicate - 4e-6 to 1000 is about 9 order of magnitude - no where near the boundaries of double-precision floating point representation. The IEEE754 double-precision binary floating-point format allows 53-bits for precision which yields about 16 orders of magnitude (53 log10(2) = 15.955). Checkout the wikpedia page: https://en.wikipedia.org/wiki/Double...g-point_format . This is of course provided the numbers are normalized.

Now we know range is not an issue for your case with double-precision floats, let's review the format in Fluent .cas file snippet you posted. Here's one number as an example:

-4.5090 1324 5978 244e-04

I inserted spaces in the significand to make it clearer. You'll notice there are 16 digits in the significand. So the format used is in fact double precision. The actual format used, in C-style printf format string, appears to be something like %.*e.

As to why the some of the numbers aren't exactly to the numbers you perhaps input? There could be some round off error incurred with the internal algorithm(s) between your input and where the output is generated. Any floating point operation that uses finite precision numbers suffers from round off error of some degree. Having said that if you indeed used, for example, exactly a value 1 but 9.989873815144565e-01 is the result, it would seem the round off is a bit excessive. However, there may be a lot of operations going on in between the initial input and eventual output.

I don't see an issue with how the accuracy of the floats stored in the file. If your issue is the difference between your input and the actual output, you would need to provide more information (ideally the actual .pw file) to better determine what is happening.

-Chris

[AeroIQ]

Thanks for the reply and guidance.

I am aware of the double precision specification, and, while I do not disagree with you per se, whether the precision is sufficient also seems to depend on where in the large geometry domain the small features are located. The number representation accuracy is different in the vicinity of the origin than it is at "away", say at 1 km. There are several references in the gaming graphics community, see e.g. http://www.gamasutra.com/view/featur...ats.php?page=1, to explain this. For single precision floats the given dimensions are problematic, but not necessarily so with dp...

Originally Posted by cnsidero

If your issue is the difference between your input and the actual output, you would need to provide more information (ideally the actual .pw file) to better determine what is happening.
-Chris

... yet my issue is not whether dp is sufficient for the big ship case. My issue is precisely the difference between the input and the file result in the simple example. You should be able to reproduce what I did based on the information in the first post. Having specified the tolerances, all I did was draw a horizontal (x-dir, fixed) line segment with integer coordinates. Then I specified 2 divisions, and extruded one cell towards north (y-dir, normal). This was then exported to a Fluent .cas file for analysis.

Thanks again for your help.

[dgarlisch]

FYI, numerical precision has been improved starting in Pointwise V18.0R1. I suggest you upgrade if possible.

That being said,


I exported your grid using V18 and generated this output:

(0 "Zone 1 Number of Nodes : 6")
(10 (1 1 6 1 2)(
0.000000000000000e+00 0.000000000000000e+00
5.000000000000000e+00 0.000000000000000e+00
1.000000000000000e+01 0.000000000000000e+00
0.000000000000000e+00 1.000000000000000e+00
5.000000000000000e+00 1.000000000000000e+00
1.000000000000000e+01 1.000000000000000e+00
))


I exported the same grid using V17.2R2 and got the same output:

(0 "Zone : 1 Number of Nodes : 6")
(10 (1 1 6 1 2)(
0.000000000000000e+00 0.000000000000000e+00
5.000000000000000e+00 0.000000000000000e+00
1.000000000000000e+01 0.000000000000000e+00
0.000000000000000e+00 1.000000000000000e+00
5.000000000000000e+00 1.000000000000000e+00
1.000000000000000e+01 1.000000000000000e+00
))


When you did your extrude, which extrude type did you pick?

• Create, Extrude, Normal...
• Create, Extrude, Translate...

The Normal extrude will cause splay in the extrusion. Do multiple steps over a longer distance to visually see the splay.

You should use the Translate method to get linear extrusions.