Port Stokes to new SystemKernels

[alexfikl]

Probably better viewed commit by commit, since the second commit adds type annotations and is a bit noisy.

[Copilot]

Pull request overview

This PR updates pytential’s symbolic Stokes machinery to use Sumpy’s newer SystemKernel APIs (e.g. StokesletSystemKernel, StressletSystemKernel) instead of the older per-component kernels, while also adding/cleaning up type annotations to reduce the pyright baseline footprint.

Changes:

• Port Stokeslet/Stresslet wrapper implementations from component kernels to system kernels and replace derivative handling with AxisTargetDerivative.
• Introduce/expand typing (including ABC base operator, annotated attributes, and @override markers).
• Remove now-obsolete pyright baseline suppressions for pytential/symbolic/stokes.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
pytential/symbolic/stokes.py	Migrates symbolic Stokes wrappers/operators to SystemKernels and refactors derivative/stress expressions with added typing.
.basedpyright/baseline.json	Drops baseline entries corresponding to typing issues that are addressed by the refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[inducer]

Thanks for making this! Do you think it would also be possible to replace all the *Wrapper classes with a generic system-kernel applier? If not, what are the obstacles?

[alexfikl]

Well, using the Stokes kernels as an example (and the component order from Pozrikidis), we'd need

$$\begin{aligned} \mathcal{S} & = \int G_{ij}(x, y) q_j(y), \\\ \mathcal{S}^* & = \int G_{ji}(x, y) q_j(y) \end{aligned} \qquad \begin{aligned} \mathcal{D} & = \int n_k(y) T_{ijk}(x, y) q_i(y), \\\ \mathcal{D}^* & = \int n_k(x) T_{ijk}(x, y) q_j(y) \end{aligned}$$

where the star ones are just the adjoints. I haven't looked too much how these look for $\mathcal{S}', \mathcal{S}'', \mathcal{D}'$ since they're not very used, but once these are constructed we can probably just extend things like sym.normal_derivative to work on them (?).

Just thinking out loud a bit.. ideally, we'd have something like

apply(system_kernel, density, direction1, direction2, direction3, ...)

We can probably get away with letting the SystemKernel return a tuple of ndim - 1 indices to dot into with the first one being the density and the rest being the direction vectors. This should allow using

u=apply(stokeslet, density)
traction=apply(stresslet, density, normal, adjoint=True)
D=apply(stresslet, density, normal, adjoint=False)
sigma=apply(stresslet, density, adjoint=True)

to compute the double layer potential or the traction or the full stress tensor (i.e. skipping the normal just doesn't dot). Something like that? Not sure what else would be needed here..

[inducer]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

[alexfikl]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

Yeah, separating them is fine. The normal here would be specifically for the double layer / normal derivative type usage, right?

One thing that I'm not sure about is some of my older Stokes work, where I wanted to get the tangential stress, which, if I recall correctly was something like this

$$\tau = t_k(x) \int T_{ijk}(x, y) q_j(y) dy$$

Is this worth shoving in here somehow or is it too specific? i.e. I can contract with the density to get the "stress tensor" and then it's my job (not pytential's) to know how to contract to get the normal/tangential stress.

[inducer]

Unresolved interface issues:

• How would one do a double-layer (e.g. Laplace)?
• stress case doesn't work.
• More of Isuru's use cases.

[alexfikl]

Probably better viewed commit by commit, since the second commit adds type annotations and is a bit noisy.

[Copilot]

Pull request overview

This PR updates pytential’s symbolic Stokes machinery to use Sumpy’s newer SystemKernel APIs (e.g. StokesletSystemKernel, StressletSystemKernel) instead of the older per-component kernels, while also adding/cleaning up type annotations to reduce the pyright baseline footprint.

Changes:

• Port Stokeslet/Stresslet wrapper implementations from component kernels to system kernels and replace derivative handling with AxisTargetDerivative.
• Introduce/expand typing (including ABC base operator, annotated attributes, and @override markers).
• Remove now-obsolete pyright baseline suppressions for pytential/symbolic/stokes.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
pytential/symbolic/stokes.py	Migrates symbolic Stokes wrappers/operators to SystemKernels and refactors derivative/stress expressions with added typing.
.basedpyright/baseline.json	Drops baseline entries corresponding to typing issues that are addressed by the refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[inducer]

Thanks for making this! Do you think it would also be possible to replace all the *Wrapper classes with a generic system-kernel applier? If not, what are the obstacles?

