Specification of flow-field variables for bcnormal - s_int and s_ext

[SRkumar97]

Hello!
I am trying to setup a case in which the left side of the domain is an inlet with the Hard type BC. Here, I wish to specify the primitive flow-field variables in the body of the bcnormal() function in prob.H
But it is not clear how I should assign and store the flow-field variables. I see that cases such as EB-BluffBody and EB-FlowPastCylinder cases use the s_ext state is used to store the primitive variables at the boundary of interest.
E.g.
s_ext[URHO] = prob_parm.rho;
s_ext[UMX] = prob_parm.rho * prob_parm.vx_in;
s_ext[UMY] = prob_parm.rho * prob_parm.vy_in;
s_ext[UMZ] = 0.0;
s_ext[UEINT] = prob_parm.rho * prob_parm.eint;

Whereas, in some cases the s_int (or) s_inter state is also declared within the body of bcnormal() function and values are specified for this s_int state
e.g. this is from MultiSpecSod inclined shock tube problem
for (int n = 0; n < NVAR; n++) {
s_ext[n] = s_int[n];

I tried to infer from the description provided in the BCs page (https://amrex-combustion.github.io/PeleC/BoundaryConditions.html) but there is very little info on s_int vs s_ext

The usage and relevance of these two states are very confusing, can someone please help? I just want to declare all my primitive variables for the left inlet boundary.

Thanks in advance!

[dmontgomeryNREL]

PeleC is a cell-centered FVM solver that utilizes ghost cells outside of the domain to determine values at the boundary. s_int represents the interior cell center closest to the boundary while s_ext is the exterior ghost cell. When using a Hard coded boundary condition, you must define the value of the ghost cell, s_ext.

In the code you quoted, s_ext[UMX] = prob_parm.rho * prob_parm.vx_in, is an inlet boundary condition for the x-component of momentum. This sets the ghost cell equal to the interior cell, which assumes that the inlet flow is constant from the ghost cell to the interior cell.

See chapter 8 of Blazek's book Computational Fluid Dynamics: Principles and Applications for more information about the outflow conditions used in the EB-FlowPastCylinder case.

[SRkumar97]

Thank you so much!

[SRkumar97]

Hi, I want to clarify a bit further. You've mentioned that when using Hard coded BC, the exterior ghost cell state s_ext should be defined. Now, in my case, I want to specify flow field variables exactly at the left boundary face; want the code to ensure that whatever I am specifying in the ghost cell state s_ext, is applied onto the boundary face at x-plane, (say) my inlet (idir=0 and sgn=1). Because my main intent is to specify certain pre-computed values of flow field variables at the boundary face, throughout the calculation.
How to got about this? Currently I'm only specifying s_ext with my pre-computed values; but as calculation proceeds I'm observing that my corresponding regions of the boundary plane do not show up the values I've specified in the s_ext.

[himcraft]

@SRkumar97 If you have pre-computed values on the boundary face, you need to extrapolate them to the ghost cells through s_ext. As Dave Montgomery mentioned above, the function bcnormal function of EB-FlowPastCylinder case inplemented this extrapolation procedure by assigning values of s_ext from point d (interior cell value) and point b (boundary face value). For the inlet boundary in your case, just extrapolate towards the left.

If your pre-computed values change with time, also need to include the temporal argument in your implementation.

[SRkumar97]

Actually this is what already I did in the bcnormal() function in prob.H, corresponding to my inflow boundary at the left side of domain. My BC is time-invariant. But despite setting s_ext array correctly and the eos, my values at the inflow boundary showed completely different values. I finally found out that this problem was more to do with the Chemistry model/Gas Law and the numerical scheme [ppm]. I just sorted it out some time back, by changing my Gas law to Gamma Law, which is the ideal gas law for standard air and updated scheme to ppm. Thanks a ton, @himcraft @dmontgomeryNREL !