[deepblue17]

Servus,

I have tried out a icoTopoFoam case. I began at the mixer2D tutorial. Then I changed the mesh like in this case http://www.cfd-online.com/OpenFOAM_D...tml?1123794946 But not radial only axial and very simple only with 32 points. I have made like a rotor/stator with each three blocks. Before and behind the blades the boundary condition is cycil. The sliding b.c. is betwenn rotor and stator.
Do I need the celltoRegion file?

The configuration is running, but is than aborted. The failure is like:

Time = 0.0005

Total volume change: 4.51028e-17
ICCG: Solving for p: solution singularity
BICCG: Solving for Ux, Initial residual = 1.57256e-06, Final residual = 2.47283e-23, No Iterations 1
BICCG: Solving for Uy, Initial residual = 1.68984e-06, Final residual = 5.24896e-23, No Iterations 1
BICCG: Solving for Uz, Initial residual = 8.34627e-07, Final residual = 3.83218e-23, No Iterations 1
ICCG: Solving for p, Initial residual = 0.424909, Final residual = 6.8224e-07, No Iterations 13
time step continuity errors : sum local = 1.56593e-296, global = 6.73108e-298, cumulative = 0.00314565
time step continuity errors : sum local = 1.56593e-296, global = 6.73108e-298, cumulative = 0.00314565
time step continuity errors : sum local = 1.56593e-296, global = 6.73108e-298, cumulative = 0.00314565
time step continuity errors : sum local = 1.56593e-296, global = 6.73108e-298, cumulative = 0.00314565
Mean and max Courant Numbers = 3.8738e-287 5.44948e-286
deltaT = 1.30217e-298
ExecutionTime = 14.98 s


Time = 0.0005

Total volume change: 4.51028e-17
ICCG: Solving for p: solution singularity
BICCG: Solving for Ux, Initial residual = 1.55853e-06, Final residual = 5.80535e-23, No Iterations 1
BICCG: Solving for Uy, Initial residual = 1.67476e-06, Final residual = 7.41848e-23, No Iterations 1
time step continuity errors : sum local = nan, global = nan, cumulative = nan
time step continuity errors : sum local = nan, global = nan, cumulative = nan
time step continuity errors : sum local = nan, global = nan, cumulative = nan
time step continuity errors : sum local = nan, global = nan, cumulative = nan
Mean and max Courant Numbers = nan nan
deltaT = 0.2
ExecutionTime = 15.03 s


Time = 0.2005



--> FOAM FATAL ERROR : Bad points.

From function void plane::calcPntAndVec
(
const point&,
const point&,
const point&
)

in file meshes/primitiveShapes/plane/plane.C at line 108.

FOAM aborting

Can anyone help me?

I can also post the b.c. and the blockMeshDict if it is helpful.

If I get the case to be run. I can it post as a turbomachinery tutorial.

[hjasak]

It is already wrong here:


ICCG: Solving for p: solution singularity

You pressure solution should not be singular - check the setup and boundary conditions.

Hrv

[deepblue17]

Servus,

thank you very much for the message. I have now changed the boundary condition. But now it is aborted because of another failure:

Reading field p

Reading field U

--> FOAM Warning :
From function Foam::findRefCell(const polyMesh& mesh, const label refCelli)
in file findRefCell/findRefCell.C at line 90
Requested reference cell 0 is on a constraint boundary, selecting reference cell 1

Starting time loop


Time = 0.0005

--> FOAM Serious Error :
From function cyclicPolyPatch::geometricOrder
in file meshes/polyMesh/polyPatches/derivedPolyPatches/cyclicPolyPatch/cyclicPolyPatchMorph.C at line 386
patch:crotor4 : Cannot match vectors to faces on both sides of patch
half0Ctrs[0]: (0.0125163 0.0216922 0.0349684)
half1Ctrs[0]: (0.0124943 0.0216539 0.035)
Please use topological matching or adapt the featureCos() setting
Continuing with incorrect face ordering from now on!

At the beginning of the computation and then at the end:

Time = 0.0075

--> FOAM Serious Error :
From function cyclicPolyPatch::geometricOrder
in file meshes/polyMesh/polyPatches/derivedPolyPatches/cyclicPolyPatch/cyclicPolyPatchMorph.C at line 386
patch:crotor4 : Cannot match vectors to faces on both sides of patch
half0Ctrs[0]: (0.0114203 0.0226413 0.0347411)
half1Ctrs[0]: (0.0123269 0.0217427 0.0349996)
Please use topological matching or adapt the featureCos() setting
Continuing with incorrect face ordering from now on!
Direct mapping: number of inserted faces; 0
Total volume change: -0.000990963


