[supersoldier]

Originally Posted by ahmad12982

2D+axisy. dynamic mesh refinement can be found in the link below.
http://faculty.yu.edu.jo/ahmad_a/Lis.../AllItems.aspx

Thank you so much! Excelent work

[OlegSutyrin]

In my previous post, I have somehow managed to put wrong version of some file(s) in the archive. I cannot find the way to edit that post, so correct version of the archive is attached here.

[david112]

Hi Oleg,
I want to try your dynamicRefineFvMesh2D tool for OpneFoam4, but got problems while compiling it. Doint exactly aus you described it I get

In file included from dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.C:26:0:
dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.H:80:22: fatal error: hexRef2D.H: Datei oder Verzeichnis nicht gefunden
compilation terminated.
/opt/openfoam4/wmake/rules/General/transform:8: die Regel für Ziel „/opt/openfoam4/platforms/linux64GccDPInt32Opt/src/dynamicFvMesh/dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.o“ scheiterte
make: *** [/opt/openfoam4/platforms/linux64GccDPInt32Opt/src/dynamicFvMesh/dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.o] Fehler 1

when the wmake command is exequted in the /opt/openfoam4/src/dynamicFvMesh folder.

Do you know what I'm doing wrong?

Greetings
David

[OlegSutyrin]

david112,
my mistake! You need to put hexRef2D codes to the place before trying to compile 'wmaking' dynamicFvMesh folder. Here is updated and extended installation guide (still assuming you installed OF4 into '/opt/openfoam4/'):

0. go into root mode: run 'sudo -i'

1. put 'dynamicRefineFvMesh2D' folder into '/opt/openfoam4/src/dynamicFvMesh/' folder;
add 'dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.C' line into '/opt/openfoam4/src/dynamicFvMesh/Make/files';

2. put 'hexRef2D' folder into 'opt/openfoam4/src/dynamicMesh/polyTopoChange/polyTopoChange/' folder;
add 'polyTopoChange/polyTopoChange/hexRef2D/hexRef2D.C' line into '/opt/openfoam4/src/dynamicMesh/Make/files';

3. compile code:
'cd /opt/openfoam4/src/dynamicFvMesh/'
'wmake'
cd '/opt/openfoam4/src/dynamicMesh/'
'wmake'
This works for me. Hope it will work for you too!

[david112]

Thank you for the quick answer. Quiet easy... I when tried it yesterday in this order I forgot to change to root mode. Now it seems to work for me too.

I will try some 2D cases but atually I want to adapt to a 3D-Case for refining the Mesh in 2 directions. Do you know whether anyone did that before?

Greetings
David

[OlegSutyrin]

David, I believe that no one had posted such code. Obviously, if I found such code here, I would use it instead of aforementioned 2D libraries: refining only in 2 dimensions is exactly what is needed in 2D cases.

[david112]

Hi Oleg,
the compiling works now without errors, but the solver doesnt run. I got this error while running the pimpleDyMFoam solver:

Starting time loop

Courant Number mean: 0.04210927 max: 0.1690338
deltaT = 2.4e-05
Time = 2.4e-05

Selected 1373 cells for refinement out of 50868.
Refined from 50868 to 54987 cells.
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigSegv::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::dynamicRefineFvMesh2D::refine(Foam::List<int> const&) at ??:?
#4  Foam::dynamicRefineFvMesh2D::update() at ??:?
#5  ? at ??:?
#6  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#7  ? at ??:?
Speicherzugriffsfehler (Speicherabzug geschrieben)

perhaps you can solve my problem es fast as the other one.
greetings David

[OlegSutyrin]

David,
I have tested this lib only on the simplest meshes (rectangular, even-sized cells) and rhoCentralFoam solver, so cannot predict it's behavior in more complex cases. I remember it kind of randomly (after thousands of successful time steps and un/refinements) crashing on forwardStep tutorial, though. But that was with my custom solver, so I'm not sure the problem was in the refinement lib.
Don't know why your case crashes, sorry :-(

[Luca Cornolti]

Checking some computation with my code in foam ext 3.2, it seems that sometimes the simulations crash when the fields are mapped from the old mesh to the new one.
This problem rarely appears with planar configurations, while it takes place more often when wedges are considered.

Anyway, I have no clear idea about the reason of this, as these events are quite random.

[MSF]

Hi,

I tried to compile the library from Ahmad but I get the following error message(OF 2.2.2):

g++: error: unrecognized command line option ‘-fvMotionSolver’

Anyone an idea what that means?

Best,
Moritz

[david112]

Hi Oleg and all other interested!

I took the code from Oleg and tried to change it for my purpose. So I changed the dicision which Face has to be cutted in 4 faces. Instead of looking for empty faces the code now looks for faces where all points have the same y-position.
here you can see the changes:

    boolList isDivisibleFace(mesh_.nFaces(), false); //OS: change to PackedBoolList?
    boolList isDivisibleEdge(mesh_.nEdges(), false); //OS: change to PackedBoolList?
    boolList isXZPlaneFace2(mesh_.nFaces(), true);

    
    // deciding which face is to split in 4 faces
    for (label facei = 0; facei < mesh_.nFaces(); facei++)
    {
        const label & patchID = mesh_.boundaryMesh().whichPatch(facei);
        
        //my code ----------------------------------------------------------------------
        const Foam::face theFace = mesh_.faces()[facei];
        // comparing the y-values of every point of the face        
        for (int myPointCounter1=0; myPointCounter1 < 4;myPointCounter1++)
        {
            for (int myPointCounter2=0; myPointCounter2 < 4;myPointCounter2++)
            {             
                if (myPointCounter1 > myPointCounter2 )    // to get every combination only once            
                {
                    const Foam::Vector<double> point1 = mesh_.points()[theFace[myPointCounter1]];
                    const Foam::Vector<double> point2 = mesh_.points()[theFace[myPointCounter2]];
                    scalar yValuePoint1 = point1.y(); 
                    scalar yValuePoint2 = point2.y();            
                    /*if (debug)  {Pout<< "comparisons between"
                                     << yValuePoint1 << " and " 
                                     << yValuePoint2 << endl;}*/ 
                    if ((yValuePoint1 - yValuePoint2) != 0 )
                    {
                        isXZPlaneFace2[facei] = false;
                    }
                }
            }
        }


        // checking for 2D empty faces not used in this case 
    /*    if (mesh_.boundaryMesh()[patchID].type() == "empty" || mesh_.boundaryMesh()[patchID].type() == "wedge")
        {
            isXZPlaneFace[facei] = true;
        }
        if (debug)  {Pout<< "checking face: " << myFaceCounter << endl;} 
        myFaceCounter++; */
        
        //if (isA<emptyPolyPatch>(mesh_.boundaryMesh()[patchID])


        if (debug)  
        {
            Pout<< "facei: " << facei << endl;
            Pout<< "isXZPlaneFace2[facei]: " << isXZPlaneFace2[facei] << endl;
        }

        if (isXZPlaneFace2[facei] == true) //OS: added wedge type
        {
            isDivisibleFace[facei] = true;
            const labelList& fEdges = mesh_.faceEdges(facei);

            forAll(fEdges, i)
            {
                label edgej = fEdges[i];
                isDivisibleEdge[edgej] = true;
            }
        }
    }

That works in the easiest cases, but still leads to problems in 3D meshes.
A mesh consiting of a single cell will be splitted perfectly. Also meshes with only 1 cell in the y-direction work fine (case1unrefined.png -> case1refined.png).

When getting more cells in y-direction the order of some faces isn't correct anymore. (case2unrefined.png -> case2refined.png). Perhaps it helpes to find the mistake if we do more cells in the y-direction. Here you can see, that the first cell is spitted correct, at all the following cells one of the new split cells is uncorrect for the last cell two of the new splitted cells are uncorrect (case3 refined.png).


Do you have an idea where in the code I should look for solving this problem?

[david112]

I looked into the faces, owner and neighbour files in the polyMesh folder of case2 and figured out where the mistakes happen. Here are the corrected files. Perhaps that helps to find the mistake.
faces

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       faceList;
    location    "2.4e-05/polyMesh";
    object      faces;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //


36
(
4(2 16 24 15)
4(13 25 24 16)
4(24 25 12 15)
4(16 24 26 19)//4(15 24 26 19)
4(26 24 15 18)//4(26 24 16 18)
4(21 25 24 22)
4(8 22 24 16)
4(14 25 24 17)
4(9 17 24 22)
4(3 15 24 17)
4(22 24 26 23)//4(17 24 26 23)
4(17 24 26 20)//4(22 24 26 20)
4(0 12 25 13)
4(1 14 25 12)
4(7 21 25 14)
4(6 13 25 21)
4(4 19 26 18)
4(10 23 26 19)
4(11 20 26 23)
4(5 18 26 20)
4(0 13 16 2)
4(2 16 19 4)
4(8 16 13 6)
4(10 19 16 8)
4(3 17 14 1)
4(5 20 17 3)
4(7 14 17 9)
4(9 17 20 11)
4(2 15 12 0)
4(4 18 15 2)
4(1 12 15 3)
4(3 15 18 5)
4(6 21 22 8)
4(8 22 23 10)
4(9 22 21 7)
4(11 23 22 9)
)


// ************************************************************************* //

owner

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       labelList;
    note        "nPoints:27  nCells:8  nFaces:36  nInternalFaces:12";
    location    "2.4e-05/polyMesh";
    object      owner;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //


36
(
0
0
0
1
1
2
2
3
3
4
5
6
0
4
3
2
1
5
6
7
0
1
2
5
4
7
3
6
0
1
4
7//5
2
5//7
3
6
)


// ************************************************************************* //

neighbour

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       labelList;
    note        "nPoints:27  nCells:8  nFaces:36  nInternalFaces:12";
    location    "2.4e-05/polyMesh";
    object      neighbour;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //


12
(
1
2
4
5
7
3
5//7
4
6
7//5
6
7
)


// ************************************************************************* //

greetings,
David

[OlegSutyrin]

