[Andy_Wang]

Hello Foamers,

i have several parts of a car door. i meshed them one by one with snappyHexMesh. And i want to combine them together in one mesh so i used mergeMesh utility. Everythings was fine until i ran the simulation. The water flows from the tank down and reached the window. What's strange is, the water just flows through the window(the window has a name scheiben and is defined als wall). I tried to run a similar simulation just with the part(scheiben) direct from snappyHexMesh. It behaviors right. So i can say the snappyHexMesh is without problem and the issue must be somewhere in mergeMesh. Can anyone please help me with this?

i use openfoam 2.4.0 in ubuntu 16.04. The solver is interFoam.

[Andy_Wang]

hier are some pics, that may help to better unterstand

[Antimony]

Hi,

You would need to show the log of the mergeMeshes process and if possible the boundary file before and after the mergeMeshes process. And if allowable, your geometry as well.

Unfortunately, the images and the variable files won't provide info on the problem.

Cheers,
Antimony

[Andy_Wang]

Originally Posted by Antimony

Hi,

You would need to show the log of the mergeMeshes process and if possible the boundary file before and after the mergeMeshes process. And if allowable, your geometry as well.

Unfortunately, the images and the variable files won't provide info on the problem.

Cheers,
Antimony

Hi Antimony,

thanks for your reply. I have 3 parts, scheiben, dl_a and dl_i. My first step is to merge scheiben and dl_a with:
mergeMeshes scheiben/ dl_a/
cd scheiben/
mv 0.001/polyMesh/* constant/polyMesh/

The second step is to merge scheiben and dl_i:
mergeMeshes scheiben/ dl_i/
cd scheiben/
mv 0.002/polyMesh/* constant/polyMesh/

I attached the boundary files before and after mergeMeshes hier. The geometries dl_a and dl_i are too big to upload even after compression. I'll find a way to upload these two. I really hope with these informations the problem can be found:-)

[Astrodan]

I think the problem is relatively simple, mergeMesh only merges two mesh regions into one polyMesh directory, however you still obtain two different regions (run checkMesh, it will show that). What you need to do is run a combination of mergeMesh and stitchMesh. I can't give you the exact commands out of my head, but you'll figure it out I guess.

Furthermore, after running one stitchMesh operation (and you can only run one stitching at once) files get created in the current (i.e. constant or time) polyMesh directory (see http://www.cfd-online.com/Forums/ope...tml#post183538), you will need to manually delete those to run stitchMesh again.

[Antimony]

Hi,

I agree with Astrodan. mergeMeshes still keeps the two regions separate.
stitchMesh, in my opinion, is a bit of a gamble. AFAIK, there have been problems with the stitching process when it is done more than once (or twice, can't remember exactly).

There was a fix that wyldckat had come up with that seemed to work for some users, but unfortunately not for me. Link: https://github.com/wyldckat/stitchMeshMultiPatch

I resorted to cyclicAMI to make the different mesh regions talk to each other.

Hope this helps.

Cheers,
Antimony

[Astrodan]

I think the problem you are addressing are related to the files that need to be deleted, and although this sounds bad, i never encountered any problem with it.

However, cyclicAMI patches are quite a good alternative I use myself as well. And to simplify things further, I would suggest to have a look at the cyclicACMI boundary, which also supports not completely matching patch areas.

[Andy_Wang]

Hi Timm and Antimony,

many thanks for your reply. I'll try your tipps out and see what happens then!

cheers,
Anzhi

[Antimony]

Hi,

Even when the files were deleted the problem always remained. In fact I remember it being a common enough problem that many had experienced, which is what led to the creation of the separate stitchMeshMultiPatch. (Perhaps they corrected it in later versions of OF)

You could stitch two meshes, but the next time you tried, invariably you ran into some error that simply could not be resolved.

Yes, cyclicACMI is probably more versatile that cyclicAMI, but it isn't something that I have had the chance to test out much.

Cheers,
Antimony

[Andy_Wang]

Hi to all,

i tried stiticMesh today,but it always ended up with an error when i used this utility with: stitchMesh dichtteil_a dichtteil -partial. Hier is the error report:
--> FOAM FATAL ERROR:
Duplicate point found in cut face. Error in the face cutting algorithm for global face 4(400019 415828 418733 415827) local face 4(8 9 10 11)
Slave size: 2122 Master size: 6196 index: 2.
Face: 9(468429 415828 418733 469071 468537 469068 469069 469070 469067)
[...]

i think it's an common error that many people have also experienced. But unfortunately i can't finde any solution to it.

i also tried to use the cyclicACMI patch. But i still can't figure it out how to set it up and to use it. Could you please tell me something in detail according to the usage of the cyclicACMI patch?

And another question is, even if i used mergeMeshes to combine my parts and they are still in diffrent regions, the definition of the parts is not changed. They are still "wall". How can water flows through wall?

thanks
Anzhi

[Astrodan]

Hi Anzhi,

sorry it took me so long to respond, but I had a course and was not at my work PC. Sadly I cannot give you a working case as an example for the ACMI interface, but I can give you the dictionaries(/dictionary entries) that I use.

Case scenario: I have one simulation mesh which has an outlet, here called outletTT_tmp. Another simulation has the boundary inletCH_tmp. Both are supposed to be connected.
For my method, both boundaries are at the (numerical) exact same coordinates.

topoSetDict.ACMI:

actions
(
    // Get both sides of ami
    // ~~~~~~~~~~~~~~~~~~~~~

    // Create faceZone for patch outlet
    {
        name    outletTTFaces;
        type    faceSet;
        action  new;
        source  patchToFace;
        sourceInfo
        {
            name    outletTT_tmp;
        }
    }
    {
        name    outletTTFaces;
        type    faceZoneSet;
        action  new;
        source  setToFaceZone;
        sourceInfo
        {
            faceSet outletTTFaces;
        }
    }
...
// Same for inlet

This dictionary simply is required to create faceZones, which are used to address the correct cells for the next step. Pretty straight forward.

createBafflesDict.ACMI

// Baffles to create.
baffles
{
    // NOTE: cyclicAMI patches MUST BE defined PRIOR to their associted
    //       blockage patches

    ACMIOutlet
    {
        //- Use predefined faceZone to select faces and orientation.
        type        faceZone;
        zoneName    outletTTFaces;

        patches
        {
            master
            {
                //- Master side patch
                name                outletTT_ACMIInterface;
                type                cyclicACMI;
                matchTolerance      0.0001;
                neighbourPatch      inletCH_ACMIInterface;
                nonOverlapPatch     outletTT_ACMIBlockage;
                
                transform           noOrdering;
            }
            slave // not used since we're manipulating a boundary patch
            {
                //- Slave side patch
                name                outletTT_ACMIInterface;
                type                patch;
            }

            master2
            {
                //- Master side patch
                name                outletTT_ACMIBlockage;
                type                wall;
            }
            slave2 // not used since we're manipulating a boundary patch
            {
                //- Slave side patch
                name                outletTT_ACMIBlockage;
                type                wall;
            }

        }
    }
    
    ACMIInlet
    {
        //- Use predefined faceZone to select faces and orientation.
        type        faceZone;
        zoneName    inletCHFaces;

        patches
        {
            master
            {
                //- Master side patch
                name                inletCH_ACMIInterface;
                type                cyclicACMI;
                matchTolerance      0.0001;
                neighbourPatch      outletTT_ACMIInterface;
                nonOverlapPatch     inletCH_ACMIBlockage;

                transform           noOrdering;
            }
            slave // not used since we're manipulating a boundary patch
            {
                //- Slave side patch
                name                inletCH_ACMIInterface;
                type                patch;
            }

            master2
            {
                //- Master side patch
                name                inletCH_ACMIBlockage;
                type                wall;
            }
            slave2 // not used since we're manipulating a boundary patch
            {
                //- Slave side patch
                name                inletCH_ACMIBlockage;
                type                wall;
            }
        }
    }
}

Slightly more complex. Each entry selects one of the previously defined faceZones and creates and interface and blockage patch. The tool here basically reassigns patch information, as it is also done for any other cyclic patch example I have seen so far.
Note that I can use "transform noOrdering;", since my coordinates are equal. I tried with some distance in between, but somehow this seems not to work properly, or more likely I haven't figured out how. Use the transformPoints tool if your meahes are not in the right positions.

0/field (here 0/U):

...
    // ACMI Cyclic Boundaries
    //  The not connected part
    ".*_ACMIBlockage"
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    
    // The connected part
    ".*_ACMIInterface"
    {
        type            cyclicACMI;
        value           uniform (0 0 0);
    }
    
    // Temporary patches that just need to be defined
    ".*_tmp"
    {
        type            fixedValue;
        value           uniform (999 999 999);
    }  
}

This simply defines the patches. I use regular expressions to reference the (new) patches, since this way I only need to define one BC for all cyclicACMI. Also I have the BC for ".*_tmp" which helps with all tools that complain if you have a boundary in your mesh without the associated BC. However, in the end the _tmp BC is completely unused, and the value only exists to detect errors (velocities of 999 m/s should be easily detectable).

No on how to create/merge your mesh. Lets assume you have the structure:

|-caseScheiben
\-caseBase

The your mesh creating script should look something like this:

# create scheiben mesh

cd caseScheiben
blockMesh

# create main mesh
cd ../caseBase
blockMesh
mergeMeshes . ../caseScheiben
topoSet -dict system/topoSetDict.ACMI
createBaffles -overwrite -dict system/createBafflesDict.ACMI

# checkmesh should now return two regions, but an otherwise acceptable mesh (assuming the mesh was okay beforehand)
checkMesh

Apparently, you might want to adjust names, parameters, and further details. This should only be an initial guideline.

[Andy_Wang]

Hi Timm,

thank you very much for your reply. really appreciated.

According your setting up i did some changes. The topoSet and createBaffles do work now. However the problem that the water flows through the wall "scheibe", is till there. Maybe the problem isn't hier?

cheers
Andy

[Astrodan]

That seems to be the case. But then we probably need more information.

What might help you (in general), though I think here it doesn't, is a function object which measures the flow over each patch. The following does the job sufficiently, although I believe for more precise data you'd need to employ swak4Foam expressions:

functions {
    waterMassBalance
    {
        type                patchFieldFlow;
        outputControlMode   timeStep;
        outputInterval      1;
        factor              1;

        patches
        (
            list
            of
            patches
        );

        fields
        (
            alpha.water
        );

        verbose             true;
    }
}

With this you can check over which patch your water flows, and maybe detect the leak.

[Andy_Wang]

Hi Timm,

thanks again! It seems to be helpful to check over which patch the water flows. I'll try this out and see what can i get.

Andy