Have ContactFormulation-derived classes own search by ebchin · Pull Request #276 · llnl/Tribol

ebchin · 2026-10-26T16:07:43Z

This PR moves coarse search and formulation-specific candidate filtering into ContactFormulation-derived classes.

The formulation factory constructs and injects owned CoarseSearch and RefinedSearch strategies.
Formulation operations receive current mesh views, and Energy Mortar finds candidate pairs for each gap or force calculation rather than retaining mesh views or a fixed pair list.
ProjectedEdgeSearch refines two-dimensional linear-edge candidates by rejecting exact self-pairs, optionally rejecting shared-node pairs, and requiring nondegenerate edge normals separated by at least 90 degrees. It leaves projected-overlap construction to Energy Mortar quadrature generation.
InterfacePairChecks provides the reusable topology and edge-orientation checks without requiring face-data preprocessing.
Search inputs remain unchanged, and refined search returns owned retained candidates in the input allocator for sequential, OpenMP, CUDA, or HIP execution.
Mesh 1 is consistently the non-mortar integration side and mesh 2 is the mortar side, including MFEM field registration and Energy Mortar assembly.
The effective binning proximity scale is computed from the configured scale and current mesh length instead of being cached.
Penalty configuration is applied through the formulation factory rather than a method-specific base-class setter.
Regression coverage includes filtering, ownership, current mesh coordinates, mesh ordering, unequal surface meshes, disjoint projected intervals, and zero-width integration intervals.

Validation: tribol_refined_search and tribol_interface_pair_checks pass with LLVM 19 in Debug with Enzyme. Release validation also covered Energy Mortar penalty/LM patch and finite-difference suites. Sequential and OpenMP execution were exercised; CUDA/HIP remain for CI.

This is the first PR in the replacement stack. Replaces #275.

Move projection configuration and coordinate-only geometry into the search branch. Construct the configured projection once and retain it in ProjectedEdgeSearch, while preserving the existing Energy Mortar interface. Keep projection bounds independent of quadrature storage so downstream quadrature generators can reuse them without introducing a dependency into contact search.

Remove the projection template and configuration from refined edge search, retaining self-pair, shared-node, and opposing-normal checks. Restore its implementation to a source file and remove unused projection strategies from this branch. Treat empty penalty integration intervals as inactive. Cover retained disjoint pairs, current orientation, and zero quadrature contributions in regression tests.

srwopschall

Mostly all good. Per our 3 hour convo today this stuff and the new language we are developing can be confusing. It can also be a little more difficult to review knowing that the design is actively changing PR to PR. A lot of my comments reflect this and ask for more clarity.

srwopschall · 2026-10-27T21:38:49Z

  int mesh1_id = 100;
  int mesh2_id = 101;
-  tribol::registerMfemCouplingScheme( cs_id, mesh1_id, mesh2_id, mesh, coords, mortar_attrs, nonmortar_attrs,
+  tribol::registerMfemCouplingScheme( cs_id, mesh1_id, mesh2_id, mesh, coords, nonmortar_attrs, mortar_attrs,


Does this need a helpful comment about mesh id ordering?

Yes, added. Renamed meshes to mortar/nonmortar.

srwopschall · 2026-10-27T21:41:04Z

+  }
+}
+
+TEST( InterfacePairChecks, rejects_degenerate_projection_edges )


Verify any test that relies on that old projection bounds check in 2d is removed or updated.

srwopschall · 2026-10-27T21:42:20Z

+ * @file
+ * @brief Test how ProjectedEdgeSearch filters candidate pairs and returns the accepted pairs.
+ *
+ * These tests check that filtering keeps only accepted pairs, leaves the input unchanged, and returns a separate array.


clarify what "filtering" means exactly here.

Clarified what filtering removes and returns

srwopschall · 2026-10-27T21:43:08Z

+ * @brief Test how ProjectedEdgeSearch filters candidate pairs and returns the accepted pairs.
+ *
+ * These tests check that filtering keeps only accepted pairs, leaves the input unchanged, and returns a separate array.
+ * They also check shared-node rejection, deferred overlap calculation, updated coordinates, and empty results.


Verify that the "interface_pair" checks don't overlap or duplicate any of the checks here.

Yes, verified. This is more verifying the composition, execution backends, array ownership, etc.

srwopschall · 2026-10-27T21:44:14Z

+ *
+ * These tests check that filtering keeps only accepted pairs, leaves the input unchanged, and returns a separate array.
+ * They also check shared-node rejection, deferred overlap calculation, updated coordinates, and empty results.
+ * Individual geometry checks are tested in tribol_interface_pair_checks.cpp.


