Turbulent perturbation

[indra098124]

Following this discussion (AMReX-Codes/amrex#3775), I am trying to map the flow field from one PeleC simulation to another. The simulation domain from where the data is interpolated to the inlet uses periodicity in z but has EB in other direction (a channel flow for e.g.). May I confirm that turbInflow should work for this scenario?

[indra098124]

This is the data I want to map in my toy problem

And this is what I am getting in the main simulation at the inlet when I use EB (which is a box of [-1,1])

the velocity is zero in the covered cell, which is fine but the interpolated data at the inlet did not come correct.

I repeated the above without EB and this is what I get.

velocity distribution is slightly shifted towards -x and +y. Is this expected? Do you have any suggestion to avoid this?

[baperry2]

The first thing to note is that the PeleC turbinflow capability only supports mapping the 3 components of velocity, so you would have to make some modifications within PeleC/PelePhysics to be able to map additional variables as you ask about in that AMReX issue.

If you only care about mapping the three components of velocity, then I believe the turbinflow generated using that AMReX utility should be compatible with PeleC, which uses the implementation in PelePhysics that derives from what was in LM/IAMR, although @drummerdoc might know better.

Using the turbinflow capability that was generated in a domain with EB is an off-label usage and there definitely may be issues to iron out to get it to work. For example, the interpolation of the turbinflow data isn't aware of EB in the generation, and could end up using covered cell data in the interpolation. I'm hypothesizing that this may partially but not fully explain what you are seeing.

It looks like your simulation domain is coarser than the initial simulation used to generate the turbinflow. What does it look like if both are on the same grid (this shouldn't be a requirement, but it could help reveal what's going on)?

[indra098124]

@baperry2 thank you for explaining. Yes, I was able to add in additional components. I tried using the same resolution, other than the shift (I understand it now), there are some discrepancies on the left and the right end. It might be coming from EB as you mentioned.

[drummerdoc]

When you look at the HDR file that is created for the turbulence, what does it think the size of the domain is in all three directions? In the BC-tangential directions, it should be 2 + 3.dx, where dx is the mesh spacing of the data that you are using to generate the turbulence. In the direction normal to the BC (usually z), the file should think the domain is 2 + dx.

Aside from that, there should be a shift of dx/2 and dy/2 in the data you see coming in because the incoming data starts as cell-centered but is treated by the interpolator algorithm as node-centered. This shift should be "periodically-correct", in that the original source data was padded with periodic filling, but it will be shifted in both tangential directions the same way. If you don't want this behavior, you'll need to fix things in many places unfortunately.

[drummerdoc]

Let me try to explain that shifting better...
If I had node-centered data across the x-dimension of a domain, spaced at dx=1, over a domain with 16 cells on the side. I would put the i=0 node at the left wall, and the i=16 node at the right wall. If I needed one extra node on either side of the domain to allow the ability to construct a centered parabolic interpolator to fill data right up to the domain edges, I'd need data from -1 to 17. Now, say that I'm getting that data from a cell-centered source, where the left side of the i=0 cell would hit the left side of the domain and the right side of the i=15 cell would hit the right side of the domain. I could fill 1 cell-centered grow cell on the left (to i=-1) and two on the right (to i=17) such that the data in cell-centered slots (-1,0,1) would be identical to the data in slots (15,16,17). If I read in the 19 values (written from CC data) into a NC container, I will get node data with the correct periodicity for a well behaved periodically-correct interpolation. The downside is that my interpolated data will be shifted to the left by dx/2.

[drummerdoc]

This is all a remnant of something done probably 20 years ago. Admittedly, we should someday change all this to actually be based on cell-centered data being interpreted as such so that we can exactly recover data if pushed in on the same grid. However, between the mappings, and shifting, and planes in memory, and refinement ratios, etc, there are many places to get this wrong...not to mention the usual "backward compatibility" problem one is always faced with when fundamentally changing such things. So, for now, this is how this particular code does this. I apologize for the confusion all this causes.

[indra098124]

Thanks a lot @drummerdoc for explaining. It all makes sense. If I understand correctly, then it is also the reason why the interpolated data is not symmetric about the x and y axis because due to EB boundary and the shift, the interpolation will be in error.