[granzer]

I recently ran a simple pipe flow simulation using both symmetry boundary conditions and wedge boundary conditions using icoFoam solver. The results were identical. I was wondering what is the difference between these two conditions. Is there a situation where it would be preferable to use a wedge condition?

[hjasak]

A wedge is used for axial and spherical symmetry and needs to perform a coordinate transformation for the wedge angle and not a simple mirroring.


Hrv

[granzer]

Originally Posted by hjasak

A wedge is used for axial and spherical symmetry and needs to perform a coordinate transformation for the wedge angle and not a simple mirroring.


Hrv

Thank you for your reply. I had that OpenFoam uses the same cartesian coordinates for the Wedge condition and there is no transformation. Also, advantages or disadvantages does the wedge condition and the symmetry condition have over each other? (as I think the symmetry condition can do what the wedge condition can do.)

[Tobi]

Dear Granzer,

as Hrv already mentioned. The wedge type has a transformation included (https://github.com/OpenFOAM/OpenFOAM...FvPatchField.C). This is different compared to the symmetry boundary conditions. As Hrv said, wedge -> transformation and is used for axis-symmetric calculations.

[granzer]

Originally Posted by Tobi

Dear Granzer,

as Hrv already mentioned. The wedge type has a transformation included (https://github.com/OpenFOAM/OpenFOAM...FvPatchField.C). This is different compared to the symmetry boundary conditions. As Hrv said, wedge -> transformation and is used for axis-symmetric calculations.

Originally Posted by hjasak

A wedge is used for axial and spherical symmetry and needs to perform a coordinate transformation for the wedge angle and not a simple mirroring.

Thank you @Tobi and @hjasak. Does wedge condition allow flow through the wedge? Wedge boundary condition and the math behind it??????? this post makes me think it does [I am assuming that rotational flow around the axis means there will be flow through the wedge faces] but Axisymmetric Whirl BCs; Wedge or Cyclic? this post is contradicting it.

[Hughtong]

Originally Posted by hjasak

A wedge is used for axial and spherical symmetry and needs to perform a coordinate transformation for the wedge angle and not a simple mirroring.


Hrv

Dear Hrv.
How about rotational cyclic? I've dived into the code of cyclic and wedge, found that both cyclic and wedge contain transform() function which defined in `transformField.H`. But it seems that the math behind them are different. But the wedge contains a cosAngle_ calculation which cyclic do not have. So what is the different of rotational cyclic and wedge? They seem got much in common, but do have different implemention. :

[Tobi]

Not sure if Hrv will reply, but the difference should be clear.

For wedge type we perform the transformation mentioned by Hrv to have a rotational-axis-symmetric result. The cycle type is used to map the values of one patch to another. If the patches are not located exactly at the same position (which should be the case in general), we need to perform a transformation of one position to the other. E.g. you want to put the outlet values back to the inlet on a straight channel. If the topology of the patches are identical, you would use cyclic + a translation transformation. If you would, E.g do the same of a 90deg elbow pipe, you would do the same but here you would perform a rotational translation. It will simply transform your data at one position to the other.

[Hughtong]

Originally Posted by Tobi

Not sure if Hrv will reply, but the difference should be clear.

For wedge type we perform the transformation mentioned by Hrv to have a rotational-axis-symmetric result. The cycle type is used to map the values of one patch to another. If the patches are not located exactly at the same position (which should be the case in general), we need to perform a transformation of one position to the other. E.g. you want to put the outlet values back to the inlet on a straight channel. If the topology of the patches are identical, you would use cyclic + a translation transformation. If you would, E.g do the same of a 90deg elbow pipe, you would do the same but here you would perform a rotational translation. It will simply transform your data at one position to the other.

Thank you Tobi! But I still got one problem. The 90deg elbow pipe is also rotational-axis-symmetric, I can also use wedge ,am I right? I think if these boundary contain some transformation, the result will be in the flow direction? So can I use mesh.boundary()[patchI].Sf()[patchFaceI] to monitor the pair of cyclic, wedge, and symmetry to see what it will happen? I am planning do it.

[hjasak]

Hi,

Nice topic. Apologies for the lengthy reply.

This is a difference between what my friend calls 2-d vs 2.5-d vs 3-d. Let’s take them in turns.

A flat 2-d case is clear: solve eg x and y and z-components of vectors are zero

Wedge: Please have a look at the Navier-Stokes equations in a cylindrical coordinate system. You have the 1/y prefactor in the laplacian - and I don’t like it. It account for the fact that the surface area of a face increases with radius; also there is a cylindrical component of the gradient. To deal with this, I build a wedge mesh and have the special wedge boundary condition. For scalars it does nothing but for vectors it takes the cell centre value and transforms it to be in the plane of the wedge boundary before using normal algorithm for eg gradient of a vector field. There are some limitations. First, the central plane of the geometry need to be a principal plane of the global Cartesian coordinate system. Fine. Second, front and back wedge boundaries must be flat and forward and backward angle of a wedge must be the same. Third, from and back wedge patch must be 2 separate patches; otherwise I cannot do the transformation correctly. Fourth, the wedge must be 1 cell thick.

This is what my friend Jean-Marie calls 2-d. YOU ARE NOT ALLOWED SWIRL!!!

What happens if I want a wedge-like geometry, but with swirl? Well, this is 2.5-d but we need to get there.

The first step is that you make it 3-d but cyclic. This is fine: say, make a 90-deg geometry and put cyclic boundaries on the sides. This is called “periodic” rather than cyclic because you need a coordinate transformation between the patch pair, but you can make it implicit. However, I don’t like this: can I have the geometry with 1-cell thickness where instead of wedge boundaries I gave cyclic (periodic) and I allow swirl?

The short answer is: you cannot. The best you can do is to make your wedge 2 cells thick, with cyclics .

The reason for this is as follows: if I have 3-d mesh with cyclic it all works. Coordinate transformation contribution in the matrix is added as off-diagonal contribution and it all works. However, if your cyclic wedge is 1-cell-thick, the cell basically couples TO ITSELF! Therefore the additional terms from cyclic coordinate transformation needs to be added to the diagonal and not off-diagonal to make it work. If you try it, the code will either blow up or give you inappropriate swirl solution.

Painful, I know. It is fixable with a new 1-cell-cyclic condition for a proper 2.5-d solution with swirling flow, but I’m not doing this without a project and some funding.

Hrv

[qingqingliu]

Originally Posted by granzer

Thank you @Tobi and @hjasak. Does wedge condition allow flow through the wedge? Wedge boundary condition and the math behind it??????? this post makes me think it does [I am assuming that rotational flow around the axis means there will be flow through the wedge faces] but Axisymmetric Whirl BCs; Wedge or Cyclic? this post is contradicting it.

The wedge boundary condition does allow flow through the wedge.

[hjasak]

There is a difference. I actually wrote this code. If you don't trust me, write your own or CAREFULLY test the code I wrote and report what you think is a bug.


How is it possible that the wedge boundary allows for the rotating flow if the wedge-normal velocity direction is not solved for? Check for

Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)

in checkMesh output

(this is for 3-D). Also, check out this piece of code - polyMesh.H in my version

//- Return the vector of geometric directions in mesh.
// Defined according to the presence of empty and wedge patches.
// 1 indicates unconstrained direction and -1 a constrained
// direction.
const Vector<label>& geometricD() const;

//- Return the number of valid geometric dimensions in the mesh
label nGeometricD() const;

//- Return the vector of solved-for directions in mesh.
// Differs from geometricD in that it includes for wedge cases
// the circumferential direction in case of swirl.
// 1 indicates valid direction and -1 an invalid direction.
const Vector<label>& solutionD() const;


As you will see in fvMatrixSolve.C, solution in the wedge-normal direction is disabled. When you project the cell-centre vector onto a wedge it does:



fvPatchField<Type>:perator==
(
transform
(
refCast<const wedgeFvPatch>(this->patch()).faceT(),
this->patchInternalField()
)
);

which kills the wedge normal velocity.


So how on Earth, I beg you, can you get a wedge-normal flux???


Hrv

[Hughtong]

Originally Posted by hjasak

Hi,

Nice topic. Apologies for the lengthy reply.

This is a difference between what my friend calls 2-d vs 2.5-d vs 3-d. Let’s take them in turns.

A flat 2-d case is clear: solve eg x and y and z-components of vectors are zero

Wedge: Please have a look at the Navier-Stokes equations in a cylindrical coordinate system. You have the 1/y prefactor in the laplacian - and I don’t like it. It account for the fact that the surface area of a face increases with radius; also there is a cylindrical component of the gradient. To deal with this, I build a wedge mesh and have the special wedge boundary condition. For scalars it does nothing but for vectors it takes the cell centre value and transforms it to be in the plane of the wedge boundary before using normal algorithm for eg gradient of a vector field. There are some limitations. First, the central plane of the geometry need to be a principal plane of the global Cartesian coordinate system. Fine. Second, front and back wedge boundaries must be flat and forward and backward angle of a wedge must be the same. Third, from and back wedge patch must be 2 separate patches; otherwise I cannot do the transformation correctly. Fourth, the wedge must be 1 cell thick.

This is what my friend Jean-Marie calls 2-d. YOU ARE NOT ALLOWED SWIRL!!!

What happens if I want a wedge-like geometry, but with swirl? Well, this is 2.5-d but we need to get there.

The first step is that you make it 3-d but cyclic. This is fine: say, make a 90-deg geometry and put cyclic boundaries on the sides. This is called “periodic” rather than cyclic because you need a coordinate transformation between the patch pair, but you can make it implicit. However, I don’t like this: can I have the geometry with 1-cell thickness where instead of wedge boundaries I gave cyclic (periodic) and I allow swirl?

The short answer is: you cannot. The best you can do is to make your wedge 2 cells thick, with cyclics .

The reason for this is as follows: if I have 3-d mesh with cyclic it all works. Coordinate transformation contribution in the matrix is added as off-diagonal contribution and it all works. However, if your cyclic wedge is 1-cell-thick, the cell basically couples TO ITSELF! Therefore the additional terms from cyclic coordinate transformation needs to be added to the diagonal and not off-diagonal to make it work. If you try it, the code will either blow up or give you inappropriate swirl solution.

Painful, I know. It is fixable with a new 1-cell-cyclic condition for a proper 2.5-d solution with swirling flow, but I’m not doing this without a project and some funding.

Hrv

Thank you for your detailed answers dear Prof. Jasak! Truly appreciate it!