[Wolfram]

Hi all,

I am trying to mesh a cylinder with a propeller inside. sHM ignores the feature edges provided by the in- and outlet of the cylinder, while inner feature edges provided by the propeller are captured properly.

Screenshot 2022-07-28 140823.jpg

The error message by sHM is shown below:

Refinement phase
----------------

Found point (0 0 0.05) in cell 43665 on processor 0
Reading external feature lines.
Refinement level 2 for all cells crossed by feature "rrInlet.eMesh" (72 points, 72 edges).
Read feature lines in = 0.06 s


Feature refinement iteration 0
------------------------------

Marked for refinement due to explicit features    : 0 cells.
Determined cells to refine in = 0 s
Selected for feature refinement : 0 cells (out of 135000)
Stopping refining since too few cells selected.


Surface refinement iteration 0

[AtoHM]

What refinement levels are you setting for the surfaces and edges?

[Wolfram]

Originally Posted by AtoHM

What refinement levels are you setting for the surfaces and edges?

I tried levels from 2 to 6. Unfortunately, the edges are not snapped regardless of the refinement (for sure, the influence of "chopped" is less obvious)

[Yann]

Hi Wolfram,

Could you post your snappyHexMeshDict so we can have a look?

Yann

[Wolfram]

Originally Posted by Yann

Hi Wolfram,

Could you post your snappyHexMeshDict so we can have a look?

Yann

Sure, many thanks for your help in advance.

snappyHexMeshDict.txt

[Yann]

Thanks!

Have you tried switching from implicitFeatureSnap to explicitFeatureSnap? AFAIK you have to be in explicit mode in order to use the parameters defined in the features subdictionary for snapping.

        // Detect (geometric only) features by sampling the surface
        // (default=false).
        implicitFeatureSnap false;

        // Use castellatedMeshControls::features (default = true)
        explicitFeatureSnap true;

It does not explain why the features are not refined though, as the parameters seem to be read by snappy according to your log file.

How do you visualize the eMesh files in paraView ?

The snapping issue on the cylinder also might be related to the use of separate STL files rather than one single STL for the whole cylinder. This is probably another thing worth trying.

Yann

[AtoHM]

Another thought: resolveFeatureAngle seems offly high. Try 30.

[Wolfram]

Originally Posted by AtoHM

Another thought: resolveFeatureAngle seems offly high. Try 30.

true. I am sorry, the uploaded file is from a "trial". The resolveFeatureAngle was examined with values from 5 - 91

[Hr_kules]

Hey,

you couldtry to use a single eMesh file. I have noticed i a log file that always only one was used and this one wasn't even the desired region. Apaprt from that make sure that the stl used to extract the eMesh is also closed that way you should be able to utilize the eMesh.

And try to use the explicit snapping! Hope i could help.

[Wolfram]

Originally Posted by Hr_kules

Hey,

you couldtry to use a single eMesh file. I have noticed i a log file that always only one was used and this one wasn't even the desired region. Apaprt from that make sure that the stl used to extract the eMesh is also closed that way you should be able to utilize the eMesh.

And try to use the explicit snapping! Hope i could help.

Hi,

I tried to use the single eMesh. It is the circle in the screenshot. Unfortunately the error is persistent.

[AtoHM]

Another shot in the dark: strange things can happen during the run, if the prescribed locationInMesh hits a face or node. Your choice seems likely to hit one of these on the background mesh or refined mesh during the castellatedMesh process.
To avoid this, use slightly off float numbers, in your case (0.00013 -0.00031 0.050012) for example. Maybe this fixes things.

[Wolfram]

Originally Posted by Yann

Thanks!

Have you tried switching from implicitFeatureSnap to explicitFeatureSnap? AFAIK you have to be in explicit mode in order to use the parameters defined in the features subdictionary for snapping.

        // Detect (geometric only) features by sampling the surface
        // (default=false).
        implicitFeatureSnap false;

        // Use castellatedMeshControls::features (default = true)
        explicitFeatureSnap true;

It does not explain why the features are not refined though, as the parameters seem to be read by snappy according to your log file.

How do you visualize the eMesh files in paraView ?

The snapping issue on the cylinder also might be related to the use of separate STL files rather than one single STL for the whole cylinder. This is probably another thing worth trying.

Yann

Hi Yann,

the eMesh file is shown in my screenshot. It looks reasonable. I used 3 separate stl files to define the entire cylinder in order to obtain three different patches (inlet, wall, outlet)

[Yann]

Originally Posted by Wolfram

Hi Yann,

the eMesh file is shown in my screenshot. It looks reasonable. I used 3 separate stl files to define the entire cylinder in order to obtain three different patches (inlet, wall, outlet)

Hi Wolfram,

You can concatenate the 3 stl into one in order to have 1 single STl containing the different patches you need for your case.
Have a look at this post, it looks a bit similar to your issue: snappyHexMesh - 90° edges problem