--> FOAM FATAL ERROR : face 0 and 3 areas do not match by 0.042609% -- possible face ordering problem

From function cyclicFvPatch::makeWeights(scalarField& w) const
in file meshes/fvMesh/fvPatches/derivedFvPatches/cyclicFvPatch/cyclicFvPatch.C at line 62.

FOAM aborting

I now i must have a problem with my mesh. When I am looking at the mesh after the first step at paraview, i saw that:

1.) the knots at the rotor/stator interface will be stay conected, so that the mesh is deforming. In the start, i have made knots with the same coordinates, but there are different labels.



2.) the insideSlider moved forward to the inlet and the outsideSlider is moving to the outlet, so that in step two, there are no inlet and outlet faces.



Maybe I can change some boundary condition, but i don't no which one. In the p-b.c. everything is declared as zeroGradient. In the U-b.c. it is similar to the mixer2D tutorial.

Thank's for the help.

Has anybody made a equal simulation, witch another solver?

[mattijs]

Does it work without cyclics?

cyclics in combination with topology changes (e.g. sliding interface) might still have problems. The message you get is from the mesh modification algorithm trying to match opposite cyclic faces and failing.

[deepblue17]

Thanks

O.k. something like this I expected. But when I am defining the cyclic b.c. as wall b.c. , the rotation will be not done very well. Because the knots in the middle between the rotor and stator will stay conected. That is the problem, it is the same with cyclic and walls (see image 1). Then the mesh is deforming and then the planes does not have exactly the same area.
So I am thinking that I have to change something in the boundary condition. But what?

[deepblue17]

Servus,

so I have now made an much easier testcase. I have had two zylinders. One as innerSlider and the other as outerSlider. But now the problem. If the mesh is not exactly symmetrycal in the phi-direction the calculating is aborted. But when it is all symmetrical the calculation is running.
What is to change, that the calculation will also run, when the mesh is not symmetrical?

And when the rpm is too high (in my case 100) it comes to an error during the calculation, something like that he can't find the master or slave face.

Thanks
Oliver

[deepblue17]

I don't know why the images are not above, but now here they shold be are.

[deepblue17]

Servus,

the cylinder case is working, if I simulate the hole cylinder. But when I want only to simulate on passage the calculation is aborted. The solver is very sensitive to mesh resolution, increasing of rpm and the deltaT. And the cyclic boundary condition will not be able to use.



I want to do such a case, like rotor and stator:



This image is from an static icoFoam caclulation with these boundary conditions.

I want to simulate only one passage, so the solver had to set the two boundary patches automatically, because the area is changing. I think, the mixerFvMesh.C had to modify, but in which way. Has somebody an idea?

I don't need topological changes in my caclulation, because th mesh shoud be the same all the time. Only the boundary areas at the inner/outerSlider had to change. The boundary conditions shoud be the same (cyclic).

Oli

[guido_adriaensen]

Hello Oliver!

I was wondering if you could share your code so far. I'm working on something similar, I would like to simulate a piston moving along an inlet and outlet, the 2-stroke engine principle. So far I have not managed to do this, my mesh is morphing instead of sliding. The cilinder you posted on the 13th of january seems to be doing what I want. :-) So I would be very happy if you could share it.
Thanks!

regards
Guido

I am also interested in this example. If u can post it for sure u will be saving me a lot of time...

Greetings
Atzaru

[deepblue17]

Servus,

here is the test case.

kupplung.tar.gz

I think you know what to do with it. There are only two cylinder's, one is rotating and one is stationary.

But now back to my problem. Has anybody an idea how can i implement such a rotor/stator interface as i described at the 15th?

Did anybody know what is to change in the sourcecode? I thought starting from the icoTopoFoam solver is an good advantage. Isn't it?

Thank's for the idea's
Oli

[hjasak]

This kind of thing should work without major trouble. I have done a number of calculations with more complex topological changes and all is well. However, this is not a "beginner" kind of problem beucase there's lots of things you need to be careful about.

I would strongly advise finding out all you can about the solver and the topo engine and then playing around with simple tutorials until you figure out exactly what the solver is doing. Once you set it all up properly, your case will work.

Enjoy,

Hrv

[deepblue17]

Servus,

now i have an more easier way for the rotor/stator interface.



There is the "Rotor/Stator Interface". The outlet of the rotor is with a cyclic b.c. connected with the rotorInterface (insideSlider). And the same procedure with the statorInterface (outsideSlider). But now I have to duplicate these boundary conditions over the hole interface (in this case,these are walls). How can I do that? I need only a foward conditon and not a backward, like a master and slave condition. The cyclic is i my opinion a forward/backward boundary condition.

