[jaswi]

Hello Forum
Hello Prof. Jasak

Wish you all a nice day.

Please let me know if anybody has information on how to properly setup Mixer simulation with mixerGgiFvMesh.

I tried with a simple 3D setup with inner and outer domains. It works with icoDyMFoam but no fluxes are transferred through the interface.

Here are the pictures:




Please provide some feedback

With Best Regards
Jaswinder


PS: There is a post which claims to have successfully achieve this but without any further info

http://www.cfd-online.com/OpenFOAM_D...es/1/5967.html

[lr103476]

I have observed the same problem, with mixer2D.

Frank

[hjasak]

Means you are doing something stupid. Switch on some debugging on sliding interfaces etc and find out if it actually couples properly.

Have an animation for encoragement

mixer in OpenFOAM animation

a nicer mixer

You need to be MUCH more precise about your problem - this sounds as if a feature does not work, whereas in fact it does. It also leaves a bad (and inaccurate, I hope) impression about OpenFOAM.

So:
- check if the sliding interface mesh modifier is there
- check if the zones are set up properly
- check if topological changes are triggered
- check if the mesh moves properly

and then I will be able to help in a more efficient manner. Also, you will learn a bit about how OpenFOAM works, which is always positive...

Hrv

Hrv

[jaswi]

Hello Hrv.

Thanks for the reply

First of all , I am no saying that mixerFvMesh does not work. It does work with all the features you have implemented. The sliding interface and other stuff in place does work properly.

My problem lies somewhere else. I have geometry with 500K cells and I can't use parallelization alongwith topological features such as sliding interface. The single processor version works fine.

So I looked around and found mixerGgiFvMesh which seems not to use slidingInterface. Please correct me if i am wrong there.

I found a post of Rolando,

http://www.cfd-online.com/OpenFOAM_D...es/1/5967.html

which claims to be successfull with the mixerGgiFvMesh. The above posted pictures are from using mixerGgiFvMesh.

Hope that clears the doubt.

Now I looked into the implementation of mixerGgiFvMesh and it differs from the mixerFvMesh. The one with Ggi defines a cell zone and uses it identify zones and the update function simply uses movePoints():

movePoints
(
csPtr_->globalPosition
(
csPtr_->localPosition(allPoints())
+ vector(0,tempRpm_*360.0*time().deltaT().value()/60.0, 0)
*movingPointsMask()
)
);

I myself dont't understand where slidingInterface will come into picture with GgI version of mixerFvMesh.

Please help me out on this as I have to use mixerGgiFvMesh for my case

With best regards
Jaswinder

[jaswi]

Hi Frank

The above posted inquiry is not about mixer2d. mixer2D works perfectly fine with slidingInterfaces.

Its extension to 3D also works fine.

What I have posted above is the result of using mixer3D with mixerGgiFvMesh

Thanks for your Reply

With Best Regards
Jaswinder

[jaswi]

Hello Forum

Its seems to me that to use mixerFvGgiFvMesh ,

I have to specify the interface patches as ggiFvPatch.

I haven't figured out how to do that yet but its seems I am on the right track.

Hrv, I need a shot in the arm :-)

With Best Regards
Jaswinder

[lr103476]

I haven't had any problems with mixer2D using slidingInterfaces. But I have similar problem of no flux through interfaces, when using GGI.

It seems that a case using GGI need to be setup slightly different from using slidingInterfaces. For example, how to setup the /polyMesh/meshModifiers in case of GGI......???

Btw, besides the no flux issue (which I think is just a case setup issue), the GGI worked nicely in parallel with me (slidingInterface did not), just use manual decomposition to put the complete interface on the same processor.

Regards, Frank

[hjasak]

Come on guys, this is noit science...

Here is a ready-to-run test case for you, I have just tried it out:

mixerGgi_HJ_19Feb2008.tgz

You can also get a case with results from:

Mixer GGI tutorial with results

Hrv

[lr103476]

Hrv, believe it or not, but just found out myself :-) I was about to post the solution, but this is even better. Thanks.

[jaswi]

Dear Prof Jasak

Thanks a lot

I just wrote an email to you with probable values and checked the forum for one last time and found your attachment

Thanks

With Best Regards
Jaswinder

[lr103476]

In serial GGI seems to work ok now. Although, I noticed the following problems when simulating the mixer2D till endTime=10.
1) Velocity field is OK in time.
2) Pressure shows oscillatory behavior which is not present when using the ordinary sliding interface.
3) In parallel, the job quits immediate after completing the first timestep......

Are some of these problems known to you Hrv, I mean, GGI is still in development, right?

Regards, Frank

[lr103476]

Sorry to bother you, but are these problems known in the latest development of GGI?

Frank

[carlodean]

Hi,
I believe to have the same problem of others in this discussion.
I need to simulate the flux in a compressor using OpenFoam.
As I see it's impossible to run sliding interface in parallel and the solution seems to be the mixerGgiFvMesh.
Does it work in parallel?
Can anyone answer to this question?
thanks everybody

[jaswi]

Hi Carlo

Welcome to the CLUB :-)

No its not working in the parallel for the so-called Lower OpenFOAM beings that is us.

It might be working for the Higher OpenFOAM Beings i.e people who wrote the code because they know how to do that.


