[mesh manipulation] refineMesh Problems: strange cells/cuts were added

bjoern1 · December 18, 2015, 07:01

Hello together!

I tried to refine my mesh via the refineMesh in OpenFoam 2.3.0. My mesh has a cylinder, surrounded by cuboid. As you can see in the pictures there is a problem with the inner cells.
I used patchLocalCoeffs as follows:

Code:

patchLocalCoeffs
{
    // Normal direction is face normal of zero'th face of patch
    patch           front;
    tan1            ( 1 0 0 );
    tan2            ( 0 1 0 );
}

CheckMesh -allGeometry -allTopology gives the following error:

Code:

 ***Concave cells (using face planes) found, number of cells: 142
  <<Writing 142 concave cells to set concaveCells

Does anyone have experience with the same error?

Thanks a lot for your help!

wyldckat · December 19, 2015, 14:38

Quick questions:

What is the complete "refineMeshDict" you used?
Can you share your case?
- If not, can you reproduce this error with OpenFOAM's tutorial mesh "stressAnalysis/solidDisplacementFoam/plateHole/"?

bjoern1 · December 21, 2015, 06:54

Hello Bruno,

I created 2 reduced test-cases (One for both sides, because of the different amount of cells). The error can be reproduced with the following commands:

Code:

blockMesh
topoSet -dict system/topoSetDict_refine
refineMesh -dict system/refineMeshDict

I also tried to reproduce the error with my refineMeshDict in the plateHole case, but it refined without a problem.

Thanks a lot for your help!

wyldckat · January 2, 2016, 09:01

Greetings Björn and a Happy New Year!

I finally bring good news on this! The solution is to change the referential you're using from this:

Code:

patchLocalCoeffs
{
    // Normal direction is face normal of zero'th face of patch
    patch           front;
    tan1            ( 1 0 0 );
    tan2            ( 0 1 0 );
}

To something like this:

Code:

patchLocalCoeffs
{
    // Normal direction is face normal of zero'th face of patch
    patch           front;
    tan1            ( 1 1 0 );
    tan2            ( -1 1 0 );
}

As for the actual problems, here is the diagnosis:

In the first attached image "the_actual_problem_using_polyhedrons.jpg" is shown the actual cell shapes, when compared to the shapes you showed in the other images. The reason for the different renders is pretty much explained here: http://openfoamwiki.net/index.php/FA...is_in_ParaView
The attached image "side_by_side_direction1.jpg" shows what happens if we only do the direction 1 "tan1" of the refinement. I only selected 2 cells to be refined.
The attached image "Number_2D_points.png" shows the number of points each face has got in the shown image, after the "tan1" refinement occurred. The problem revealed here is that there are 2 cells are are in fact no longer hexahedral cells, i.e. each cell doesn't only have 6 faces. The faces tagged with the 5 marker have 5 points from our point of view, which equates to cells with 7 faces.
The attached image "Number_2D_points_result.png" shows the result of the second cut over "tan2", which resulted in the faces tagged with 4 to be properly cut, but the one tagged with 5 got a bad cut.
- The reason for the bad cut is actually very simple: the cut had to be done based on the centre of the cell and the plane that has the normal defined by the local "tan2" for this tagged "5" cell. Notice that the bad cut goes through the centre of that "tan1" refined cell.

The origin of the problem might not be very clear, but the problem is that given the original "tan1" and "tan2" directions, resulted in the actual cell cutting directions to depend on how they were aligned with each reference direction. That is demonstrated in the last 2 pictures, where the "tan1" refinement resulted in different direction cuts.

This is why using a different direction referential solved the problem, since the new referential is more closely aligned with the desired cuts.

As a fun fact, if we use the original referential and the 3 directions:

Code:

directions      
(
        tan1
        tan2
        normal
);

we get the result shown in the attached image "hilarious_3directions_pure_hex.jpg", because the pure hexahedral cutting is used and it gets confused with the given cutting directions

As for diagnosing this, it took me quite a while to debug it

I assumed that this was a bug, so it took something like 4 to 6 hours to diagnose, spread across a few days (hence taking a bit longer to restart where I left off the day before). I spotted a few issues and I will propose a bug fix of it... even if it's just warning messages with a suggestion for a fix for the user.

