Discussion: data structure for singularities in kernel-split

[fryklund]

We are about to implement Helsing-Ojala product integration quadrature (pquad) to Chunkie. To invoke pquad, we need to know what kind of singularities that are involved for a specific kernel, and function handles for the smooth part, Cauchy part, log part etc. Before we begin, we would like to agree on a data structure. We suggest two options:

1, To have a set of involved the singularities.

2, The function handles are set to zero for singularities that won't be used.

Also, there is the issue of having different function handles for target points off boundary and on boundary.

We look forward to hearing your thoughts.

[askhamwhat]

Hi Fredrik,

Very exciting.

I think we can classify the Helsing-Ojala-friendly singularities with 4 numbers, say [a,b,c,d] which would correspond to

(log(z-w))^a (log(zc-wc))^b (z-w)^c (zc-wc)^d

where z is a target, w is a source, zc and wc denote the conjugates of z and w, and a,b are non-negative and c,d are non-positive parameters.

Then a kernel's splits could be specified by a list of singularity types (each entry is a vector of the form [a,b,c,d]) and a list of corresponding smooth functions (each entry is a function handle). For the short term, we could say that only some combinations of [a,b,c,d] are supported (e.g. only integer valued, we could even say b=d=0 for a first pass but we'll want these for modified Stokes, biharmonic, etc) but I think that this format is basically future proof.

I think this is like option 1.

I'd be happy to hear from other folks as well.

Best, Travis

[askhamwhat]

Oops. I had actually meant that we could eventually include things like c = 0.5 as well (again not needed for a first pass).

[fryklund]

Hi Travis,

Hai and I think that only the involved singularities should be given in a list, stored under kern.split, for example kern.split = ["log","Cauchy"]. Then a separate list kern.splitsmooth has the smooth functions multiplying the singularities as entries. Any singularity that would have the entry '0' in your [a,b,c,d] is excluded.

Won't the list you suggest have to be longer than four elements, as we might need the real or imaginary parts of the kernels you list?

Please let us know what you think.

Best, Fredrik

[askhamwhat]

I think a list of names is okay but the experience Ludvig and I had with modified Stokes is that you can get some of these other kernel types from splits. That's why I was thinking something fairly general (also square root singularities sound amusing down the line). You're right that you'd need another entry in the array to determine if you want the real or imaginary part (or maybe even the complex value in some cases?)

[fryklund]

Good point about modified Stokes, maybe we should pass around a list of the type [a,b,c,d,...] up to as many entries that are needed, but never show this list to the user. I don't know what the user interface would be though.

[sj90101]

But do we know how to deal with singular kernels like |x-y|^alpha log|x-y| for arbitrary alpha? The kernel-split quadrature is based on complex analysis. I can do log times 1/sqrt. But the general case seems very difficult. It'd be great if we can actually handle the general case outlined in the email by Travis.

On Fri, Feb 2, 2024 at 10:19 AM Travis Askham @.***> wrote:

I think a list of names is okay but the experience Ludvig and I had with modified Stokes is that you can get some of these other kernel types from splits. That's why I was thinking something fairly general (also square root singularities sound amusing down the line). You're right that you'd need another entry in the array to determine if you want the real or imaginary part (or maybe even the complex value in some cases?)

— Reply to this email directly, view it on GitHub https://github.com/fastalgorithms/chunkie/issues/56#issuecomment-1924086693, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYRAIUXOCVWTFUJB3L3OQDYRT7XFAVCNFSM6AAAAABCRNQN52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRUGA4DMNRZGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[askhamwhat]

I'm not sure exactly how to do the general alpha case (could be a fun project for someone) but I think we wouldn't really have to implement all options at first. I was thinking of this format as trying to cover a lot of future possibilities. For now, the routine could reject the options that aren't implemented (perhaps we could start with integer options, then half integer, etc). I'm guessing there may indeed be a general calculus to this in the end but for now we could use this input and just have a bunch of special cases implemented.

Perhaps you could do the four numbers [a,b,c,d] and a string or flag or something for real part, imaginary part, complex value.

[fryklund]

Hi Travis,

I like your suggestion of having four numbers and flags for the real part, imaginary part, or complex valued.

[askhamwhat]

implemented in #105