Strange Result of ERCOFTAC Centrifugal Pump MRF case in OF2.2.x
 

Hi,

Recently, I've tried ERCOFTAC Centrifugal Pump MRF case (ECPGgi2D) for OpenFOAM-2.2.x, and encountered strange results as attached images.
For comparison, I've also attached the results for OF2.1.x.
Results for OF2.1.x are in good agreement with original published results (OF-1.5-dev).

For OF2.2.x case, I used simpleFoam with following fvOptions.

-------fvOptions ----------------------------------------------------
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object fvOptions;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

MRF1
{
type MRFSource;
active true;
selectionMode cellZone;
cellZone rotor;
nonRotatingPatchs ( INLET OUTLET GGI_EXT GGI_INT BLADE_ROT);

MRFSourceCoeffs
{
origin (0 0 0);
axis (0 0 -1);
omega 209;
}
}
---------------------------------------------------------------------

If someone has the solution to correct this problem, please let me know.
Any comment would be appreciated.

Hi

I have no problems with commit 2.2.x-b6d83360ae0e

I have uploaded the working case here and removed the reliance on the old turbo stuff. Only 2.2 BC's.

LINK TO CASE

Hi, linnemann.
I tried case file of you, I was able to get same result as you.
But for now, I could not find any important difference in your dictionary files with mine.
I'm going to continue to investigate in detail.

Best regards,

Masashi Ohbuchi

Hi,

here some comments on your fvOptions:
- there is a typo in the nonRotatingPatchs -> nonRotatingPatches
- I would not declare the patch BLADE_ROT as non-rotating

Here is the fvOptions I'm using:
Best Regards - Brahim.

hi everyone,

are the nonRotatingPatches needed to be included in the dict?
in my case (3D radial fan) the mrfZone is a cylinder and within the cylinder there are wall (from the fan blade)

so should i add the wall within the mrfZone in the nonRotatingPatches or just leave it without nonRotatingPatches?

thanks
regards,
nash

i have tried without including the patch and with the patch included in fvOption.

the right one is not to include the patch within the mrfZone as nonRotatingPatches.
Hope this helps.

regards,
nash

Help
 

Hi
I'm a new openfoam user. I am interested in your case. (i'm studying about centrifugal pump). I tried your case but i can't get results the same your.
(i'm using ubuntu 13.04; openfoam 2.2.2)
Please show to me.
Thank you so much.

ercoftac Centrifugal Pump for OF2.2.x
 

Thank you, Brahim.
And I appologize for my delayed response.
You were correct!.
My essential mistake was the setting of nonrotatingPaches.
I've attached case files adapted to OF2.2.x.
All validation cases; ECPGgi2D(MRF+Ggi), ECPStitchedMesh2D(MRF+StitchMesh)
and ECPMixerGgiFvMesh2D(Sliding+Ggi) will be working fine.
The Allrun script in the postProcessing directory also works.
In these archive, because of the limitation of maximum size, mesh files(rotor2D and stator2D) and measurement data are not included.

Best regards,
M.Ohbuchi

Hi,

Thank you for adapting the case to OF2.2.x. I am trying to use OF2.3.x for my case but with some problems.
I have some doubts:
It seems like now it is not needed to make faceZones. It is enough with cellZone definition performed inside topoSet. And now, inside OF code faceZone selection is done automatically.

Ohbuchi has defined BLADE_ROT within patches subDict. I thought that is not needed because by default all patches included in the MRF zone were rotated.

I am trying to simulate a rotor with a fixed part of the geometry but there are problem in the rotor surface. k, epsilon and so give very extrange values ( +12 or so at iteration 5).
For nonRotatingPatches I have added only AMI1 and AMI2 interfaces.

Mesh was generated for y+ around 100 so I am using nutkWallFunction.

I hope someone can help me.

HI,

Please check and see attached tar archive. It'll work with OF2.3.
As you already mentioned above, cellZone is only needed for defininig MRF zone.
And faceZone was not used in my case files.
And I also think nutkWallFunction is more suitable for wall boundary for k.

Ohbuchi

Dear Niels Nielsen:
Thank you for your sharing. But I can't open the link, could you please send a copy to my email znhuang@163.com?

Xianbei