[feno102]

Dear all,

I'm new user to OpenFoam and I just have learned it for a few months. In brief, I'm interested to use OpenFoam to simulate electromagnetic fields for my study case. As starting point, I learned to reproduce Ze Huang's work in his thesis "OpenFoam Simulation for Electromagnetic Problems"and successfully obtained similar results.

Since I'm planning to use a rather complex geometry, I used snappyHexMesh to reproduce Ze Huang's work for similar geometry that he created using blockMesh. The result was far from what I expected. In the first figure (see the attached file named as "Elpot_at_positive_z_direction.jpg), I noticed that there is a distinct gap interface between the small square box (rodUp) and its bigger surrounding neighbor. When checking the sets and the zones of my geometry, I found that that there is unexpected mesh (faceset) as indicated by an arrow (see "Elpot_rod_comparison.jpg")

Furthermore, these unexpected mesh is created by createPatch when converting "rodUpFace" and "rodDownFace" facesets into "rodUp" and "rodDown" patches. The facesets were generated by topoSet and here is my topoSet configuration.

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.4.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      topoSetDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

actions
(

    // create new rodzone
    {
        name    rodZone;
        type    cellSet;
        action  new;
        source  zoneToCell;
        sourceInfo
        {
            name AMIZone;
        }
    }

    {
        name    rodUpFace;
        type    faceSet;
        action  new;
        source  cellToFace;
        sourceInfo
        {
            set rodZone;
	    option all;
        }
    }

    {
        name    rodDownFace;
        type    faceSet;
        action  new;
        source  cellToFace;
        sourceInfo
        {
            set rodZone;
	    option all;
        }
    }
  
    {
        name    rodUpFace;
        type    faceSet;
        action  subset;
        source  patchToFace;
        sourceInfo
        {
            name maxZ;
        }
    }

    {
        name    rodDownFace;
        type    faceSet;
        action  subset;
        source  patchToFace;
        sourceInfo
        {
            name minZ;
        }
    }
);

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

The log file for topoSet (no error):

/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.4.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.4.0-f0842aea0e77
Exec : topoSet
Date : Nov 27 2015
Time : 06:43:41
Host : "TesLAC1060"
PID : 3991
Case : /home/feno/OpenFOAM/feno-2.4.0/run/tutorials/mesh/snappyHexMesh/unite
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Reading topoSetDict

Time = 0
mesh not changed.
Created cellSet rodZone
Applying source zoneToCell
Adding all cells of cellZone AMIZone ...
Found matching zone AMIZone with 640 cells.
cellSet rodZone now size 640
Created faceSet rodUpFace
Applying source cellToFace
Adding faces according to cellSet rodZone ...
faceSet rodUpFace now size 2256
Created faceSet rodDownFace
Applying source cellToFace
Adding faces according to cellSet rodZone ...
faceSet rodDownFace now size 2256
Read set faceSet rodUpFace with size 2256
Applying source patchToFace
Adding all faces of patch maxZ ...
Found matching patch maxZ with 16 faces.
faceSet rodUpFace now size 16
Read set faceSet rodDownFace with size 2256
Applying source patchToFace
Adding all faces of patch minZ ...
Found matching patch minZ with 16 faces.
faceSet rodDownFace now size 16

End

For my createPatch configuration:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.4.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      createPatchDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// Do a synchronisation of coupled points after creation of any patches.
// Note: this does not work with points that are on multiple coupled patches
//       with transformations (i.e. cyclics).
pointSync false;

// Patches to create. An empty patch list just removes patches with zero
// faces from $FOAM_CASE/constant/polyMesh/boundary.
patches
(
    {
        name rodUp;
        patchInfo
        {
            type            patch;
        }
        constructFrom set;
        set rodUpFace;
    }
    {
        name rodDown;
        patchInfo
        {
            type            patch;
        }
        constructFrom set;
        set rodDownFace;
    }
);

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

The log file for createPatch (no error):

/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.4.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.4.0-f0842aea0e77
Exec : createPatch -overwrite
Date : Nov 27 2015
Time : 06:47:10
Host : "TesLAC1060"
PID : 4010
Case : /home/feno/OpenFOAM/feno-2.4.0/run/tutorials/mesh/snappyHexMesh/unite
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Reading createPatchDict

Adding new patch rodUp as patch 11 from
{
type patch;
}

Adding new patch rodDown as patch 12 from
{
type patch;
}


Read 16 faces from faceSet rodUpFace
Read 16 faces from faceSet rodDownFace

Doing topology modification to order faces.

Not synchronising points.

Removing patches with no faces in them.

Removing zero-sized patch maxZ type patch at position 0
Removing zero-sized patch minZ type patch at position 1
Removing zero-sized patch maxX type patch at position 2
Removing zero-sized patch minX type patch at position 3
Removing zero-sized patch maxY type patch at position 4
Removing zero-sized patch minY type patch at position 5
Removing zero-sized patch rod type wall at position 6
Removing zero-sized patch rod_slave type wall at position 7
Removing patches.
Writing repatched mesh to 0

End

My questions are simple:
1. Is this bug in createPatch?
2. Does this unexpected mesh (facesets) created by createPatch would affect the result of the solver?

Thank you,

Cheers

Ferensa

Note: If someone need to reproduce my work, please use "united.zip" file

[wyldckat]

Greetings Ferensa,

I've tested the case you attached with both OpenFOAM 2.4.x and 2.4.0, but I was not able to reproduce the same error. I ran the commands you instructed in the README file, namely:

1. blockMesh
2. surfaceFeatureExtract
3. snappyHexMesh -overwrite
4. topoSet 
5. createPatch -overwrite 
6. createBaffles -overwrite

and I was not able to reproduce the issue, namely the weird faces on the side that look something like a dented surface.

Did you perhaps run any command slightly differently? Do you have any folders named "1" or "2"?

Best regards,
Bruno

[feno102]

Dear Bruno,

Thank you for your reply.

I ran the commands exactly as given in the README file, and no folders 1 and 2 inside my case folder.

Here is what I did to obtain the weird surface faces on my case.

After executed the commands in README file and followed by executing paraFoam, I carried out these following steps.
1) Check "include Sets" and "include Zones" boxes (as indicated in "Unite-01.jpg" figure)
2) Uncheck "internal Mesh" box.
3) Check "rodUp" and "rodDown" patches boxes (see Unite-02.jpg)
4) Check "rodUpFace" and "rodDownFace" faceSets boxes (see Unite-02.jpg)
5) Click "apply"

