CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM

Problem after mergeMesh, water flows through the wall, which should not happen

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By Astrodan

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   May 29, 2016, 11:04
Default Problem after mergeMesh, water flows through the wall, which should not happen
  #1
New Member
 
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10
Andy_Wang is on a distinguished road
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.
Attached Files
File Type: doc alpha.water.doc (26.5 KB, 5 views)
File Type: doc p_rgh.doc (16.0 KB, 1 views)
File Type: doc U.doc (15.5 KB, 0 views)
Andy_Wang is offline   Reply With Quote

Old   May 30, 2016, 12:42
Default
  #2
New Member
 
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10
Andy_Wang is on a distinguished road
hier are some pics, that may help to better unterstand
Attached Images
File Type: jpg without scheibe.jpg (30.9 KB, 39 views)
File Type: jpg with scheibe.jpg (36.0 KB, 33 views)
Andy_Wang is offline   Reply With Quote

Old   May 30, 2016, 12:50
Default
  #3
Senior Member
 
Join Date: Aug 2013
Posts: 407
Rep Power: 16
Antimony is on a distinguished road
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
Antimony is offline   Reply With Quote

Old   May 30, 2016, 15:01
Default
  #4
New Member
 
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10
Andy_Wang is on a distinguished road
Quote:
Originally Posted by Antimony View Post
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:-)
Attached Files
File Type: doc boundary before mergeMeshes.doc (14.0 KB, 5 views)
File Type: doc boundary after first mergeMeshes.doc (14.5 KB, 5 views)
File Type: doc Boundary after second mergeMeshes.doc (15.0 KB, 1 views)
File Type: zip scheiben.stl.zip (58.1 KB, 1 views)
Andy_Wang is offline   Reply With Quote

Old   May 31, 2016, 04:45
Default
  #5
Member
 
Timm Severin
Join Date: Mar 2014
Location: Munich
Posts: 63
Rep Power: 12
Astrodan is on a distinguished road
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 likes this.
Astrodan is offline   Reply With Quote

Old   May 31, 2016, 06:00
Default
  #6
Senior Member
 
Join Date: Aug 2013
Posts: 407
Rep Power: 16
Antimony is on a distinguished road
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
Antimony is offline   Reply With Quote

Old   May 31, 2016, 06:24
Default
  #7
Member
 
Timm Severin
Join Date: Mar 2014
Location: Munich
Posts: 63
Rep Power: 12
Astrodan is on a distinguished road
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.
Astrodan is offline   Reply With Quote

Old   May 31, 2016, 06:36
Default
  #8
New Member
 
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10
Andy_Wang is on a distinguished road
Hi Timm and Antimony,

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

cheers,
Anzhi
Andy_Wang is offline   Reply With Quote

Old   May 31, 2016, 06:38
Default
  #9
Senior Member
 
Join Date: Aug 2013
Posts: 407
Rep Power: 16
Antimony is on a distinguished road
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
Antimony is offline   Reply With Quote

Old   May 31, 2016, 17:53
Default
  #10
New Member
 
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10
Andy_Wang is on a distinguished road
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
Andy_Wang is offline   Reply With Quote

Old   June 13, 2016, 10:54
Default
  #11
Member
 
Timm Severin
Join Date: Mar 2014
Location: Munich
Posts: 63
Rep Power: 12
Astrodan is on a distinguished road
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:
Code:
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
Code:
// 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):
Code:
...
    // 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:
Code:
# create scheiben mesh
Code:
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.
Astrodan is offline   Reply With Quote

Old   June 13, 2016, 16:24
Default
  #12
New Member
 
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10
Andy_Wang is on a distinguished road
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
Andy_Wang is offline   Reply With Quote

Old   June 14, 2016, 05:38
Default
  #13
Member
 
Timm Severin
Join Date: Mar 2014
Location: Munich
Posts: 63
Rep Power: 12
Astrodan is on a distinguished road
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:
Code:
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.
Astrodan is offline   Reply With Quote

Old   June 15, 2016, 09:11
Default
  #14
New Member
 
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10
Andy_Wang is on a distinguished road
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
Andy_Wang is offline   Reply With Quote

Reply

Tags
cyclicacmi, mergemeshes

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Setting the height of the stream in the free channel kevinmccartin CFX 12 October 13, 2022 22:43
Mass imbalance problem in multiphase water and steam CFX case Antech CFX 1 October 26, 2020 05:03
No liquid water exist in my Fuel Cell simulation fatchang FLUENT 19 October 15, 2018 15:27
problem with cyclicAMI and wall distance Maff OpenFOAM Bugs 5 August 14, 2014 15:41
uptodate water distribution network fredius,magige,tanzanian,(e.a) Main CFD Forum 0 January 27, 2002 08:10


All times are GMT -4. The time now is 21:58.