Consider new localintegral API function #218

Activity

1. juliohm

   added

   enhancementNew feature or requestNew feature or request

   help wantedExtra attention is neededExtra attention is needed

   on Feb 1, 2026
2. mikeingold commented on Feb 2, 2026

   

   mikeingold

   on Feb 2, 2026

   Collaborator

   More actions

   If I'm understanding this correctly, the request is for an alternative to integral that performs the integration in the parametric $[0,1]$ coordinate space instead of mapping to the Unitful/physical Point coordinate space?

   Thinking out loud:

   This would be conceptually simple, but might require some thought to implement well. Currently the integral function is (mostly) a high-level wrapper that dispatches onto _integral worker functions.

   The simplest implementation would probably just require replicating the current src/integral.jl code and modifying this into localintegral and _localintegral functions, though that will add a little overhead over time keeping these implementations in sync.

   Adding a keyword option setting to integral would still require separate _localintegral workers, but also adds complexity to the interface, so probably isn't a good idea. I also do like the suggested idea of this having a separate localintegral name since it's fundamentally a different problem being solved.

   To do:

   • Update unit test system
     • Include a standard @test for the localintegral
     • Derive and include local integral solutions for each test set
   • Determine how to handle/mirror all of the current integration code paths
     • Alias functions like lineintegral'? These really just provide a convenience paramdim(geometry)verification, so may not provide a lot of additional value to users oflocalintegral`, but would feel to me like a bit of an API gap...
     • For geometries that currently require a specializations wrapper
3. JoshuaLampert commented on Feb 2, 2026

   

   JoshuaLampert

   on Feb 2, 2026

   Member

   More actions

   To reduce the overhead keeping implementations in sync, I think it should be possible to reuse localintegral in integral because what integral currently does is nothing else than mapping the physical space into the parameter space and then computing a local integral. So if we already have a function written in terms of parametric coordinates the first part is not needed anymore, but the second is the same. For the simplest example of QuadGK.jl I think it could something like this:

   function _localintegral(
           integrand,
           rule::GaussKronrod;
           FP::Type{T} = Float64
   ) where {T <: AbstractFloat}
       return QuadGK.quadgk(integrand, zero(FP), one(FP); rule.kwargs...)[1]
   end
   
   function _integral(
           f,
           geometry,
           rule::GaussKronrod;
           FP::Type{T} = Float64,
           diff_method::DM = _default_diff_method(geometry, FP)
   ) where {DM <: DifferentiationMethod, T <: AbstractFloat}
       _check_diff_method_support(geometry, diff_method)
   
       # Only supported for 1D geometries
       if !Meshes.iscurve(geometry)
           msg = "GaussKronrod rules not supported in more than one parametric dimension."
           throw(ArgumentError(msg))
       end
   
       integrand(t) = f(geometry(t)) * differential(geometry, (t,), diff_method)
       return _localintegral(integrand, rule; FP = FP)
   end

   👍React with 👍1Reacted by Júlio Hoffimann
4. JoshuaLampert commented on Apr 8, 2026

   

   JoshuaLampert

   on Apr 8, 2026

   Member

   More actions

   This should now be available in v0.57 of Meshes.jl.
5. JoshuaLampert

   closed this as completedon Apr 8, 2026