Consider new `localintegral` API function

[juliohm]

The existing integral function takes a point p with global coordinates. Sometimes, we just need to perform integration inside the geometry in terms of local parametric coordinates. For example, if we know the function values f1, f2, f3 at the vertices a triangle, we can use the barycentric coordinates to integrate a linear function: f(u, v) = f1 + (f2 - f1) * u + (f3 - f1) * v.

A new localintegral function that expects integrands in terms of parametric coordinates would really help in these situations.

[mikeingold]

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

[JoshuaLampert]

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