Conversation
Benchmark Results (Julia vlts)Time benchmarks
Memory benchmarks
|
Benchmark Results (Julia v1)Time benchmarks
Memory benchmarks
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1327 +/- ##
==========================================
+ Coverage 85.50% 85.62% +0.12%
==========================================
Files 199 200 +1
Lines 6376 6409 +33
==========================================
+ Hits 5452 5488 +36
+ Misses 924 921 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Regarding support for multiple quadrature libraries, we need to think if it is really necessary. If it is necessary, we could start by creating an IntegrationInterface.jl package after this PR is merged, similar to the DifferentiationInterface.jl approach. |
There is Integrals.jl, which basically provides exactly that. |
I think it would be nice because Gauss-Kronrod should be more efficient to get a certain accuracy in 1D and H-adaptive cubature should be better suited in multi D. |
I saw it, but it is not at the same level of DifferentiationInterface.jl. It includes a bunch of dependencies, including backends and SciML stuff. |
|
Please feel free to add tests if you have some already written in MeshIntegrals.jl. I will try to continue the work over the weekend, and next week we should have a final version to review 👍🏽 |
JoshuaLampert
left a comment
JoshuaLampert
left a comment
There was a problem hiding this comment.
I have two questions:
- How do we deal with the specializations? Do we add them in (a) later PR(s)?
- How should we write tests? In MeshIntegrals.jl we have quite extensive tests, which take some time though.
- Should we have tests for every (supported) geometry? I think we should because just because the integral works fine for one or a few geometries does not mean it works for all, see the need for the specializations. I think we can use the non-trivial (i.e., we do not just integrate a constant function) analytical tests we have in the test suite of MeshIntegrals.jl.
- Should we use some test infrastructure to automate the testing and reduce code duplication and redundancy like in MeshIntegrals, see here or should we rather go with a straightforward approach and testing each geometry individually?
We should add them here as well. I will try to find the time tomorrow to finish up the additions 👍🏽
Yes. We should have full coverage.
I think we can be more straightforward testing each geometry individually. It gives us more freedom to add more tests later without affecting all other tests. |
|
@JoshuaLampert I've ported some tests from MeshIntegrals.jl to see if everything was working as expected, but the results are not matching. Do you have any idea of what might be happening? Could it be related to the default backend? Should we adjust the tests? |
They are very likely failing due to the low number of Gauss-Legendre points you are using by default, i.e., related to your comment #1327 (comment). I think for general non-linear functions, we should provide a much higher value for |
|
Also I just see from the failing |
Got it! I will try to find a small enough number that gives us a good default for moderately nonlinear functions.
We want to preserve the type of the input. I thought the implementation would guarantee that, but maybe the backend is promoting the arguments? I will double check. |
I think the problem is that the Gauss-Legendre nodes and weights provided by FastGaussQuadrature.jl are |
|
I've increased the default order to After we sort out the source of the issue, we could pick something like 3 by default (exact approximation of polynomials of degree 5). It is hard to imagine applications where this default wouldn't be enough. |
|
Could the change in results be related to the change of variable formula? I used |
Hm, currently, I don't see another semantic difference between the two implementations. So give it a try? |
|
What is different is the finite difference scheme used to compute the |
That was it. I will adjust the tests to be more explicit about the |
|
@JoshuaLampert we have all methods in place. The tests for |
JoshuaLampert
left a comment
JoshuaLampert
left a comment
There was a problem hiding this comment.
Thanks! This looks mostly good to me. I left a few minor suggestions/questions below.
- A test for
SimpleMeshis still missing. - Should we also add a test that the floating point type is preserved by
integralor do you think this is already implicitly tested for by the accuracy tests? - I don't see right now why the geometries, which need a custom transformation fail. It seems like they have the same reason why they fail. So to debug this I would pick the simplest one (I guess
Ray), add some debug statements at different steps in Meshes.jl and MeshIntegrals.jl and see where they differ to see what might be the problem. Did you already try something like this? I do not have the time to do that right now though (I am on vacation). Otherwise maybe AI also has an idea?
src/integration.jl
Outdated
| # specialize quadrangle for performance | ||
| localintegral(fun, quad::Quadrangle; n=3) = _uvwintegral(fun, quad, n) |
There was a problem hiding this comment.
Why does this specialization improve performance?
There was a problem hiding this comment.
We had a method for general Polygon that got erased. The method for general polygon relied on discretization, and this method for Quadrangle relies on direct sampling with the parametric function. I will review the code to see if this method is still necessary.
Will add it right after we fix Triangle and Tetrahedron
I think we can assume the implementation preserves the number type.
Will check that. |
|
The results are very sensitive to the transformation. Replacing |
|
I see, but the different transformations you use here compared to MeshIntegrals.jl alone is not the reason for the broken tests, are they? I would first like to fix the bug we still have here (by using the same transformations we had in MeshIntegrals.jl and comparing with the results we get there) before trying different transformations. |
|
I'm planning to refactor the PR in terms of the IntegrationInterface.jl
draft. That way we make sure things are working as expected before the
package is registered. After registration we could adjust the env, run
tests, review and merge.
That way we don't waste time debugging code that will be discarded later
anyways.
Em ter., 17 de mar. de 2026, 11:02, Joshua Lampert ***@***.***>
escreveu:
… *JoshuaLampert* left a comment (JuliaGeometry/Meshes.jl#1327)
<#1327 (comment)>
I see, but the different transformations you use here compared to
MeshIntegrals.jl alone is not the reason for the broken tests, are they? I
would first like to fix the bug we still have here (by using the same
transformations we had in MeshIntegrals.jl and comparing with the results
we get there) before trying different transformations.
—
Reply to this email directly, view it on GitHub
<#1327 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZQW3N63GHW7X45GMUICVL4RFLI5AVCNFSM6AAAAACWCA725KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANZVGIYDKMJUG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I think I have an idea what the issue with the current transformation implementation is. We need to take the Jacobian of the transformation into account. The way this works in MeshIntegrals.jl is that we create a helper geometry
Probably the easiest is the fourth option. Edit: Ah, now I see your message above. Looks like we go with option 4 😄 |
|
Exactly. I figured the bug this morning and even drafted a
ReparametrizedGeometry type here. I believe we could delegate this work to
IntegrationInterface.jl to avoid creating an additional geometry type just
for that specific implementation.
Em ter., 17 de mar. de 2026, 12:25, Joshua Lampert ***@***.***>
escreveu:
… *JoshuaLampert* left a comment (JuliaGeometry/Meshes.jl#1327)
<#1327 (comment)>
I think I have an idea what the issue with the current transformation
implementation is. We need to take the Jacobian of the transformation into
account. The way this works in MeshIntegrals.jl is that we create a helper
geometry _ParametricGeometry, which has the transformation built in,
i.e., when we integrate, say, a Ray the geometry we integrate is actually
a _ParametricGeometry, which in turn means differential(geom, uvw) *also*
takes into account the *transformed* geometry. This ensures we apply the
correct Jacobian, which involves both Jacobians: One from the
transformation from [0, 1] to whatever domain the parametric function uses
and the other Jacobian from the parametric function itself. It's currently
not that straightforward to fix that here because we would need to pass the
transformed geometry to differential, which has geom ∘ trans as
parametric function (we cannot simply pass geom ∘ trans because
differential and functions therein are specialized on Geoemetry). I see a
few solutions:
- Use a similar approach as MeshIntegrals.jl with a new geometry.
- Define parametric functions for the geometries in question mapping
from [0,1] as the other geometries. We would need a good interface for that
to differentiate the two versions.
- Keep differential(geom, uvw), but additionally explicitly multiply
by the Jacobian of the transformation.
- Wait for IntegrationInterface.jl and use the transformations from
there, i.e., pass the boundaries appropriately. I think this should also
fix this issue.
Probably the easiest is the fourth option.
—
Reply to this email directly, view it on GitHub
<#1327 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZQW3LTQR4U6FMD3VT3K5D4RFU6XAVCNFSM6AAAAACWCA725KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANZVHAZTEOJVG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sounds like a good plan.
Yeah, I just did a bit of debugging and I am at least happy that now I have an understanding of why it was failing before (I would have been pretty unsatisfied if I would have never find out what the issue was 😅). But yes, having this handled in IntegrationInterface.jl is the cleanest and easiest solution on our side. I am pretty confident that this will automatically be fixed once we switch to IntegrationInterface.jl since it seems that Pablo figured out a reasonable implementation for transformations also for unbounded domains. So let's keep fingers crossed. I'm excited to see a draft using IntegrationInterface.jl in this PR. |
|
Thanks for starting the IntegrationInterface.jl implementation. Two suggestions/questions:
|
Will do. If you can help later rebasing this PR on top of the latest master branch after the other PR is merged, that would be great. I always mess up with Git rebase 😮💨
I was planning to wait for the registration. This PR would only be merged after the dependency is ready. What do you think? |
Because I would mess up a proper Git rebase, I would probably do it manually 😅. I.e., just create a new branch, add and commit the corresponding code to that branch (should be doable manually because AFAICT, it affects everything in this PR except src/integrals.jl, src/Meshes.jl, test/integration.jl, and Project.toml; so it should be easy to separate), create and merge that PR, and then merge master into this PR (potentially fix merge conflicts).
I think it would be nice to test already earlier. Using the |
Notice that this PR already adds |
|
After #1332 is merged, I will try to ask GitHub Copilot to rebase for me. It should be better at Git for sure 🤣 |
Am I missing something? I don't see that.
The errors I currently see in CI are ERROR: LoadError: expected package `IntegrationInterface [03ca86a4]` to be registeredsee https://github.com/JuliaGeometry/Meshes.jl/actions/runs/23212027058/job/67463028776?pr=1327. |
|
Oh I see, there must be some difference between the GitHub Action and the local tests I am running. Locally I can execute the code just fine. My Project.toml+Manifest.toml are pointing to the URL on GitHub. |
|
Yeah, probably that is in the Manifest.toml. |
|
Closing in favor of #1333 |
* Copy files from #1327 * Minor adjustments * Update tests * Update tests * Update default method * Add tests * Add tests * Fix integrand * Update tests * add IntegrationInterface.jl to [sources] * most tests not broken anymore * test for plane passes with rtol = 1e-3 * Decompose Rope and Ring into Segment parts * update to new integral interface * Strip units from integrand to help backends * Undo strip units * Use HAdaptiveIntegration * Minor refactor * Update tests * Update tests * Use rtol in HAdaptiveIntegration backend * Uncomment test with PolyArea * remove sources section again * format --------- Co-authored-by: Joshua Lampert <joshua.lampert@uni-hamburg.de>
3 participants
Ports
integralfrom MeshIntegrals.jl and addslocalintegralfor integration of functions that are defined locally in terms of parametric coordinates.@JoshuaLampert do you have suggestions before I start writing tests?