Test workflow + custom metric docs

[fjebaker]

Going to debug the test workflow in this PR and also committing some of the custom metric documentation.

[fjebaker]

Seems that the GeometricalPredicates.jl package is failing to build, which is needed for the Voronoi tesselation libraries...

[fjebaker]

I can't workout what is causing this. The version of GeometricalPredicates installed on the CI machine is v0.4.1, and then it complains about:

ERROR: LoadError: MethodError: no method matching quadrants(::Int32, ::Int32, ::Int32, ::Int32)
Stacktrace:
 [1] _init_inv_peano_3d()
   @ GeometricalPredicates ~/.julia/packages/GeometricalPredicates/1dBKW/src/GeometricalPredicates.jl:998
 [2] top-level scope
   @ ~/.julia/packages/GeometricalPredicates/1dBKW/src/GeometricalPredicates.jl:1008
 [3] include
   @ ./Base.jl:418 [inlined]
 [4] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt64}}, source::String)
   @ Base ./loading.jl:1318
 [5] top-level scope
   @ none:1
 [6] eval
   @ ./boot.jl:373 [inlined]
 [7] eval(x::Expr)
   @ Base.MainInclude ./client.jl:453
 [8] top-level scope
   @ none:1
in expression starting at /home/runner/.julia/packages/GeometricalPredicates/1dBKW/src/GeometricalPredicates.jl:1

But that method is defined? It's in the v0.4.1 tagged source code anyway... I've tried pinning the compat version of VoronoiCells, but it installed the right version during that run, so I have no idea if this will make any difference.

[fjebaker]

I noticed I had the arch set as x86 in the matrix of test machines for the CI. I have instead adjusted it to pick the architecture by itself, but added the macOS-latest machine to broaden the scope. Hopefully this will resolve any strange version-resolution issues.

[fjebaker]

Seems to be working after letting the matrix pick Julia architecture x64, instead of x86. This is precisely because only Int64 is supported. I know GeometricalPredicates makes use of some IEEE standards for interoperating between floats and ints, so I imagine there's a reason for that.

Anyway, hopefully the tests now pass okay.

[fjebaker]

Setting --math-mode=ieee seems to be much more reliable (unsurprisingly), but makes me think #29 is very imporant.

[codecov-commenter]

Codecov Report

Merging #28 (4e9418a) into main (c77da7c) will decrease coverage by 5.28%.
The diff coverage is 52.81%.

@@            Coverage Diff             @@
##             main      #28      +/-   ##
==========================================
- Coverage   70.26%   64.97%   -5.29%     
==========================================
  Files          34       40       +6     
  Lines         612      905     +293     
==========================================
+ Hits          430      588     +158     
- Misses        182      317     +135     

Impacted Files	Coverage Δ
src/AccretionFormulae/orbit-interpolations.jl	0.00% <0.00%> (ø)
src/AccretionGeometry/AccretionGeometry.jl	68.75% <ø> (ø)
src/DiscProfiles/DiscProfiles.jl	40.00% <ø> (ø)
src/DiscProfiles/transfer-functions.jl	0.00% <0.00%> (ø)
src/GeodesicTracer/GeodesicTracer.jl	87.50% <ø> (ø)
src/GradusBase/metric-params.jl	0.00% <ø> (ø)
src/GradusBase/physical-quantities.jl	0.00% <ø> (ø)
src/Rendering/point-functions.jl	60.00% <0.00%> (+17.14%)	⬆️
src/Rendering/utility.jl	22.22% <ø> (ø)
src/const-point-functions.jl	0.00% <0.00%> (ø)
... and 20 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7268227...4e9418a. Read the comment docs.

[fjebaker]

That's wild -- despite having defined the expectations values on a mac running the latest OS, the CI calculates completely different values??

Evaluated: isapprox(36043.47569730063, 36284.46364155733; atol = 0.001, rtol = 0.0)

[fjebaker]

Going to disable macOS for now, just to keep things moving, but will open an issue related to this.