Thanks
Oli

[hjasak]

Hi All,

In order to get over this rumour about problems with sliding interfaces in 3-D, I have tried extruding the mixer2D tutorial and runing it using icoDyMFoam. It all works fine and here's a movie to prove it:

3-D mixer vessel.

Enjoy,

Hrv

[rafal]

hi
"to see mean to believe "
ok i believe it is possibe to create it. (but how?)

I have been trying to create 3D vessel mesh for last 2 days. i always get this error:

--> FOAM FATAL ERROR : Duplicate point found in cut face. Error in the face cutting algorithm for global face 4(99 01 9902 10000 9999) local face 4(397 398 412 411)
Slave size: 1200 Master size: 960 index: 323.
Face: 4(9120 9121 9165 9164)
Cut face:
101
(...)[lots of lines]

This error apprears no matter what solver i use (my with topo changes or icoDyMFoam) so i assume that its a problem of mesh only.

What is this error related to? Is it still a bug?( ref to: Hanging nodes March 18, 2005 )How to fix it?

If you would be so kind (and have a second of spare time), have a look on my setup.
i attached the mesh and cellToRegion file if you need to look at it to figure out what is wrong.
blockMeshDict
cellToRegion.gz

i checked a mesh with checkMesh but the only errors are like in mixer2D, so i assume its ok.

can you possibly send me the mesh setup of the case you used to create a movie (a good code is worth more than a thousand words of explanation)

thank you in advance.

rafal rafal.zietara@postgrad.manchester.ac.uk

[deepblue17]

Servus,

to simulate a whole stage is not a problem. But to simulate only one passage of a stage is a problem. I hoped the createPatch utility would be able to solve that problem. So has anybody a new idea to solve that problem?

Thanks
Oliver

[hjasak]

Hi Rafal,

I have put the case for you in my my case repository. Please donwload it and let me know because this stuff gets deleted on a regular basis.

It is fair to say that I'm using my development version but no changes in the code have been required. In short, this is what I did:

- copied the 2-D mixer tutorial
- extended the geometry in the z-direction and added some cells to make it 3-D
- created the mesh. Changed the boundary condition on the top and bottom plane to wall. Updated fields in the zero directory for the new boundary condition
- run the code. No problems
- made the animation :-)

Enjoy,

Hrv

[hjasak]

Hi Oliver,

There is a difference: I wrote all the code for the sliding interface and this should work for a 3-D case - as it does. The implementation is complete and the problems that remain are (basically) bugs. A partial overlap with coordinate transformation was not a part of my plan because I don't/didn't need it.

In order to do partial overlap cases you refer to, additional code needs to be written. If done cleverly, the code will slot into its place with the rest of the sliding interface and the tools I've already written will be re-used. Have in mind that the additional code only needs to create a coupled boundary with coordinate transformation which is updated as the surfaces slide over each other; the rest of the code, including top-level solvers, field mapping, mesh motion, topological change support etc. remains intact.

Have fun,

Hrv

[rafal]

Hi Hrv
Thanks a for prompt answer. Actually i got this mesh earlier on my own. This is more or less a first layer of my mesh (my impeller blades are thicker but it doesn't matter). The error appeared when i complicated the problem and tried to add another stationary* fluid on the top of the impeller zone. I asked because i had impression that you did the same.

Anyway i end up with three layers of fluid in whole vessel and two zones (baffle, impeller zone). i have two layers of sliding in two directions. For one layer, a radius is a normal face vector and for the other – axis. It is easier to see it than describe



Thanks for effort I will try to dig this problem(error) deeper and than maybe i will bother more
rafal

small comment:
*stationary in terms of mesh motion, elements are in one place but fluid can flow through them

[hjasak]

Hehe,

What you have here are intersecting topo changers. Let's try a little mental trick: each sliding interface is a separate self-contained object, right? Now, think very slowly and carefully and thell me who is responsible for managing the points on the line where two sliding interfaces intersect (the radial and the axial one)?

This kind of topological change is done by writing special mesh classes and triggering first one and then the other sliding interface (decouple-recouple), which is not easy - well, you need to know what you are doing... If you want examples, have a look at how Tommaso and I deal with valves in OpenFOAM (intersecting layering and sliding) in internal combustion engines simulations with moving valves.

You have several options:
- extend the sliding interface in a cylindrical surface up and down. This should work;
- make a single sliding interface out of both sliders. The surface will have a corner, which is troublesome. This should work in principle but I have trouble with a similar case in the past.

Enjoy,

Hrv