# Insert a boundary condition without removing periodicity assumption

I've to perform a multi-fluid internal flow simulation with a code which intrinsically assumes periodicity on a given direction (say z) on a cartesian grid. Nonetheless, the problem I'm trying to solve does not involve this kind of condition, in fact the fluids are running out from the computed domain through the two z extreme edges (one of them at sonic speed, the other at almost sonic speed) after being generated inside it from a given constant source. The simulation evolves the two fluids profiles up to a quasi-stationary state, when it is stopped.

Due to the code structure, I can't change the coordinate set (hence, I need to keep z as the direction on which the two fluids are getting out of the computed domain). I was then trying to figure out a way to solve this problem without removing the periodicity assumption, which would require a painful amount of coding. I thought of adding a penalized buffer layer at both z direction extremes on which I could impose the boundary conditions I need.

The problem is I must have Dirichlet BCs for velocities, and homogeneous Neumann BCs for fluids density at z extremes, and this would lead to a constant accumulation of the two fluids in this buffer layer, which will at least give some troubles to reach a quasi-stationary state for the simulation to end. I thought of adding a densities sink inside this buffer layer for this reason but I'm not sure about how this could impact the simulation inside the "real" computed domain (since one of the two fluids is not actually flowing at sonic speed).

Hence my questions are:

• how do you think the densities sink inside the buffer layer would influence the simulation inside the "real" computed domain?
• do you have any other idea to deal with this problem?

Thanks a lot in advance to anyone who will pay attention to this.

• Can't you rotate your system? That is, use $x$ or $y$ coordinates for your required boundary conditions. May 2 at 18:56
• Why would you want to go to such extreme measures to use a code that doesn't fit what you want to do with it? Surely there is a better use of your time... May 2 at 23:35
• Thanks for your feedback! @nicoguaro Unfortunately no, as I've said before (for other reasons) I need to keep the coordinate system in this way. May 3 at 6:34
• @WolfgangBangerth thank you too. I agree, but actually this is a master thesis project. The code has other properties which motivate the interest in trying to apply it to our problem (it is actually a plasma turbulence code). May 3 at 6:37