Cheers,

Ferensa

[wyldckat]

Hi Ferensa,

So what happens is this:

1. When you run topoSet, it creates the faceSets, which I like to call "shopping lists" for the ID numbers of each face in/on the mesh.
2. When you run createPatch, it tells us this particular line:
   

   Doing topology modification to order faces.

   It might look to be innocent enough, but this is telling us that the order of the faces has been changed.
3. If you take a look at the file "constant/polyMesh/boundary", you will see something like this:
   • before createPatch:

         mold
         {
             type            patch;
             nFaces          6400;
             startFace       76520;
         }

   • after createPatch:

         mold
         {
             type            patch;
             nFaces          6400;
             startFace       76488;
         }

   And as you can see, the start face number changed. This means that the faceSets you created with topoSet are now outdated, because they referred to the old ID list of the faces.
   

That is why you see the big change in the representation of the faceSets. Technically this can be considered a bug or a missing feature in OpenFOAM, but the concept is somewhat simple: what do you want to do with the faceSet after you've already created the patch you wanted from it?
And if you want to recover the faceSets, you can use another topoSet to recreate them by using the operation "patchToFace", if I remember correctly.

Best regards,
Bruno

[feno102]

Dear Bruno,

Thank you for pointing out the change of startFace number in boundary file

Note:
Recovering the facesets from "rodUp" and "rodDown" patches using topoSet does not solve the issue since the patches are generated from corrupted facesets.

I checked again my boundary file before and after executing CreatePatch, and now I know why the values of startFace shifted.

From my experience on "propeller" case tutorial, if the boundary patch names that created by createPatch are similar with those created by blockMesh or snappyHexMesh. The startFace values of those patches would remain the same.

However, if the boundary patch names that stated in createPatch are different from those created by blockMesh or snappyHexMesh, createPatch would remove the old patch names along with their ID numbers, and allocate new ID numbers for the new patch names and placed them after the old patches. This what happened in my case.

The solution is simple, use the same patch names in createPatch. But I prefered to skip topoSet and just used createPatch to remove boundary patches with zero nFaces.

Here is my boundary after executing snappyHexMesh

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

11
(
    maxZ
    {
        type            patch;
        nFaces          16;
        startFace       76488;
    }
    minZ
    {
        type            patch;
        nFaces          16;
        startFace       76504;
    }
    maxX
    {
        type            patch;
        nFaces          0;
        startFace       76520;
    }
    minX
    {
        type            patch;
        nFaces          0;
        startFace       76520;
    }
    maxY
    {
        type            patch;
        nFaces          0;
        startFace       76520;
    }
    minY
    {
        type            patch;
        nFaces          0;
        startFace       76520;
    }
    rod
    {
        type            wall;
        inGroups        1(wall);
        nFaces          0;
        startFace       76520;
    }
    rod_slave
    {
        type            wall;
        inGroups        1(wall);
        nFaces          0;
        startFace       76520;
    }
    mold
    {
        type            patch;
        nFaces          6400;
        startFace       76520;
    }
    moldUp
    {
        type            patch;
        inGroups        1(Upper);
        nFaces          1584;
        startFace       82920;
    }
    moldDown
    {
        type            patch;
        inGroups        1(Bottom);
        nFaces          1584;
        startFace       84504;
    }
)

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

