Generalize differential element calculation to n-dims

[mikeingold]

Changes

• Uses geometric algebra to generalize differential to handle geometries with arbitrary numbers of parametric dimensions.
• Adds CliffordNumbers.jl as a dependency.
• Converts all prior usages of the generic error function into throwing more appropriate/specific error types.
• Implements un-broken tests for 4D Box now that this is fixed.
• Minor API change to jacobian such that (geometry, ts) -> ::NTuple{paramdim(geometry), Meshes.Vec}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (bd71834) to head (0aada68).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #101   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           17        17           
  Lines          258       260    +2     
=========================================
+ Hits           258       260    +2     

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

[JoshuaLampert]

This is probably a breaking change since it adds a new dependency.

I don't think that adding a dependency counts as breaking change.

[mikeingold]

This is probably a breaking change since it adds a new dependency.

I don't think that adding a dependency counts as breaking change.

I don’t think I’ve seen this documented as a strict requirement. I may be thinking back to a recent heated discussion between the Julia Slack and Discourse about license changes and how some users felt strongly that certain actions constituted a breaking change that should require a more explicit downstream acceptance.

I don’t feel that strongly about it, and I don’t know how many actual users we have that might care, so it’s admittedly probably a bit of an academic question.

[mikeingold]

@JoshuaLampert Do you know a way for us to categorize some @testitems or @testss specifically as belonging to some kind of non-CI extended tests? With this PR as-is, Tetrahedron and 4D Box tests are something like 90% of all CI time, so I'm wondering if we can partition them into a separate non-default set of tests.

[mikeingold]

Also, thanks again for implementing Downgrade action! It made a good catch here.

[JoshuaLampert]

@JoshuaLampert Do you know a way for us to categorize some @testitems or @testss specifically as belonging to some kind of non-CI extended tests? With this PR as-is, Tetrahedron and 4D Box tests are something like 90% of all CI time, so I'm wondering if we can partition them into a separate non-default set of tests.

Yes, we can give the tests tags and filter all the tests by the tags, see https://www.julia-vscode.org/docs/stable/userguide/testitems/#Tags. Let's do that in a separate PR?

[JoshuaLampert]

That's pretty cool. Thanks. I can't judge the CliffordNumbers.jl implementation because I'm not an expert in geometrical algebra, but since tests pass, I assume everything is fine.

[JoshuaLampert]

Thanks for your explanation. I now understand what this does. While experimenting with this a bit, I came up with this alternative to handle the units. It's a bit shorter. I am not sure which version is preferable, but I thought I'll just leave it here. I you prefer the original approach I'm totally fine with that.

[mikeingold]

I added a @testitem specifically to check functions under utils.jl that should bring us back up to 100% code coverage.

Also, I did some testing locally with a jacobian API that returns as NTuple instead of Vector. There was a huge performance improvement locally, running some integral tests nearly twice as fast on my local machine. Given the difference, and that this generalization is a non-trivial feature update, I'd like to go ahead and consolidate these into a v0.15 update.~

Update: the huge difference I was initially seeing locally seem to have been anomalous. I just ran a more thorough @benchmark jacobian(...) test and the performance differences between Vector and NTuple outputs seem to be more on the order of about 10%.

[JoshuaLampert]

LGTM

[mikeingold]

LGTM

Thanks! I'll give this one final review this evening.

[mikeingold]

I made two changes:

• Increased minimum version of CliffordNumbers.jl to v0.1.4 based on a release note from the package owner.
• Removed @inline from a utility function; I hear this is now generally not recommended practice.