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

when can stitchMesh be used?

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

Like Tree4Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   February 28, 2013, 05:15
Default when can stitchMesh be used?
  #1
Senior Member
 
Elo´se
Join Date: Jul 2012
Location: Trondheim, Norway
Posts: 103
Rep Power: 5
Eloise is on a distinguished road
Hello,

I'm trying to stitch different meshes together. Here is what I found:
- internal mesh is a cylinder: no problem.
- internal mesh is a block: not possible (see here).
- internal mesh is a sphere: not possible (I did not succeeded).

Am I right? Or did one of you managed to stitch a block or a sphere inside another mesh?

Thanks for your feedback!
Elo´se
Attached Images
File Type: jpg InnerCylinder.jpg (98.2 KB, 264 views)
File Type: jpg InnerSphere.jpg (97.8 KB, 226 views)
Eloise is offline   Reply With Quote

Old   March 2, 2013, 11:00
Default
  #2
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,488
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings Elo´se,

I can only guess that it really depends on the meshes you've got to be stitched! Can you share simple case examples of what you're trying to do?

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   March 2, 2013, 13:42
Default
  #3
Senior Member
 
Elo´se
Join Date: Jul 2012
Location: Trondheim, Norway
Posts: 103
Rep Power: 5
Eloise is on a distinguished road
Hello Bruno,

Here are some test cases:
1) for a Cylinder: run .\Allrun_Cylinder. You can see that is works by looking at the log.checkMesh where the two internal patches have no faces.
2) for a Sphere: run .\Allrun_Sphere. The stitchMesh ends with an error.
3) for a Block: no test case, but I'd suggest to simply replace the sphere by a box in the Sphere test case.

Thanks for your interest in this case
Elo´se
Attached Files
File Type: gz Cylinder.tar.gz (2.7 KB, 126 views)
File Type: gz Sphere.tar.gz (16.9 KB, 65 views)
Eloise is offline   Reply With Quote

Old   March 2, 2013, 20:47
Default
  #4
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,488
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Elo´se,

