[dogan]

Hi everyone,

I am having problems with stitchMesh command in OF 2.1.x. My case a centrifugal pump which has 2 interfaces between the rotating part and the stationary part. I want to run a case with MRFSimpleFoam solver. Mesh was in .msh format, and i converted it to openFoam by using fluent3DMeshToFoam. after that, i used topoSet and i obtained the constant>polyMesh>sets directory with rotor file in it. afterwards, what i know is, i need to stitch the interfaces, which indicates the connection between rotating and the stationary parts, but the problem is, the number of the faces of two patches are not identical, i think because of that the stitchMesh command gives me the following error message:


FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) in "/home/gulacd2k/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/gulacd2k/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libOpenFOAM.so"
#2 Foam::enrichedPatch::calcCutFaces() const in "/home/gulacd2k/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libdynamicMesh.so"
#3 Foam::enrichedPatch::cutFaces() const in "/home/gulacd2k/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libdynamicMesh.so"
#4 Foam::slidingInterface::coupleInterface(Foam:oly TopoChange&) const in "/home/gulacd2k/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libdynamicMesh.so"
#5 Foam:olyTopoChanger::topoChangeRequest() const in "/home/gulacd2k/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libdynamicMesh.so"
#6 Foam:olyTopoChanger::changeMesh(bool, bool, bool, bool) in "/home/gulacd2k/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libdynamicMesh.so"
#7
in "/home/gulacd2k/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/bin/stitchMesh"
#8 __libc_start_main in "/lib64/libc.so.6"
#9
at /home/abuild/rpmbuild/BUILD/glibc-2.15/csu/../sysdeps/x86_64/elf/start.S:116


i couldn't find what should i do,
thanks in advance for your helps
Dogan

[dogan]

Hi,


i am working on a centrifugal pump geometry, and i want to stitch two interfaces with the stitchMesh command. the master interface is GEOM-SIDE-2 has 5481 faces, and the slave interface has 3248 faces.

once i run the command "stitchMesh GEOM-SIDE-2 GEOM-SIDE-1" the following error message comes up:


Create mesh for time = 0

Coupling partially overlapping patches GEOM-SIDE-2 and GEOM-SIDE-1
Resulting internal faces will be in faceZone GEOM-SIDE-2GEOM-SIDE-1CutFaceZone
Any uncovered faces will remain in their patch
Adding pointZone GEOM-SIDE-2GEOM-SIDE-1CutPointZone at index 0
Adding faceZone GEOM-SIDE-2GEOM-SIDE-1MasterZone at index 0
Adding faceZone GEOM-SIDE-2GEOM-SIDE-1SlaveZone at index 1
Adding faceZone GEOM-SIDE-2GEOM-SIDE-1CutFaceZone 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
Reading volScalarField p
Reading volScalarField nut
Reading volScalarField k
Reading volScalarField omega
Reading volVectorField U


