[wouterremmerie]

Hi everyone,

I'm looking to simulate the behavior of a propeller (see attachment) that is partly submerged in water (bottom part) and partly in air (top part). The sense or rotation is such that the water is pulled upward and slung into the air.

There is also a stationary duct around the propeller (the duct is fully submerged, at least at the start of the system).

I've been reading on how to tackle this, and it seems that there multiple options for the rotation:
- MRF (moving reference frame (?))
- moving mesh
- keep everything stationary and apply movement to the boundaries? not sure if this is possible.

So my questions are the following:
- which method would you use to model the rotation?
- how do you combine the rotation with a multiphase solver?
- are there examples of rotation objects in multiphase environments available?
- which solvers would you use?

Many thanks for all the help, I'm looking forward to it!!

Best regards,

Wouter Remmerie.

[Artur]

I think multiphase/interDyMFoam is what you're looking for - it's a transient, multiphase solver for two phases solved using VOF method and dynamic mesh. MRF is a steady state approach so not good enough for what you're trying to study I assume. I used the former to simulate propellers close to free surface (open water and in presence of the hull) and it worked just fine. I'd recommend familiarising yourself with $FOAM_TUTORIALS/incompressible/pimpleDyMFoam/propeller/ to start with and then upgrading your case to interDyMFoam.

Good luck,

A

[wouterremmerie]

Dear Artur,

thanks very much! I've been experimenting with MRF, that works, so now I'll move on to interDyMFoam, using the tutorials that you mentioned.

I'll post as soon as I have results.

Greetz

Wouter.

[wouterremmerie]

Hello Artur,

I made some progress thanks to your tips:

pimpleDyMFoam:
- I used salome to create a mesh with a rotating zone inside. I used the "createAMIFaces" and "createBaffles" to build the boundaries for AMI1 and AMI2.
- using "moveDynamicMesh" I could see the mesh moving
- it also calculates, with logical results, so this case is a success so far
- see attachment 'CFDOnlinePimpleDyMFoam.tar.gz'
- one question though: I used the "mixerVesselAMI2D" tutorial case as a reference. Strangely enough, under the "U" starting conditions, also the stator receives the "movingWall" tag. Do you knwo why this is? (in the propeller case, the outer cylinder is just tagged "fixedValue", as you would expect). I had to apply this as well, to get my model running.


interDyMFoam:
- When I change the solver to interDyMFoam, I run into problems (case also attached as "CFDOnlineInterDyMFoam.tar.gz", log file attached as "log.interDyMFoam")
- I used the solver files (fvSolution, fvSchemes, ...) of the DamBreak if I'm not mistaking (this worked for the MRF solution). I'm guessing the error could be in here.
- the solver starts to run, but after a very short time, it ends with an error
- if revolution speed is decreased 10 times (in dynamicMeshDict), it will get 10 times further timewise. Would the problem be linked to the moving mesh?
- I tried with different timesteps & precision & setFields properties, but no succes.
- here as well, running "moveDynamicMesh" and "interFoam" works fine. But running "interDyMFoam" results in problems. So I'm guessing the problem is in the combination of both?

Do you have an idea what I'm doing wrong?

Files can be found here:
http://users.telenet.be/kinematica/CFDOnline/

Many thanks for the help,

best regards

Wouter Remmerie.

[Artur]

I'm glad to see you're making some serious progress!

First things first, your interFoam run fell over because of this (just before the error was thrown):

AMI: Patch source weights min/max/average = 0, 1.00006791, 0.998789595

Until then all residuals and everything else looks fine. This error means that the sliding mesh cannot interpolate one or more of the faces because they were assigned weighting of 0.0 (in practice that means that there isn't a good enough match between the two sides of AMI). Try increasing the AMI tolerance when you are creating it, reducing (counter-intuitive, I know) AMI refinement level, refining the .stl file (if that's what you use). If you were using snappy I'd advise increasing the no. snap iterations too.

