[alessio.nz]

Hi,

Is there a paper/document which explains the meaning of the cylindricalInletVelocity Boundary Condition for OpenFOAM? I need to set up an inlet velocity in a tube with the following features: 133 m/s axial velocity, 0 m/s radial, 77 m/s tangential (clockwise). I tried to use the following BC available but there are some lines I don't get, like: axis (0 0 1) , centre (0 0 0).

Can someone help me?

The BC is the following:

type cylindricalInletVelocity;
axialVelocity 133;
tangentialVelocity 77;
centre (0 0 0); //by default (0 0 0)
axis (0 0 1);
rpm 0;
radialVelocity 0;
value uniform (0 77 133);

[N. A.]

Hey Alessio,

Were you able to get the information about axis and center?

I dont know if the axis is in cartesion cordinate system or cylindrical.

Thanks,
Nir

[AlanR]

Alessio,

The best way to understand OF is to look at the source code. For your BC, look in src/finiteVolume/fields/fvPatchFields/derived/cylindricalInletVelocity. Looking through the .C and .H files usually tells you a lot. I think the Center (0 0 0) is the center of your cylindrical inlet, which is set to (0 0 0) by default. If your mesh geometry is different, use the input vector to align it. The axis vector is to specify the direction of axial flow (0 0 1) being positive z.

I usually search the forum to see if there are relevant posts, then I will look through the source code. Good luck,

Alan

[alessio.nz]

Hi Nir, the system I was talking about was cylindrical. Axis and center refers to the mesh ones. The axis is the z, also considered as axial.

[alessio.nz]

Hi Alan, the problem was not so trivial: if you consider the situation, what I needed was a flow with axial and tangential velocity. The axial velocity of 133 m/s and tangential one of 77 m/s. The tangential obtained in the BC of Cyl BC was not the right one, because it is depented on the radius of the inlet tube, meaning that if I have a rpm value and a diameter, this tangential velocity is radius dependent, while, what I actually need, is a uniform tangential velocity (which has to recreate the swirler conditions). What I would like to set up a tangential velocity as I could do for the radial one (see the lines). Do you think is it possible?

[amwouden]

Alex, the case you described is exactly what I've wanted from the cylindricalInletVelocity condition. The best way I found was to just modify the source code. The modified library is attached.

Firstly, there are a few things that I have learned.
1) the center point is in Cartesian coordinates; very few, if any, OpenFoam utilities are in Cylindrical coordinates

2) at no point in the library is a component defined in Cylindrical coordinates. Rather, radial and tangential are defined in the form (x-contribution, y-contribution, 0)

3) the specification for the radial and tangential velocities are incorrectly scaled. Note below that the variable "d" is the relative radial-tangential distance between the cell-face center and the "centre". The "d" used in subsequent calculations should be replaced with a "dhat" where

vectorfield dhat = d/mag(d)

This adjustment should clear the radial-dependent scaling on the components.

