Extend Stokes tests to 3d

[alexfikl]

Has the following additions

• Gathers the operator for 2d exterior Stokes flow from Hsiao and Kress 1985 into a HsiaoKressExteriorStokesOperator that looks similar to the ones in symbolic.pde.scalar. This was previously scattered in test_stokes.
• Adds a new 3d exterior Stokes operator from Hebeker 1986.
• Adds tests for both of them closer to what's in test_scalar_int_eq.

[alexfikl]

Note to self: these currently run, but don't converge :(

[inducer]

Thanks for working on this! It might be useful to coordinate with @isuruf, who is working on improved support for Stokes from the expansion end.

[alexfikl]

Thanks for working on this! It might be useful to coordinate with @isuruf, who is working on improved support for Stokes from the expansion end.

Sure. Hopefully they don't intersect too much, since this doesn't touch any of the stuff in StokesletWrapper and StressletWrapper.

[alexfikl]

I played with this a little more and the 2D case looks believable. The errors it gives are

h	Error	Running EOC
0.471239	2.58493e-05
0.269279	2.14650e-06	4.44
0.188495	4.10728e-07	4.63

In 3D, something is weird and it doesn't quite seem to converge properly. The density looks a bit piecewise too. Is that just because it's just not refined enough?

h	Error	Running EOC
1.953120	0.0127851305633298
0.987596	0.0050672330807967	1.357
0.495535	0.0030170224494500	0.751

[inducer]

I agree that the density looks suspicious. Have you tried generously dousing the problem in quadrature resolution?

[alexfikl]

Found some time to play with this a bit more and checked just oversampling more. The tables are for x4, x6, x8 oversampling.

h	Error	EOC
1.9550946032720538	0.0034877836269566267
0.9910378795717739	0.0016482227922434503	1.103
0.4961416850626058	0.0016128199135288116	0.031

h	Error	EOC
1.9550946032720538	0.00012531643654912475
0.9910378795717739	2.7004374541610817e-06	5.647
0.4961416850626058	4.6939213355632876e-07	2.528
0.2480926994176438	2.5599775955256034e-07	0.874

h	Error	EOC
1.9550946032720538	9.663888733592458e-05
0.9910378795717739	4.1176079755284613e-07	8.033
0.4961416850626058	1.931213475040549e-09	7.750

Looking at the density in the x8 case, it looks a lot nicer than the one for the x4 case from before.

These errors and convergence still looks very fishy to me. It has a 3rd order QBX and 3rd order discretization and the quadrature is 12, 18, 24, so I'm not sure where the numbers above are coming from.

[inducer]

Thanks for working on this! I agree that the convergence data is a bit strange. My main two concerns:

• It looks like at least the x4 and x6 cases bottom out in terms of convergence. I'm guessing that's quadrature error.
• I wonder what drives this hunger for source resolution. I'm not sure I have a conjecture, but I sure would like to see a QBX integrand evaluated on the mesh...

Nonetheless, I think this is better off merged than not, especially given that

• the x8 data look "clean enough", and
• the tests aren't close to the "leader board" of slow tests.

What do you think?

[alexfikl]

What do you think?

I agree that it's better to merge this and leave figuring out the convergence for some other time.

the tests aren't close to the "leader board" of slow tests.

That's because they were marked as slowtest and weren't actually running on the CI 😁.

I've changed that to only mark the 3D case as slow, since the 2D case is running pretty well locally. I imagine it will be a bit slower on the CI, since it needs to generate quite a few loopy/sumpy kernels, but nothing too bad.

[inducer]

LGTM, thanks! Filed #45 so that we don't lose track that there's still something buried here.