[chapman]

Originally Posted by olivier

[...] Then the mixerGgiFvMesh was built on the mixer2D test case, it is a dynamicFvMesh build to solve a mixer case, so I guess a rotor and a stator radially set. [...]

If anybody knows whether mixerGgiFvMesh can be used to handle an axial turbine, please let me know.

@Olivier: Thanks again, you were a great help to me so far.

[chapman]

I have disovered that it works fine when using only one CPU.

Currently I am trying to find out whether it has to do with movingCells. The statement "Number of moving cells in the moving region" shows the wrong number of cells when using multiple CPUs.

[lord_kossity]

Originally Posted by chapman

Hi Olivier,

my origin is located in the rotor region.

Speaking of the other keywords:
The keyword axis is self-explaining, but what about direction ?

Andy

If your mesh turns in the wrong direction just give your rpm value in constant/dynamicMeshDict a negative signum.

[aldo.iannetti]

Originally Posted by chapman

Hello everyone,

in the meantime icoDyMFoam works very well even without Louis' trick.

However, I am facing another problem at the moment. I would like to connect a stator mesh and a rotor mesh using a SlidingInterface. Unfortunately, not only the rotor mesh is moving


My dynamicMeshDict looks like this:

 
dynamicFvMeshLib  "libtopoChangerFvMesh.so";
dynamicFvMesh      mixerGgiFvMesh;
 
mixerGgiFvMeshCoeffs
{
    coordinateSystem
    {
        type            cylindrical;
        origin          (1.7 0 0);
        axis            (0 0 1);
        direction      (1 0 0);
    }
 
    rpm             60;
 
    slider
    {
        moving    ( rotor_inlet );
        static      ( stator_outlet );
    }
}

Is it necessary to put also the other rotor patches (like rotor_casing, rotor_hub, etc.) in "moving"?

Hi,
IDid you resolve your problem? I think I have the same problem with turbDyMFoam, I have the stator volume rotating together with the rotor volume.
Thanks
Aldo