Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (926fb1c) 82.30% compared to head (b66482a) 82.30%.

@@            Coverage Diff             @@
##             main    #1299      +/-   ##
==========================================
- Coverage   82.30%   82.30%   -0.01%     
==========================================
  Files         165      165              
  Lines       25244    25241       -3     
==========================================
- Hits        20778    20775       -3     
  Misses       4466     4466              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks @domfournier for this, and sorry leaving you waiting for this review.

I think this is ready to be merged. I just pushed a small change to improve the test function: now it runs the same test in the three orientations, not only on "y". I also renamed the function to be more descriptive.

Let me know what do you think. If you like it, ping me so I can merge this.

BTW, I just opened #1333 that it's related to this. If you can take a look at it, that would be great.

Looks good man. I pushed a small fix to address your question on #1333 . Result looks good. Good to go on this end.

I get a line search failure with this @jcapriot

def coterminal(theta):
    return (theta + np.pi) % (2 * np.pi) - np.pi

I don't think that's quite it, since the modulo in python takes the sign of the dividor. For example

coterminal(-np.pi - np.pi/4) -> 3/4 np.pi

But would expect -pi/4

But this works

coterminal = np.sign(theta) * (np.abs(theta) % np.pi)

I get a line search failure with this @jcapriot

def coterminal(theta):
    return (theta + np.pi) % (2 * np.pi) - np.pi

I don't think that's quite it, since the modulo in python takes the sign of the dividor. For example

coterminal(-np.pi - np.pi/4) -> 3/4 np.pi

But would expect -pi/4

But this works

coterminal = np.sign(theta) * (np.abs(theta) % np.pi)

$3\pi/4$ is the correct coterminal angle for $-\pi - \pi/4=-5\pi/4$

Why did you put a negative in front there?:

coterminal = -((theta + np.pi) % (2 * np.pi) - np.pi)

instead of

coterminal = (theta + np.pi) % (2 * np.pi) - np.pi

Forget about the negative sign. I think we need to preserve the sign of the incoming angle.

We can argue all day about what the true coterminal should be mathematically, in the end we need the example in 03-magnetics/plot_inv_mag_MVI_Sparse_TreeMesh to return a smooth model, and not get weird stuff on the wrap around [-pi, pi]. That was the intent of this function.

Not this

What layer are you cutting this at? Just so I can compare locally later this evening. I think I understand what you’re saying regarding what needs to happen during minimization. Just need to test a few things.

Also probably the easiest way to “undo” the cell difference would be to just use dA = cell_gradient.sign() @ angles instead of dA= cell_distances * cell_gradient @ angles

I sliced it at the same index, but Z axis. Also adjusted the limits to [-75, 75] for close up.

Also probably the easiest way to “undo” the cell difference would be to just use dA = cell_gradient.sign() @ angles instead of dA= cell_distances * cell_gradient @ angles

Sounds good. Done.
I reverted the changes to coterminal as requested by @santisoler , to be addressed instead on PR #1334

So these are the current results I'm getting on main:


These results mostly agree with what's on the current documentation page:
https://docs.simpeg.xyz/content/examples/03-magnetics/plot_inv_mag_MVI_Sparse_TreeMesh.html#sphx-glr-content-examples-03-magnetics-plot-inv-mag-mvi-sparse-treemesh-py

These are the results I'm getting with this PR:

Forget about the negative sign. I think we need to preserve the sign of the incoming angle.

We can argue all day about what the true coterminal should be mathematically, in the end we need the example in 03-magnetics/plot_inv_mag_MVI_Sparse_TreeMesh to return a smooth model, and not get weird stuff on the wrap around [-pi, pi]. That was the intent of this function.

I totally agree that the ultimate goal is to penalize non-smoothness in the neighboring angles in the model. That's also why I suggested of fixing the bug in coterminal in a separate PR: it's related to this one, but in the end they are different things.

I think the problem here is that we need to compute angles differences for each neighboring pair, and having a single array of coterminal angles moved to $[-\pi, \pi)$ (or any other interval of length of $2\pi$) won't solve it.

For example, if we have theta_1 = np.pi - 0.001 and theta_2 = -np.pi + 0.001, their difference is just 0.002, but if we compute the differences between their coterminal angles we'll get 2 * np.pi - 0.002, leading to an unwanted penalization for the smoothness of these two.

I think the solution is to have a function that can compute the difference between two angles that's smaller or equal than np.pi.

Forget about the negative sign. I think we need to preserve the sign of the incoming angle.
We can argue all day about what the true coterminal should be mathematically, in the end we need the example in 03-magnetics/plot_inv_mag_MVI_Sparse_TreeMesh to return a smooth model, and not get weird stuff on the wrap around [-pi, pi]. That was the intent of this function.

I totally agree that the ultimate goal is to penalize non-smoothness in the neighboring angles in the model. That's also why I suggested of fixing the bug in coterminal in a separate PR: it's related to this one, but in the end they are different things.

I think the problem here is that we need to compute angles differences for each neighboring pair, and having a single array of coterminal angles moved to [−π,π) (or any other interval of length of 2π) won't solve it.

For example, if we have theta_1 = np.pi - 0.001 and theta_2 = -np.pi + 0.001, their difference is just 0.002, but if we compute the differences between their coterminal angles we'll get 2 * np.pi - 0.002, leading to an unwanted penalization for the smoothness of these two.

I think the solution is to have a function that can compute the difference between two angles that's smaller or equal than np.pi.

I think it's important to point out that we are already computing the coterminal angle after taking differences.

In the meantime, this looks fine to me now, only issue is that the second order smoothness isn't being tested here (but it wasn't before either).

Ok so can we move this one forward, and battle it out further on #1334 ?

So these are the current results I'm getting on main: These results mostly agree with what's on the current documentation page: https://docs.simpeg.xyz/content/examples/03-magnetics/plot_inv_mag_MVI_Sparse_TreeMesh.html#sphx-glr-content-examples-03-magnetics-plot-inv-mag-mvi-sparse-treemesh-py

The top plot is the smooth Cartesian result, no problem there. This what the smooth Spherical looks like on main