[robbo]

I was trying to do the cylinder tutorial explained in the programmer's guide.
Once i've finished to do it I've started to wonder how to make the cylinder rotate.
What boundary condition I've to give to the cylinder instead of symmetry? It should be Wall? and if is this the right way how i can specify the angular speed of the cylinder? I've to specify a non uniform speed (point to point in cartesian coordinates) for all the points of the cylinder's surface?

thanks in advance for the help

Robbo

[ngj]

Hi Roberto

You need to program a new boundary condition (at least that is what I think). The programming is rather simple, and I have something at another computer, which might help you. The short story is, that you know the point on the surface, x_S, and the center of the cylinder, x_0. Then specify

v = x_S - x_0.

Say that the angular frequency is omega, then the boundary condition for the velocity for the cylinder surface in any given point is given as (assume 2D)

U = - omega * vector(-v_2,v_1,0)

where v_1 and v_2 are the first and second component of v. Assumed that the cylinder rotates clockwise, if anti-clockwise just remove the minus in front.

Have fun, and if you need my source, just send me an email.

- Niels

[robbo]

Hi Niels,

I've tried to send you a mail but i'm not sure you have received it.
Could you send me please your code? i've understood what you said but I don't know exactly how to do it.

tia

Roberto

[ngj]

Hi Roberto

As you said in the email, you are not completely sure how to compile, so I will make a small walk-through:

First here is the boundary condition.



Unpack the archive and from the command-line you go into the directory and type:

wmake libso

This creates a dynamic library which is placed in the folder $FOAM_LIBBIN. The library is called librotatingCylinderFvPatchVectorField.so.

Then unpack the following



which is a small test case with to concentric circles, where the large one rotates with a given cyclic frequency. The frequency and the center of the rotating cylinder is given in case/0/U. The library is only for 2D-case in the xy-plane, as I have not extended the code. Notice that the linking of the new boundary condition to icoFoam happens through /case/system/controlDict, where the library is added at the bottom.

Hope it works, otherwise to not hesitate to ask.

/ Niels

BTW: The setup is actually how viscosity was measured, because the flow is a couette-type of flow for large radii and small gaps. Thus the velocity profile is known, and therefore by measuring the force acting on the still cylinder, the viscosity can be determined as the velocity of the 'lid' is known.

[ngj]

Hi Roberto

As you said in the email, you are not completely sure how to compile, so I will make a small walk-through:

First here is the boundary condition.

rotatingCylinder.tar.gz

Unpack the archive and from the command-line you go into the directory and type:

wmake libso

This creates a dynamic library which is placed in the folder $FOAM_LIBBIN. The library is called librotatingCylinderFvPatchVectorField.so.

Then unpack the following

viscosityTest.tar.gz

which is a small test case with to concentric circles, where the large one rotates with a given cyclic frequency. The frequency and the center of the rotating cylinder is given in case/0/U. The library is only for 2D-case in the xy-plane, as I have not extended the code. Notice that the linking of the new boundary condition to icoFoam happens through /case/system/controlDict, where the library is added at the bottom.

Hope it works, otherwise to not hesitate to ask.

/ Niels

BTW: The setup is actually how viscosity was measured, because the flow is a couette-type of flow for large radii and small gaps. Thus the velocity profile is known, and therefore by measuring the force acting on the still cylinder, the viscosity can be determined as the velocity of the 'lid' is known.

[mark_michael]

When you want to rotate the cylinder-patch ! Why didn't you take the "movingWallVelocity" - Boundary Condition in the U - file of your Time-step ??

[ngj]

Hi

I didn't know it existed. Thanks for the info

I have been looking at the source, and it deals with present and old face-centers, so using it wouldn't that require the use of a moving-mesh solver?

/ Niels

[mark_michael]

ok ! i didn't realised that you want to move the mesh ! i just thought that the boundary-condtion should implimeted U-tangential=const. and U*n=0 in the education !

Mark !

[ngj]

Hihi, I think we are talking in two different direction.
I am not interested in moving the mesh, but in movingWallVelocity there is call to both old and present face-locations, see below, thus isn't that the same as stating that the mesh most be moving to use the patch?

Best regards,
Niels

==========================================

void movingWallVelocityFvPatchVectorField::updateCoeffs ()
{
if (updated())
{
return;
}

const fvPatch& p = patch();
const polyPatch& pp = p.patch();
const fvMesh& mesh = dimensionedInternalField().mesh();


const pointField& oldAllPoints = mesh.oldAllPoints();

vectorField oldFc(pp.size());

forAll(oldFc, i)
{
oldFc[i] = pp[i].centre(oldAllPoints);
}

vectorField Up = (pp.faceCentres() - oldFc)/mesh.time().deltaT().value();

const volVectorField& U = db().lookupObject<volvectorfield>("U");
scalarField phip =
p.patchField<surfacescalarfield,>(fvc::meshPhi(U)) ;

vectorField n = p.nf();
const scalarField& magSf = p.magSf();
scalarField Un = phip/(magSf + VSMALL);


vectorField::operator=(Up + n*(Un - (n & Up)));

fixedValueFvPatchVectorField::updateCoeffs();
}