These are awesome test cases !
But you forgot to mention that for the box and the sphere you were using snappyHexMesh!
And it's easily solved! The missing magic step if this after mergeMeshes:
Code:
rm 0/cc* 0/*Level
Those files are generated by snappyHexMesh for future reference, in case you want to do some advanced mesh manipulation and diagnosing.

In addition, you can use the "-overwrite" option in mergeMeshes as well (I'm using OpenFOAM 2.1.x and I haven't checked with 2.1.1):
Code:
#!/bin/sh
# Source tutorial run functions
. $WM_PROJECT_DIR/bin/tools/CleanFunctions
. $WM_PROJECT_DIR/bin/tools/RunFunctions
                          
cd IntDom_Sphere/
cleanCase
runApplication blockMesh  
runApplication snappyHexMesh -overwrite 

cd ../ExtDom_Sphere/
cleanCase
runApplication blockMesh 
runApplication snappyHexMesh -overwrite 
runApplication mergeMeshes -overwrite . ../IntDom_Sphere/  
rm 0/cc* 0/*Level
runApplication stitchMesh -partial -toleranceDict toleranceDict -overwrite sphere_ext_region0 sphere_int_region0
Best regards,
Bruno
elvis, Tobi and Alhasan like this.
wyldckat is offline   Reply With Quote

Old   March 3, 2013, 08:35
Default
  #5
Senior Member
 
Elo´se
Join Date: Jul 2012
Location: Trondheim, Norway
Posts: 103
Rep Power: 5
Eloise is on a distinguished road
Hi Bruno,

Thanks for your fast answer! The sphere is indeed created with snappyHexMesh and this additional line solves it all . I haven't had time yet to work on the sphere creation in blockMesh, it will probably come soon.

It is already very good news that the stitching can work with spherical and cubic internal meshes when using snappyHexMesh!

I'm actually working with 2.0.x, so the -overwrite option is not available for mergeMeshes.

Regards,
Elo´se
Eloise is offline   Reply With Quote

Old   May 13, 2013, 05:21
Default
  #6
Senior Member
 
Join Date: Mar 2010
Location: Germany
Posts: 117
Rep Power: 7
cutter is on a distinguished road
Hi,

thanks for your test cases. I've tried them with OF 2.2.x, they're working without any problems.

Did you make any progress with the block case?! Occasionally I have similar problems that could only be resolved by preparing the whole mesh in an external tool. I therefore modified your Cylinder test case to create a Cube case by removing the arcs within the blockMesh files (see below). This causes stitchMesh to fail with the following error:
Code:
--> 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

    From function void enrichedPatch::calcCutFaces() const
    in file slidingInterface/enrichedPatch/enrichedPatchCutFaces.C at line 263.
This is really strange since the two patches should match even perfectly. Can this be resolved by modifying the toleranceDict? Maybe it's even worth a bug report...

The same error has also been observed in StitchMesh on two patches and creating interface in openfoam.

Cutter
Attached Files
File Type: gz Cube.tar.gz (2.5 KB, 17 views)
cutter is offline   Reply With Quote

Old   May 19, 2013, 06:27
Default
  #7
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,488
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings Cutter,

It's simple! Instead of "-partial", use "-perfect".

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   May 30, 2013, 04:21
Default
  #8
Senior Member
 
Join Date: Mar 2010
Location: Germany
Posts: 117
Rep Power: 7
cutter is on a distinguished road
Hi,

ok, that's true for the trivial case when the discretization of master and slave patches match.

What's the right way to do it when I change the discretization of the internal block to say 25x25x30?

Code:
blocks
(                
        hex (0 1 3 2 4 5 7 6) (25 25 30) simpleGrading ( 1 1 1)   
);
This seems to cause problems with -perfect (of course), -partial and even without both of these options (the latter should be used in my understanding).

Thanks
Cutter
cutter is offline   Reply With Quote

Old   June 9, 2013, 13:08
Default
  #9
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,488
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Cutter,

Well, from what I've managed to figure out, what you're trying to do is to weld the mesh, not stitch the mesh

In this scenario, it's necessary to add points to the faces of cells on each side of the connecting patches, so that they can be stitched together afterwards. And after adding the points, it might be necessary to split the cells as well, so that they aren't of the polyhedral variety.

The only OpenFOAM utility that I'm aware of doing this is modifyMesh: http://openfoamwiki.net/index.php/ModifyMesh - but this utility is very far from being automated.

...

Well, I wrote the above and then went on to investigate this further. I found out something interesting, based on this post: StitchMesh on two patches - post #15
So basically I had to split up the patches on both sides, so that the stitching would happen on a one-to-one basis.
Problem is that after stitching once, it breaks something and we have to rely on mesh conversion to/from Fluent format, because apparently something gets fixed in between the two. Then we can stitch another pair.

This can get pretty boring to do manually, so I'm going to keep investigating this, since it's an interesting topic .

______
edit: Nope, two of the patch pairs it can handle just fine, but the other two give this kind of error:
Code:
Face 196625 reduced to less than 3 points.  Topological/cutting error B.
Old face: 2(3066 2625) new face: 2(3066 2625)
______

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   June 10, 2013, 10:55
Default
  #10
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,488
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Cutter,

First note: I created a variant of stitchMesh that allows stitching up several patches in a single run, by relying on a dictionary file to specify which patches should be stitched together and how they should be stitched: https://github.com/wyldckat/stitchMeshMultiPatch

Problem is... that this did not solve the problem

So here's what I've found out so far:
  1. There is no need to rely on mesh conversion to/from Fluent format for using stitchMesh various consecutive times, it's just a matter of removing these files/folders:
    Code:
    constant/polyMesh/meshModifiers
    
    #I'm not 100% certain about this one
    0
    
    #these are not usually necessary to be removed, but just in case
    constant/polyMesh/*Zones
  2. I've used autoPatch for splitting up all surfaces into individual patches, instead of having a single patch on each side of the interface. Problem is that 2 opposite patch-pairs can be stitched, but then the other 2 cannot be stitched. For example: the North and South patch pairs can be stitched, but then the East and West patches cannot, giving the error:
    Code:
    Face * reduced to less than 3 points.  Topological/cutting error B.
    as I mentioned in the previous post.
  3. Attached is the modified case I'm talking about. After running Allrun_Cube, check the contents of the file "ExtDom_Cube/log.stitchMeshMultiPatch". Note: it relies on "stitchMeshMultiPatch" I mentioned above, but you can edit the script Allrun_Cube and use the normal stitchMesh instead.
  4. The reason for this problem seems to be because stitchMesh (or more specifically, "perfectInterface/slidingInterface") was not designed for these kinds of "floating" interfaces, as shown in the attached image. The problem are the faces at the ends of these patches, over the Y axis. Since they are "floating", the algorithm apparently believes that these stitched faces would collapse onto themselves.
    This is probably the problem that originally was triggered when only 2 4-sided patches are used and for which the previous message is:
    Code:
    Zero length edge detected.  Probable projection error: slave patch probably does not project onto master.  Please switch on enriched patch debug for more info


The next step would be either to:
  • Report this on the bug tracker: http://www.openfoam.org/bugs/
  • Or to look into the source code in "enrichedPatch.C", in an attempt to figure out how this might be solved.


Another test can could be performed would be to stitch not just 2 meshes, but 5 meshes:
  1. the internal mesh + the one on the north;
  2. then + the other on the south;
  3. then + one on the east;
  4. then + the last one on the west.
In other words, to slice up the meshes even more and stitching together in a way that the problem we're having would not occur, since the interfacing patch would always be next to 2 other patches.


This is an interesting problem, but this is as far as I can figure out for the next few weeks/months. Feel free to report this on the bug tracker, since you're more interested in this than me!

Best regards,
Bruno
Attached Images
File Type: jpg Screenshot from 2013-06-10 15:36:56.jpg (46.3 KB, 102 views)
Attached Files
File Type: gz Cube_autoPatch.tar.gz (6.1 KB, 10 views)
wyldckat is offline   Reply With Quote

Old   June 25, 2013, 09:04
Default
  #11
New Member
 
arnau1985's Avatar
 
Arnau
Join Date: Jan 2012
Posts: 17
Rep Power: 5
arnau1985 is on a distinguished road
Hi wyldckat,

I had this very same problem:

Code:
Face * reduced to less than 3 points.  Topological/cutting error B.
Check this thread out, I think I managed to solve it:

Problem with stitchMesh: it does not work in meshes with several common patches

Good luck!


Arnau.
arnau1985 is offline   Reply With Quote

Old   June 25, 2013, 17:13
Default
  #12
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,488
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings Arnau,

Nope, "-perfect" only works in some cases... if you take a look at post #7, that was my initial conclusion, which only worked for the intially presented case from post #6. But it doesn't work for the indication given in post #8.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   June 30, 2013, 20:09
Default
  #13
Member
 
Jason Eason
Join Date: Jan 2010
Location: Portage, Michigan
Posts: 44
Rep Power: 7
JulytoNovember is on a distinguished road
Does stitchMesh only work with flat surfaces? Or can you stitch 2 symmetrically curved surfaces together?
__________________
Debian Squeeze - OpenFOAM-2.1.x, Paraview-3.12.0
JulytoNovember is offline   Reply With Quote

Old   July 1, 2013, 07:51
Default
  #14
Senior Member
 
Join Date: Mar 2010
Location: Germany
Posts: 117
Rep Power: 7
cutter is on a distinguished road
Hi, please have a look at the cylinder case in post #1.
cutter is offline   Reply With Quote

Old   July 24, 2013, 11:01
Default error in stitchMeshing
  #15
New Member
 
Marcus
Join Date: May 2013
Posts: 15
Rep Power: 4
marcus85 is on a distinguished road
Hi together,

i want to stitch my mesh, but the problem is, that there are 2 different regions defined after mergeMeshing. Now i've the Problem that i can't solve the case with rhoSimpleFoam.
And there are also the Problem with my boundary conditions for my mesh in the boundary file...I need urgent help, because i've only 2 Months till i must deliver my master thesis.

Please help!

Here are my logfile for using stitchMesh in partial and perfect mode.
And a screenshot of my 2 Mesh Regions, which are already merged.

Thx all for your supply.

kind regards

Marcus

Code:
 Build  : 2.0.x-0751ac349341
Exec   : stitchMesh -case ./MergeMeshes/ -partial inlet_inlet_prt outlet_outlet_prt
Date   : Jul 24 2013
Time   : 16:34:52
Host   : cpi02968.c166.c.iav.de
PID    : 28859
Case   : ./MergeMeshes
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations


Create time

Create mesh for time = 4

Coupling partially overlapping patches inlet_inlet_prt and outlet_outlet_prt
Resulting internal faces will be in faceZone inlet_inlet_prtoutlet_outlet_prtCutFaceZone
Any uncovered faces will remain in their patch
Adding pointZone inlet_inlet_prtoutlet_outlet_prtCutPointZone at index 0
Adding faceZone inlet_inlet_prtoutlet_outlet_prtMasterZone at index 0
Adding faceZone inlet_inlet_prtoutlet_outlet_prtSlaveZone at index 1
Adding faceZone inlet_inlet_prtoutlet_outlet_prtCutFaceZone at index 2
Sliding interface parameters:
pointMergeTol            : 0.05
edgeMergeTol             : 0.01
nFacesPerSlaveEdge       : 5
edgeFaceEscapeLimit      : 10
integralAdjTol           : 0.05
edgeMasterCatchFraction  : 0.4
edgeCoPlanarTol          : 0.8
edgeEndCutoffTol         : 0.0001
Reading all current volfields


--> FOAM FATAL ERROR: 
Problem : Patch inlet_inlet_prt starts at 8008784
Current face counter at 17426001
Are patches in incremental order?

    From function polyTopoChange::polyTopoChange(const polyMesh& mesh, const bool strict)
    in file polyTopoChange/polyTopoChange/polyTopoChange.C at line 2442.

FOAM aborting

#0  Foam::error:rintStack(Foam::Ostream&) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libOpenFOAM.so"
#2  Foam::polyTopoChange::addMesh(Foam::polyMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::List<int> const&, Foam::List<int> const&) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#3  Foam::polyTopoChange::polyTopoChange(Foam::polyMesh const&, bool) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#4  Foam::polyTopoChanger::topoChangeRequest() const in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#5  Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#6  main in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/bin/stitchMesh"
#7  __libc_start_main in "/lib64/libc.so.6"
#8  Foam::UOPstream::write(char) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/bin/stitchMesh"

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.0.x-0751ac349341
Exec   : stitchMesh -case ./MergeMeshes/ -perfect inlet_inlet_prt outlet_outlet_prt
Date   : Jul 24 2013
Time   : 16:39:18
Host   : cpi02968.c166.c.iav.de
PID    : 28885
Case   : ./MergeMeshes
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

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

Create mesh for time = 4

Coupling perfectly aligned patches inlet_inlet_prt and outlet_outlet_prt
Resulting (internal) faces will be in faceZone inlet_inlet_prtoutlet_outlet_prtCutFaceZone

Note: both patches need to align perfectly.
Both the vertex positions and the face centres need to align to within
a tolerance given by the minimum edge length on the patch
Adding faceZone inlet_inlet_prtoutlet_outlet_prtCutFaceZone at index 0
Reading all current volfields


--> FOAM FATAL ERROR: 
Problem : Patch inlet_inlet_prt starts at 8008784
Current face counter at 17426001
Are patches in incremental order?

    From function polyTopoChange::polyTopoChange(const polyMesh& mesh, const bool strict)
    in file polyTopoChange/polyTopoChange/polyTopoChange.C at line 2442.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libOpenFOAM.so"
#2  Foam::polyTopoChange::addMesh(Foam::polyMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::List<int> const&, Foam::List<int> const&) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#3  Foam::polyTopoChange::polyTopoChange(Foam::polyMesh const&, bool) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#4  Foam::polyTopoChanger::topoChangeRequest() const in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#5  Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/lib/libdynamicMesh.so"
#6  main in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/bin/stitchMesh"
#7  __libc_start_main in "/lib64/libc.so.6"
#8  Foam::UOPstream::write(char) in "/usr2/shared1/OpenFOAM/milano/OpenFOAM/OpenFOAM-2.0.x/platforms/linux64Gcc45DPOpt/bin/stitchMesh"
Attached Images
File Type: jpg Screenshot_1.jpg (98.8 KB, 106 views)

Last edited by wyldckat; August 17, 2013 at 14:29. Reason: Added [CODE][/CODE]
marcus85 is offline   Reply With Quote

Old   July 25, 2013, 03:25
Default
  #16
New Member
 
Marcus
Join Date: May 2013
Posts: 15
Rep Power: 4
marcus85 is on a distinguished road
Or can i use another tool or function of Openfoam, that can solve this problem?
marcus85 is offline   Reply With Quote

Old   July 26, 2013, 09:55
Default
  #17
Senior Member
 
Elo´se
Join Date: Jul 2012
Location: Trondheim, Norway
Posts: 103
Rep Power: 5
Eloise is on a distinguished road
Hi,

I keep working on the sphere case. During the stitchMesh process, non orthogonal faces are created at the interface between the two meshes and they have a negative impact on the simulation. Does anyone knows how to avoid them?

Regards,
Elo´se
Eloise is offline   Reply With Quote

Old   August 18, 2013, 13:06
Default
  #18
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,488
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings to all!

@Marcus:
Quote:
Originally Posted by marcus85 View Post
Or can i use another tool or function of Openfoam, that can solve this problem?
I've been very busy for the past few weeks, so according to your other post, you probably have less than 1 month + 1 week
Either way, the problem with your case is that the mesh seems to be badly damaged on the lower part, which leads the 2 patches to not being in full contact, which is likely why you are getting those error messages.

If you had a very simple and small example of your case that gives the same error, it would be the best. Otherwise, only by seeing the case for myself.



@Elo´se:
Quote:
Originally Posted by Eloise View Post
I keep working on the sphere case. During the stitchMesh process, non orthogonal faces are created at the interface between the two meshes and they have a negative impact on the simulation. Does anyone knows how to avoid them?
A few questions:
  1. Which solver did you use?
  2. Why do you need the interface?
Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   August 20, 2013, 04:20
Default
  #19
Senior Member
 
Elo´se
Join Date: Jul 2012
Location: Trondheim, Norway
Posts: 103
Rep Power: 5
Eloise is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
  1. Which solver did you use?
  2. Why do you need the interface?
Hi Bruno,

My case is actually the following: I measure the lift and drag on an object placed in a steady uniform flow for several hundreds orientations. Before, I was re-meshing the object for each flow orientation. What I'd like to do is to have the object meshed in a sphere, so that I just need to rotate the sphere and merge it to the outer mesh to get the appropriate flow orientation. It saves a lot of time!

2. I actually don't need an interface. Once the meshes are merged, there shouldn't be any influence from the interface on the flow.

1. I use simpleFoam. I compared results obtained with the previous meshing approach (which I use as reference) and the merging approach and I get some differences in lift and drag. I'm actually not sure what the differences are due to:
  • is it due to non-orthogonal faces created at the interface between the two meshes? (see figure)
  • is it due to the fact that, once the sphere is rotated, the cells are no longer aligned with the flow?
  • is it due to the distance of the sphere to the object?
I have tested several background mesh orientations (see figures) and several sphere diameters in order to check the 2nd and 3rd points but I haven't reached any conclusion yet: there is no specific trend, the results seem just randomly spread around the reference value.

If you have any recommendations for this kind of case, they are welcome

Regards,
Elo´se
Attached Images
File Type: jpg ReferenceMesh.jpg (70.5 KB, 92 views)
File Type: jpg Mesh1.jpg (88.7 KB, 81 views)
File Type: jpg Mesh2.jpg (89.6 KB, 93 views)
File Type: jpg nonOrthoFaces.jpg (14.3 KB, 64 views)
Eloise is offline   Reply With Quote

Old   August 21, 2013, 10:34
Default
  #20
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,488
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Elo´se,

Nice! Although keep in mind that the quality of the mesh on the interface might interfere with the results, no matter how good it is.

Nonetheless, your description seems to be what I was hoping for, namely that you can use "cyclicAMI" patches, without the need for stitching!
Have a look at this post: Problem using AMI post #184

The idea is that for using "cyclicAMI" patches, you don't need a solver that has dynamic mesh capabilities.
You only need dynamic mesh capabilities if you wanted to change the angle orientation during the simulation.
But since you don't want to, you can even use moveDynamicMesh for only moving the mesh between each run! My advice is to move only one iteration, based on the time 0; but you might even want to try and use the fields from the previous run to start them for the next simulation, as long as the angle change is small.

Although, I think using transformPoints with the option "-region" might be easier than using moveDynamicMesh.

Best regards,
Bruno
Alhasan likes this.
wyldckat is offline   Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
stitchMesh problems along patch edges ribe OpenFOAM Mesh Utilities 2 March 5, 2013 16:25
stitchMesh perfect vs partial Eloise OpenFOAM Mesh Utilities 1 February 22, 2013 12:25
stitchMesh question? vishalsacharya OpenFOAM Native Meshers: blockMesh 0 December 10, 2012 00:41
stitchMesh dhruv OpenFOAM Mesh Utilities 13 February 23, 2012 18:14
stitchMesh marine OpenFOAM Mesh Utilities 1 April 27, 2010 10:59


All times are GMT -4. The time now is 04:31.