[gustavoliveira]

Hello,


I am trying to use the snappyhexmesh to refine the mesh around the channel. I create a blockMesh with 2x2x2 cells and I would like to delimit and refine inside my stl file that represents the channel. But the quality of the cells after the snappyHexMesh doesnt look good. I would like cell around the boundaries of the stl file to be smoother. And on the y-axis the cells are bigger than another axis. I've tried a lot of things but I dont know how to improve. Can someone help me? I attached the results of the blockMesh, snappyHexMesh and the case.


Thanks a lot.

[Yann]

Hi Gustavo,

First thing: your STL looks pretty bad (see screenshot). I would not expect to get a clean mesh out of a bad STL file.

Second thing: the STL file does not fully intersect the blockMesh domain so snappy does not remove the unwanted part of the mesh when I try to mesh it.

By the way: which version of OpenFOAM are you using?

Regards
Yann

[gustavoliveira]

Hi Yann, thanks a lot.

Now I've atacched the case in the correct domain. The stl original is to big to be attached on the forum, so I cut it but I didnt test the case. Sorry about the that.

Really the stl file is very bad, I wasted some time filling the holes after I receveid it. But the first ~120 meters on the x-axis doesnt look too bad, dind it? And it is the main region of interest, and I'd expect that snappyHexMesh refine a little better mainly in the y-axis direction, or not?

By the way I'am using the openfoam9.

Thanks again.

[Yann]

OK so, this is a fun one!

Your geometry is very far away from the origin of the coordinate system: the STL file coordinates are about 6e6-7e6 meters.

The default mergeTolerance in snappyHexMeshDict is 1e-6 and the default writePrecision in controlDict is 6. It basically means you have a precision of 1 meter on your mesh, which explains the poor resolution you get on your mesh.

I translated your STL closer to the origin with this command:

surfaceTransformPoints "translate=(-666791 -7.77586e+06 -729.012)" constant/triSurface/canal9.stl constant/triSurface/canal9_translated.stl

Then I modified your Allrun scrip to also translate the initial mesh (after running blockMesh) and it seems to works better, as you can see on the screenshot. The geometry is still not very good, but this is related to the quality of the STL file.

You could probably also fix it by increasing the mergeTolerance and writePrecision, but I did not try it so I don't know if something else could mess up the mesh.

Cheers,
Yann

[gustavoliveira]

Looks great! Thank you so much! Do you know why snappyHexMesh needs to work with the domain near the origin?

[Yann]

I think this is only a matter of precision: with the default writePrecision of 6, if your coordinate is 100000m, then the nodes coordinates will have a precision down to the meter.

If the coordinate is 1m instead, the nodes coordinates will have a precision down to the hundredth of millimeter.

I think this is why you had this weird behavior where cells seem to be elongated along the y-axis: the coordinates get truncated with a precision lower than the actual cell size and this leads to distorted cells.

I am not sure my explanations are very clear, but if you want to have a look for yourself, change the write format from binary to ascii in your controlDict, and then compare the constant/polyMesh/points file of your original case with the one of the case I posted.

Regards,
Yann