Contact 1 of 3

[gabemorris12]

Description

This is the first of a three stage pull request plan to get contact into Fierro single-node. This first stage covers sorting the set of contact nodes in such a way to allow easy access to nodes in proximity to a patch/surface. For now, all contact features are handled by struct contact_patch_t and struct contact_patches_t. The first is for handling the many roles between a single patch and node, such as detection, force resolution, computing normals, etc. The latter is for setting up the instances of struct contact_patch_t, getting contact pairs, handling interactions between patches, etc. Though the name might imply that only patches are considered, this can be manipulated to handle higher order surfaces. Such features are not expected to be available immediately.

In the future, SGH::boundary_contact() will look like this:

contact_bank.sort(mesh, nodes, corner);  // contact bank is an instance of contact_patches_t, which is a member of class SGH
contact_bank.get_contact_pairs(dt);
contact_bank.normal_increments(dt);  // frictionless force resolution
contact_bank.remove_pairs(dt);  // remove contact pairs that fall off the edge of a patch or have zero force

This PR covers the contact_patches_t::sort() method, initializing the instances of contact_patches_t and contact_patch_t in SGH::setup(), and the contact_patches_t::find_nodes() method, which takes in a contact_patch_t instance and determines the nodes that could penetrate the contact_patch_t.

Type of change

Please select all relevant options

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Formatting and/or style fixes
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Test A : With contact_test.yaml as the input, see that it successfully runs with each call of contact_bank.sort() in the boundary_contact function. Additionally, outputting the contact_bank.nsort array correctly depicts the nodes sorted propagating first in the x direction, then the y direction, then the z direction. Calling contact_bank.find_nodes() with patch 2 as the patch of interest correctly finds nodes 18 19 20 21.
• Test B : The similar procedure above can be done with contact_test2.yaml.

Test Configuration:

• OS version: MacOS
• Hardware: M3 Pro
• Compiler: cling

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• The code builds from scratch with my new changes
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[jacob-moore22]

We probably want the contact bank to live outside of the SGH solver, that way we can use the same framework for multiple solvers. Lets chat at our next meeting about where that needs to live.

[jacob-moore22]

Note: For all KOKKOS_FUNCTIONS, it needs the macro (KOKKOS_FUNCTION) placed before the return type on the line above for both the declaration and the definition. @nathanielmorgan, do we have a macro wrapping KOKKOS_FUNCTION to alias to something like DEVICE_FUNCTION, for those who dont know kokkos? May be worth doing.

[jacob-moore22]

Consider adding a comment explaining what add_sub is doing. If it is documented somewhere else, note that.

[gabemorris12]

I added this for the next pull request:

// collecting all the points that will be used to construct the bounding box into add_sub
// the bounding box is the maximum and minimum points for each dimension