[MikeWorth]

I'm trying to set up a simulation using overset meshing (overInterDyMFoam), and am seeing spurious high velocities that only seem to appear when I add boundary layers to my mesh around a moving object.

I'm wondering if this is due to interpolation issues between the large ~2mm background mesh cells and the flat (high aspect ratio) ~5um boundary layer cells. It's hard to see what's going on, but I think that the high velocities start off near the 'hole wall' interpolation surface.

Out at the overset boundary, cells are near-enough the same size on the two meshes, but obviously this won't be the case next to the hole. I've seen generic comments around keeping cell sizes similar, but have also seen examples using boundary layers; surely smaller boundary layers are supported?

Thanks,
Mike

[Anouk]

Hey Mike,


I've have a similar problem. I'm getting high frequency oscillations in the force response of a moving object from an overset mesh simulation in OpenFOAM (v2006). That is, if the mesh resolution of the "foreground" mesh (around the moving object) is not matching that of the background mesh. I've illustrated the problem with the twoSimpleRotors test case, see attached pictures. The left case has the original mesh resolutions of this tutorial test case, i.e. a similar mesh resolution of rotor and background mesh. On the right hand side you see a test case where if I've refined the rotor (foreground) mesh. As you can see this results in more high frequency oscillations.

So my question is; did you find a solution to this problem? As for my actual test case keeping the same mesh resolution for foreground and background mesh would result in a large increase in computational effort..

Another question: does anyway know if there are settings for the overPimpleDyMFoam solver with which you can set where the interpolation of the results on the meshes should be done? I want to set this to as close to the overset boundary as possible, as in my actual test case the cell sizes near that boundary are equal to that of the background mesh.

Kind Regards,


Anouk

[MikeWorth]

I never found a resolution to either this issue, or a separate one that prevented me working using axisymmetry. I changed my model to using AMIs, which worked because the motion between foreground and background mesh was simple and predetermined. In my case a linear motion, although rotating circular motion sounds like it may match your use case.