CFD Online Discussion Forums - Possible bug or limitation in stl-generated surface for sampling analysis

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Post-Processing (https://www.cfd-online.com/Forums/openfoam-post-processing/)

- - Possible bug or limitation in stl-generated surface for sampling analysis (https://www.cfd-online.com/Forums/openfoam-post-processing/170240-possible-bug-limitation-stl-generated-surface-sampling-analysis.html)

Possible bug or limitation in stl-generated surface for sampling analysis

Hi,
In sampling results over surfaces, openfoam allows for using an stl-generated surface. For example in line 312 of $FOAM_UTILITIS/postProcessing/sampling/sample/sampleDict

Code:

 triSurfaceSampling   

 {     

    // Sampling on triSurface 

        type        sampledTriSurfaceMesh;      

        surface     integrationPlane.stl;       

        source      boundaryFaces;  // What to sample: cells (nearest cell)        

                           // insideCells (only triangles inside cell)   

                           // boundaryFaces (nearest boundary face)     

    interpolate true;   

  }

I'm currently working on the simulation of an impeller rotating in a cylindrical tank. Prior to applying the above method for sampling on complicated surfaces, I thought of first “validating” it by comparing the results with those obtained by using the cuttingPlane type. Since I have a cylindrical tank, the cutting plane along the cross-section, is a disk. So I made a disk in salome and exported it as stl. Here is the file for surface sampling:

Code:

surfaceSampling

{

    type            surfaces;

    functionObjectLibs ("libsampling.so");

    outputControl   outputTime;



    surfaceFormat   vtk;

    fields          (U);



    interpolationScheme cellPoint;



    

    surfaces

    (



     cuttingPlaneBase

     {

        // Cutingplane using iso surface

        type            cuttingPlane;

        planeType       pointAndNormal;

        pointAndNormalDict

        {

            basePoint       (0 0 1);

            normalVector    (0 0 1);

        }

        interpolate     true;



      }



    stlBased

        {

        

        // Sampling on triSurface

        type        sampledTriSurfaceMesh;

        surface     znormal.stl;

        source      cells;  

  

            interpolate     true;



       }





     ); 

  

 }

The results are attached.

As it can be seen the stl approach completely fails. For some reason it doesn't really cut through the cells, rather keeps the original triangles form the stl. In the sampleDict, it's mentioned that the first approach using plane or cutting plane always generates a triangulated surface as well. So now I'm a bit confused as how to deal with this. Is this a bug in the type sampledTriSurfaceMesh which doesn't perform a topoSet analysis automatically? Like creating cellSet from the stl surface? or limitation of the approach or I missed something out?

Thanks
Ali

This behaviour is intended. You'll need to generate a nicer sampling surface. The resolution of the sampling surface should be higher than your mesh resolution.

Also: http://www.openfoam.org/mantisbt/view.php?id=1235

Thanks Anton for the reply.
A few questions:
1) As the figure for the sampled surface using type cuttingPlane shows, the surface is also triangulated which is inline with the description in the sampleDict (line 157th "planes are always triangulated"). But the triangulation seems so follow after selecting cells that are cut through by the plane, and triangulation is performed on the selected cells. So initially some sort of topoSet-like utility is used. this is just a guess though.

2) if that is the case, then the approach to sampling seems to be quite different from that of the TriSurfaceMesh type. For this type, it seems that it will just directly use the triangles of the stl surface. Is that correct?
Regarding the increase in resolution of the triangulated surface, the way stl triangulates isn't like a finite-element based triangulation. I tried to increase the resolution of the stl generated disk using Salome, and of course it increases the number of the triangles, but then makes the aspect ratio even worse, since all generated triangles share a point as visible in previous attached image. And naturally the resulting surface representation of U looks just the same as the lower resolution one. To me there seems to be a missing step in the TriSurfaceMesh type. I mean some sort of mapping just like the cuttingPlane type.

3) Having checked the link you included, makes it more puzzling for me as how TriSurfaceMesh type works. Based on your figures it seems that more that the resolution of stl-surface, is the interpolation procedure which matters the most. But I couldn't directly link the methods bellow the images to the interpolation schemes in sampleDict (cell,cellPoint, cellPointFace, pointMVC). So could you please tell me if I'm correct about the following:

Interpolation scheme corresponding to the image sampledTriSurfaceCells.png: cell
Interpolation scheme corresponding to the image sampledTriSurfacePoints.png: pointMVC
Interpolation scheme corresponding to the image sampledTriSurfaceCellsInterpolatedToPointValues.pn g cellPoint

Best
Ali

An STL meshing algorithm will try to describe the surface with the least amount of triangles possible, absolutely disregarding the quality. You want to use advancing front or something that makes a high quality shell mesh. You can put the resulting mesh in an STL file without any issues.

Your understanding of how the sampling works is correct.