[alexfikl]

Well, using the Stokes kernels as an example (and the component order from Pozrikidis), we'd need

$$\begin{aligned} \mathcal{S} & = \int G_{ij}(x, y) q_j(y), \\\ \mathcal{S}^* & = \int G_{ji}(x, y) q_j(y) \end{aligned} \qquad \begin{aligned} \mathcal{D} & = \int n_k(y) T_{ijk}(x, y) q_i(y), \\\ \mathcal{D}^* & = \int n_k(x) T_{ijk}(x, y) q_j(y) \end{aligned}$$

where the star ones are just the adjoints. I haven't looked too much how these look for $\mathcal{S}', \mathcal{S}'', \mathcal{D}'$ since they're not very used, but once these are constructed we can probably just extend things like sym.normal_derivative to work on them (?).

Just thinking out loud a bit.. ideally, we'd have something like

apply(system_kernel, density, direction1, direction2, direction3, ...)

We can probably get away with letting the SystemKernel return a tuple of ndim - 1 indices to dot into with the first one being the density and the rest being the direction vectors. This should allow using

u=apply(stokeslet, density)
traction=apply(stresslet, density, normal, adjoint=True)
D=apply(stresslet, density, normal, adjoint=False)
sigma=apply(stresslet, density, adjoint=True)

to compute the double layer potential or the traction or the full stress tensor (i.e. skipping the normal just doesn't dot). Something like that? Not sure what else would be needed here..

[inducer]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

[alexfikl]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

Yeah, separating them is fine. The normal here would be specifically for the double layer / normal derivative type usage, right?

One thing that I'm not sure about is some of my older Stokes work, where I wanted to get the tangential stress, which, if I recall correctly was something like this

$$\tau = t_k(x) \int T_{ijk}(x, y) q_j(y) dy$$

Is this worth shoving in here somehow or is it too specific? i.e. I can contract with the density to get the "stress tensor" and then it's my job (not pytential's) to know how to contract to get the normal/tangential stress.

[inducer]

Unresolved interface issues:

• How would one do a double-layer (e.g. Laplace)?
• stress case doesn't work.
• More of Isuru's use cases.

[alexfikl]

Probably better viewed commit by commit, since the second commit adds type annotations and is a bit noisy.

[Copilot]

Pull request overview

This PR updates pytential’s symbolic Stokes machinery to use Sumpy’s newer SystemKernel APIs (e.g. StokesletSystemKernel, StressletSystemKernel) instead of the older per-component kernels, while also adding/cleaning up type annotations to reduce the pyright baseline footprint.

Changes:

• Port Stokeslet/Stresslet wrapper implementations from component kernels to system kernels and replace derivative handling with AxisTargetDerivative.
• Introduce/expand typing (including ABC base operator, annotated attributes, and @override markers).
• Remove now-obsolete pyright baseline suppressions for pytential/symbolic/stokes.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
pytential/symbolic/stokes.py	Migrates symbolic Stokes wrappers/operators to SystemKernels and refactors derivative/stress expressions with added typing.
.basedpyright/baseline.json	Drops baseline entries corresponding to typing issues that are addressed by the refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[inducer]

Thanks for making this! Do you think it would also be possible to replace all the *Wrapper classes with a generic system-kernel applier? If not, what are the obstacles?

[alexfikl]

Well, using the Stokes kernels as an example (and the component order from Pozrikidis), we'd need

$$\begin{aligned} \mathcal{S} & = \int G_{ij}(x, y) q_j(y), \\\ \mathcal{S}^* & = \int G_{ji}(x, y) q_j(y) \end{aligned} \qquad \begin{aligned} \mathcal{D} & = \int n_k(y) T_{ijk}(x, y) q_i(y), \\\ \mathcal{D}^* & = \int n_k(x) T_{ijk}(x, y) q_j(y) \end{aligned}$$

where the star ones are just the adjoints. I haven't looked too much how these look for $\mathcal{S}', \mathcal{S}'', \mathcal{D}'$ since they're not very used, but once these are constructed we can probably just extend things like sym.normal_derivative to work on them (?).

Just thinking out loud a bit.. ideally, we'd have something like

apply(system_kernel, density, direction1, direction2, direction3, ...)

We can probably get away with letting the SystemKernel return a tuple of ndim - 1 indices to dot into with the first one being the density and the rest being the direction vectors. This should allow using

