[jcapriot]

Refine surface currently handles horizontal padding by scaling the input point clouds about its middle point from the bounding box. This causes an inconsistency because the refining surface does not explicitly honor the input points (it's a scaled and potentially shifted version of it). This can usually be accounted for with appropriate z-padding as the z refinement ends up enveloping the intended surface anyways, but without it, the cells might not even be refined where the user intended...

This changes how the horizontal padding happens, consistent with a nearest neighbor extrapolation of the triangulation of the point cloud, outwards. It does so by adding extra points away from each node along the boundary, in the direction of it's outward bisector. Making this much more consistent with the intuitive operations.

There is a bit of consistency so that corners extend outward a distance beyond the requested extension, but in such a way that it is consistent with the extensions on either side of it. Think a diagonal extension of a square's corner vs the extension out from its side. This is also bounded so that sharp corners don't end up blowing it out.

The only caveat is that it works best under convex hull triangulations (which is the most common case). Triangulations without convex boundaries are very rare, and the assumption would be that users who have those types of triangulations, should know how to handle them. This is warned about in the docstrings of the function though.

[codecov]

Codecov Report

❌ Patch coverage is 97.74011% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.15%. Comparing base (30d8531) to head (e8c3081).

Files with missing lines	Patch %	Lines
discretize/utils/mesh_utils.py	94.20%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #422      +/-   ##
==========================================
+ Coverage   87.06%   87.15%   +0.08%     
==========================================
  Files          93       93              
  Lines       19348    19498     +150     
  Branches     2157     2172      +15     
==========================================
+ Hits        16846    16993     +147     
- Misses       1814     1816       +2     
- Partials      688      689       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jcapriot]

Here's a few images detail the current behavior, and why it might be unexpected.

[santisoler]

Looks good! I like the new behavior much more than the previous one. It's way more intuitive and closely related to what I would expect from those refinements.

One thing I could see from your example plots is that passing the same arguments for the refinement, the new approach much generate more cells. Have you experimented with some of the EM forwards to see if tweaking those arguments to produce roughly the same number of cells still achieves good accuracy?

Just being curious. I think we should move forward with this PR.

[jcapriot]

Awesome, I'll get this merged in to main and we can start working on the next release for discretize.

I'm not sure if it generates more (or less) cells in general, especially for the common convex boundary cases. But it should be something to investigate on a case-by-case basis. Like I said before, when there was vertical padding along with horizontal padding, this issue was mostly masked, and I think that is the much more common route in the EM related refinements. I could see it affecting potential fields more though, where you don't necessarily need to refine away from the surface vertically just to get better simulation results. Indeed, in these cases you might be able to get away with less cells because you don't need the vertical enclosure anymore.