Gap automeshing

[dbochkov-flexcompute]

Integrated gap meshing in an iterative way. Now LayerRefinementSpec has two additional parameters:

• gap_meshing_iters: NonNegativeInt = 1 to set the number of iteration to perform for attempting resolving all gaps
• dl_min_from_gap_width: bool = True whether or not to reduce dl_min reduce to the minimal detected gap width.

A few of points to discuss:

• Doing just one iterations seems to be performing quite well, so that could be a good default. But maybe we should switch to a higher number and just let it iterate until no multiple crossings are detected in a single cell?
• Currently it does not distinguish between thin gaps and thin strips. Do we want to control mesher behavior for the two types
• while we use snapping planes for achieving the desired result, we currently do not store them, and, as a consequence, we cannot plot them. Should we worry about that?

examples of meshing thin strips and gaps:

[dbochkov-flexcompute]

one more point:

• currently we also take into account all structures. Should we worry about making it work for a selected set of structures in this PR?

[weiliangjin2021]

Thanks for this great feature!

Doing just one iterations seems to be performing quite well, so that could be a good default. But maybe we should switch to a higher number and just let it iterate until no multiple crossings are detected in a single cell?

Agree that we can set 1 as default if ti works quite well already. Then we can add an option like inf or a string to indicate it will iterate until no crossings are detected?

Currently it does not distinguish between thin gaps and thin strips. Do we want to control mesher behavior for the two types

Right now, we don't have good conformal scheme for thin strips, so probably no need right now.

while we use snapping planes for achieving the desired result, we currently do not store them, and, as a consequence, we cannot plot them. Should we worry about that?

Not too concerned, but I wonder that it's not hard to store them?

currently we also take into account all structures. Should we worry about making it work for a selected set of structures in this PR?

My understanding is that metallic structures are more of a concern. So we probably only need to distinguish between metallic (PEC, lossyMetal) and dielectric.

[weiliangjin2021]

Half way through the code. Looks quite nice, although taking quite a bit efforts in understanding the logic. Some high-level description in each function will be very helpful. Some minor comments so far:

[dbochkov-flexcompute]

sprinkled around some more comments in the code, had to recall myself what I was doing 😅

[dmarek-flex]

Another great feature! I found a couple of small things in the associated comments. The only real sticking point for me is that it would be nice to get a symmetric grid, when the structure itself is symmetric.

I think it came up in the meeting and maybe there is no easy solution. But for the structure below it seems to always give an asymmetric grid. I thought maybe part of the reason could be due to how intersections are found with grid boundaries, which does not make use of a tolerance. The grid boundary and the polygon vertex might be very close.

And here is the original grid without gap refinement. (setting gap_meshing_iters=0)

[dbochkov-flexcompute]

should be all addressed now. Some notable changes:

• Regarding @dmarek-flex point on doing this with some tolerance allowance, I implemented the following: intersections that are very close to cell boundaries are duplicated to the neighboring edges across those boundaries. That is, if we have a PEC boundary segment passing through a grid node (up to some tolerance) , we consider that this segment crosses both edges around this grid node. This seems to nicely improve the quality of resolving gaps and strips. Here's the circularly polarized antenna with base resolutions 6 (needed 2 iterations), 10, 15, and 20

• Additionally, now I also explicitly filter out intersections that happen due to very small features slightly protruding into cells. This prevents dl_min from becoming unreasonably small. If we do want to resolve such feature in certain cases, it can be done by turning on convex_resolution in CornerFinderSpec
• Changed the strategy of how snapping points are generated: previously, I would create only 1 snapping line per problematic grid spacing. Now, for a given column (or row) of cells, I look for the one with max number of found intersections and create (num_intersections - 1) snapping points to resolve all gaps/stripes with one go. This seems to reduce the total number of iteration to converge the grid.

[weiliangjin2021]

Code looks good! Just one part not fully understand: how re-entering subcell features are filtered. Could you provide some visual explanations?

[dmarek-flex]

Everything looks pretty good! Just one improvement for code coverage, and friendly reminder for Changelog.

Also I tried another notebook with the gap meshing. WidebandBeamSteerableReflectarrayWithPRUC.zip

I assumed it would place snapping lines in the gap between simulation boundary and the arrows. Instead it gives:

And when I use many more iterations:

Is this expected?

[dbochkov-flexcompute]

Is this expected?

yeah, currently it ignores boundary conditions. I should add that. In this example, it's periodic I assume? I think need to add for PEC and PMC boundary conditions as well

[dmarek-flex]

Is this expected?

yeah, currently it ignores boundary conditions. I should add that. In this example, it's periodic I assume? I think need to add for PEC and PMC boundary conditions as well

yea periodic

[dbochkov-flexcompute]

Is this expected?

yeah, currently it ignores boundary conditions. I should add that. In this example, it's periodic I assume? I think need to add for PEC and PMC boundary conditions as well

yea periodic

Actually, just realized, that even with proper boundary treatment there won't be any additional grid lines in this example. Because the edges across periodic sides are already separated by a grid line (=simulation domain edge)

[dbochkov-flexcompute]

Code looks good! Just one part not fully understand: how re-entering subcell features are filtered. Could you provide some visual explanations?

@weiliangjin2021 Damian's case is a good example of that: note those sharp corners that cross the same grid segment before crossing anything else, this is what I call a small re-entry feature.

When we look for intersections between PEC polygons and grid lines, we go around the polygon's perimeter one segment after another. So, when such a small feature intersects the same edge twice, the array that stores indices of intersected cells will have two consecutive elements with the same value. Such elements are removed from array of intesections.

Btw, in Damian's comment above these small features were still resolved after two iterations 😅, but I already found a bag, and now grid stay the same after the first iteration

[dbochkov-flexcompute]

Should be ready to go. This is how it works now for boundaries:

• refine is PEC or PMC
  

• no refine if periodic and separated

• refine if periodic and no gap on one side
  

[dmarek-flex]

Great I think its ready, thanks for handling BCs!