Surface normal inconsistency along the fault plane

[jhuang2601]

Describe the bug
For field scale simulations, direction of surface normal could vary from place to place with MPI runs (opposite sign for outward and inward normal), see below:

If the sign convention of surface normal is not consistent along fault plane, the computed normal traction on fault elements would vary significantly (localized change from tension to compression) and challenge the contact solver.

Expected behavior
The direction of the surface normal must remain consistent over the entire fault plane.

[rrsettgast]

@jhuang2601 Are these the "surface element" normal, or the face normals?

[OmarDuran]

@jhuang2601 I have the same question as @rrsettgast. If we are talking about the normals associated with the surface element s, how do you ensure they are always oriented in particular manner?
On the other hand, if you are referring to the normals associated with the faces of 3D elements not being outward, then there is a bug.

[npillardou]

@jhuang2601 I have the same question as @rrsettgast. If we are talking about the normals associated with the surface element s, how do you ensure they are always oriented in particular manner? On the other hand, if you are referring to the normals associated with the faces of 3D elements not being outward, then there is a bug.

These are the normals of the fracture surface elements (not the 3D volume face normals, which are correctly outward-pointing). The inconsistency arises because the elemsToFaces[kfe][0] / [1] ordering is not globally consistent across adjacent fracture elements, causing faceNormal[f0] - faceNormal[f1] to alternate in sign.

However, there is a flaw in the current fix: ComputeRotationMatricesKernel is called unconditionally at every time step in implicitStepSetup(), rebuilding the rotation matrices from scratch. The orientation correction I added only runs during stress initialization. This means the inconsistency can return on subsequent time steps.

The fix should instead be applied inside ComputeRotationMatricesKernel (or immediately after every call to it), not just during initialization. Alternatively, the root cause should be addressed by enforcing a consistent sign convention for f0/f1 ordering.

[OmarDuran]

Your concern treats the issue as static, but fractures can be created dynamically during the simulation. Calling ComputeRotationMatricesKernel every time step is therefore intentional, it ensures newly created fractures are properly oriented.

What you describe as a flaw is actually required behavior. The problem isn’t orientation handling; it’s a bias in one branch of the contact mechanics that leads to inconsistent results.