--> FOAM FATAL ERROR:
Duplicate point found in cut face. Error in the face cutting algorithm for global face 4(476034 466684 466686 476036) local face 4(0 1 2 3)
Slave size: 3248 Master size: 5481 index: 0.
Face: 5(476034 466684 466686 338175 476036)
Cut face:
101
(
476034
466684
466686
644233
338166
466686
466684
559434
559436
........




Those interfaces indicates the connection between rotor and stator of the pump, and my aim is to run a simulation with MRFSimpleFoam after stitching them. I am using OF 2.1.x. I tried whatever i know, but i couldn't find a solution. i hope some of you can help me in this matter.

thanks
Dogan

[wyldckat]

Greetings Dogan,

Without a test case, I can't figure this out myself. But my suggesting is that you try using the "-partial" option with stitchMesh.

There are a few examples given in the following thread and the respective solution for those examples: http://www.cfd-online.com/Forums/ope...mesh-used.html
From it you should be able to derive some information that might help you get closer to the solution.

If you're still not able to figure it out, please create a simple case that can lead to a similar error that you are having and share it with us! This way I or anyone else can help you figure this out!

Best regards,
Bruno

[reza1980]

Hi Dogan,
Please inform us if you have found a solution,I have exactly same problem with stitches for same case.
Best
Reza

[dogan]

Hi Reza,
unfortunately i couldn't manage to get rid of this error message. So i mean, in my case, stitchMesh command didn't work. I definitely believe that it is because of the inappropriate mesh quality.

In my case, i had 2 interfaces needed to be stitched, but stitching didn't work so instead of that, to couple that interfaces i used GGI algorithm which is available in O.F.1.6 ext version.

if you need more info, please ask, i will try to help

[reza1980]

Dear Dogan,

First I would thank you for your reply. My main case is to analyse a self-propelled case that means a hull of ship model includes the rudder and propeller.This mesh is generated coreectly and we have exact results for AMI.
But to consider the case with MRF ,I need to remove and stitch AMI surfaces .
For a simple case,just a propller arranged with 2AMI surfaces, I could remove and stitch two surfcaes by stitchMeshes -perfect AMI1 AMI2, where the number of cells for each AMI boundary was identical.
However,in self-propelled case I have problem altough the number of cells are not identical.

I would like to know what you did to handle with GGI.
Best
Reza

[reza1980]

In addition, I am nterested to handle this with OF2.1x otherwise I have to resolve the errors about the classes of cells.

[dogan]

Hi again,

as far as i know, for an MRF case, you can keep your AMI or GGI interface, and you can just apply the MRF solver. If your case is already giving correct results with AMI, here what i understand is that you ran it as transient, you can also run it as steady state. but be aware of that, you must have "MRFZones" dictionary in the constant folder which describes the moving and the stationary faces.

in your case, if you already managed to run it with AMI once, then you don't need to try it with GGI. GGI is only needed when there exist an overlapping problem between the neighbor interfaces. So you can just keep using AMI.

[reza1980]

I am not sure , keeping AMI surfaces results well solutions . I did already for the simple propeller case but the results was not Ok however I approaches good results with removing and stitches AMI surfaces and updating MRF solver

[dogan]

normally the way to set up MRF for O.F. is to stitch the meshes, and this is also what i tried in the first place. but it is for sure stitching procedure has problems, and it is not working properly.
on the other hand, in the description of GGI (or AMI), it is said that it is used for both steady state and transient simulations.

anyway, good luck with your work. i hope you find a solution to stitch the meshes.

[novakm]

Hi.

As Bruno has said, we are not able to help you, unless you give us a test case.
Nevertheless, if you want to use stitchMesh, which is basically a static sliding interface, you should be certain, that your interface is completely planar. Under this condition, it should be possible to force the stitchMesh to work. From the error log it looks like a cross penetration of intefaces.

Parameters of the sliding interface are placed in etc/controlDict. Try to "play" around with these parameters together with an increasing of the mesh resolution. These steps have always worked for me.

BR

Martin

[reza1980]

Hi Martin,
I have read the post related this matter and tested all tricks that may help to stitch two surfaces and resolve this problem but the error is same.
I don't understand what you mean exactly about the but I attached two surfaces in 3 views that must be stitched ,the surfaces are AMI ones and overlapped on each other .
More specifically,I want to investigate again that keeping AMI would results solution with updating the set-up corresponding MRFSimpleFoam.
Reza

AMI2
{
type cyclicAMI;
nFaces 67364;
startFace 43159648;
matchTolerance 1e-5;
neighbourPatch AMI1;
transform noOrdering;
}
AMI1
{
type cyclicAMI;
nFaces 77070;
startFace 43674918;
matchTolerance 1e-5;
neighbourPatch AMI2;
transform noOrdering;
}

[reza1980]

I keep AMI surfaces and define MRFzones but the result is not Ok.

[novakm]

Originally Posted by reza1980

I keep AMI surfaces and define MRFzones but the result is not Ok.

I am sorry, but I am afraid that I cannot help you with "not OK". Without a log or test case or proper definition of current problem it is impossible to advice.

[novakm]

Some info:

Try to use attachMesh. If it doesn't work, you could use the manual preparation that is described here:
http://openfoamwiki.net/index.php/Ho...mic_mesh_cases

1.3.3 Sliding interface
Finally, a sliding interface. The idea of a sliding interface is that I've got two pieces of detached mesh that I want to connect (call it left and right). I will first need to pick out a set of BOUNDARY faces on each side which will merge. Also, when I look at two patches that partially overlap, some part of them will become internal faces and some parts will remain uncovered. We want to keep the uncovered faces on the left and right in separate boundary patches.
In order for the setup to work, I will therefore need:
one face zone (at the beginning made up of boundary faces) for the left and right side.
one boundary patch for each of the sides. Typically at the beginning of the story (when the patches are disconnected) all patch faces will also belong to a zone
scratch space: one empty zone for cut faces and one point zone for cut points.
This mesh modifier does not need a triggering criterion - it will find out whther the mesh has changed based on the relative mesh motion. Also, setting up mesh motion needs to be done carefully, as the two pieces of the mesh should move independently from each other before the mesh attached.
An example of a sliding interface is given below:
mixerSlider
{
type slidingInterface;
masterFaceZoneName outsideSliderZone;
slaveFaceZoneName insideSliderZone;
cutPointZoneName cutPointZone;
cutFaceZoneName cutFaceZone;
masterPatchName outsideSlider;
slavePatchName insideSlider;
typeOfMatch integral;
coupleDecouple off;
projection visible;
attached off;
active on;
}
(this may change a bit between the versions).

[reza1980]

Please let me know if it is possible not to merge rotor and stator.
I mean that the entire of the domain is exported to OPenFoam that lead not to create to parts of stator and rotor.

[reza1980]

following this subject ,we can employ AMI interface and update MRFZones as:

 /*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM Extend Project: Open Source CFD        |
|  \\    /   O peration     | Version:  1.6-ext                               |
|   \\  /    A nd           | Web:      www.extend-project.de                 |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      MRFZones;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

1
(
propZone
    {
        //patches   (rotor);
        // Fixed patches (by default they 'move' with the MRF zone)
        nonRotatingPatches (Inlet Outlet Wall AMI1 AMI2);

        origin    origin [0 1 0 0 0 0 0]  (0 0 0);
        axis      axis   [0 0 0 0 0 0 0]  (1 0 0);
        omega     omega  [0 0 -1 0 0 0 0] 84.823; // rad/s ?
    }
)

// ************************************************************************* //

[Jetfire]

Hi everyone

Just a small doubt , for rotor stator simulations if the rotor mesh and stator mesh are created separately which one do you suggest

1.merge both the meshes in ICEM and then convert the merged mesh to Openfoam using fluent3DMeshToFoam or

2.import the 2 meshes separately and then use mergeMesh and stitchMesh in openfoam

[wyldckat]

Greetings Jetfire,

Merge meshes, no stitching required. Have a look at this post of mine: http://www.cfd-online.com/Forums/ope...tml#post446517 post #184

Best regards,
Bruno