Problem has been solved by using one single closed STL rather than several separate files.

Yann

[linnemann]

Hi

I have no issues with meshing a pipe both with Implicit and Explicit feature edges.
Implicit is even a tad better. I'm using OpenFOAM 2206

If you want to use multiple STL files remember that in the surfaceFeatureExtractDict file to enable the line in bold.
Otherwise it will not generate edges at the open end of the pipe.
I like to use separate STL files to better control what edges get refined and which don't.

Forgot to ask, which version of OF are you using?
If its 4.1 which is listed in the uploaded dict then snappy was not good at snapping at the time.
EDIT: Just tried with 4.1 and it worked just fine.

wallOuter.stl
{
    extractionMethod    extractFromSurface;

    extractFromSurfaceCoeffs
    {
        includedAngle   150;
    }

    subsetFeatures
    {
        // Keep nonManifold edges (edges with >2 connected faces)
        nonManifoldEdges       no;

        // Keep open edges (edges with 1 connected face)
        openEdges       yes;
    }

        writeObj                yes;
}

You can use Holzmann excellent material as starting point.
https://holzmann-cfd.com/community/t...meshing-a-pipe

[Wolfram]

Originally Posted by linnemann

Hi

I have no issues with meshing a pipe both with Implicit and Explicit feature edges.
Implicit is even a tad better. I'm using OpenFOAM 2206

If you want to use multiple STL files remember that in the surfaceFeatureExtractDict file to enable the line in bold.
Otherwise it will not generate edges at the open end of the pipe.
I like to use separate STL files to better control what edges get refined and which don't.

Forgot to ask, which version of OF are you using?
If its 4.1 which is listed in the uploaded dict then snappy was not good at snapping at the time.
EDIT: Just tried with 4.1 and it worked just fine.

wallOuter.stl
{
    extractionMethod    extractFromSurface;

    extractFromSurfaceCoeffs
    {
        includedAngle   150;
    }

    subsetFeatures
    {
        // Keep nonManifold edges (edges with >2 connected faces)
        nonManifoldEdges       no;

        // Keep open edges (edges with 1 connected face)
        openEdges       yes;
    }

        writeObj                yes;
}

You can use Holzmann excellent material as starting point.
https://holzmann-cfd.com/community/t...meshing-a-pipe

Many thanks for your input.

I am playing now for hours, among other things with the files from Tobias as mentioned

I tried now an combined stl-file which I merged with the "cat" command. Still the edges are not captured ...

Were you able to call the surfaceFeatureExtractDict within foam-extend4.1? Typing "surfaceFeatureExtract" in fe41 does not work, thus I created the .eMesh-files with OF2012 - maybe this is the problem???

Edit: In OF2012 the edges are captured o.O

[linnemann]

Hi


Over the years I have really just decided to stick with the OpenFOAM.com version.


At a certain time .ORG, .COM and EXTEND was pretty much compatible.
Nowadays they have diverged enough that you need to tinker with many of the standard files to switch between them.


RANT BEGIN
See for example moving meshes, CGI (extend), AMI (com) and now NCC (org).
Why could they not just rework AMI so we could continue using the same setup?
Guess that's what happens when egos meet opensource collaboration.
RANT END



I only ever switch from COM version if there is a feature I really need from the other.

[Yann]

Originally Posted by linnemann

At a certain time .ORG, .COM and EXTEND was pretty much compatible.
Nowadays they have diverged enough that you need to tinker with many of the standard files to switch between them.

This is also true here on the forum. It gets harder to help people as the answer might vary according to the version used in the initial post, and I guess it must also be confusing for new users searching the forum and finding answers they cannot apply on the version they use.

[Wolfram]

Originally Posted by linnemann

Hi


Over the years I have really just decided to stick with the OpenFOAM.com version.


At a certain time .ORG, .COM and EXTEND was pretty much compatible.
Nowadays they have diverged enough that you need to tinker with many of the standard files to switch between them.


RANT BEGIN
See for example moving meshes, CGI (extend), AMI (com) and now NCC (org).
Why could they not just rework AMI so we could continue using the same setup?
Guess that's what happens when egos meet opensource collaboration.
RANT END



I only ever switch from COM version if there is a feature I really need from the other.

Well, I was also comfortable with the .com version. But for steady turbomachinery applications I am dependent on "mixingPlanes".
As far as I know, foam-extend is the only version offering this functionality?

Were you able to employ the "surfaceFeatureExtractDict" within foam-extend? Right now, this seems to be the biggest obstacle for me of using sHM in foam-extend.

[AtoHM]

Too lazy to really look into it (I use it with -ESI versions and it works nicely), but I think the command is named differently in -dev version "surfaceFeatures"? And it seems there are more differences for the -extend version?
.eMesh with foam-extend. surfaceFeatureExtract does not work.