u=apply(stokeslet, density)
traction=apply(stresslet, density, normal, adjoint=True)
D=apply(stresslet, density, normal, adjoint=False)
sigma=apply(stresslet, density, adjoint=True)

to compute the double layer potential or the traction or the full stress tensor (i.e. skipping the normal just doesn't dot). Something like that? Not sure what else would be needed here..

[inducer]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

[alexfikl]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

Yeah, separating them is fine. The normal here would be specifically for the double layer / normal derivative type usage, right?

One thing that I'm not sure about is some of my older Stokes work, where I wanted to get the tangential stress, which, if I recall correctly was something like this

$$\tau = t_k(x) \int T_{ijk}(x, y) q_j(y) dy$$

Is this worth shoving in here somehow or is it too specific? i.e. I can contract with the density to get the "stress tensor" and then it's my job (not pytential's) to know how to contract to get the normal/tangential stress.

[inducer]

Unresolved interface issues:

• How would one do a double-layer (e.g. Laplace)?
• stress case doesn't work.
• More of Isuru's use cases.

[alexfikl]

Probably better viewed commit by commit, since the second commit adds type annotations and is a bit noisy.

[Copilot]

Pull request overview

This PR updates pytential’s symbolic Stokes machinery to use Sumpy’s newer SystemKernel APIs (e.g. StokesletSystemKernel, StressletSystemKernel) instead of the older per-component kernels, while also adding/cleaning up type annotations to reduce the pyright baseline footprint.

Changes:

• Port Stokeslet/Stresslet wrapper implementations from component kernels to system kernels and replace derivative handling with AxisTargetDerivative.
• Introduce/expand typing (including ABC base operator, annotated attributes, and @override markers).
• Remove now-obsolete pyright baseline suppressions for pytential/symbolic/stokes.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
pytential/symbolic/stokes.py	Migrates symbolic Stokes wrappers/operators to SystemKernels and refactors derivative/stress expressions with added typing.
.basedpyright/baseline.json	Drops baseline entries corresponding to typing issues that are addressed by the refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[inducer]

Thanks for making this! Do you think it would also be possible to replace all the *Wrapper classes with a generic system-kernel applier? If not, what are the obstacles?

[alexfikl]

Well, using the Stokes kernels as an example (and the component order from Pozrikidis), we'd need

$$\begin{aligned} \mathcal{S} & = \int G_{ij}(x, y) q_j(y), \\\ \mathcal{S}^* & = \int G_{ji}(x, y) q_j(y) \end{aligned} \qquad \begin{aligned} \mathcal{D} & = \int n_k(y) T_{ijk}(x, y) q_i(y), \\\ \mathcal{D}^* & = \int n_k(x) T_{ijk}(x, y) q_j(y) \end{aligned}$$

where the star ones are just the adjoints. I haven't looked too much how these look for $\mathcal{S}', \mathcal{S}'', \mathcal{D}'$ since they're not very used, but once these are constructed we can probably just extend things like sym.normal_derivative to work on them (?).

Just thinking out loud a bit.. ideally, we'd have something like

apply(system_kernel, density, direction1, direction2, direction3, ...)

We can probably get away with letting the SystemKernel return a tuple of ndim - 1 indices to dot into with the first one being the density and the rest being the direction vectors. This should allow using

u=apply(stokeslet, density)
traction=apply(stresslet, density, normal, adjoint=True)
D=apply(stresslet, density, normal, adjoint=False)
sigma=apply(stresslet, density, adjoint=True)

to compute the double layer potential or the traction or the full stress tensor (i.e. skipping the normal just doesn't dot). Something like that? Not sure what else would be needed here..

[inducer]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

[alexfikl]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

Yeah, separating them is fine. The normal here would be specifically for the double layer / normal derivative type usage, right?

One thing that I'm not sure about is some of my older Stokes work, where I wanted to get the tangential stress, which, if I recall correctly was something like this

$$\tau = t_k(x) \int T_{ijk}(x, y) q_j(y) dy$$

Is this worth shoving in here somehow or is it too specific? i.e. I can contract with the density to get the "stress tensor" and then it's my job (not pytential's) to know how to contract to get the normal/tangential stress.

[inducer]

Unresolved interface issues:

• How would one do a double-layer (e.g. Laplace)?
• stress case doesn't work.
• More of Isuru's use cases.

[alexfikl]