edit: Bug/feature report submitted: http://www.openfoam.org/mantisbt/view.php?id=1960

Best regards,
Bruno

bjoern1 · January 4, 2016, 06:33

Hi Bruno! Happy New Year!

thanks a lot for your time and help, I really appreciate it. So when I use refineMesh on the quadrant it works really well, but unfortunately I need to refine at least a semi-circle. This is because my geometry, in a bigger picture, doesnt have enough symmetry for a quadrant. As you can see in the attached pictures, the new patchLocalCoeffs only shift the problem to the global coordinates.(I have used parafoam -builtin for rendering now)

Do you think there is also an opportunity to mesh semi or full circles?

Many greetings!

Björn

wyldckat · January 4, 2016, 18:35

Quick answers:

Quote:

Originally Posted by bjoern1

I have used parafoam -builtin for rendering now

That alone isn't enough. The detail is that you must use the Polyhedron representation. The wiki page explains how this is used for each reader (.OpenFOAM vs .foam).

Quote:

Originally Posted by bjoern1

Do you think there is also an opportunity to mesh semi or full circles?

I was afraid you might need that. Please try intermediate angles, such as:

Code:

tan1 (1 0.5 0);
tan2 (-0.5 1 0);

Or even:

Code:

tan1 (1 0.5 0);
tan2 (1 -0.5 0);

Hopefully this will work, because the Hex option is used, which should enforce pure hexahedral cuts, even if tan1 doesn't make 90 degrees with tan2.

If this doesn't work, then we'll need to implement some way to make the orientations uniform with the original mesh... something like refining all 2 or 3 directions at the same time, instead of doing each direction, one at a time

bjoern1 · January 5, 2016, 06:17

Hi Bruno!

I tried the following configurations for the patchLocalCoeffs (I attached the pictures):

Code:

A:
tan1            ( 1 0 0 );
tan2            ( 0 1 0 );

Code:

B:
tan1            ( 1 1 0 );
tan2            ( -1 1 0 );

Code:

C:
tan1 (1 0.5 0);
tan2 (-0.5 1 0);

Code:

D:
tan1 (1 0.5 0);
tan2 (1 -0.5 0);

Code:

E:
tan1 (1 0.1 0);
tan2 (1 -0.1 0);

Code:

F:
tan1 (1 0.5 0);
tan2 (-1 0.5 0);

C & D are the ones you suggested. I also tried some more intermediate angles. Sadly they all didnt work out. For some of them, the results are very similiar.

bjoern1 · January 5, 2016, 06:19

and the picture of the latest formation...

wyldckat · January 6, 2016, 19:00

Hi Björn,

Then the only solution I can think of, will require programming into OpenFOAM. I'll try to have a solution for this on the upcoming weekend.

Best regards,
Bruno

bjoern1 · January 8, 2016, 09:31

Hi Bruno!

thank you so much for your help! By now I use a workaround, without refining the mesh. Of course it is still interesting how non-trivial meshes can be refined.

Best regards,

Björn

wyldckat · February 21, 2016, 13:07

Hi Björn,

Sorry for the late reply, but only today did I finally manage to complete the contribution for refineMesh: http://www.openfoam.org/mantisbt/view.php?id=2004

A ton of details are provided there-in, but if you want, I can provide a custom utility that does the same features as the contribution. Although I need you to remind me which OpenFOAM version you are using, if you still need this.

Best regards,
Bruno

Chief-CeTe · February 29, 2016, 07:44

Hello Bruno,

I am working with Björn and answering in his behalf since he is not availlabe at the moment.
Thank you so much for your great work! It is great seing you put so much effort into this.
In fact, we are still interested eventhough we worked arround the problem in one case. There will be others following where we can't.
We use OF 2.3.0 at the moment but installing a newer version for the refineMesh would be possible as well.

Best regards ans thanks again,
Thorben

Sugajen · October 2, 2017, 22:23

Hi all,

This looks like an old post but I thought you guys will be able to give some guidance on my similar issue.
I am trying to refine my entire geometry using refineMesh. But it throws a lot of warnings. It also creates a bunch of .obj files like anchors_169445.obj, cell_830619.obj,cellLoop_655655.obj while refining.
I tried changing the directions as done in posts above but no luck. Is there anything in particular that should be changed in the refineMeshDict ? or is it geometry specific ? Any help will be very helpful

