In this week’s Volupe blog post we will take look at the combination of overset mesh and adaptive mesh refinement (AMR). My colleague Christoffer wrote a blog post about overset mesh a while back and how it works with refinements for close proximity between static and rotating surfaces [Overset mesh when close proximities occur – VOLUPE Software]. This post will instead look specifically which settings we have to work with when using AMR and overset mesh combined. We wish to make sure that the refined zone is large enough to resolve the mesh in both the background and overset mesh regions, allowing for acceptor and donor cells on either region to be of a similar size.

The reason for this post is based on a support case we have received where the refinement and the moving overset mesh region end up out of sync. Looking a bit deeper into this we found that this offset is hard to get rid of, but we have some tips and tricks on how to handle this issue summarized in this post.

Example case with a falling hollow cylinder

To be able to understand the issue we are talking about here, a dummy case is defined. The case involves a hollow cylinder moving downwards in a hollow overset mesh region (seen in the left picture). The center picture shows the background mesh (a trim mesh) with the overlay of the overset mesh region (a mesh with polyhedral cells). The picture shows the mesh before initialization, hence also before the refinement. The rightmost picture shows the initialized mesh and hence also the first result of the refinement.

In this case, the adaptive mesh refinement criteria are based on the overset mesh refinement. Only after creating at least one overset mesh interface, it is possible to select the overset mesh refinement criteria. As the center picture above shows, the background mesh is much coarser than the mesh in the overset region, hence, to improve the interpolation of the overset interface the AMR is used to keep the cell sizes similar.

The picture below shows the model selection for the case. We rely on one level of refinement, meaning that our refined trim cells only split up into a maximum of eight cells. Splitting one cell into eight means that the cells size will be half the size in every direction, since 2 to the power of 3 is eight.

N.B. The case is a strict dummy case with the physics frozen. It is only the Implicit Unsteady solver, Adaptive mesh solver, and rigid body motion solver that is updated during the iterations.

The problem – Offset in AMR

Looking at the mesh after the first timestep for this geometry, when the timestep is updated and all inner iterations have been iterated, we can already see the issue happening when combining AMR with overset mesh. The picture below shows the progression from initialization of the overset mesh through three consecutive timesteps. Already in the first timestep there is an offset introduced between the overset region and the refined background mesh, making the refinement seemingly useless here as the refinement is there to ease the interpolation of the overset interface and the background mesh.

It can be argued here that the movement happens too fast for the time step, you are generally not recommended to move cells where interpolation occurs more than one full cell-size. Nonetheless, if you reduce the timestep the problem actually still persists, although it becomes less and less apparent (and less relevant also) as the refinement for all intents and purposes is still aligned with the overset region.

Let us look at another example, where the timestep is ramped, aiming for the refinement zone to never fall behind. Small incremental increases of the timestep size will stop the problem, right?

Wrong! We can see in the animation that initially, when the timesteps are small, the background refinement follows nicely. But as soon as the size of the timestep becomes too large, the refinement zone falls behind. What is even more interesting is that near the end of the animation, the timestep is again reduced to smaller (initial) sizes and the refinement zone then finds its way back, once again matching the overset region.

It seems like the update of the refinement zones happens after each timestep, and their location is based on where the overset mesh was located in the previous timestep. Again, this is not a problem with small movements, or small timesteps, but this causes a limitation in how aggressively you can advance in your simulation.

The alternative solution (to a reduced timestep)

We have identified a problem, and I would not post this if I did not have a solution or workaround in mind (other than the more obvious solution to lower your time step, which we recommend you to do). If you still choose to move with a higher relative motion in each timestep than the background mesh refinement can follow, you can change the expert setting of “interface refinement width”, located under the selected overset mesh refinement criteria. This way the refinement zone is increased, and the larger movement is buffered by the increased refinement width.

Even at the highest timestep we had looked at previously, the whole overset region is still located inside the refinement, and interpolation should be fine. The value of 10 is clearly much larger than necessary but is used for emphasis. The left picture shows the initialization and right one the position after one timestep.

Another option you have to work with, if you allow for several refinement levels, is to work with the width of individual refinement levels. Again, starting with an Interface refinement width of 2, we have increased the Max refinement level to 2 and start with the setting of Transition width equal to 2. So instead of working with settings for the full refinement zone, we impact the size of the zone by increasing the size of each individual level.

The below picture shows the result when changing the interface refinement width from 1 to 10, making sure that the width of the smallest refinement level is kept big enough to make sure the overset region stays inside the refinement almost regardless of the movement.

I hope this has been useful for you, when dealing with overset mesh motion together with AMR. As usual, if you have questions, you are welcome to reach out to support@volupe.com.

Author

Robin Victor
+46731473121
support@volupe.com