Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1333 +/- ##
==========================================
+ Coverage 85.54% 85.68% +0.13%
==========================================
Files 199 200 +1
Lines 6384 6439 +55
==========================================
+ Hits 5461 5517 +56
+ Misses 923 922 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
The tests are now run in CI on Julia v1. With the new version on main of IntegrationInterface.jl many
The |
|
Awesome! As soon as we get Simplex support in II.jl, we can fix the
remaining tests with Triangle Tetrahedron, general Polygon and Mesh.
Em qua., 18 de mar. de 2026, 12:11, Joshua Lampert ***@***.***>
escreveu:
… *JoshuaLampert* left a comment (JuliaGeometry/Meshes.jl#1333)
<#1333 (comment)>
The tests are now run in CI on Julia v1. With the new version on main of
IntegrationInterface.jl many @test_broken were fixed. The remaining ones
are
- PolyArea: I think we just need another specialization for that
similar to Domain, see
https://github.com/JuliaGeometry/MeshIntegrals.jl/blob/af80869c608a99bc5fde9ed8154dd7c82942a597/src/specializations/PolyArea.jl
.
- Triangle, Tetrahedron, and SimpleMesh: We need to be able to
integrate simplices. Ideally, this is directly supported by
IntegrationInterface.jl. I think, @pablosanjose
<https://github.com/pablosanjose> already has plans for that.
The Float32 tests are failing. This looks like an issue in
IntegrationInterface.jl. I'll try to create an MWE and report.
—
Reply to this email directly, view it on GitHub
<#1333 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZQW3IIODJBQQ4B4Y7GDK34RK4B5AVCNFSM6AAAAACWVMAXC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAOBTGI4TSOJRHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Another thing to consider are |
|
Also another though/question: I see you increased the number of Gauss-Legendre points to 20 by default (which I find a reasonable choice). We still use some explicit relative tolerances in the tests, which I think came from the time where we had a smaller number of points by default. Did you check if we can relieve the |
Will experiment with this approach.
I think of this current default as something temporary while II.jl provides a backend that also supports simplices. At the end we will try to pick a single backend that handles boxes and simplices, and will set the default parameters using some concrete criteria. |
Nice! It indeed seems to be much more accurate. The test for |
| """ | ||
| function localintegral(fun, geom::Geometry, method=GAUSSLEGENDRE) | ||
| # integrand is equal to function times differential element | ||
| integrand(uvw...) = fun(uvw...) * differential(geom, uvw) |
There was a problem hiding this comment.
I think it would be good to allow for a custom diff_method that gets passed to differential so you can customize both the integration method and the diff_method for differentiation.
There was a problem hiding this comment.
It makes sense. Out of curiosity, do you have an example where users might need to change the default differentiation and integration methods? I am wondering if there is always a "best" default in these geometric settings. If the notion of "best" default exists, i.e., a backend that is the fastest, more accurate, native Julia etc., then we need to reassess the need for customization of backends in these functions.
There was a problem hiding this comment.
If you want the best in terms of accuracy you should obviously take something AD based because it is exact in contrast to FiniteDiff.jl. However, (as we already saw in the differential PR) AD is easier to fail and ForwardDiff.jl conceptionally simpler. In terms of speed, I think forward mode AD is mostly faster than FD here, but that would need to be benchmarked. So I would like to allow for customization. I think @kylebeggs is also interested in customizable differentiation backends for integral since he added Enzyme.jl support to MeshIntegrals.jl.
Regarding customizability of the integration method, this mostly depends on the geometry. For 1D geometries QuadGK.jl should normally be most efficient, more multi some H-adaptive cubature. On the other hand if you want to compute many integrals, you might want to pre-allocate Gauss-Legendre (or some other Gauss) nodes and weights, so that you can reuse them for the different integrals you want to compute. So I would also like to have the option to customize this.
So to summarize a "best" default meaning best for all use-cases is probably difficult to find for both the differentiation and integral method, but of course, having sensible defaults that are robust and are reasonably fast and accurate in most use cases is still important.
There was a problem hiding this comment.
One thing we need to do in order to support customization of both backends (differentation + integration) is replace the current positional argument by two keyword arguments:
derivative(..., ∂backend=...)
integral(..., ∂backend=..., ∫backend=...)We could do that in a separate PR after this one here is merged.
|
I reran one Float32 test to see if pablosanjose/IntegrationInterface.jl#30 fixed the Float32 tests, see https://github.com/JuliaGeometry/Meshes.jl/actions/runs/23269401309/job/67774013904?pr=1333. The good message is yes, the previous failing |
|
Interesting, can you try to use an AD backend for |
|
Opened a dedicated issue: #1336 |
|
The |
|
That has to be a bug. Perhaps you need a finite atol in this case? Try |
Tried it and even with Float64 the test with |
|
Can you write here the function and the domain bounds? |
|
This seems to be the problem: julia> f(x₁, x₂, x₃, a) = (√(a^2 - x₁^2) + √(a^2 - x₂^2) + √(a^2 - x₃^2))
f (generic function with 1 method)
julia> J = Integral(f, Domain.Box{3}(a -> ((0,0,0), (a, a, a))); backend = Backend.HAdaptiveIntegration())
Integral
Mutating : false
Domain : Functional{Box{3}}
Backend : HAdaptiveIntegration
Integrand : f
julia> J(0.2)
┌ Warning: maximum number of subdivisions reached `maxsubdiv=65536`, try increasing the keyword argument `maxsubdiv`.
└ @ HAdaptiveIntegration ~/.julia/packages/HAdaptiveIntegration/JRwB2/src/integrate.jl:120
0.0037699120880203977
|
|
Opened an issue at HAdaptiveCubature: zmoitier/HAdaptiveIntegration.jl#57 |
|
By setting |
|
Regarding the failing downstream test: I am seeing the same error on another repo. So I think CairoMakie.jl is currently broken. |
| # ------------------------------------------------------------------ | ||
|
|
||
| # default integration method | ||
| const HADAPTIVE = II.Backend.HAdaptiveIntegration(rtol=1e-3) |
There was a problem hiding this comment.
I am wondering whether it makes sense to make rtol depending on the floating point type. The default for this is sqrt(eps(T)), which evaluates to 1.4901161193847656e-8 for Float64 and to 0.00034526698f0 for Float32. So setting this always to 1e-3 means we loose quite some accuracy for the Float64 case. Maybe it would be more sensible to use something like 10 * sqrt(eps(T)) (since sqrt(eps(T)) was too small), which for Float32 is close to 1e-3, but gives us more accuracy for the Float64 case. We can also add that in another PR though because I think we wanted to touch the default anyway and make it a function depending on the geometry, right?
There was a problem hiding this comment.
I played with atol=Meshes.atol(numtype(eltype(geom))) in the II.jl backend, but forgot to play with rtol too. We could investigate this issue in a separate PR to avoid delaying the progress 👍🏽
|
IntegrationInterface.jl is now registered, you can add it to your deps for CI |
Already done :) |
Benchmark Results (Julia vlts)Time benchmarks
Memory benchmarks
|
Benchmark Results (Julia v1)Time benchmarks
Memory benchmarks
|
JoshuaLampert
left a comment
JoshuaLampert
left a comment
There was a problem hiding this comment.
LGTM and CI is green 🥳
The remaining three open conversations will be handled in separate PRs.
|
Amazing stuff! 🎉 Thank you all for the huge help. Special thanks to @pablosanjose for the new IntegrationInterface.jl package, super nice addition! |
3 participants
Cleaned version of #1327.