refineMeshDict

Code:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      topoSetDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

actions
(
    {
        name forRefinement;
        type cellSet;
        action new;
        source boxToCell;
        sourceInfo
        {
            box (0.02411732 0.01826876 -0.09695647) (0.05348801 0.04984307 -0.05463678);
        }    
    }
    
);

Warnings

Code:

--> FOAM Warning : 
    From function void Foam::cellCuts::setFromCellCutter(const Foam::cellLooper&, const Foam::List<Foam::refineCell>&)
    in file meshCut/cellCuts/cellCuts.C at line 2241
    Found loop on cell 208 that resulted in an unexpected bad cut.
    Suggestions:
      - Turn on the debug switch for 'cellCuts' to get geometry files that identify this cell.
      - Also keep in mind to check the defined reference directions, as these are most likely the origin of the problem.

Thanks,
Sugajen

lukasf · October 31, 2018, 10:52

Hi,

I want to address two issues with the refineMesh utility. I am using OpenFOAM 4.1.

1.)
First of all I, do not really understand the use of the patchLocalCoeffs after switching to coordinateSystem patchLocal.

At https://openfoamwiki.net/index.php/RefineMesh there is a description of a refineMeshDict.

On the one hand it states that the coordinate system is DIFFERENT for every cell when the patchLocalCoeffs is used and on the other and it states that the normal direction is the face normal of zero'th face of patch (hence all the cells have the SAME coordinate system). In my opinion, this would only be true if the normal direction of the face normal of the zero’th face of the patch is the same for all cells.

Therefore, I do not understand the comment of wyldckat with respect to bjoern1’s issue.
He uses the front patch to define the normal vector which should lead to a normal vector with the components of ( 0 0 1 ) in the example. Hence, this resulting normal vector would be the same if a global coordinate system is be used with the definition of tan1 ( 1 1 0 ) and tan2 ( -1 1 0 ).

Moreover, why is it necessary to define a second direction tan2? I thought to only define the patch to get the patches normal (either of the zero’th face of the path or of all cells) and to define tan1.
In an orthogonal coordinate system the direction tan2 would be defined due to tan1 and the defined normal vector.

2.)
I am trying to refine a mesh. My aim is to refine a mesh at custom locations as often as I want. I refine the locations of the mesh by selecting cells using a topoSetDict and then I use a refineMeshDict to cut those cells. By repeating this process I can get the refinement level I need. When refining a region the cells in the topoSet region are hexahedron cells but at the border of the topoSet the cells turn into polyhedron cells. I think that this is going to be the problem I have. The problem occurs when the cells are not perfectly rectangular to each other.

Hence, I have uploaded two test cases to show you my issue. The cases are called 0_understandRefineMesh and 1_understandRefineMesh. Use the Allrun script to create the final mesh. Basically I use these commands:

Quote:

topoSet -dict system/topoSetDict.globalRefinement1
refineMesh -dict system/refineMeshDict.globalRefinement1
topoSet -dict system/topoSetDict.globalRefinement2
refineMesh -dict system/refineMeshDict.globalRefinement2

The first globalRefinement1 marks a big region and globalRefinement2 marks a smaller region. If you run the commands the other way around (Allrun_wrong_command_order)

Code:

topoSet -dict system/topoSetDict.globalRefinement2
refineMesh -dict system/refineMeshDict.globalRefinement2
topoSet -dict system/topoSetDict.globalRefinement1
refineMesh -dict system/refineMeshDict.globalRefinement1

(note the change of the index 2 and 1), the issues arise when the cells are not perfectly rectangular.

Hence, there is no problem in the case 0_understandRefineMesh because there are only rectangular cells in the mesh. The case 0_understandRefineMesh represents a square cube (perf_cube_3).
In 1_understandRefineMesh one side of the cube is slightly skewed, which results in skewed cells on two sides of the cube. Here the order of the commands is important. (Allrun_wrong_command_order will not work perfectly and ugly cells are created!)

wyldckat · November 1, 2018, 13:17

Greetings to all!

@Sugajen: I hope you've solved you issue since then. Without more specific details, it's nearly impossible to deduce what went wrong exactly.

@Lukas: Wow, OK, it's going to take me a while to answer to all of these... here we go:

Quote: