[asking]

Hi everyone,

I have a cylinder forced to vibrate in the y-direction following a sinusoidal function. The amplitude is 1.5 diameters and its frequency is 2 Hz. In addition, the cylinder is subjected to an inlet velocity of 0.132 m/s.

The mesh region is composed in three zones. An O-ring configuration where y+<1, a deformable zone of triangular mesh, and a stationary zone with quad elements (image attached). The deformable zone absorbs the cylinder motion and it's subjected to remeshing when its necessary.

mesh.png

A simulation is performed without remeshing for 0.5 seconds (one cycle of movement) and with a constant inlet velocity of 0.132 m/s. The force (image attached) is a little bit erratic the first time-steps but it stabilises after that.

lift-noremesh.png

Then, the same simulation is performed with remeshing. The lift force has a number of spikes which coincides with changes in the number of cells as the deformable zone is remeshed (both graphs attached).

data-remesh.png

I have tried multiple approaches to remove this issue and only one thing has worked: changing the second order implicit time discretisation to the first order. Unfortunately this imply a reduction of accuracy in the flow equations. In addition, I have seen two papers that are able to use second order implicit to solve a similar case.

Some of the things I have tried:
1.- time step ts reduction. ts/2 and ts/4.
2.- reducing remeshing interval from 5 to 2.
3.- starting with forst order and then changing it to second order.
4.- Implicit updates in the dynamic mesh section

Anyone have some ideas? I am quite stuck here!

Thank you!
Regards

[vinerm]

It is required that boundary layer is resolved and for that you have a O-ring mesh around the cylinder. However, do you ensure that the region containing boundary layer mesh moves along with the cylindrical wall so that the BL mesh is undisturbed? That could be one reason for the spikes. Another reason could be the motion itself; if it has jerks. So, you have to check if the motion definition has any variable acceleration; in case it is not SHM.

[asking]

Thank you for your response vinerm!

Originally Posted by vinerm

Another reason could be the motion itself; if it has jerks. So, you have to check if the motion definition has any variable acceleration; in case it is not SHM.

The cylinder motion is forced following this displacement equation: y(t) = 1.5*D*sin(2*pi*f*t), where y is the y-direction, D is the cylinder diameter, f is the frequency, and t is time. I used a UDF with the DEFINE_CG_MOTION macro. In that macro, I added the velocity vy(t) as the derivative of the previous equation.

I confirmed that vy(t) is correct by monitoring the displacement in Fluent. It correctly follows a smooth sinusoidal motion with the expected amplitude and frequency. So, to me, the cylinder has the expected displacement without sudden changes.

Originally Posted by vinerm

It is required that boundary layer is resolved and for that you have a O-ring mesh around the cylinder. However, do you ensure that the region containing boundary layer mesh moves along with the cylindrical wall so that the BL mesh is undisturbed? That could be one reason for the spikes.

I checked that the O-ring zone moved with the cylinder as a single unit by:

1.- Checking the number of cells: This value is constant throughout the simulations.
2.- Checking the area of the O-ring: I noticed small fluctuations in this value but the ratio between the maximum and minimum value is 0.99999 so I assume this fluctuations are due to numerical rounding.
3.- Checking the displacement of the cylinder and the limits between the O-ring boundary: Here I may have found something. The difference between these two displacements ranged between 2.16e-5 and 7.44e-5 (0.00056D and 0.002D). This difference should be theoretically be zero, which is not. Even though there are small values, its ratio is 3.45 which could be significant since the element size in the O-ring zone is very small.

I tried to change the UDF to reduce the difference between the cylinder and the O-ring boundary without success. Could be the reason but not sure.

Regards!

[vinerm]

Fluent has an option to ensure that BL mesh moves along with the moving domain. You can use that to ensure that there is no relative motion or deformation between BL mesh and the cylinder.

[asking]

Originally Posted by vinerm

Fluent has an option to ensure that BL mesh moves along with the moving domain. You can use that to ensure that there is no relative motion or deformation between BL mesh and the cylinder.

Thank you vinerm! Unfortunately (for me) the mesh inside the O-ring is moving as a single unit and, as a consequence, the BL moves with the cylinder. Also, if it was a BL issue, the problem would be on the simulation without remesh, which is not the case.

I have been testing other things. I have been checking the "dynamic mesh volume cell" which indirectly marks the cells to remesh. The mesh deforms only in the deformed zone as expected but I can't find a way to check specifically which cells are being remeshed. Anyone knows how to do this?

I also increased the diffusion parameter forcing a greater number of big cells (the ones near the boundary of the deformable zone) are marked for remeshing and avoiding smaller cells near the O-ring to be remeshed and somehow affect the results. I moved the diffusion parameter from 1.6 to 2 and 3 (image attached).

remesh_diffusion.jpg

There is a reduction on the magnitude and number of the spikes. Does it means that it is the remeshing of small cells near the boundary of the O-ring creating these spikes? Maybe my deformable zone is not big enough... but on the other hand I designed it to avoid remeshing the smallest cells in the deformable zones. I am quite confused!

Regards,

[vinerm]

It is good that BL moves with the cylinder. I don't know the extent of vertical movement for your case, however, I hope there is enough space left on top or bottom when cylinder is at its top-most or bottom-most position, resp. Otherwise, there would be sudden increase in the stresses.

As far as mesh deformation is concerned, you can try to write case files at various time-steps and then observe if mesh is bad closer to a spike. Another improvement you can do is by using Node Based Gradient instead of default Least Square.

[Emanuel Camacho]

Asking, did you find any solution concerning this problem?