Add support for integrating Meshes.Domain and PolyArea

[mikeingold]

Changes

• Adds an integral(f, ::Domain) method that partitions a domain using Meshes.discretize and then sums the integrals of these sub-geometries.
• Generalizes the alias functions (e.g. lineintegral) to accept anything <:Meshes.GeometryOrDomain union type.

I'm planning for this PR to close #27 and #169

TODO

• Add specializations/PolyArea.jl with methods
• Determine whether docstrings usage of diff_method=FiniteDifference() is still valid
• Determine whether args like diff_method are being determined at the correct level. I.e. if SimpleMesh doesn't directly support Enzyme, but results in sub-geometries inheriting that lack of support. Maybe just pass through all args....
• Why do CartesianGrid tests take 80+ minutes?
• Update CHANGELOG
• Add/update entries on the Support Matrix in the docs

Add tests for integrating over:

• CartesianGrid
• PolyArea
• RegularGrid
• SimpleMesh
• StructuredGrid

[github-actions]

Benchmark Results

	main	6ece30e...	main / 6ece30e...
Differentials/Differential	0.205 ± 0.001 μs	0.206 ± 0.001 μs	0.996 ± 0.0068
Differentials/Jacobian	0.17 ± 0.0001 μs	0.169 ± 0.001 μs	1.01 ± 0.006
Integrals/Segment/Scalar GaussKronrod	0.561 ± 0.0084 μs	0.562 ± 0.0064 μs	0.998 ± 0.019
Integrals/Segment/Scalar GaussLegendre	1.66 ± 0.01 μs	1.72 ± 0.0073 μs	0.965 ± 0.0072
Integrals/Segment/Scalar HAdaptiveCubature	0.723 ± 0.014 μs	0.716 ± 0.025 μs	1.01 ± 0.041
Integrals/Segment/Vector GaussKronrod	2.74 ± 0.068 μs	2.73 ± 0.067 μs	1 ± 0.035
Integrals/Segment/Vector GaussLegendre	17.6 ± 0.62 μs	17.7 ± 0.56 μs	0.999 ± 0.047
Integrals/Segment/Vector HAdaptiveCubature	3.56 ± 0.1 μs	3.61 ± 0.13 μs	0.985 ± 0.046
Integrals/Sphere/Scalar GaussKronrod	0.0694 ± 0.0017 ms	0.0692 ± 0.0012 ms	1 ± 0.03
Integrals/Sphere/Scalar GaussLegendre	1.88 ± 0.0033 ms	1.87 ± 0.01 ms	1.01 ± 0.0059
Integrals/Sphere/Scalar HAdaptiveCubature	0.0483 ± 0.00013 ms	0.0478 ± 0.00012 ms	1.01 ± 0.0037
Integrals/Sphere/Vector GaussKronrod	0.103 ± 0.0017 ms	0.104 ± 0.0016 ms	0.99 ± 0.022
Integrals/Sphere/Vector GaussLegendre	3.35 ± 0.082 ms	3.31 ± 0.1 ms	1.01 ± 0.04
Integrals/Sphere/Vector HAdaptiveCubature	0.1 ± 0.0017 ms	0.1 ± 0.0016 ms	1 ± 0.023
Rules/GaussLegendre	22.2 ± 0.54 μs	21.8 ± 0.62 μs	1.02 ± 0.038
Specializations/Scalar GaussLegendre/BezierCurve	0.245 ± 0.0071 ms	0.251 ± 0.0071 ms	0.977 ± 0.04
Specializations/Scalar GaussLegendre/Line	7.11 ± 0.056 μs	7.01 ± 0.056 μs	1.01 ± 0.011
Specializations/Scalar GaussLegendre/Plane	0.745 ± 0.0018 ms	0.745 ± 0.0016 ms	1 ± 0.0033
Specializations/Scalar GaussLegendre/Ray	5.84 ± 0.048 μs	5.87 ± 0.047 μs	0.994 ± 0.011
Specializations/Scalar GaussLegendre/Rope	0.0509 ± 0.00021 ms	0.0528 ± 0.00023 ms	0.964 ± 0.0058
Specializations/Scalar GaussLegendre/Tetrahedron	0.158 ± 0.0012 s	0.156 ± 0.0012 s	1.02 ± 0.011
Specializations/Scalar GaussLegendre/Triangle	0.717 ± 0.017 ms	0.631 ± 0.0073 ms	1.14 ± 0.03
time_to_load	1.41 ± 0.0059 s	1.4 ± 0.01 s	1 ± 0.0083

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[mikeingold]

Interesting. The remaining errors with the SimpleMesh tests are invalid barycentric coords errors from integrating Triangles.

[mikeingold]

Still debugging. One of the remaining issues (UndefVarError: geometry not defined) has a stack trace that appeared at first to be throwiing directly from combinations.jl:138's use of geometry, but I've done some debugging and it appears to be coming from some other function further along the stack.

Edit: got it. There was a holdover in the default rule selection for the integral(::Domain) method.

[mikeingold]

I've run some tests locally to figure out why the Meshes.CartesianGrid test set takes so long, and I've run across some odd results.

• The test set initially took about 80 minutes to run on my computer.
• I ran some tests in a separate REPL and couldn't find any obvious slow integration. Then I tried adding some Logging.@debug lines to give me a quick trace on where the tests are spending all of their time, and suddenly it would repeatably run in about 15 seconds.
• I manually reverted my local repo state to the current commit to make sure there wasn't some unnoticed change and then I rebooted VS Code. Re-running the test set, the first run took about 12 minutes, but then successive runs took 10-15 seconds.

[mikeingold]

Based on a little more debugging, even in the longer CartesianGrid runs the actual runtests function only requires 10-15 seconds, so I suspect that TestItems is also measuring compilation time and that must be dominating the first runtime in this case. Odd that it only seems to be an issue here and not also for RegularGrid. Maybe some kind of type instability/inference issue?