[robbo]

Hi Niels,

I had no time at all to continue my OpenFOAM projects during the last weeks. Now that I've found the time i've tried to compile the boundary condition you've posted but the make command gives no good results at all :-(
it exits with Error 1. How can I do? Do you think that posting you (mayba via mail) the shell's output could help (it's pretty long and unreadable though...)?

thanks for your help

Roberto

[ngj]

Hi Roberto

Just give it a try, we might be able to find a solution.

- Niels

[robbo]

Hi Niels,

i was reflecting about my original question: I think I was wrong. I'll try to explain in a few words.
My original purpose was to compute numerically the lift generated on a rotating cylinder for a potential flow and compare it with analytical solution.
My first solution for that problem was: make the cylinder rotate and the solutor will do the rest.
Now iI was thinking that in a potential flow making the cylinder rotate will not affect the remaining part of the flow because of the absence of viscosity.
I think I have to change my approach.
I need to superimpose on the uniform flow field a free vortex (generated in a real fluid by the viscosity, but not in a potential flow). In a few words I have to force a flow field generated by the viscosity in a nonviscous fluid.
How can I do? and how can I subsequently calculate the resultant force acting on the cylinder by integrating the pressure distribution on the cylinder?
I'm aware that I have to change the geometry of the case because in those conditions there's no more symmetry in the flow field.

tia

Roberto

[ngj]

Hi Roberto

If you are going to do viscous modeling, then why do you not use any of the many viscous solvers in the OF-package. Superimposing the viscous part on the potential flow is probably possible in OF - wouldn't know where to start though - but I see another problem, which is significantly more severe. Because superimposing two solutions require the equations to be linear, thus you are essentially restricted to creeping flow solutions, otherwise the convective terms may become non-negligible.
Thus using the viscous solvers you are not limited to a certain range of Reynolds numbers.

Best regards,

Niels

[robbo]

Hi Niels,

My aim was to validate the potentialFlow solver, I don't need to do viscous modeling. If anyone has sugestions...

Thanks

Roberto

[ngj]

Hi

I have hardly ever solved any potential flow problems, but if you take a book in Complex number then there will probably several examples on the use of conformal mapping, and conformal mapping is basicly a mapping of the laplace-operator (at least in all the cases I have ssen).

Actually I have seen a paper of the flow under a sluice gate assuming potential flow, see [1].

Further you could look into textbooks in geotechnic, as all plane flows in soils are also based on the laplace equation with appropriate boundary conditions.

Hope this inspires you.

- Niels

[1]: Flow from a Sluice Gate under Gravity, V.J.Klassen, Journal of Mathematical Analysis and Apllications 19, pp 253-262, 1967

[robbo]

Hi Niels,

I was looking to the results of the cylinder tutorial simulation (that with uniform flow, I've not even added the swirl. Always facing with the lack of time :-)) and I've found something strange.
I've done the simulation as described in the programmer's guide (with nNonOrthogonalCorrectors=3).
The velocity field in this case seems to have a good agreeement with that I expected but the pressure filed is uniform across all the domain. This is not really what i expected to view... The pressure should be higher on the stagnation point on the nose of the cylinder and less on the top of it, exactly in the opposite way as the velocity does. I'm wrong? What I'm not considering?

thanks so much

Roberto

[ngj]

Hi Roberto

The reason p=0 is that you do not write the pressure field by default from potentialFoam. Execute the solver as follows:

potentialFoam . cylinder -writep

Best regards,

Niels

[robbo]

Hi Niels,

I've done what you wrote me to do and potentialFoam writes the pressure field. What I think is that the pressure field it plots is incorrect.
The pressure shows a sort of continuous linear decreasing towards the whole field (near and far from the cylinder). I'dont think that this has good matching with what really happens. In fact with this pressure field (and with this velocity distribution) the total pressure within the domain is not constant although it should be 'cause in a potential flow without shocks there are no losses.
Do you think that I'm right?
I'was thinking that this is because of the pressure equation used. In the programmer's guide it says that potentialFoam uses laplacian(p)=0.
I don't think that that equation is correct. I don't have books but I remember from my studies that there should be something connected with the velocity field. How can tha solver couple the velocity field with the pressure field in this way?
Thanks for your help!

Roberto

[robbo]

I've found in my university stuff that the pressure equation for an incompressible fluid is:

laplacian(p)=-rho*d(U_i)/d(x_k)*d(U_k)/d(x_i)

This equation is written using Einstein notation for vector components, and i and k are generic components.

Has anyone some news about this problem? Niels do you think that could be helpful if I move this discussion (or the last two messages only) in the bug section?

thanks

Roberto

[ngj]

Well, if you into the source of potentialFoam, you will find that the pressure equation is not solves as

laplaian(p) = 0

but

laplacian(p) = div(phi)

which should be the same as you have written above. Though I agree that it is odd that you have the 'linearly' decreasing pressure.

Have a nice weekend,

Niels