Goal-oriented point discharge 2D demo doesn't converge

[ddundo]

The anisotropic part of the point_discharge2d-goal_oriented.py demo doesn't converge in the maximum set 35 iterations.

[ddundo]

 1, complexity:  400, dofs:  531, elements: 1007
 2, complexity:  600, dofs:  771, elements: 1499
 3, complexity:  800, dofs:  977, elements: 1911
 4, complexity: 1000, dofs: 1232, elements: 2418
 5, complexity: 1000, dofs: 1272, elements: 2498
 6, complexity: 1000, dofs: 1246, elements: 2445
 7, complexity: 1000, dofs: 1264, elements: 2482
 8, complexity: 1000, dofs: 1266, elements: 2486
 9, complexity: 1000, dofs: 1289, elements: 2533
10, complexity: 1000, dofs: 1368, elements: 2691
11, complexity: 1000, dofs: 1344, elements: 2643
12, complexity: 1000, dofs: 1301, elements: 2556
13, complexity: 1000, dofs: 1281, elements: 2516
14, complexity: 1000, dofs: 1381, elements: 2714
15, complexity: 1000, dofs: 1325, elements: 2603
16, complexity: 1000, dofs: 1342, elements: 2639
17, complexity: 1000, dofs: 1399, elements: 2750
18, complexity: 1000, dofs: 1342, elements: 2636
19, complexity: 1000, dofs: 1290, elements: 2535
20, complexity: 1000, dofs: 1272, elements: 2498
21, complexity: 1000, dofs: 1253, elements: 2461
22, complexity: 1000, dofs: 1291, elements: 2539
23, complexity: 1000, dofs: 1280, elements: 2516
24, complexity: 1000, dofs: 1369, elements: 2691
25, complexity: 1000, dofs: 1323, elements: 2597
26, complexity: 1000, dofs: 1307, elements: 2568
27, complexity: 1000, dofs: 1324, elements: 2602
28, complexity: 1000, dofs: 1335, elements: 2626
29, complexity: 1000, dofs: 1259, elements: 2476
30, complexity: 1000, dofs: 1312, elements: 2582
31, complexity: 1000, dofs: 1279, elements: 2517
32, complexity: 1000, dofs: 1252, elements: 2462
33, complexity: 1000, dofs: 1250, elements: 2458
34, complexity: 1000, dofs: 1320, elements: 2598
35, complexity: 1000, dofs: 1281, elements: 2520
Failed to converge on subinterval 0 in 35 iterations.

But it converges on the branch on_the_fly_v1 which doesn't make use of yield functionality, but the convergence output is the same as above:

 1, complexity:  400, dofs:  531, elements: 1007
 2, complexity:  600, dofs:  771, elements: 1499
 3, complexity:  800, dofs:  977, elements: 1911
 4, complexity: 1000, dofs: 1232, elements: 2418
 5, complexity: 1000, dofs: 1272, elements: 2498
 6, complexity: 1000, dofs: 1246, elements: 2445
 7, complexity: 1000, dofs: 1264, elements: 2482
 8, complexity: 1000, dofs: 1266, elements: 2486
Element count converged after 8 iterations under relative tolerance 0.005.

[jwallwork23]

So does this suggest that the use of yield has broken this demo?

If not then we should use git bisect to find the breaking change.

edit: ignore me - I now see that your PR closes this.

[ddundo]

Yup, all good! I'll merge after the CI things pass (no rush at all).

But on a side note... if you look at the full 35 iterations, do you have an idea why it becomes so "unstable" past the 8th iteration? It almost feels accidental that it converges - meshes are somewhat dissimilar and qoi value doesn't converge. I've noticed the same in my Hessian-based glacier example, where I didn't ramp up complexity, that the first few iterations would be quite nice and seem to converge, but then it suddenly goes wrong.

I'm wondering if we could somehow try to prevent this and avoid potentially large mesh changes. Would it be unreasonable to somehow combine the iteration k-1 metric with iteration k metric when adapting the mesh at kth iteration?

[jwallwork23]

I looked into this a bit the other day. I wonder if we could introduce some "stalling" criteria (e.g., one of the quantities has "almost" converged, but is oscillating) and then, when this is detected turn off one of the adaptation operations. I found that as soon as you set dm_plex_metric_no_insert it converges at the next iteration. To me it would make sense to turn off node insertion/deletion if the DoF count is near convergence, for example.

[ddundo]

That does sound sensible - thanks for checking! Although the meshes seem to almost oscillate between fine/coarse resolution at source/receiver in one iteration, and vice versa in the next. That's what made me think it would be good to somehow prevent big changes between iterations.

But not too important either way probably :) so I'll let you decide if you want to open a new issue about it

[jwallwork23]

@acse-ej321 I gather you have been working on switching between adaptation methods so thought you might find this discussion interesting.