|
[Sponsors] |
May 14, 2008, 10:51 |
Ok, Andras,
your test case
|
#21 |
Member
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 17 |
Ok, Andras,
your test case works in the way you are describing it using OpenFOAM-1.4.1 Applying the proposed steps to my case always causes problems with the stitchMesh function, normally running into the error --> FOAM FATAL ERROR : Zero length edge detected. Probable projection error: slave patch probably does not project onto master. Please switch on enriched patch debug for more info#0 Foam::error::printStack(Foam::stream&) in "~/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so" Maybe you can even help me out of this situation!? I would be really interested in finally solving this problem... |
|
May 14, 2008, 11:42 |
Andreas,
I am trying to sti
|
#22 |
New Member
Andras Horvath
Join Date: Mar 2009
Posts: 29
Rep Power: 17 |
Andreas,
I am trying to stitch the faces that make up the surface of a cylinder (to connect inner and outer meshes for Multiple Reference Frame simulations). I can stitch either both pairs of circles or the cylindrical shell but I can't connect the shell patches, when the circles are already stitched. I have tried creating combined patches and stitching the pairs at once and also stitching them one by one. Either way I run into "projection errors" and other strange errors like you do. A congruent straight line edge between two or more patches stitches fine. I checked that with another test case. Congruent curved edges seem to be the troublemaker when the patches are not parallel to each other... but this is just a guess. To cut it short: I'm stuck. Although some people say that stitchMesh is actually working fine I think there are some bugs underneath the carpet (especially concerning more complex geometries). Andras |
|
May 15, 2008, 04:52 |
Hello Andras,
what I'm tryi
|
#23 |
Member
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 17 |
Hello Andras,
what I'm trying to stitch are the diffeent mesh resolutions here: . As can be seen the Interfaces aren't curvy and the geometry seems quite simple. But not simple enough for stitch Mesh... I do not even find a starting point were to continue with a new approach of solving that problem. So any idea for a new starting point is pretty welcome!! |
|
May 15, 2008, 06:07 |
Hi Andreas!
You could try cre
|
#24 |
New Member
Andras Horvath
Join Date: Mar 2009
Posts: 29
Rep Power: 17 |
Hi Andreas!
You could try creating two final patches using the "createPatch" tool with a createPatchDict that looks like this:
Then stitch the combined patches. Have you already tried my recipe on your mesh with OpenFoam-1.4.1 vanilla? Best, Andras |
|
May 15, 2008, 06:39 |
Hello Andras,
well, maybe I
|
#25 |
Member
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 17 |
Hello Andras,
well, maybe I did not get the point, but the patches are already defined out of the four faces. For example if I use stitchMesh <root> <case> IF_1_inside IF_1_outside, my aim is to stitch the two patches surrounding the smallest square. What I'm trying to say is that e.g. IF_1_inside consists out of the faces 1, 2, 3, 4, and I do not have to stitch every single face. (As far is I understood the functionality of createPatch is to combine the faces to one single patch!?) I already tried your recipe on my mesh with OpenFoam-1.4.1 from the opencfd page, but what is the vannila version of that? Thanks for your time, Andreas |
|
May 15, 2008, 07:38 |
Hi Andreas!
When saying vanil
|
#26 |
New Member
Andras Horvath
Join Date: Mar 2009
Posts: 29
Rep Power: 17 |
Hi Andreas!
When saying vanilla I mean the standard release without any development patches... I'm sorry to say I have no further ideas concerning stitchMesh at the moment. Andras |
|
August 13, 2008, 05:55 |
hi,
I do not know if my pro
|
#27 |
Senior Member
mayank gupta
Join Date: Mar 2009
Posts: 110
Rep Power: 17 |
hi,
I do not know if my problem falls in this thread or not but it is kind of strange. I am trying to mesh a small region between the slot and flap. I define points in sequence but point 3 should be to the right of point 2 but it comes to the left of point 2 no matter what I try. I am attaching both the image file and the blockMeshDict with this. Can some one please take a look and help me? I am just trying this patch individually before I put it in my main mesh. Thanx a lot. blockMeshDict |
|
December 10, 2008, 10:09 |
Hello,
I've tried to get rid
|
#28 |
New Member
Sebastian Krick
Join Date: Mar 2009
Posts: 9
Rep Power: 17 |
Hello,
I've tried to get rid of 2 pairs of interfaces in my simulation and did so like Andras Horvarth. But when I run foamMeshToFluent I get the following error message: --> FOAM FATAL ERROR : edgeFaces_ full at entry:16 for edge 2 0#0 Foam::error::printStack(Foam:stream&) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so" #1 Foam::error::abort() in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so" #2 Foam::cellMatcher::calcEdgeAddressing(int) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so" #3 Foam::tetMatcher::matchShape(bool, Foam::List<foam::face> const&, Foam::List<int> const&, int, Foam::List<int> const&) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so" #4 Foam::degenerateMatcher::match(Foam::List<foam::fa ce> const&, Foam::List<int> const&, int, Foam::List<int> const&) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so" #5 Foam::degenerateMatcher::match(Foam::primitiveMesh const&, int) in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so" #6 Foam::primitiveMesh::calcCellShapes() const in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so" #7 Foam::primitiveMesh::cellShapes() const in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/lib/libOpenFOAM.so" #8 Foam::fvSchemes::read() in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/applications/bin/foamMeshToFluent" #9 Foam::objectRegistry::writeData(Foam:stream&) const in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/applications/bin/foamMeshToFluent" #10 __libc_start_main in "/lib/libc.so.6" #11 Foam::fvMesh::readUpdate() in "/usr/lib64/OpenFOAM/OpenFOAM-1.4.1/applications/bin/foamMeshToFluent" From function calcEdgeAddressing(const faceList&, const label) in file meshes/meshShapes/cellMatcher/cellMatcher.C at line 202. FOAM aborting Aborted |
|
March 6, 2009, 06:00 |
Hi all,
now I've played ar
|
#29 |
New Member
olivier braun
Join Date: Mar 2009
Location: Lausanne, Switzerland
Posts: 19
Rep Power: 17 |
Hi all,
now I've played around with stitchMesh in a similar configuration than Andreas Dietz, just that it is all hexa. In fact the mesh is generated with ICEM pure hexa in good old block refinement style. When going through unstruct representation in ICEM in order to use fluent format for transfer, there is no connectivity of the non-conformal patches as could have been in Multiblock representation IIRC good old TASCflow times. SO far so good. So I went to stitch together all the patches and understood I had to do it separately, which means to fiddle around in ICEM to separate the volumes and interface regions ok. (tried the n-squared setting to 1, worked with no complaint but meshCheck complained about degenerate elements, believe he found some elements on opposite sides of the interfaces surrounding a hydrofoil). Got it to have 2x8 patches, pairing each. I put up a little shell script to automate the task. It might be neither bullet-proof neither a tutorial of efficient shell programming but it might be useful for some: # The pairing patches from ICEM are named e.g. INT_01_E_0 INT_01_E_1 (or _Red _Green) # The important is that two and only two patches containing the PatchList entry exist PatchList=( INT_01_E INT_01_W INT_01_N INT_01_S INT_12_W INT_12_E INT_12_N INT_12_S ) echo ${PatchList[@]} for PatchBase in ${PatchList[@]}; do rm constant/polyMesh/*Zones rm constant/polyMesh/meshModifiers Patches=$(grep $PatchBase constant/polyMesh/boundary) echo $Patches stitchMesh ${Patches[0]} ${Patches[1]} if [ -e 1e-05/polyMesh/ ] then rm -r constant/polyMesh/ mv 1e-05/polyMesh/ constant/ rm -r 1e-05 npatch=$(grep -P -m 1 ^[0-9]+$ constant/polyMesh/boundary) nrm=$(grep -c $PatchBase constant/polyMesh/boundary) nnew=$(( $npatch - $nrm )) echo "$npatch $nrm $nnew" cp constant/polyMesh/boundary tmpbnd cat tmpbnd | sed "18s/$npatch/$nnew/" | sed "/$PatchBase/,+5d" > constant/polyMesh/boundary checkMesh else exit fi done So far I run into trouble again as soon as stitching a patch neighboring an already stitched patch. Patching N-S and N-S is fine, or E-W and E-W, as soon as a neighbor shall be stitched, I get an error: Face 1977839 reduced to less than 3 points. Topological/cutting error B. Old face: 2(218300 218301) new face: 2(218300 218301) From function void slidingInterface::coupleInterface(polyTopoChange& ref) const in file polyMeshModifiers/slidingInterface/coupleSlidingInterface.C at line 1794. with 1.5-dev (1095) I ended up following another strategy that seamed more obfuscated at the beginning but showed up to be pretty feasible. I export just a simple coarse Mesh from ICEM via fluent format into Foam. Then i got the refinement region boundaries as STL files from ICEM, I've slightly blown them up by offset. Use cellSet to define the refinement regions and refineMesh-dict on the cell sets to do the classical Hex-Cutting 2x2x2. This proved to work quite easily and avoids transferring huge fluent format files. When using embedded refinement regions, have to start with the most outer one, because cells at the 'hanging node interface' become polyhedral and cannot be refined with the standard hex cell cutting. Hrvoje, as you are apparently working on the invoked routines, I can provide you a more detailed description of what happens. Cheers Olivier |
|
April 8, 2009, 03:15 |
a compromise to stitching corners with stitchMesh
|
#30 |
Member
Richard Kenny
Join Date: Mar 2009
Posts: 64
Rep Power: 18 |
Recently, I happened to be working on stitching together interfaces (tops of boxes in fact) that contain corner points
and initially encountered some of the problems mentioned earlier on this thread cf. Anita April 21, 2008, 13:27 lord_kossity May 15, 2008, 07:52 To take Anita's outline problem: ------------------------------------ |6......................................5| |.........................................| |.........................................| |1...........................2................| |==============................| |10.......................9 || .............| |............................ ||...............| |............................ ||...............| |7....................... 8 || 3.............4| ------------------------------------ stitching 1-2 with 10-9 prevents a similar operation for the pair 9-8 and 2-3. The problem seems to be related to the projection of nodes from edge 9 to positions along edge 2. These projected nodes appear as isolated points along edge 2 (when examining the interface 2- 3 in paraView for example) which do not (necessarily) coincide with the vertices of the faces on the interface 2-3. The algorithm (in enrichedPatchCutFaces.C) notices this and aborts. As a possible compromise I used the schema below to resize the patches 9-8 and 2b-3 so that common edge points of (2a - 9 - 2b) are no longer included. After stitching all interfaces i.e. initially 1 - 2a with 10-9a then 2b-3 with 9b-9 one is left with a narrow patch one face area wide designated by "*". A "skeletal" patch, if you like, that will require suitable boundary conditions in order to minimize its impact upon the prevailing flow. ------------------------------------ |6......................................5| |.........................................| |.........................................| |1...........................2a................| |==============................| 10........................9a *...............| | .......................9b || 2b.............| |............................ ||...............| |............................ ||...............| |7....................... 8 || 3.............4| ------------------------------------ The dimensions of the flow problem in my case meant that the presence&influence of such a "skeleton" could be regarded as negligible. This may not always be the case though. The following is a prescription (using either OpenFoam-1.5.x or OF-1.5-dev) to resize the relevant patches using a combination of "faceSet" ("pointSet" could be incorporated too if required) and "createPatch" commands: ( where interface1 = 1 - 2 - 3 interface2 = 10 - 9 - 8 ) 1) in faceDictInterface1Faces // Name of set to operate on name interface1Faces; // One of clear/new/invert/add/delete|subset/list action new; topoSetSources ( // Patch to faces patchToFace { name interface-1-2-3; } ); ...issue commands " cp faceDictInterface1Faces system/faceDict " "faceSet" 2) now extract faces whose normals point in the required direction faceSetDictNormalx // Name of set to operate on name interface1-xDirectionFaces; // One of clear/new/invert/add/delete|subset/list action subset; // Actions to apply to pointSet. These are all the topoSetSource's ending // in ..ToFace (see the meshTools library). topoSetSources ( normalToFace { normal (1 0 0); // Vector cos 0.01; // Tolerance (max cos of angle) } ); ...issue commands " cp faceSetDictNormalx system/faceDict " "faceSet" 3) for each set of faces aligned in a particular direction (or sitting on a component interface plane) take those that have no vertex lying on the common edge 2-9. faceSetDictNormalxReduced // Name of set to operate on name interface1-xDirectionReducedFaces; // One of clear/new/invert/add/delete|subset/list action subset; // Actions to apply to pointSet. These are all the topoSetSource's ending // in ..ToFace (see the meshTools library). topoSetSources ( // Faces with face centre within box // Ensure the bounds do *not* include any common edge vertices boxToFace { box (xMin yMin zMin) (xMax yMax zMax); } ); ...issue commands " cp faceSetDictNormalx system/faceDict " "faceSet" 4) createPatchDictNormalxReduced // Tolerance used in matching faces. Absolute tolerance is span of // face times this factor. matchTolerance 1E-3; // Do a synchronisation of coupled points. //pointSync true; pointSync false; // Patches to create. // If no patches does a coupled point and face synchronisation anyway. patches ( { // Name of new patch name interface1NormalxReduced; // Type of new patch type patch; // How to construct: either 'patches' or 'set' constructFrom set; // If constructFrom = set : name of faceSet set interface1-xDirectionReducedFaces; } ); ...issue commands " cp createPatchDictNormalxReduced system/createPatchDict " "createPatch" Then repeat steps 1)-4) for all the various interface planes. Finally, "stitchMesh" the 'reduced' interface planes and apply boundary conditions to the remaining mesh "skeleton". It's a painful process but might be a useful compromise in some circumstances. When the surfaces meeting at the corner of an interface are non-planar then greater use of "boxToFace" ( or similar pointSet directives) will unfortunately be required it seems. With regard to cylindrical cap interfaces (cylinders with one closed end), it appears that sometimes these can be stitched directly ( using OF-1.5dev, I didn't extensively check with OF1.5.x) and sometimes not (!). The only noticeable difference in the two cases being the distribution of interface points along the edges. If points from both interfaces coincide (to whatever tolerance) along the edge then the stitching process is likely to fail. In the latter situation decomposing as above, 1) - 4), might be an alternative approach. I hope this helps, Richard Kenny. |
|
January 13, 2012, 09:02 |
|
#31 |
Member
Aqua
Join Date: Oct 2011
Posts: 96
Rep Power: 15 |
Hello,Hrv,
I am trying to simulate two cars passing by each other, by moving mesh. so the geometry model is like in the attachment: block1 and block2 are the air parts, icube and ocube are two cars. block1 and block2 will move towards each other by setting their interfaces GGI. Now, I am trying to mesh it. I tried to used snappymultiRegionFoam case to create the mesh. so, in triSurface, there are four files: block1.stl, block2.stl, icub.stl, ocube.stl. without icube and ocube, I got it managed to creat the mesh. Then I added the icube and ocube. but,during snappyhexmesh, some information is givin like this: CellZones: block1 size:7919 block2 size:7737 icube size:0 ocube size:0 FaceZones: iblock size:0 oblock size:1200 icube size:0 ocube size:0 Could you please help me on this? Is there some other way to creat the mesh i want? Thank you so much!! Aqua |
|
April 4, 2013, 12:51 |
|
#32 |
Member
Yosmcer Mocktai
Join Date: Apr 2013
Location: Behind a computer
Posts: 50
Rep Power: 17 |
As this post is related to stichMesh and that I do not use it, I made a new thread:
Merging ege patches Last edited by Yosmcer; April 5, 2013 at 17:36. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Foam::error::PrintStack | almir | OpenFOAM Running, Solving & CFD | 92 | May 21, 2024 08:56 |
Problem using AMI | vinz | OpenFOAM Running, Solving & CFD | 298 | November 13, 2023 09:19 |
[mesh manipulation] Automatically delete empty patches from boundary file after stitchMesh | g_b | OpenFOAM Meshing & Mesh Conversion | 4 | November 23, 2020 08:37 |
Possible bug with stitchMesh and cyclics in OpenFoam | Jack001 | OpenFOAM Pre-Processing | 0 | May 21, 2016 09:00 |
[mesh manipulation] Problem with stitchMesh: it does not work in meshes with several common patches | arnau1985 | OpenFOAM Meshing & Mesh Conversion | 2 | June 25, 2013 09:49 |