I'd recommend taking the mesh which worked fine for you with pimpleDyMFoam and using that as a starting point to find the settings which give you what you want, I usually use the same schemes for both by enlarge.

If you are looking at time dependent flows make sure you have enough pimple iterations per time step (2-3 should be OK I think) because now I think you only have 1. If there is some quasi steady-state solution then this should get you there but the time record will be wrong.

As for the boundary condition, fixedValue should be just fine for static parts, that's what I use too. movingWall assumes linear displacement between each time-steps which is fine for very small time-steps but will lead to small errors when that becomes larger (there might be some weird through-face velocity components); see a previous post about it and the solution to it if you do encounter such problems:

http://www.cfd-online.com/Forums/ope...-tutorial.html

Best of luck,

A

P.S. I'd be very happy to see some screenshots of your case when you get it to work if you don't mind, it seems very interesting.

[wouterremmerie]

Hi Artur,

I did as you suggested and used the mesh that was working for the pimpleDyMFoam.
- I increased the AMI tolerance from 0.0001 to 0.01, 0.1 and 1 . None of these solved the problem unfortunately. Same AMI error.
- I went back to salome to create a finer mesh (number of elements 3-5 times higher than original mesh) but no changes there either. Same AMI error.
- in attachment a picture of the mesh of AMI1 (or 2, identical). It's not a snappyHexMesh. Do you think the problem might be due to this type of mesh (although it works fine for the pimpleDyMFoam with AMI...)?
- When I create the AMI1 and 2 boundaries, I use "createBaffles", as they do in the propeller tutorial. I get a small error in the end:

Converted 8492 faces into boundary faces in patches
2
(
AMI1
AMI2
)


--> FOAM Warning :
From function createBaffles
in file createBaffles.C at line 657
Setting field on boundary faces to zero.
You might have to edit these fields.
Writing mesh to 0
End

Do you know what this means and do you think it might have an impact on the errors I get?

- it really seems like the difference between pimpleDyMFoam and interDyMFoam is causing this error, although I do not immediately see any relation to the AMI error. Do you have any other thoughts on this?


I'll definately keep you up to date when I get results, although I will need to check regarding confidentiality! In that case, I'll make a different version or so, to share.


Thanks again for the help,

best regards,

Wouter Remmerie.

[Artur]

It's indeed awkward that the same mesh works with pimple but doesn't with interFoam. I suppose they run at different time steps and one of them simply "skips over" the bit of the mesh that causes your case to crash, I've experienced that when I was varying maxCo for the same mesh.

I get the same warning as you, I think it means that it automatically assigns fixedValue 0 to all fields on the AMI patches. I get over it by overwriting the 0/ folder with my 0.org/ which already has BC's for the AMI patches in it.

Is there any chance you can change your maxCo or maxAlphaCo values a bit, maybe that will make it "skip over" the problematic bit? Not an elegant solution, I know, but might just do it for this particular mesh. In the meantime, maybe you can have a go at meshing your case using snappy, perhaps that would work better with the sliding mesh implementation of OpenFOAM. Also, you didn't mention whether your case blows up very soon or after a while of running fine? What version of OpenFOAM are you running it at?

I'll have a think about what else you could do to make it better.

A

[wouterremmerie]

Hi Artur,

I'm running 2.2.1.
- existing mesh:
I tried running different time steps, different speeds and variations of alphaco etc. All didn't work, and like you said, not the most elegant solution...

- snappy:
took your advice and started learning snappy with some tutorials (propeller mostly). And that worked fine after a while!!

I posted the result here:
http://users.telenet.be/kinematica/CFDOnline/AMI.wmv
Just for a reference, I added the MRF version as well (seems to match quite well):
http://users.telenet.be/kinematica/CFDOnline/MRF.wmv

If you're interested, I can post the files themselves too. But perhaps there is a more permanent place to store them, instead of my local ftp? (if someone else reads this later on, when the files will be gone).

Next steps for me I gues::
- monitor convergence (is that valid for time dependent simulations?)
- monitor the force (motorbike tutorial I guess!)
- mesh the real propeller, with loads of cells
- run it on an Amazon AMI


Thanks again for all the help Artur, it really made the difference!!


Greetz

Wouter.

[Artur]

Glad your trial simulation worked fine!

I spoke to my colleague on Friday (he's got a lot more experience than me in using AMI) and he said that he had tried using externally created meshes for it (Pointwise) but they did cause a lot of this type of problems and so he switched to snappy. That ties in with your path to the solution quite clearly.. Fortunately SHM is OK for most applications.

You can create public download links on dropbox if you want to share larger files with people on this forum or elsewhere. I'd be quite interested to see how you set your AMI case, always worth looking at someone else does things

If your case has a quasi-steady solution (e.g. flow through an open water propeller) then your force should stabilise after some point. So I guess it all depends on the very interesting problem you're trying to investigate

Let me know if you run into some problems on the way, I'll be happy to help if I can.

All the best,

A

[wouterremmerie]

Hello Artur,

first of all, here are the files mentioned above:
- MRF movie: https://dl.dropboxusercontent.com/u/...Online/MRF.wmv
- AMI movie: https://dl.dropboxusercontent.com/u/...Online/AMI.wmv
- AMI working OpenFOAM files (watch out, some tweaking required with the "0" folder during running of "mesh" and "Allrun"...)
https://dl.dropboxusercontent.com/u/...Online/AMI.rar

Secondly, now that I'm looking at snappyHexMesh for the real scenario, I ran into the following challenge: there is only a small gap between the stator and the rotor (blades pass by closely to the fixed part).
There is a region (the AMI boundary) that passed in between. It's defined as a region in snappyHexMesh, using an STL. That all works, but the problem is that, I think, the gap between the rotor and the stator is too narrow. Therefore, the mesh of the rotor snaps to the mesh of the stator, bridging the gap.

I can keep increasing all sorts of refinement settings, but that leads in the end to memory problems.

As there is a surface defined in between the stator and the rotor (not a physical sufrace, but the boundary of a region), is there a simple way to tell snappyHexMesh to have cells there, and explicitely tell it to split at that location? I'll need that split for the AMI anyway...

I added an image to explain:
https://dl.dropboxusercontent.com/u/...shSmallGap.png

Thanks again!

PS: sorry I can't share the real geometry, but it's a propeller meant to bring air into a tank. So not for propulsion or anything! It shoots the water upwards into the air (through the duct).

Hopefully someone has come across this "small gap" issue in snappyHexMesh!

Greetz

Wouter.

[Artur]

Hi,

I have experienced similar problems when meshing a propeller in proximity to a hull. Tomorrow I'll dig up the old cases and try to see how I dealt with it and try to reduce the gap even further to see if there is a chance it might work for you at all.

I was actually meaning to do a calculation for a ducted propeller for some time now, and now your case has given me motivation.

Stay tuned

A

[Artur]

OK, so it seems that everything either I or those of my colleagues to whom I've spoken have done in the past boils down to shrinking the AMI interface so that it's "just" outside the prop radius, having a well refined gap region and similar (or even the same) refinement regions in the AMI, on the prop and the inner side of the stator as to avoid weird mesh distortions as you're adding layers, for instance. Thinking about it now I reckon that the "tolerance" parameter might also affect whether your stator will be snapped to AMI or vice versa (unconfirmed yet). Let me know how that goes for you, I'll try to play around with it too when I get some time

All the best,

A

[wouterremmerie]

Hi again Artur,

how are your projects going? Hopefully lots of fun openfoam work

regarding snappyHexMesh:
- it seems that surface refinement was the way to go to get elements in between the small gap: the surface for the AMI runs in between (its not an actual patch, just the boundary of the rotating region). Putting the surface refinement of that area high enough, seemed to work. I am stuck on memory however to continue
- another question I have: to mesh the duct properly, I add some "feature refinement" so that the edges are properly meshed. This works, but on the outer edge, I have "surplus" triangles, that should not be there (the part itself, as is the STL file, is high res and perfectly round). Do you have any idea how to counter this? see attached image.
I tried playing with the tolerance but that doesn't solve the problem.
I have a surface attached to this ring (not a real one, boundary zone), perhaps that is the problem? The duct seems to eat some of the faces that should belong to that surface instead.

Thanks again for the help,

regards,

Wouter.

[wouterremmerie]

------------------

[Artur]

Hi,

Didn't see your 2nd post and already started writing a response :P How did you solve the problem?

A

[wouterremmerie]

Hello Artur,

I was too quick to post the reply last time: I had been looking at the wrong edge of the system! So problems were stil there.

Nevertheless, I proceeded differently: instead of trying to get the AMI boundary in between the rotor and the stator, I expanded it to include the stator as well. That required a whole lot less mesh (AMI in between had to be so fine that it became unfeasible).

I added the "fixed" velocity boundary to the stator, and the "movingWall" to the rotor.
Seems to work! Perhaps there are a few things not entirely correct with this approach, but there is indeed no tangential velocity on the stator. My guess is that this more and more correct as you get a smooth surface on the stator, so that those faces are truly tangential and do not push any fluid forward while rotating. But that's an assumption.

Nevertheless, some attempts to get the AMI in between resulted in the following "uncertain" conclusions:
- best way was to define an extra volume that encapsulated both the stator surface and the beginning of the rotating region, and add region refinement to that. That gave the basic castellated mesh refinement needed to snap to both the stator and the rotating region boundary (the AMI)
- that still resulted in a lot of spikes on the stator (which were not present in zones away from the AMI). Tried a lot of things to solve that. None worked perfect, however setting the maxNonOrtho limit to something as low as 30 seemed to clean it up. This however, was so dominant that snapping to the AMI was of poor quality.
- TET quality also seemed to have some good effect.
- but no final solution. would be nice if there was (perhaps there is) a method of telling the mesh explicitely to leave a gap somewhere and snap to both given surfaces.

Other than that, I'm wondering whether I have the "best" settings for the solver. Time step is really low, but it's stable.

I use the following for fvschemes and fvsolutions:

fvschemes:
ddtSchemes
{
default Euler;
}

gradSchemes
{
default Gauss linear;
}

divSchemes
{
div(rho*phi,U) Gauss limitedLinearV 1;
div(phi,alpha) Gauss vanLeer;
div(phirb,alpha) Gauss interfaceCompression;
div((muEff*dev(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
default Gauss linear corrected;
}

interpolationSchemes
{
default linear;
}

snGradSchemes
{
default corrected;
}

fluxRequired
{
default no;
p_rgh;
pcorr;
alpha1;
}


fvsolutions:
solvers
{
pcorr
{
solver PCG;
preconditioner DIC;
tolerance 1e-10;
relTol 0;
}

p_rgh
{
solver PCG;
preconditioner DIC;
tolerance 1e-07;
relTol 0.05;
}

p_rghFinal
{
solver PCG;
preconditioner DIC;
tolerance 1e-07;
relTol 0;
}

U
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-06;
relTol 0;
}
}

PIMPLE
{
momentumPredictor no;
nCorrectors 3;
nNonOrthogonalCorrectors 0;
nAlphaCorr 1;
nAlphaSubCycles 2;
cAlpha 1;
pRefCell 0;
pRefValue 0;
}


(if you know how to embed this as text instead of creating this long post, let me know ). Do you think these settings are reasonable for this problem?
I see other posts on the best settings, namely regarding maxCo and maxAlphaCo (do you know what the difference is?):
http://www.cfd-online.com/Forums/ope...m-laminar.html

Hopefully these notes trigger you or someone else

Best of luck with your own projects!

[Artur]

Hi,

Glad to hear you're making progress with your case. It's an interesting concept to put the stator inside the AMI - I would suppose that it should work if it's an axisymmetric body, and it seems that indeed it worked for you.

Your settings seem quite all right to me (by the way, you can use the [CODE] [\CODE] to make a scrolled window - # in bottom line, on the right hand side of the advanced edit options).

For my cases I seem to use very similar ones, except:

laplacianSchemes
{
    default         Gauss linear limited corrected 0.33;
}

and

snGradSchemes
{
    default         limited corrected 0.33;
}

and

divSchemes
{
    div(rho*phi,U)		Gauss linearUpwind grad(U);
}

The latter two shouldn't make much difference but the former one seems to make quite a bit of difference in terms of stability. See how it works for you.

I'm wondering, if your stator is "flat" on the inside, would it work if you just used it as a side for the AMI itself? For instance by adding surfaces at the inlet and outlet to it, thus defining a cylinder, and then selecting the cells inside the stator as the whole of the AMI. That would make the side of the AMI a solid boundary, which might give awkward results but maybe it's worth a try.

All the best,

Artur

[wouterremmerie]

Hi Artur,

sounds like an interesting approach, if it would work, that would be a more elegant solution compared to what I have now (it's still running though and looks realistic, but too much mesh).

Regarding the implementation, a few questions:
- can the inner wall of the stator be both an AMI patch and a boundary patch? Or must it be just one of those?
- the part of the stator that will form the AMI patch, must I remove that from the stator patch?
- if the AMI static patch (the part on the stator) functions as a boundary, can I add boundary conditions to it? Under velocity, it must say "fixed value" for a boundary, but must say "cyclicAMI" for the AMI patch. So I'm guessing that the AMI patch itself cannot be a boundary patch at the same time? And that therefore there must be a separate boundary patch as well?
- is there an easy way to select the faces that are common to both an existing patch (e.g. the stator tube) and a cellZone (e.g. the rotating region) ? (I'm guessing that there
exists a good combination of cellSet, cellToFace, ... to obtain it!).
I'm using the following code, I think it should work, but I get some errors for now (UPDATE: code below works. rotatingRegion seemed to be corrupted. works after fixing that).

{
        name    tubeInnerWall;
        type    faceSet;
        action  new;
        source  patchToFace;
        sourceInfo
        {
            name     tube;
        }
    }

    {
        name    tubeInnerWall;
        type    faceSet;
        action  subset;
        source  cellToFace;
        sourceInfo
        {
            set     rotatingRegion;
            option  all;
        }

Best regards & thanks again,

Wouter.

[Artur]

HI,

I think that finding BC's for this that will both work and be physically meaningful will be the biggest challenge (if it's even possible with the way AMI works). I reckon it will all depend on the patch topology that you'll get from your topoSet - my initial idea was to have a solid boundary and the AMI at the same location, so AMI having the regular interpolation BC and the solid wall a typical no-slip type. If that wouldn't work then perhaps adding a thick-ish layer to the stator and selecting the outer face of that as AMI (essentially leaving just a cell heigh gap between that and the wall) would. The advantage of the latter (in case of a cylindrical duct) would be that you wouldn't need to snap to the AMI as the layer extrusion "should" sort it out for you if your surface mesh is allright.

Good luck,

A

[wouterremmerie]

Hi Artur,

thanks for the tips. It's indeed not straight forward. I'm trying to make the AMI faces. Normally I do that using "createBaffles", which works for zones that are in the middle of a mesh. It works for boundary faces too, if I enable the option to include boundary faces. But by doing that, the boundary patch itself loses these faces!

Do you have any idea how I could create an extra 2 patches (the AMI faces), without loosing the existing boundary of the stator tube? Using OpenFOAM tools...?

I don't think it's as easy as copying patches, as there really need to be new points, faces and especially relationships to neighboring cells. Are there alternatives to the createBaffles to create new patches / cells / ...?

Hopefully I can get it to work, would be a nice thing to

Thanks again for the help,

regards,

Wouter.