[dmoroian]

Hi,
I try to put a rotating body inside openFoam starting from the mixer2D example. The geometry is just a testing one (see http://www.fm.vok.lth.se/Staff/Priv/...lidingmesh.jpg) and consists of a prism rotating inside a cylinder. The interface between the rotating and the stationary bodies is a cylinder.
The geometry is generated with gambit and then imported without any problems in openFoam. I wrote the cellToRegion file puting 0 for the moving cells and 1 for the stationary ones and icoTopoFoam recognizes the right number of rotating cells.
The boundary file contains the following(beside the header):
4
(
stat_slide
{
type patch;
nFaces 1400;
startFace 282454;
}

casing
{
type wall;
nFaces 5356;
startFace 283854;
}

blade
{
type wall;
nFaces 160;
startFace 289210;
}

rot_slide
{
type patch;
nFaces 1400;
startFace 289370;
}
)

The problem appears when I try to run:
icoTopoFoam . foam
.....
Create mesh

Selecting topoFvMesh mixerFvMesh
Time = 0
Adding zones and modifiers to the mesh
Number of cells in the moving region: 20521
Adding point, face and cell zones


--> FOAM FATAL ERROR : Not all zones and patches needed in the definition have been found. Please check your mesh definition.

From function void slidingInterface::checkDefinition()
in file slidingInterface/slidingInterface.C at line 83.

FOAM aborting

Aborted

The whole setup is in the foam directory (see http://www.fm.vok.lth.se/Staff/Priv/DM/foam). Can anyone tell me what do I need more to run icoTopoFoam with this case?
Maybe it's a good idea to mention that I could see the mesh with paraFoam so it seems to be ok. I read the threads with Pei, but the it did not gave me too many clues. I hope he will put soon on wiki the promised tutorials.
This test case is the first step towards a computation with a wind turbine that runs right now in parallel on fluent. I would like to compare the results with openFoam.

Best regards,
Dragos

[mattijs]

Did you check your meshMotionDict? Do you have a mesh with two parts?

The sliding interface cannot cross a parallel boundary so be careful with your decomposition if you want to run in parallel.

[dmoroian]

Yes I did and this is the file:
topoFvMesh mixerFvMesh;

mixerFvMeshCoeffs
{
coordinateSystem
{
type cylindrical;
origin (0 0 0);
axis (0 0 1);
direction (1 0 0);
}

rpm 240;

slider
{
inside rot_slide;
outside stat_slide;
}
}

[hjasak]

I cannot think how to make this any more clear:

--> FOAM FATAL ERROR : Not all zones and patches needed in the definition have been found. Please check your mesh definition.

The mixerFvMesh is set up to do the job for you, starting from the definition of a two-piece mesh and adding all zones and modifiers for you. If this in not appropriate, you can also build your mesh modifiers by hand and add them to the mesh definition, without relying on mixerFvMesh to do it for you.

Enjoy,

Hrv

[hjasak]

Hello Dragos,

I've heard from Mattijs you're having the mesh cutting problems in the sliding mesh motion. It is possible that my development version has got this fixed and if possible I'd like to try your case with my latest code - if possible, would you please send me the mesh on my E-mail address (packed and cleaned). If the stuff works, I promise you access to the bug fixes in return.

I am pretty busy at the moment, so not much is likely to happen in the next coupld of weeks; however, it is in my interest to fix the bug in my code (if is't still there) and I'd be grateful for your help.

Regards,

Hrv

[hjasak]

Hi Dragos,

Thank you for the data - I have looked at your case and reproduced the error. This is probably to do with either the right-hand walk or the projection issues on sliding surfaces with corners.

I would suggest you to simplify the sliding interface. Firstly, you could consider making the whole internal part around the blade as rotating (top to bottom), which would result in a single cylindrical interface. This should work and has been tested. Secondly, you may wish to split the sliding interface into three parts (cylinder, top and bottom); however, cases where sliding interfaces intersect each other have not been tested. Thirdly, you may consider making the sliding interface into a sphere or another similar shape without sharp edges, which should make the problem easier or make it go away.

Of course, the option of sorthing out the algorithm is still there. The two critical bits are the point projection and the right-hand walk in the calculation of the cut faces. All bugs I have fixed in the last year or more have been in point projection, so this is the best candidate for detailed analysis (pretty painful, lots of pieces of paper and mesh analysis by hand).

Good luck,

Hrv