What does individual geometry checks mean? It looks like checks here are going through the full CG on actual topology.

This is a good point, there are still projections in InterfacePairChecks that aren't being used anymore. I removed those and cleaned up related tests and restored the projection in EnergyMortar for now (it will be removed in the quadrature PR). Also, make the comment specific.

srwopschall · 2026-10-27T22:39:42Z

+ * space. Candidates and both meshes must use the same allocator, accessible from the selected execution mode.
+ * No face-data preprocessing is required. Temporary storage scales with the candidate count, not all possible pairs.
+ */
+class ProjectedEdgeSearch final : public RefinedSearch {


So this is basically a 2D cg filter? But is this responsible for computing overlaps?

Yes, it filters candidates. Quadrature computes the overlap.

srwopschall · 2026-10-27T22:39:57Z

+
+/**
+ * @file
+ * @brief Filter edge candidates by topology and orientation without calculating projected overlap.


Verify that this does not compute overlaps. Should it?

It does not, that will be done in the quadrature (next PR).

srwopschall · 2026-10-27T22:41:19Z

+   * @param mesh2 Current target mesh view.
+   * @return Owned accepted pairs in the input allocator; their order is unspecified.
+   */
+  ArrayT<InterfacePair> filterCandidatePairs( const ArrayT<InterfacePair>& candidate_pairs, MeshData::Viewer mesh1,


I thought that the refined search should compute overlap pairs. This is somewhat different than what we talked about. Does energy mortar just compute and store that info differently than in legacy common plane and mortar? As in, this does not use CompGeom stuff? If that is the case, these approaches will have to be merged and refactored per our discussion on the purpose of a refined search and when/where overlaps are computed using comp geom machinery so all the CG stuff is unified.

No CompGeom stuff for 2D energy mortar. It's simple enough to not need it. 3D common plane should use it, but 2D likely will not either.

For a 3D common plane refined search class, we can include CompGeom

srwopschall · 2026-10-27T22:43:01Z

+  virtual ~RefinedSearch() = default;
+
+  /**
+   * @brief Filter current candidates and return an owned array of accepted pairs


If this does not or is not intended to compute overlaps with the comp geom machinery perhaps make this very clear since all of this is in some sort of flux. If this is just meant to be a geomFilter() type operation, clarify what "accepted pairs" means as this point. This looks like it is probably further refinement of the candidate pair list to exclude self-pairs or pairs that share a node etc. "Accepted pairs" isn't clear as to what that means.

Fixed the language here and elsewhere. Generally, accepted -> retained

srwopschall · 2026-10-27T22:43:42Z

 ## [Version 0.2.0] - Release date YYYY-MM-DD

 ### Added
+- Added `ProjectedEdgeSearch` to reject self-pairs, optionally reject shared-node pairs, and require opposing edge


Consider "Added ProjectedEdgeSearch as a derived refined search to reject....

We should discuss what belongs here, more generally. I think this is too verbose. We should keep it to user-facing changes or underlying changes that give new behavior that would be noticeable to users. We can encode that in e.g. CONTRIBUTING.md.

Move contact search and filtering into contact formulations

e93c535

This was referenced Oct 26, 2026

Add interface quadrature data #277

Closed

Have ContactFormulation-derived classes own search #275

Closed

ebchin mentioned this pull request Oct 27, 2026

Generate configurable quadrature within contact pair calculations #278

Open

srwopschall reviewed Oct 27, 2026

View reviewed changes

ebchin added 14 commits October 27, 2026 16:26

Clarify EnergyMortar mesh ordering

3d01899

Document separated projection handling

0091181

Clarify projected edge filtering tests

889cf91

Keep projection geometry in EnergyMortar

0ecc421

Clarify refined search topology coverage

511cb0d

Clarify EnergyMortar patch parameters

1cfd7db

Compute effective binning scale on demand

3dcac25

Update effective binning scale contract

2150cb0

Clarify zero-length EnergyMortar intervals

ee4f8a9

Rename EnergyMortar candidate search

36989cb

Match legacy opposing normal cutoff

aae3ea1

Express opposing normals with edge vectors

fd422c6

Clarify refined search candidate results

d96d25e

Format contact search changes

cc23124

srwopschall approved these changes Oct 28, 2026

View reviewed changes

ebchin merged commit 1c123f0 into develop Oct 28, 2026
14 checks passed

ebchin deleted the feature/ebchin/contact-search branch October 28, 2026 20:54

Conversation

ebchin commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

srwopschall left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ebchin commented Oct 26, 2026 •

edited

Loading