Probably better viewed commit by commit, since the second commit adds type annotations and is a bit noisy.

[Copilot]

Pull request overview

This PR updates pytential’s symbolic Stokes machinery to use Sumpy’s newer SystemKernel APIs (e.g. StokesletSystemKernel, StressletSystemKernel) instead of the older per-component kernels, while also adding/cleaning up type annotations to reduce the pyright baseline footprint.

Changes:

• Port Stokeslet/Stresslet wrapper implementations from component kernels to system kernels and replace derivative handling with AxisTargetDerivative.
• Introduce/expand typing (including ABC base operator, annotated attributes, and @override markers).
• Remove now-obsolete pyright baseline suppressions for pytential/symbolic/stokes.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
pytential/symbolic/stokes.py	Migrates symbolic Stokes wrappers/operators to SystemKernels and refactors derivative/stress expressions with added typing.
.basedpyright/baseline.json	Drops baseline entries corresponding to typing issues that are addressed by the refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[inducer]

Thanks for making this! Do you think it would also be possible to replace all the *Wrapper classes with a generic system-kernel applier? If not, what are the obstacles?

[alexfikl]

Well, using the Stokes kernels as an example (and the component order from Pozrikidis), we'd need

$$\begin{aligned} \mathcal{S} & = \int G_{ij}(x, y) q_j(y), \\\ \mathcal{S}^* & = \int G_{ji}(x, y) q_j(y) \end{aligned} \qquad \begin{aligned} \mathcal{D} & = \int n_k(y) T_{ijk}(x, y) q_i(y), \\\ \mathcal{D}^* & = \int n_k(x) T_{ijk}(x, y) q_j(y) \end{aligned}$$

where the star ones are just the adjoints. I haven't looked too much how these look for $\mathcal{S}', \mathcal{S}'', \mathcal{D}'$ since they're not very used, but once these are constructed we can probably just extend things like sym.normal_derivative to work on them (?).

Just thinking out loud a bit.. ideally, we'd have something like

apply(system_kernel, density, direction1, direction2, direction3, ...)

We can probably get away with letting the SystemKernel return a tuple of ndim - 1 indices to dot into with the first one being the density and the rest being the direction vectors. This should allow using

u=apply(stokeslet, density)
traction=apply(stresslet, density, normal, adjoint=True)
D=apply(stresslet, density, normal, adjoint=False)
sigma=apply(stresslet, density, adjoint=True)

to compute the double layer potential or the traction or the full stress tensor (i.e. skipping the normal just doesn't dot). Something like that? Not sure what else would be needed here..

[inducer]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

[alexfikl]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

Yeah, separating them is fine. The normal here would be specifically for the double layer / normal derivative type usage, right?

One thing that I'm not sure about is some of my older Stokes work, where I wanted to get the tangential stress, which, if I recall correctly was something like this

$$\tau = t_k(x) \int T_{ijk}(x, y) q_j(y) dy$$

Is this worth shoving in here somehow or is it too specific? i.e. I can contract with the density to get the "stress tensor" and then it's my job (not pytential's) to know how to contract to get the normal/tangential stress.

[inducer]

Unresolved interface issues:

• How would one do a double-layer (e.g. Laplace)?
• stress case doesn't work.
• More of Isuru's use cases.

[alexfikl]

Probably better viewed commit by commit, since the second commit adds type annotations and is a bit noisy.

[Copilot]

Pull request overview

This PR updates pytential’s symbolic Stokes machinery to use Sumpy’s newer SystemKernel APIs (e.g. StokesletSystemKernel, StressletSystemKernel) instead of the older per-component kernels, while also adding/cleaning up type annotations to reduce the pyright baseline footprint.

Changes:

• Port Stokeslet/Stresslet wrapper implementations from component kernels to system kernels and replace derivative handling with AxisTargetDerivative.
• Introduce/expand typing (including ABC base operator, annotated attributes, and @override markers).
• Remove now-obsolete pyright baseline suppressions for pytential/symbolic/stokes.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
pytential/symbolic/stokes.py	Migrates symbolic Stokes wrappers/operators to SystemKernels and refactors derivative/stress expressions with added typing.
.basedpyright/baseline.json	Drops baseline entries corresponding to typing issues that are addressed by the refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[inducer]

Thanks for making this! Do you think it would also be possible to replace all the *Wrapper classes with a generic system-kernel applier? If not, what are the obstacles?

[alexfikl]

