Enforcing inflow-outflow boundary solvability

[mukul1992]

Introduces routines to calculate outflux and influx at the in-out boundaries and then correct the outflux to match with influx.

Three steps:

1. set masks for tagging cells at the boundary for inflow or outflow
2. calculate influx and outflux using reductions
3. correct outflow velocities using the correction factor

[mukul1992]

Hello @cgilet @ajnonaka
Ann asked me to ping you for reviewing this PR. Could you please take a look? I'd appreciate it.

We are adding a "mass-inflow-outflow" BC in amr-wind that can manage both inflow and outflow cells within the same boundary. The strategy is to scale the outflow to match with the inflow to enforce solvability and then use Neumann conditions for the MAC/nodal projections. The functions here aim to achieve the "outflow-correction" part.

I think the only thing currently missing is the accompanying documentation. I am figuring out how to work well with the rst files on my computer. Meanwhile I'm attaching a screenshot of the implementation. While the language here is for the MAC-projection, the function is expected to handle both cell-centered and face-centered velocities.

[cgilet]

Since this is the only change in this file, is this necessary?

[mukul1992]

oops, thanks for pointing that out, I've removed it.

(I had earlier put the outflow-correction routine in this file.)

[cgilet]

Since the in_mask is the opposite of out_mask, why is it necessary to have two separate masks?

[mukul1992]

Oh that's a good point! For instance, I could have a value of -1 for inflow and +1 for outflow as these masks are integers and not boolean and then use those values for the if conditions in the reduction.

Thanks, I'll try this out and let you know when I've implemented it.

[mukul1992]

I have now implemented a single in/out mask that sets to -1 for inflow, +1 for outflow, and 0 for interior cells.

See: 6d567d5

[asalmgren]

Or you can still treat them like bools so have in_mask be 1 if inflow and 0 if outflow ...

…

On Tue, Jul 2, 2024 at 10:57 AM Mukul Dave ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In Utils/hydro_enforce_inout_solvability.cpp <#129 (comment)> : > + + // create a 2D box normal to dir at the low/high bndry + Box box2d(box); box2d.setRange(dir, bndry); + + auto vel_arr = vel_mf->array(mfi); + auto in_mask = inflow_mask.array(mfi); + auto out_mask = outflow_mask.array(mfi); + + // tag cells as inflow or outflow by checking vel direction + ParallelFor(box2d, [=] AMREX_GPU_DEVICE (int i, int j, int k) + { + if ((side == Orientation::low && vel_arr(i,j,k) >= 0) + || (side == Orientation::high && vel_arr(i,j,k) <= 0)) { + in_mask(i,j,k) = 1; + } else { + out_mask(i,j,k) = 1; Oh that's a good point! For instance, I could have a value of -1 for inflow and +1 for outflow as these masks are integers and not boolean and then use those values for the if conditions in the reduction. Thanks, I'll try this out and let you know when I've implemented it. — Reply to this email directly, view it on GitHub <#129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACRE6YSKJWHYXQ5GUTCIHBTZKLSW5AVCNFSM6AAAAABI7BK7QCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCNJUGUYTQMZYGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Ann Almgren Senior Scientist; Dept. Head, Applied Mathematics Pronouns: she/her/hers

[mukul1992]

Or you can still treat them like bools so have in_mask be 1 if inflow and 0 if outflow ...

I think that wouldn't work because for the reduction, I also need to differentiate between the interior and boundary cells as the reduction loops over everything. So 0 would be for interior cells and -1, 1 can be for in/outflow. Let me know if there is a better way to do the reduction, we could disucss it tomorrow morning.

[cgilet]

When I first saw "direction_dependent", it wasn't clear to me what this meant. The rest of the BCTypes are mathematical BCs. Why is "direction_dependent" the mathematical BC here instead of "mixed" or "Robin"?

[WeiqunZhang]

We could remove it from amrex::BCType and use user_*.

[WeiqunZhang]

mixed might be okay too. But What mixed means is likely user dependent, whereas other types (e.g., reflect_odd, foextrap, etc.) are clear on what they mean and AMReX can fill them for the user.

[mukul1992]

We added this math BC type in AMReX (AMReX-Codes/amrex#3965) where the cells are to be treated differently based on in/out flow. Perhaps @asalmgren could comment on the naming.

[WeiqunZhang]

To amrex, that's a user type that it does not know how to handle.

[WeiqunZhang]

On the user side, the user could define auto my_preferred_name = amrex::BCType::user_1;.

[mukul1992]

I think the reason for adding a special math type rather than just using user_1 was so that it can be used consistently across dependent codes, say, amr-wind and amrex-hydro, and so it does not conflict with other custom types that may be added in the future.

[WeiqunZhang]

amr-wind uses amrex-hydro. So it could use the types defined in amrex-hydro. (If it does not use amrex-hydro, then it probably does not matter.)

[cgilet]

If this is meant to be used with both the Nodal and MAC projections, then since the BC types for those linops differ and I don't think that can be used for this purpose.

If this could be used more generally, in additional application codes, then maybe instead of having the BCRec it could be something more like a flag that indicates whether to include the face in the sum or not?

[mukul1992]

I have now added a description to the sphinx docs.