Variable boundary conditions on embedded boundaries

[asmunder]

Opening an issue to discuss inhomogeneous boundary conditions on the embedded boundaries, as suggested by @drummerdoc . This might be implemented in PeleLM by @esclapez first (https://github.com/AMReX-Combustion/PeleLM/issues/157) and then taken up into PeleC.

In principle there are two cases - one that is simple to implement, one that is more general:

1. varying wall temperature, possibly Neumann on some regions.
2. ability to set all components of the state on different regions. You could have an inlet jet on this part, varying temperature on this other part, injecting fuel over here, etc. In principle arbitrarily complicated.

For case 1 I have something that seems to be working, which I'll describe in the next comment. For case 2 I will leave it up for discussion.

[asmunder]

Case 1.

During initialization of PeleC, the temperature on the boundary is set to a uniform value in a sparse data structure of type EBBndrySten, in the following piece of code that is the same in Source/PeleC_init_eb.cpp or SourceCpp/InitEB.cpp:

  if (eb_isothermal && (diffuse_temp != 0 || diffuse_enth != 0)) {
      sv_eb_bcval[iLocal].setVal(eb_boundary_T, QTEMP);
  }

Replacing that code with the following will set the boundary temperature to be varying as a function of space. The USER_DEFINED_TEMPERATURE function here takes x,y,z as arguments and returns temperature for the specific case. There should be a generic version of this function that just returns eb_boundary_T, and the user could modify that as wanted.

• Where is a logical place to put the USER_DEFINED_TEMPERATURE function?

  if (eb_isothermal && (diffuse_temp != 0 || diffuse_enth != 0)) { int ivec = 0; Real dx = geom.CellSize(0); Real bcx, bcy, bcz; for (auto& sv_ebg : sv_eb_bndry_geom[iLocal]) { const IntVect& iv = sv_ebg.iv; bcx = geom.ProbLo()[0] + iv[0]dx; bcy = geom.ProbLo()[1] + iv[1]dx; bcz = geom.ProbLo()[2] + iv[2]*dx; sv_eb_bcvaliLocal = USER_DEFINED_TEMPERATURE(bcx, bcy, bcz); ivec++; } }

Caveats with the above code: For some reason I am not able to use sv_ebg.eb_centroid[0] etc. since that only returns zeros in my testing. That would not only be cleaner code, but also one can imagine more pathological cases where the difference between the cell centroid and the EB face centroid are important to distinguish.

I am also not able to iterate over sv_eb_bcval[iLocal] itself, so I have to do this manual indexing with ivec. But even if I were able to do that, this data structure does not contain the EB face centroid coordinates, cf. the previous paragraph.

Mixed Dirichlet/Neumann temperature boundary conditions: It was mentioned by @drummerdoc that it could be possible to set the thermal conductivity to zero on some regions of the boundary, to have that region behave as if adiabatic, which would be a neat thing to have.

This is not exposed (as far as I can see) anywhere in Source/PeleC_init_eb.cpp and SourceCpp/InitEB.cpp, but the relevant code is in Source/PeleC_MOL.cpp and SourceCpp/Diffusion.cpp where it calls pc_apply_eb_boundry_flux_stencil using the values that the code above has set during init.

From the user perspective, a hacky but simple way of specifying Neumann on parts of the boundary would be to set the appropriate temperature as above for the Dirichlet regions, but set negative values in the regions Neumann is desired. Then in Diffusion.cpp one would loop through the boundary values for temperature, check for negatives, and in those cells one would zero out the thermal conductivity.

I don't know whether that is doable, or if there is a chance this negative temperature gets used in some thermo routine that throws a fit? In that case it might be enough to make a copy of the sv_eb_bcval data structure where one applies the absolute value operator before it gets passed into the pc_apply_eb_boundry_flux_stencil routine?

[RSuryaNarayan]

Hello everyone,

I am curious if other boundary conditions on EBs (like localized fuel injection from a boundary of an EB, like a jet or so) can be implemented as suggested here. I tried doing the injection from the EB case using other “Q” variables like QFS, QPRES, and QU on the EB-surface in InitEB.cpp however this doesn’t seem to give the required effect. Upon digging I find that QU is simply the tangential velocity component that is being set to zero in the InitEB.cpp file. Two questions hence:

1. Is there a way of accessing state variables anywhere in the domain at any timestep to set the injection more like a spatial BC rather than a BC on the EB due to the limited access to variables that we have on an EB surface (just thinking aloud).
2. If no, what would an ideal way be to set the normal velocity and species boundary condition on an EB surface? Thanks a lot!

[drummerdoc]

I am working on a strategy for this, but its is a bit tricky to design. First off, the code currently requests boundary conditions in terms of the (conserved) state variables, rather than the primitive variables directly. However, it certainly is the case the actual BC's are typically known, and applied numerically, in terms of the primitive variables. So, for the time being, the user will have to convert - I have created some functions to convert back and forth as part of a PR I'm working on.

The hard design problem though is providing a coordinate system along the EB that can be used to specify where on the boundary to apply things like jets, etc, and within the jet, specifying the shape/extents. Sometimes, the problem is such that one can use the global coordinates to do this, but not always. It would be much better if there was a way to specify a location on the EB and a local orientation of surface coordinates. For example, in Åsmund's example, being able to specify a linear temperature variation along the surface would require a reference location, and a direction along which one could specify a slope. I haven't come up with a strategy yet, and am open to ideas, or even just clear descriptions of use cases that can help flesh out a workable design.

[marchdf]

Hi all, someone asked me today about setting bc vals. I had some code hacked together that kind of did that so I made a draft PR (linked above). I don't know how it fits in the whole discussion above but maybe it helps to have some code to look at and improve.