Well, using the Stokes kernels as an example (and the component order from Pozrikidis), we'd need

$$\begin{aligned} \mathcal{S} & = \int G_{ij}(x, y) q_j(y), \\\ \mathcal{S}^* & = \int G_{ji}(x, y) q_j(y) \end{aligned} \qquad \begin{aligned} \mathcal{D} & = \int n_k(y) T_{ijk}(x, y) q_i(y), \\\ \mathcal{D}^* & = \int n_k(x) T_{ijk}(x, y) q_j(y) \end{aligned}$$

where the star ones are just the adjoints. I haven't looked too much how these look for $\mathcal{S}', \mathcal{S}'', \mathcal{D}'$ since they're not very used, but once these are constructed we can probably just extend things like sym.normal_derivative to work on them (?).

Just thinking out loud a bit.. ideally, we'd have something like

apply(system_kernel, density, direction1, direction2, direction3, ...)

We can probably get away with letting the SystemKernel return a tuple of ndim - 1 indices to dot into with the first one being the density and the rest being the direction vectors. This should allow using

u=apply(stokeslet, density)
traction=apply(stresslet, density, normal, adjoint=True)
D=apply(stresslet, density, normal, adjoint=False)
sigma=apply(stresslet, density, adjoint=True)

to compute the double layer potential or the traction or the full stress tensor (i.e. skipping the normal just doesn't dot). Something like that? Not sure what else would be needed here..

[inducer]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

[alexfikl]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

Yeah, separating them is fine. The normal here would be specifically for the double layer / normal derivative type usage, right?

One thing that I'm not sure about is some of my older Stokes work, where I wanted to get the tangential stress, which, if I recall correctly was something like this

$$\tau = t_k(x) \int T_{ijk}(x, y) q_j(y) dy$$

Is this worth shoving in here somehow or is it too specific? i.e. I can contract with the density to get the "stress tensor" and then it's my job (not pytential's) to know how to contract to get the normal/tangential stress.

[inducer]

Unresolved interface issues:

• How would one do a double-layer (e.g. Laplace)?
• stress case doesn't work.
• More of Isuru's use cases.

[alexfikl]

Probably better viewed commit by commit, since the second commit adds type annotations and is a bit noisy.

[Copilot]

Pull request overview

This PR updates pytential’s symbolic Stokes machinery to use Sumpy’s newer SystemKernel APIs (e.g. StokesletSystemKernel, StressletSystemKernel) instead of the older per-component kernels, while also adding/cleaning up type annotations to reduce the pyright baseline footprint.

Changes:

• Port Stokeslet/Stresslet wrapper implementations from component kernels to system kernels and replace derivative handling with AxisTargetDerivative.
• Introduce/expand typing (including ABC base operator, annotated attributes, and @override markers).
• Remove now-obsolete pyright baseline suppressions for pytential/symbolic/stokes.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
pytential/symbolic/stokes.py	Migrates symbolic Stokes wrappers/operators to SystemKernels and refactors derivative/stress expressions with added typing.
.basedpyright/baseline.json	Drops baseline entries corresponding to typing issues that are addressed by the refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[inducer]

Thanks for making this! Do you think it would also be possible to replace all the *Wrapper classes with a generic system-kernel applier? If not, what are the obstacles?

[alexfikl]

Well, using the Stokes kernels as an example (and the component order from Pozrikidis), we'd need

$$\begin{aligned} \mathcal{S} & = \int G_{ij}(x, y) q_j(y), \\\ \mathcal{S}^* & = \int G_{ji}(x, y) q_j(y) \end{aligned} \qquad \begin{aligned} \mathcal{D} & = \int n_k(y) T_{ijk}(x, y) q_i(y), \\\ \mathcal{D}^* & = \int n_k(x) T_{ijk}(x, y) q_j(y) \end{aligned}$$

where the star ones are just the adjoints. I haven't looked too much how these look for $\mathcal{S}', \mathcal{S}'', \mathcal{D}'$ since they're not very used, but once these are constructed we can probably just extend things like sym.normal_derivative to work on them (?).

Just thinking out loud a bit.. ideally, we'd have something like

apply(system_kernel, density, direction1, direction2, direction3, ...)

We can probably get away with letting the SystemKernel return a tuple of ndim - 1 indices to dot into with the first one being the density and the rest being the direction vectors. This should allow using

