|
[Sponsors] |
Problem after mergeMesh, water flows through the wall, which should not happen |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
May 29, 2016, 11:04 |
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 |
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. |
|
May 30, 2016, 12:42 |
|
#2 |
New Member
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10 |
hier are some pics, that may help to better unterstand
|
|
May 30, 2016, 12:50 |
|
#3 |
Senior Member
Join Date: Aug 2013
Posts: 407
Rep Power: 16 |
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 |
|
May 30, 2016, 15:01 |
|
#4 | |
New Member
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10 |
Quote:
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:-) |
||
May 31, 2016, 04:45 |
|
#5 |
Member
Timm Severin
Join Date: Mar 2014
Location: Munich
Posts: 63
Rep Power: 12 |
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. |
|
May 31, 2016, 06:00 |
|
#6 |
Senior Member
Join Date: Aug 2013
Posts: 407
Rep Power: 16 |
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 |
|
May 31, 2016, 06:24 |
|
#7 |
Member
Timm Severin
Join Date: Mar 2014
Location: Munich
Posts: 63
Rep Power: 12 |
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. |
|
May 31, 2016, 06:36 |
|
#8 |
New Member
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10 |
Hi Timm and Antimony,
many thanks for your reply. I'll try your tipps out and see what happens then! cheers, Anzhi |
|
May 31, 2016, 06:38 |
|
#9 |
Senior Member
Join Date: Aug 2013
Posts: 407
Rep Power: 16 |
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 |
|
May 31, 2016, 17:53 |
|
#10 |
New Member
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10 |
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 |
|
June 13, 2016, 10:54 |
|
#11 |
Member
Timm Severin
Join Date: Mar 2014
Location: Munich
Posts: 63
Rep Power: 12 |
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 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; } } } } 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); } } No on how to create/merge your mesh. Lets assume you have the structure: |-caseScheibenThe 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. |
|
June 13, 2016, 16:24 |
|
#12 |
New Member
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10 |
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 |
|
June 14, 2016, 05:38 |
|
#13 |
Member
Timm Severin
Join Date: Mar 2014
Location: Munich
Posts: 63
Rep Power: 12 |
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; } } |
|
June 15, 2016, 09:11 |
|
#14 |
New Member
AW
Join Date: Mar 2016
Posts: 17
Rep Power: 10 |
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 |
|
Tags |
cyclicacmi, mergemeshes |
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |