[standingVortex]

Hello everyone!

I am working on an atmospheric flow problem on a rather simple three-dimensional domain (essentially a cube). The grid is completely structured, populated with hexes and it has the uniform distribution in horizontal xy plane, while there is some stretching along the vertical xz.

In the present case, the bottom is treated as the wall boundary (ground), the 4 lateral sides are considered as the outlet, while the top boundary is the tricky part. Essentially, at the top domain boundary there is a circular region which is associated with the inlet velocity condition. However, this circular inlet region moves during the simulation, i.e. translates with the constant velocity and direction.

So far, I have performed the URANS simulation by applying the timeVaryingMappedFixedValue boundary condition at the entire top domain boundary by specifying the corresponding input data in the constant/boundaryData folder. These are: i) file points, obtained through surface sampling of the top boundary, and ii) a number of time folders with the associated U files. In such a way, I managed to successfully associate the desired location of the inflow faces with their corresponding velocity at the top boundary throughout the simulation.
However, while preparing the constant/boundaryData/<timeInstance>/U files, the "non-inflow" faces at the top boundary were treated with (0 0 0), resulting in the no-slip condition. Such condition is unfortunately not acceptable, as I would rather prefer to treat these non-inflow faces at the top boundary separately as the outlet patch.

In its final stage, the case will also include the complex terrain and structures in the domain, while it is planned to also perform the Large Eddy Simulations. The initial idea was to use the turbulentDFSEMInlet which also allows for the same boundaryData mapping as done with the URANS simulation. I tried that as well, but experienced non-physical velocity field near the top boundary.

Based on the presented case specifics, I would argue that a sort of inlet patch translation, or dynamic change of patch topology would be necessary. I was also considering the application of overset/dynamic meshes, but unfortunately I have no experience whatsoever with these approaches. Hence, I an not sure would that be the answer. Moreover, I am unsure is it even possible to just dynamically change the faces associated with the patch without actually morphing the mesh, as I would prefer to keep my grid as it is.

Long story short: I would like to find a way to have two separate patches at the top boundary while both of them change faces which compose these patches due to the translation of the (circular) inlet patch. Or any alternative approach that would allow me to specify two distinct boundary conditions (Dirichlet and Neumann) on changing set of cells of the top boundary as a function of time.

I would really appreciate hearing your opinion and suggestions.
Thank you very much.

[standingVortex]

Hello everyone,

Just a quick update. I tried with the overset meshes approach, but I am still having an issue. I imposed the inlet condition at the component mesh (basically a cylinder), and assigned accordingly the cell zones and zoneID to the moving zone (where my inlet is located) and the background zone. I have used the solidBodyMotionFunction linearMotion in dynamicMeshDict to define the velocity of the moving region.

Although everything seems fine to me in the setup, the simulation crashes in the very first iteration meaning I must be doing something fundamentally wrong in the setup.

I tried also translating the component mesh a bit in the vertical direction so that the inlet (at the component mesh) and top of the background mesh are not anymore in the same plane. It didn't help, and simulation crashes again. The solver in both cases reported huge amount of hole cells, which I should not have since I don't have wall in the component mesh. Actually I would expect ZERO hole cells.

My concerns are therefore the following:
1) is it possible to have inlet condition at the moving component mesh in the currently implemented overset meshes framework in OpenFOAM v2212?
2) Does the overset approach allow for the interpolation between two grids if there are no walls in the component mesh to give these hole cells?

Please also find some figures enclosed to better illustrate the case.
I would really appreciate experienced users of overset meshes to share a bit of their wisdom. Thank you very much.