Snap Precision to a STL Surface
2 Attachment(s)
Hi FOAMers !
I am now studying an airfoil and I would like to create the mesh around it with snappyHexMesh. When I ran some simulations, it gave me a high drag. Looking at the profile more precisely I saw that the stream line left the profile quite early (at least earlier than they should, which could be the cause of this higher drag. Looking more precisely, I saw that the profile did not respect well the NACA geometry which is normal as snappyHexMesh does not generate curves cells. I spent several hours looking for the parameters I should change to improve the precision of the snap to the surface and I could not find the solution. Do you know how can I improve the snapping ? You can find attached the bad surface I get and my snappyHexMeshDict File. Castellated Code:
Code:
snapControls Code:
addLayersControls Every help is welcome ! Thanks in advance ! |
Hi malaboss,
Try to install OF 2.2. Go to the new releases of OF 2.2 in the official web page and you will see that there are more parameters in the snapping part. The explicit utility works quite well. You can also try to increase the nSolveIter in the snap part. Hope this helps, David |
1 Attachment(s)
Hi David,
Thanks for the advices it helped me a lot. Increasing the solve iter from 30 to 1000 did not change anything first, I still had this "smooth castellated" mesh. Then, I upgraded my openFOAM to 2.2.x and used the featureHandlingEdge (actually I wasn't sure it was necessary to upgrade my openFoam for this, but there are many other improvment). I saw a lot of improvment as my surface respects now the STL File. I think the surface could me improved again is I increased the level in the castellated part. (I did this with level 4) Thank you ! |
2 Attachment(s)
Hi
I just tried a new simulation with the new geometry and you can find enclosed what I see for the pressure field. The quality of the snapping seems to be very important, for the fields near the wall. I am using Spalart allmaras for Re = 1000 000 Changing the castellatedMesh level from 4 to 6 (which increases a lot the amount of cells !) does not really change the problem. I enclosed also the new snappyHexMeshDict file I use. |
In addLayersControls try:
Code:
relativeSizes true; |
Thanks for the answer.
Actually I tried to change the layer mesh in many ways but it did not have any effect on the problem I showed above. I think the fact that my surface snapping is not entirely made of curves is the problem. As you can see, the low zones of pressure are located on the "angles" of my surface. Then, I think the problem is due to my snapping rather than my layer mesh I will give a try monday with your post and tell you about it. |
2 Attachment(s)
Hi FOAMers,
as I promised, I tested the new set of parameters proposed by JR22 for the layer. It did not really change the problem as I still see some jump of pressure of the angle parts of the surface. Moreover, it seems to create some weird pressure field. What I don't understand it that I could not see it when I applied the same parameters to a cylinder. I could get some correct result. But now with an airfoil, it became hard having a pressure field coherent with expectations. Again, if anyone has an idea, I would be delighted to hear it. |
Hi,
Can you upload the final mesh? |
3 Attachment(s)
Hi,
sure you can see the mesh ! I realized last night that I did not recheck my Yplus when I changed the layer controls. I replaced the Code:
finalLayerThickness 0.5; Code:
finalLayerThickness 1; However, the situation is quite the same... Here are three point of view : -One zoomed out with pressure represented : you can see the big jump of pressure on the left. -Two zoomed in screenshots representing only the mesh near the airfoil. On the trailing edge, there is some high non orthogonality. Elsewhere, the mesh is uniform but I see some high stretching from time to time. Check Mesh complains about 1 non orthogonality (it seems to be because of the trailing edge, so I don't think it is the problem here) What do you think about it ? |
Hi,
If you are running a highRe simulation I think that the yplus should be bigger than 30. If you want to control the real size of the layers you can select relativesizes: false. Have you checked if the geometry is smooth enough? |
1 Attachment(s)
Hi,
Thanks to your answer I saw that a problem comes from the STL surface itself. I generated a surface with splines and then extruded it with salome Meca. At this moment, Salome changed the accuracy of the geometry, and created the extrusion with triangle faces. You can find enclosed the stl surface viewed with discretizer set up. I posted a question on a salome forum and will tell you about it. About the weird pressure field, do you think it was due to this surface or something else ? Thank you again. |
Hi,
I know that with solidEdge you can select the accuracy of the geometry but I have no clue about salome. For sure there are open topics about the accuracy of the surface. To check the quality of the surface you can also run surfaceCheck |
Hi !
I looked for a solution with salome Meca and many people say it is impossible to change the precision of the Stl file generation in Salome. I use instead AutoCAD in which it is easy to control the number of facets of my STL file. In my version, I just have to use the function FACETRES This problem solved, I exported my file as a STL and used again snappyHexMesh. And I still had these jumps of pressure over my surface. I tried then to change many parameters, and I finally noticed that when I used the interpolation linear instead of upwind (in system/fvSchemes) everything suddenly went right ! I really do not understand why upwind generated such problem with the flow. I thought it could make the convergence easier, and modeled better the flows dominated by convection. Correct me if I am wrong but basically upwind is approximating the flow on a the frontier between 2 cells by the flow at the upstream cell. Linear is rather considering that the flow at the frontier of two cells is influenced by the upstream and the downstream equally. Upwind seemed to be a good deal to me, even if it is only first order accurate. |
Sometimes choosing inappropriate angle value with surfaceFeatureExtract command will result in to unresolved edges of the STL file. In other words not all the features of the STL surface are identified if you choose an inappropriate angle. Here is what I do:
Step-1: Use surfaceFeatureExtract with some angle to extract feature Step-2: Use surfaceFeatureConvert to convert the identified feature (you will only see edges) to an .obj file. E.g. surfaceFeatureConvert constant/triSurface/example.eMesh exmple_test.obj Step-3: Read .obj file with paraview and make sure that all the edges as they appear in the original STL surface are identified. Step-4: If you are happy you can proceed to snappyHexMesh operations else go to step-1 and continue with some other angle. Try and lets see if it works for others as well. |
Quote:
I tried to play around with pretty much all the snappyHexMeshDict parameters according to what I read on the forum, but nothing helps. In fact, I noticed that even when turning off the explicit utility, I still get the same rough edges... It looks like snappy doesn't use the features extracted at all. Any ideas about where this might come from? |
Have you checked if your stl file was precise enough ?
As I said on my previous message, my stl file was already extremly wavy. |
Yes I agree with malaboss. I think the .obj files give much better output than .stl.
|
All times are GMT -4. The time now is 07:56. |