Hi, David!
Unfortunately, I'm not able to perform proper analysis of the code, because it's still too complex for me. But one thing have catched my eye:

if ((yValuePoint1 - yValuePoint2) != 0 )

As a general rule, comparison between two floating point values should not be done in that way, since it will almost always return true due to floating point computation error. The proper way would be like

if (fabs(yValuePoint1 - yValuePoint2) < eps )

where "eps" is something like 0.00000001. Although, I'm not sure that in OpenFOAM the operator "!=" for "scalar" class is not already overloaded with such functionality.

[ssss]

Originally Posted by OlegSutyrin

Hi, David!
with such functionality.

Hi @OlegSutyrin, first of all thank you very much for adapting the code to OF4! In your posts you say that it supports wedge meshes, but I can't see any mention of it inside the code. Moreover, when I run a wedge simulation I observe 3D refinement in the wedge direction.Do you know if there something extra I should add to my dict for wedge simulations?

Thank you very much for your help

[david112]

Originally Posted by OlegSutyrin

Hi, David!
Unfortunately, I'm not able to perform proper analysis of the code, because it's still too complex for me. But one thing have catched my eye:

As a general rule, comparison between two floating point values should not be done in that way, since it will almost always return true due to floating point computation error. The proper way would be like where "eps" is something like 0.00000001. Although, I'm not sure that in OpenFOAM the operator "!=" for "scalar" class is not already overloaded with such functionality.

Hi Oleg,

good point. I fixed that.

the problems I mentioned befor where caused by the diffent orientation of the faces which where cutted into 4 faces. So, checking which faces are owned and which neighbours of a cell and reordering the points if neccesary solved that. Now i have problems with the cells at the border of the refinement, but hope for sol

@ssss:
in the hexRef2D.C file there is a line saying:

if (mesh_.boundaryMesh()[patchID].type() == "empty" || mesh_.boundaryMesh()[patchID].type() == "wedge")

which should lead to a same treatment of wedge and empty faces. Does it work for you with empty faces?

[ssss]

Hi @david112 I swear that I searched both .C files for the wedge string, but it seems I made a mistake somewhere. It is true that wedge and empty patches are treated equally. However, I observe 3D refinement in my ("complex") axisymmetric testcase while in simple 2D with empty BCs simulations there is no refinement at all in the empty direction, so maybe some additions need to be added to the code to manage wedge meshes...

[OlegSutyrin]

Hi, @ssss!
I've just run a simple test for 2D wedge refining, it works OK (but, as I mentioned before, it ignores cells that adjoin symmetry axis, since they are not hexahedrons): there was no refinement in the 3rd axis. I have no idea why that doesn't work for you :-(

Originally Posted by ssss

However, I observe 3D refinement in my ("complex") axisymmetric testcase while in simple 2D with empty BCs simulations there is no refinement at all in the empty direction, so maybe some additions need to be added to the code to manage wedge meshes...

[jmo0902]

Thanks for your contribution.
However, when I compile your files in OpenFoam 5.0 and 4.1, it gave me many errors. Can you give me some tips to debug?

Originally Posted by ahmad12982

2D+axisy. dynamic mesh refinement can be found in the link below.
http://faculty.yu.edu.jo/ahmad_a/Lis.../AllItems.aspx

[Luca Cornolti]

Dear all,

after some time I was able to work again on this topic and I completed a class which is able to refine 2D cases for both planar and axis symmetric (wedge) configurations.

Attached you can find the developed classes for OpenFOAM-6, foam-extend-4.0 and OpenFOAM-v1806.

The folders are arranged to be copied into the user directory ($WM_PROJECT_USER_DIR).

In the OpenFOAM-6 version there are also two tests for planar and wedge configurations.

I tested quite extensively the foam-extend-4.0 version.
The OpenFOAM-6 version should work as well as the code is almost the same, but I tested it only with the attached two tests as I don’t use the foundation version a lot.
The same is true for the v1806 version.


I hope that everything will work properly.

Note that a problem reported previously by me in this thread regarding mapping was solved by following the suggestion given in:

mapFields major bug

[qiyang]

Originally Posted by Luca Cornolti

Dear all,

after some time I was able to work again on this topic and I completed a class which is able to refine 2D cases for both planar and axis symmetric (wedge) configurations.

Attached you can find the developed classes for OpenFOAM-6, foam-extend-4.0 and OpenFOAM-v1806.

The folders are arranged to be copied into the user directory ($WM_PROJECT_USER_DIR).

In the OpenFOAM-6 version there are also two tests for planar and wedge configurations.

I tested quite extensively the foam-extend-4.0 version.
The OpenFOAM-6 version should work as well as the code is almost the same, but I tested it only with the attached two tests as I don’t use the foundation version a lot.
The same is true for the v1806 version.


I hope that everything will work properly.

Note that a problem reported previously by me in this thread regarding mapping was solved by following the suggestion given in:

mapFields major bug

Dear Luca Cornolti,

I am now also working on utilizing 1D AMR method in OpenFOAM, I want to know that could the 2D dynamicRefineFvMesh you write changed into 1D dynamicRefineFvMesh? Thanks.