My suggestion is that try using MRFZone appraoch or find a way to please the Higher Beings and get blessed with the related code :-).

Wish you happy FOAMing
Jaswi

[carlodean]

Thank you very much for your quick reply.
I'm trying to simulate the noise produced by a compressor in an air conditioned system.
So I need a LES model with sliding interface to simulate the rotor.
As I read in this discussion Frank Bos managed to simulate mixerGgi in parallel but he had some problems.
I tried to run mixerGgi on my pc whit turbDyMFoam but I had the same problem you had.
There are no flux through the interface.
I tried also MRFZone tutorial whit OP 1.4.1, but I don't understand completly what he do, it add only the Coriolis force to the fluid whitout moving mesh?
It will be usefull for a compressible turbolent fluid??


When I try MRFSimpleFoam with OP 1.4.1-dev I have this error:


Starting time loop

Time = 1



--> FOAM FATAL IO ERROR : Cannot read control minIter

file: OpenFOAM/carlo-1.4.1-dev/run/tutorials/MRFSimpleFoam//mixerVessel2D/system/fvSol ution::U from line 43 to line 47.

From function void lduMatrix::solver::readControl
(
const dictionary& dict,
T& control,
const word& controlName
)
in file matrices/lduMatrix/lduMatrix/lduMatrixTemplates.C at line 57.

FOAM aborting

Aborted (core dumped)

I don't understand what it wants, the input file fvSolution is the same of OP 1.4.1 and even adding minIter in U dictionary in fvSolution I have the same error.
Had anyone the same problem??
I'm sorry for all my questions but I hope someoen cuold help me.
Thank you
Carlo

[jaswi]

Hi Carlo

I can explain the MRFZone approach to you but I am a bit busy until weekend.

Try going through the MRFZone classes located in /home/openfoam/OpenFOAM/OpenFOAM-1.4.1/src/finiteVolume/cfdTools/general/MRF

The idea is basically simple and elegant. You define a cell zone and for that cell zone you add an extra source term which accounts for the effect of rotation on these cells. Now the question arises about the fluxes at the interface between the so called moving cell zone and static cell zone. The call to relativeFlux member function takes care of that. Post specific questions related to MRFZone and I will try to answer them at my best. Keeping the discussion focused is better as it might at the end lead to complete explanation of this approach and help others to understand.

Regarding minIter error that is because your case is not properly set. Here is an example of properly configured fvSolution file:

solvers
{
p PCG
{
preconditioner
{
type DIC;
}

minIter 0;
maxIter 2000;
tolerance 1e-06;
relTol 0;
};
U PBiCG
{
preconditioner
{
type DILU;
}

minIter 0;
maxIter 500;
tolerance 1e-05;
relTol 0;
};
k PBiCG
{
preconditioner
{
type DILU;
}

minIter 0;
maxIter 500;
tolerance 1e-05;
relTol 0;
};
epsilon PBiCG
{
preconditioner
{
type DILU;
}

minIter 0;
maxIter 500;
tolerance 1e-05;
relTol 0;
};
omega PBiCG
{
preconditioner
{
type DILU;
}

minIter 0;
maxIter 500;
tolerance 1e-05;
relTol 0;
}
R PBiCG
{
preconditioner
{
type DILU;
}

minIter 0;
maxIter 500;
tolerance 1e-05;
relTol 0;
};
nuTilda PBiCG
{
preconditioner
{
type DILU;
}

minIter 0;
maxIter 500;
tolerance 1e-05;
relTol 0;
};
}


PISO
{
nCorrectors 2;
nNonOrthogonalCorrectors 0;
pRefCell 0;
pRefValue 0;
}

// Relaxation factors are used for transient SIMPLE
relaxationFactors
{
p 0.5;
U 0.8;
}

If you are using Multigrid solver then the entries for each field you are solving look something like this:
pcorr GAMG
{
tolerance 1e-9;
relTol 0.05;

minIter 0;
maxIter 500;

smoother GaussSeidel;
nPreSweeps 0;
nPostSweeps 2;
nFinestSweeps 2;

scaleCorrection true;
directSolveCoarsest false;


cacheAgglomeration true;
nCellsInCoarsestLevel 20;
agglomerator faceAreaPair;
mergeLevels 1;
};

Hope that helps

Warm regards
Jaswinder

[carlodean]

thank you very much,
now I can run MRFZone, I will study MRFZone.C to undertand better what it do.
Just one question, I read on a tutorial on sliding interface and MRFZone that both could not run in parallel.
This could be a prolblem, there is any application on rotating mesh running in parallel in openfoam?
Best Regards
Carlo

[dmoroian]

Hi Carlo,
MRFSimpleFoam runs very well in parallel.

Dragos

[waterboy]

Hi,
I do have a question concerning the GGI and sliding interfaces. All the examples I found seem to be rotating and the sliding or ggi interface was at the cilindrical sides. I figured out how to set up similar cases but problems arise when the sliding or ggi interface are defined on the "bottom" or "top" of the cylinder. Is this supposed to work?
Cheers,
Pal

[hjasak]

Yes it works. We now have better interpolaion that Martin Beaudoin will present in Berlin. For more details, see the paper

Hrv