Include rotation matrix in cell values

[DRollin]

No description provided.

[codecov]

Codecov Report

Attention: Patch coverage is 96.22642% with 2 lines in your changes missing coverage. Please review.

Project coverage is 89.24%. Comparing base (42da30d) to head (0e079b5).

Files with missing lines	Patch %	Lines
src/cellvalues.jl	96.22%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #25      +/-   ##
==========================================
+ Coverage   88.61%   89.24%   +0.62%     
==========================================
  Files           5        5              
  Lines         281      316      +35     
==========================================
+ Hits          249      282      +33     
- Misses         32       34       +2     

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

[DRollin]

I could use some help defining a proper test case...
Not sure if the current one is fine.

[KnutAM]

For cohesive elements, this would be very useful to make the traction-separation implementation interface cleaner.

I believe there is a mistake (added a test proposal to show). I think the way one would need to calculate this would be (but haven't tested)

v1 = J[:, 1]
if 3d
    v3 = v1 × J[:, 2] # normal vector
    v2 = v3 × v1 # Ensures v2 perpendicular to v1 and v3
    R = Tensor{2, 3}((normalize(v1)..., normalize(v2)..., normalize(v3)...))
else if 2d
    v2 = Vec{2}(((-v[2], v[1]))
    R = Tensor{2, 2}((normalize(v1)..., normalize(v2)...))
end

[DRollin]

Thanks for the feedback 👍
I updated the code and tests.

[KnutAM]

Regarding the notation here, I believe that formally this should always be a coordinate transformation tensor, $\boldsymbol{Q}$.

That has no practical meaning since Tensors.jl don't include the coordinate bases. But still wanted to put it out here, to maybe motivate calling it something like

• coordinate_transformation
• orientation or surface_orientation
  (could be potentially be owned by Ferrite to extend the current getnormal API for facetvalues). I would imagine this would be useful for e.g. contact simulations.
• surface_transformation
• facet_transformation / facet_orientation

(personally I think the midplane is implied by being an interface, and if needed on either "side", that could be given explicitly as extra argument).