u=apply(stokeslet, density)
traction=apply(stresslet, density, normal, adjoint=True)
D=apply(stresslet, density, normal, adjoint=False)
sigma=apply(stresslet, density, adjoint=True)

to compute the double layer potential or the traction or the full stress tensor (i.e. skipping the normal just doesn't dot). Something like that? Not sure what else would be needed here..

[inducer]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

[alexfikl]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

Yeah, separating them is fine. The normal here would be specifically for the double layer / normal derivative type usage, right?

One thing that I'm not sure about is some of my older Stokes work, where I wanted to get the tangential stress, which, if I recall correctly was something like this

$$\tau = t_k(x) \int T_{ijk}(x, y) q_j(y) dy$$

Is this worth shoving in here somehow or is it too specific? i.e. I can contract with the density to get the "stress tensor" and then it's my job (not pytential's) to know how to contract to get the normal/tangential stress.

[inducer]

Unresolved interface issues:

• How would one do a double-layer (e.g. Laplace)?
• stress case doesn't work.
• More of Isuru's use cases.

[alexfikl]

Probably better viewed commit by commit, since the second commit adds type annotations and is a bit noisy.

[Copilot]

Pull request overview

This PR updates pytential’s symbolic Stokes machinery to use Sumpy’s newer SystemKernel APIs (e.g. StokesletSystemKernel, StressletSystemKernel) instead of the older per-component kernels, while also adding/cleaning up type annotations to reduce the pyright baseline footprint.

Changes:

• Port Stokeslet/Stresslet wrapper implementations from component kernels to system kernels and replace derivative handling with AxisTargetDerivative.
• Introduce/expand typing (including ABC base operator, annotated attributes, and @override markers).
• Remove now-obsolete pyright baseline suppressions for pytential/symbolic/stokes.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
pytential/symbolic/stokes.py	Migrates symbolic Stokes wrappers/operators to SystemKernels and refactors derivative/stress expressions with added typing.
.basedpyright/baseline.json	Drops baseline entries corresponding to typing issues that are addressed by the refactor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[inducer]

Thanks for making this! Do you think it would also be possible to replace all the *Wrapper classes with a generic system-kernel applier? If not, what are the obstacles?

[alexfikl]

Well, using the Stokes kernels as an example (and the component order from Pozrikidis), we'd need

$$\begin{aligned} \mathcal{S} & = \int G_{ij}(x, y) q_j(y), \\\ \mathcal{S}^* & = \int G_{ji}(x, y) q_j(y) \end{aligned} \qquad \begin{aligned} \mathcal{D} & = \int n_k(y) T_{ijk}(x, y) q_i(y), \\\ \mathcal{D}^* & = \int n_k(x) T_{ijk}(x, y) q_j(y) \end{aligned}$$

where the star ones are just the adjoints. I haven't looked too much how these look for $\mathcal{S}', \mathcal{S}'', \mathcal{D}'$ since they're not very used, but once these are constructed we can probably just extend things like sym.normal_derivative to work on them (?).

Just thinking out loud a bit.. ideally, we'd have something like

apply(system_kernel, density, direction1, direction2, direction3, ...)

We can probably get away with letting the SystemKernel return a tuple of ndim - 1 indices to dot into with the first one being the density and the rest being the direction vectors. This should allow using

u=apply(stokeslet, density)
traction=apply(stresslet, density, normal, adjoint=True)
D=apply(stresslet, density, normal, adjoint=False)
sigma=apply(stresslet, density, adjoint=True)

to compute the double layer potential or the traction or the full stress tensor (i.e. skipping the normal just doesn't dot). Something like that? Not sure what else would be needed here..

[inducer]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

[alexfikl]

So, in order to make the apply generic, given your example, we'd need something like density_contraction_axis (axes?) and normal_contraction_axis (left-over would implicitly be "output")?

Yeah, separating them is fine. The normal here would be specifically for the double layer / normal derivative type usage, right?

One thing that I'm not sure about is some of my older Stokes work, where I wanted to get the tangential stress, which, if I recall correctly was something like this

$$\tau = t_k(x) \int T_{ijk}(x, y) q_j(y) dy$$

Is this worth shoving in here somehow or is it too specific? i.e. I can contract with the density to get the "stress tensor" and then it's my job (not pytential's) to know how to contract to get the normal/tangential stress.

[inducer]

Unresolved interface issues:

• How would one do a double-layer (e.g. Laplace)?
• stress case doesn't work.
• More of Isuru's use cases.