As contained in cylindricalInletVelocityFvPatchVectorField.C (I've added a few comments):

// * * * * * * * * * * * * * * * Member Functions * * * * * * * * * * * * * //
void Foam::cylindricalInletVelocityFvPatchVectorField:: updateCoeffs()
{
if (updated())
{
return;
}
vector hatAxis = axis_/mag(axis_); //unit-vector of axial coordinate
vectorField r = (patch().Cf() - centre_); //relative distance vector
vectorField d = r - (hatAxis & r)*hatAxis; //subtract out axial component
vectorField tangVelo =
(rpm_*mathematicalConstant:: pi/30.0)*(hatAxis)^d;
//recall: hatAxis^hatRadial=hatTangential, therefore tangVelo = omega*hatTangential
operator==(tangVelo + axis_*axialVelocity_ + radialVelocity_*d);
//splice xyz components from tangential-axial-radial
fixedValueFvPatchField<vector>::updateCoeffs();
}

The modified library allows for a more convenient specification, namely
inlet
{
type cylindricalInletVelocity;
axis (0 0 1);
centre (0 0 0);
radialVelocity -10;
tangentVelocity 10;
axialVelocity 30;
value (0 0 0); //the value is not really necessary for the condition but OpenFOAM give me an error if I don't include it.
}

I've attached the new library folder. Simply unzip the folder into a convenient place and run

wmake libso

[alessio.nz]

Thanks Alex, it is very usefull!

considering I am not very familiar with the libraries, if I compile this version you attached, which has got the same name of the default one in OF, do you suggest me to change the name, or simply shall I compile and then the previous default one will be replaced?

i will try to run simulation and check if it works, with the inlet values you gave me.

thanks for the help!

cheers,

alessio

[amwouden]

In OpenFOAM 2.1, the compiling structure has changed to some degree. Attached is the drop-and-run source code for the cylindricalInletVelocity. Because OF2.1 has a native condition of the same name (which I have reservations against using for the reasons in a previous post), the name of the condition has been altered to cylindricalVelocityInlet.

1) uncompress the file to a convenient location. I use my openfoam user folder.

2) compile using: wmake libso

3) the boundary condition should compile smoothly. The condition can be applied to the velocity on a patch. in the initial condition specify

type cylindricalVelocityInlet;
axis (x y z); // axis of rotation
centre (x y z); // axial center
radialVelocity scalar; // V_r
tangentVelocity scalar; // V_theta
axialVelocity scalar; // V_z
value uniform (0 0 0); // not necessary, but paraView results in an
error without it

[paladin]

Hi Foamers !

I am trying to simulate a swirling flow with an anular inlet, and therefore I'd like to use the cylindricalInlet Velocity. (OF 2.0.x)

I'll have to run my simulation on a cluster so I can't use any additional user library suggested above...

Does anyone knows if this boundary condition works properly?

Even when I change de rpm, the velocities, etc, i still get this error :

Starting time loop
Courant Number mean: 4.24721e-05 max: 0.0535831
deltaT = 2.85714e-06
Time = 2.85714e-06
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0

--> FOAM FATAL ERROR: 
attempted copy of a deallocated temporary
    From function Foam::tmp<T>::tmp(const tmp<T>&)
    in file /Volumes/OF/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/tmpI.H at line 63.
FOAM aborting

The same simulation with a simple "fixed value" condition and an axial component works just fine.

Anyone has an idea? I am no OF expert, so I don't even understand what the error means...

Thanks in advance !

[amwouden]

What does your initial condition file for U look like?

The cylindricalInletVelocity of OF2.x should work.

[paladin]

Here is the burner geometry : http://cl.ly/NpGk

My swirling jet is between the bluff body (r=25mm) and the annular shroud (r=30mm)

The axial velocity is 16.3m/s and the tangential velocity 25.9m/s. Axis is in the X direction.

Here is my boundary condition in 0/U

	Pilot
	{
	
	type cylindricalInletVelocity;
	axis (1 0 0);
	centre (0 0 0);
	axialVelocity 16.3;
	rpm 8244; 
	radialVelocity 0;
	value uniform (0 0 0);
	}

RPM 8244 seems high but 25.9m/s tangential velocity for a 30mm annulus... I double checked the maths.

I had to put a "value" keyword, otherwise it doesn't run.


Thanks for your help

[amwouden]

After looking into it a bit further, I am noticing the same error with the native bc that is available.

The error is associated with the handling of the tangential component. In the source code:

tmp<vectorField> tangVel
(
(rpm*constant::mathematical:i/30.0)*(hatAxis) ^ d
);

By some unknown reason, it is trying use this variable without allocating it properly.
Unless you can modify the source code or use one of the user libraries above. I don't know what to suggest.

[vishalsacharya]

Why cant you use the user libraries on a cluster?

