Pretty much, yes.

I have ran a simulation of the same prop with a different hub and set up so that there is a continuous shaft coming from the inlet to the upstream end of the hub. Out of curiosity I checked the Ux velocities on the wall and found the results to be as shown in the picture. Somehow it seems that the Ux velocity is dependent on the curvature of the surface the flow is flowing around...

Note: the shaft starts about 0.5 D upstream of the blades (picture 2) and is assigned a fixedValue (0 0 0) BC for U instead of movingWallVelocity (0 0 0) which is applied to the hub and the blades, as in the propeller tutorial.

Artur,
I tried to use snappy same as tut but it seems something is wrong.
I created *.stl files and updated the relevant snappy and bloc Dic .
Would you please take a look to my case. It is just 12.5 Mb and I can sent it by email.
Reza

Hi,

I'm a bit busy today so perhaps you want to look at my setup first and then if you can't work it out I can have a look at your case? See the attachments. Execution order is: snappy, topoSet, createPatch, createBaffles.

It seems a little bit different with tut and you have an extra Dic as createBafflesDict . I attached my dic and I hope you have time to look at the.I used same name as tut to simplify .
Best and thanks already

I don't know why there is error to attach.

change the file extension to .txt, that should do it

look at this ,please.

Ok so what are the symptoms of it being wrong?

I run ,All run exe file but nothing happens

Would you please let me know how tut works?

Going step by step through the allrun.pre

1. run blockMesh - create a rectangular domain
2. extract features of the outerCylinder - will form the new domain, innerCylinder - will form the refinement region, innerCylinderSmall - will form the AMI interface
3. snap the mesh to the inside of the outerCylinder but keeping the cells inside the inner and innerSmall cylinders
4. run topoSet to remove the cellZones created by snappy
5. again, run topoSet and create faceZones which will form the inlet and outlet (note: the inlet and outlet patches from the initial domain are now empty because outerCylinder small to which the mesh has been snapped is smaller than the initial domain)
6. run topoSet yet again to create the cellZone which will form the AMI interface. the steps here are as follows:
6.1 select the cells in the inenrCyl
6.2 select the same cells once again in the set called outerCells
6.3 invert the selection of outerCels thereby selecting all the cells outside the innerCyl
6.4 convert the innerCyl cellSet to a cellZone and then to a faceSet
6.5 pick the faces at the interface between the outerCells and the innerCylinder (I am not entirely sure about this step)
6.6 Select all faces in the faceSet orientated so slave side is in innerCylinderSmallcellSet
6.7 create a dummy face set apparently needed by createPatch application
7. create the inlet & outlet patches from the sets you've created before
8. create baffles from the face zone that is there already
9. split the baffle so that you have master and slave faces of the ami (inner and outer layer as I understand it)

et voila

I should say i am confused when I face createAMi dic

Hi,
Have you considered this?
http://www.extend-project.de/user-fo...transient-case

The movingWallVelocity is applicable for small timesteps only when doing transient simulations.

Thanks a lot for that reply! Although I operate at relatively small time steps (dictated by the fine mesh resolution and maxCo) I think this might be the case. I will do a run with the BC you suggested and hopefully this will resolve the issue with the no-slip condition.

@reza: could you please be a bit more specific in terms of what confuses you in the createAmiFacesDict? I'll gladly share with you what I've learned about this tutorial but in order to do that I need to know what your problems are.

There are still a number of cells where the velocity is very small but non-zero but that is most likely due to my mesh not being perfect (occurs mainly around the feature lines). Other than that it is much much much better, especially for the shaft. Thank you very much for pointing me to the rotatingMovingWall BC.

For anyone who will try to compile the Extend version under more recent releases (I use 2.2.0): you will have to comment out the #include mathConstant.h and replace the mathConstant:: pi with 3.14159265(...). Then just follow the OpenFoam wiki guide on building your BC's and you'll be fine.

Sorry for not being clear, I'm not really pointing to the rotatingMovingWall bc. I think one can use movingWallVelocity, but expect (small) deviations from the noslip condition. If the deviations are small they should not effect results.

Best regards

Yes, I've seen that with the movingWall BC because despite small Ux components my pressure distributions and forces were very close to what they should have been. But it seems that with rotatingMovingWall I can get slightly more accurate results which I think is always better.

Thanks a lot for your hep!

If possible, please share if you make a conclusion about the difference between the bc's. I am very interested in this.

Best regards

my run with rotatingMovingWall has now fully converged in terms of forces. I ran it with exact same settings as the previous one for advance coefficient of J = 0.64 (1.601ms-1 advance velocity at ~10 rps). I have experienced pretty much the same rate of convergence and the results accuracy was in of the same order in terms of forces and moments (+/- 2% c.f. the experimental results).

Attached pictures show, in order of appearance:
1. the old case with movingWall BC (already shown a few posts above but included here for consistency)
2. the new case with rotatingMovingWall BC showing Ux velocity using the same scale as the one used for pic 1 -> note the without comparison better representation of the no-slip condition
3. the new case with rotatingMovingWall BC -> note the 5-fold difference in magnitudes of the extreme velocity values and the no-slip condition spread across the blade