[romant]

Hej,

I have a problem with the stl fileformat and the snappyHexMesh tool. The dimensions in the stl file format are as always given in mm, because all 3D cad programs (SolidEdge V20 in my case) export the original ISO dimensions. The problem now is that snappyHexMesh uses m as input, is there any way to define a scaling factor for snappyHexMesh?

[Xabi]

Hi Roman,

You can use the following command:

transformPoints -scale '(1e-3 1e-3 1e-3)'

I hope it works.
Best regards,

Xabi

[josp]

Or you can scale the stl files with surfaceConvert when you clean them

surfaceConvert in.stl out.stl -clean -scale 0.001

[romant]

Originally Posted by Xabi

You can use the following command:

transformPoints -scale '(1e-3 1e-3 1e-3)'

Yeah I was looking at that, and it will work after meshing with the same order of magnitude of the numbers and then converting the mesh.

I will try it as soon as I have my model ready. Thank you

Worked perfectly. Thanks again

[fabian_roesler]

Hi

I know that this is an old thread. However, it might be interesting for some of you, that one does not have to scale stl files before using them as input in snappyHexMesh. Nor does one have to mesh in mm units and scale the total mesh with transformPoints after meshing.
SnappyHexMesh offers a scaling option for geometry and features:

geometry
{
    cube.stl
    {
        type triSurfaceMesh;
        scale 0.001;
        name cube;
    }
};

features
(
    {
        file "cube.eMesh";
        scale 0.001;
        level 7;
    }
);

With this option, one can extract features from mm scaled stl files and use both, stl and features in snappy.

Cheers

Fabian

[JasonG]

Am I correct in assuming that the units are only relative? If I have an stl that is in inches and I wish to ultimately solve a case within OpenFOAM in inches, then there should be no converting required correct?

[kmooney]

Hi Jason,

You can't make that assumption. All of OF is in metric units which also includes material parameters [K, mu, etc..] and flow dimensions [p, U, T, etc..]. You really just have to do everything in metric and in meters.

Cheers,
Kyle

[JasonG]

Hi Kyle,

I have always understood the unit system to be relative, meaning you only need to make certain the dimension vector for a given parameter agrees with the unit system for the mesh and other parameters utilized. I have been using USCS units with inches for steady-steady incompressible flow models.

I believe section 4.2.6 of the following link addresses this.

http://www.openfoam.org/docs/user/ba...18-1000004.2.6


-Jason

[kmooney]

Hi Jason,

Its true you can operate outside of metric if you change all of the constants and material properties. I was under the impression you were planning on switching only your lengths from metric to US while leaving things like viscosity and the other constants in metric.

Its impressive though! I've never heard of anyone actually running OF in a non-metric mode.

Cheers,
Kyle

[JasonG]

I resisted as much as I could to not use it, the largest pain with USCS is wrapping your head around slugs and super-slugs when dealing with converting the viscosity and density.

I doubt the aerospace industry in the US will ever convert to a proper system

Getting my viscous layers to properly form in snappyhexmesh is proving to be more of a challenge, currently.

[obelix314]

Hallo Fabian,

Originally Posted by fabian_roesler

geometry
{
    cube.stl
    {
        type triSurfaceMesh;
        scale 0.001;
        name cube;
    }
};

features
(
    {
        file "cube.eMesh";
        scale 0.001;
        level 7;
    }
);

With this option, one can extract features from mm scaled stl files and use both, stl and features in snappy.

Have you actually tried this ? For the stl-files it is working but not for the .eMesh-files. sHM simply ignores the scaling for the features. This can also be seen from the log during meshing, when looking at the bounding box of the Feature line extraction.

Thomas

[fabian_roesler]

You are absolutely right. I tried with a simple STL where the feature is at (0, 0) and thus stays there even without scaling. So I posted my findings here. After proceeding with a more complex geometry I recognized what you posted but simply forgot posting the correct answer here.
So thank you for correcting the wrong info in the thread. For those who still want to use the scaling there are two methods to go on:
1. Scale the eMesh files manual
2. Change snappyHexMesh code to use scaling as I posted

Cheers

Fabian