I know the installation is in a non-default place and the env vars are set based on those. But the *_USER dirs can be set to you where you want your src and lib folders to be and then when you "wmake libso" user codes, it would put them there. Then you can just add the appropriate .so files to your controldict and it should work.

[marcaurel]

Hi Alex!

I'm using OpenFOAM 1.6-ext and I would also like to use your cylindricalInletVelocity BC. Have you already adjusted your version to OF 1.6-ext because there is a big difference to OF 2.x and my programming knowledge is a bit limited ?

BR
Markus

[lentschi]

Hello Markus,

you can find the appropriate file for OF-1.6-ext at

http://www.cfd-online.com/Forums/ope...tml#post305143

[S_teph_2000]

Originally Posted by amwouden

In OpenFOAM 2.1, the compiling structure has changed to some degree. Attached is the drop-and-run source code for the cylindricalInletVelocity. Because OF2.1 has a native condition of the same name (which I have reservations against using for the reasons in a previous post), the name of the condition has been altered to cylindricalVelocityInlet.

1) uncompress the file to a convenient location. I use my openfoam user folder.

2) compile using: wmake libso

3) the boundary condition should compile smoothly. The condition can be applied to the velocity on a patch. in the initial condition specify

type cylindricalVelocityInlet;
axis (x y z); // axis of rotation
centre (x y z); // axial center
radialVelocity scalar; // V_r
tangentVelocity scalar; // V_theta
axialVelocity scalar; // V_z
value uniform (0 0 0); // not necessary, but paraView results in an
error without it

Hello,

How would you proceed if your inlet velocity components were all functions of the radial direction:

type cylindricalVelocityInlet;
axis (x y z); // axis of rotation
centre (x y z); // axial center
radialVelocity scalar; // V_r =f1(r)
tangentVelocity scalar; // V_theta =f2(r)
axialVelocity scalar; // V_z=f3(r)

Stephane

[Chrisi1984]

Hello Stephane,

were you able to adapt the BC with the radius dependant values? I would also need such a BC.

Kind regards

Chrisi

[Howard]

Originally Posted by AlanR

Alessio,

The best way to understand OF is to look at the source code. For your BC, look in src/finiteVolume/fields/fvPatchFields/derived/cylindricalInletVelocity. Looking through the .C and .H files usually tells you a lot. I think the Center (0 0 0) is the center of your cylindrical inlet, which is set to (0 0 0) by default. If your mesh geometry is different, use the input vector to align it. The axis vector is to specify the direction of axial flow (0 0 1) being positive z.

I usually search the forum to see if there are relevant posts, then I will look through the source code. Good luck,

Alan

Hello, Friends! I think what you said is quite meaningful. Could I ask how learn these information or skills, learning C++? And like this situation, how do you know to look up the SRC/...derived document? Thank you!

[sitajeje]

Dear Foamers,

I set the cylindricalInletVelocity as the following:
lateral
{
type cylindricalInletVelocity;
axis (0 0 1);
centre (0 0 0);
axialVelocity constant 0;
radialVelocity constant 0.3;
rpm constant 955;
}

The radius of the cylindrical boundary is 3mm. Therefore the tangential velocity is the same as the radial velocity, and the velocity vector at this boundary should be 0.42m/s, with 45° deviating from the tangential/normal direction of the boundary. However the resulting inlet velocity was 0.37m/s and closer to the normal direction of the boundary, as you can see in the attached image. Did I misunderstand something? I would appreciate if anybody can give me some suggestions!

Best regards,

sitajeje

[Matthias Frechen]

Hi All!
We usally use cylindricalInletVelocity for square swirl diffusers, but we are not totally convinced by the accuracy of the results regarding inlet volumetric flow when using a single square inlet area. The resultant inlet volumetric flow we see in Paraview seems to be about 20- 30% to low compared to the axialVelocity we put in the input file.

Does anyone tried to use swirlFlowRateInletVelocityFvPatchVectorField or groovyBC for swirl diffusers or a different approach with promising results?


Regards
Matthias