Cover multiple cuts

[drangara]

Summary

When building the edge types, cover the cut edges that touch opposite regular corners in order to prevent the too many cuts in a face error. Logic is only enabled when flag is set to true in inputs file (default is false).

Additional background

When trying to resolve complex geometries with sharp edges one can run into cases where there are multiple EB cuts on a face. In this change, when the flag cover_multiple_cuts is set, we cover appropriate edges in order to avoid this error. Manually tested geometry generation on some complex geometries that were previously failing to resolve.

Checklist

The proposed changes:

• fix a bug or incorrect behavior in AMReX
• add new capabilities to AMReX
• changes answers in the test suite to more than roundoff level
• are likely to significantly affect the results of downstream AMReX users
• are described in the proposed changes to the AMReX documentation, if appropriate

[drummerdoc]

Can someone add a simple graphic to illustrate the target cases?

[WeiqunZhang]

I think you have to launch a separate kernel to do this. The problem is ez(i,j,k-1) may not even have been initialized by another thread yet.

[WeiqunZhang]

I don't think the fix is general enough. But it probably works for some cases.

[WeiqunZhang]

However, it won't affect anyone by default.

[drangara]

Can someone add a simple graphic to illustrate the target cases?

Here's a rough sketch of how I think the edges would get covered (red lines) in this case

[drummerdoc]

thanks for the pic....it help a ton. So, it also reinforced my own confusion. Depending on how one interprets that picture, the cell with 4 red lines completely surrounding it either has 1 fluid cell fragment and 2 boundary fragments or 2 fluid fragments and 1 boundary fragment. In the former, the algorithm to determine the boundary normal breaks down (among other things) and the normal becomes ill-defined. In the latter, the structured grid data structures are unable to represent the fluid fragments at the same index.

I'm confused about the goal of a "fix" for this problem. It would seem that the EB strategy is unable to deal with this situation properly. Can you explain the strategy attempted? Thanks

[asalmgren]

The current default is for the code to abort if it detects multiple cuts. The fix would instead declare the offending cell to be covered and allow the code to proceed.

…

On Thu, Feb 25, 2021 at 3:44 PM Marc Day ***@***.***> wrote: thanks for the pic....it help a ton. So, it also reinforced my own confusion. Depending on how one interprets that picture, the cell with 4 red lines completely surrounding it either has 1 fluid cell fragment and 2 boundary fragments or 2 fluid fragments and 1 boundary fragment. In the former, the algorithm to determine the boundary normal breaks down (among other things) and the normal becomes ill-defined. In the latter, the structured grid data structures are unable to represent the fluid fragments at the same index. I'm confused about the goal of a "fix" for this problem. It would seem that the EB strategy is unable to deal with this situation properly. Can you explain the strategy attempted? Thanks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1810 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACRE6YUPUDOMI4AOHMVNKO3TA3OHRANCNFSM4YC5HM5Q> .

-- Ann Almgren Senior Scientist; CCSE Group Lead

[drangara]

The goal of this "fix" is to try and workaround the amrex::EB2::build_faces: more than 2 cuts not supported assertion while minimizing how much the resulting geometry is messed up from the actual geometry. When trying to define large geometries with various shapes that touch each other (such as chemical looping reactor) I find myself running into this situation more often than not in very small sections while the remaining majority of the geometry is resolved fine. The goal is to allow the user to ignore these cells and hope that the rest of the code runs fine after that. Does that make sense? Thanks

[drummerdoc]

It almost makes sense :). Can you draw (or sketch) a multicut situation and the way it would look to the code if the fix were implemented as suggested? I don't quite understand how a fluid cell that has 2 fragments of solid (i.e. multi-cut) can be tagged as covered (solid) and have that make any sense.

[drangara]

So.. when resolving the example geometry posted above with the fix it looks like this

[drummerdoc]

Ahhh! That looks hard! Thanks for the pic. Much clearer now.

[drangara]

I don't think the fix is general enough. But it probably works for some cases.

Agreed. It's one way to try and cover cuts and hope that it works. No guarantee that it will work for all cases.