[Robat]

Hello dear Foamers!

The basic: I'm working with a meshing tool which handles with millimeters (Salome) and the ideasUNVToFoam interpretes it as meters, so it needs to be "convertToMeters" with transformPoints (-scale).
My case: A flow though a blood artery bifurcation at millimeter scale. The walls are really "natural" shaped so I not expected the best mesh quality (hexahedric mesh).

I ran checkMesh before scaling: Everything was "OK". Non-orthogonality was pretty high (=60), but below the limit (=70).

After scaling (transformPoints -scale '(0.001 0.001 0.001)') the second check gave the following results:
- non-orthogonality raised to 150
- wrong oriented faces
- skewness jumped above 13.000.000
- and with smaller scaling even negative cell volumes occur

I'm copletely perplexed! Correct me if I'm wrong, but a simple scaling should have no effect on mesh quality.

Please could someone give me some advise how to keep my mesh quality when scaling or at least by what this quality lost is caused ?

Thanks in advance,
Robert

[Robat]

I found the point where the problem occured on my own!
The file format precision reducing with the distance between model and coordinate triangle.

Bye
Robert

[alopenfoam]

Hello,
I have the same Issue and didn't understand the Solution. Perhaps you are still here Robert and can describe your solution method ?!
I have the same Problem. The maxskewness value rises after downscaling with transformPoints. Another way I tried was to scale the Mesh in Salome and Output it to Openfoam. Both ways are giving the same big skewness value.

Without scaling: maxskewness is about 0.6
After scaling: maxskewness is about 3.4

So I tried this with an normal cube. Building and Meshing in Salome with an Cellsize of 0.01mm. Output with unv to Openfoam -> All Fine.
But with an Cellsize of 0.001mm I get big skewness values. Anybody an idea ? I don't think its logical because a normal cube must have an skewness value of about 0. Right ?


Artur

[Robat]

Hi Artur,

sorry for the late response, I thought this thread was dead/done.

The unv file format saves coordinates in a scientific form like:
cell_coordinate1 = 0.001100 * 10^0
cell_coordinate2 = 0.003200 * 10^0
These coordinates are near the coordinate center. But my model was small and far far away from the coordinate center. So if we move the points above i.e. 1000 units away from the center, the values SHOULD look like:
cell_coordinate1 = 1.000001100 * 10^3
cell_coordinate2 = 1.000003200 * 10^3
But the decimal places are limited (.6 ?). So whats really saved is:
cell_coordinate1 = 1.000001 * 10^3
cell_coordinate2 = 1.000003 * 10^3
As you can see the smaller decimal places are cut off and the model values are affected. If we would move the point even more away
cell_coordinate1 = 1.000000 * 10^4
cell_coordinate2 = 1.000000 * 10^4
the values no longer differ and the cell thickness would be zero.

Thats what I meant with "The file format precision reduces with the distance between model and coordinate triangle."

With keeping my model close to the coordinate center, I avoided this problem.

Robert

[alopenfoam]

Hi Robert,
I've hoped this thread is not done

So now I understand your precision reason. And for that reason I think it's a bug.

I am not upscaling but downscaling the Mesh. Saving the Coordinates in the *.unv Format is done by 16 digits. Here is an Example of a Coordinate for my Mesh before and after the Scaling:
-2.3400000000000000E+02 -> scale 1E-06 -> -2.3400000000000000E-04

So I don't think I'm loosing some Information about the Mesh. Anyway the Skewness rises from for example 1.3 to 3.7 after Scaling. I've looked into the Source Code and as long as I understood the computation the Skewness don't have to change.

Since my computations work it is not a big problem. I only want to recognize the failure in my work.

Artur