Instead of replacing "maxZ" and "minZ" with "rodUp" and "rodDown", respectively, I executed empty createPatch

my new createPatchDict is

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.4.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      createPatchDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// Do a synchronisation of coupled points after creation of any patches.
// Note: this does not work with points that are on multiple coupled patches
//       with transformations (i.e. cyclics).
pointSync false;

// Patches to create. An empty patch list just removes patches with zero
// faces from $FOAM_CASE/constant/polyMesh/boundary.
patches
(
);

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

My boundary after executing createPatch become :

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

5
(
    maxZ
    {
        type            patch;
        nFaces          16;
        startFace       76488;
    }
    minZ
    {
        type            patch;
        nFaces          16;
        startFace       76504;
    }
    mold
    {
        type            patch;
        nFaces          6400;
        startFace       76520;
    }
    moldUp
    {
        type            patch;
        inGroups        1(Upper);
        nFaces          1584;
        startFace       82920;
    }
    moldDown
    {
        type            patch;
        inGroups        1(Bottom);
        nFaces          1584;
        startFace       84504;
    }
)

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

As you can see, the startFace value of mold patch before and after executing createPatch remains the same "76520". The problem is SOLVED

Unfortunately when I executed createBaffles command to create cyclicAMI patches, all ID numbers of those patches are shifted again

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

7
(
    maxZ
    {
        type            patch;
        nFaces          16;
        startFace       75848;
    }
    minZ
    {
        type            patch;
        nFaces          16;
        startFace       75864;
    }
    mold
    {
        type            patch;
        nFaces          6400;
        startFace       75880;
    }
    moldUp
    {
        type            patch;
        inGroups        1(Upper);
        nFaces          1584;
        startFace       82280;
    }
    moldDown
    {
        type            patch;
        inGroups        1(Bottom);
        nFaces          1584;
        startFace       83864;
    }
    AMI1_rod
    {
        type            cyclicAMI;
        inGroups        2 (cyclicAMI baffleFaces);
        nFaces          640;
        startFace       85448;
        matchTolerance  0.0001;
        transform       noOrdering;
        neighbourPatch  AMI2_mold;
    }
    AMI2_mold
    {
        type            cyclicAMI;
        inGroups        2 (cyclicAMI baffleFaces);
        nFaces          640;
        startFace       86088;
        matchTolerance  0.0001;
        transform       noOrdering;
        neighbourPatch  AMI1_rod;
    }
)

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

But that a question for another thread

Thank you so much for your help,

Sincerely,

Ferensa

[wyldckat]

Hi Ferensa,

Originally Posted by feno102

Note:
Recovering the facesets from "rodUp" and "rodDown" patches using topoSet does not solve the issue since the patches are generated from corrupted facesets.

I think you didn't fully understand what I wrote:

Originally Posted by wyldckat

And as you can see, the start face number changed. This means that the faceSets you created with topoSet are now outdated, because they referred to the old ID list of the faces.

In other words, the faceSets are not corrupted before running createPatch. They are only corrupted/outdated after using createPatch and/or createBaffles.

Then again, I forgot to write something I had thought about for when createBaffles is called:

Since you're reassigning internal faces to the patches that are now defined as baffles, this means that these faces need to be in the last chunk of face IDs, due to how OpenFOAM deals with face identification:

1. First chunk is for internal faces.
2. Second (last) chunk is for boundary (external) faces.

I hope this makes it clearer.
Because if you want to make the faceSets operational again, after using createPatch and/or createBaffles, you need to recreate them from the patches.

Best regards,
Bruno

[me12p1006]

Hi all,

I am trying to feed air through a square inlet on the bottom face of a 3D rectangular tank filled with water. I am able to do this using faceset in toposet dict as follows:
{
name faceGrabbed;
type faceSet;
action new;
source boxToFace;
sourceInfo
{
box (0.035 0.035 0.08)(0.04 0.04 0.08);
}
}

But when i tried to do it with cellset (by replacing the type with cellset) as given below in toposet dict then I am facing the following error: unexpected class name cellset expected faceset while reading object faceGrabbed.

{
name faceGrabbed;
type cellSet;
action new;
source boxToCell;
sourceInfo
{
box (0.015 0.015 0)(0.02 0.02 0);
}
}
)

My create patch dictionary is as follows:

{
//- name of new patch
name bubble;

//- type of new patch
patchInfo
{
type patch;
}
//- How to construct: either from 'patches' or 'set'
constructFrom set;
//- if constructionFrom = set : name of faceSet
set faceGrabbed;
}
);

I am running the following commands:
blockMesh
TopoSet
CreatePatchDict -overwrite
-------here I am getting error: Foam fatal IO error: unexpected class name cellset expected faceset while reading object faceGrabbed.

Can anyone please help as I tried a lot to retrieve this.