Unintended behaviour of `SimPEG.utils.coterminal`? about simpeg HOT 10 CLOSED

cc @domfournier

from simpeg.

Hmm ok clearly the sign flip is not good. The idea of this function is to always return the complementary angle, exactly for the reason you've mentioned (i.e. two angles that are close to each other but in different quadrants). Coterminal is called after computing the gradient (normalized difference) between the angle values. But yea, the negative is no good. We should fix it directly on #1299

from simpeg.

Nice little catch, Fortunately I don't think it was causing any issues in the way that we were using it, as we calculated co-terminal angles AFTER doing a difference (not before) so the sign flip wouldn't have mattered.

from simpeg.

But it actually does, just by visual inspection of the example/03-magnetic/plot_inv_mag_MVI_Sparse_TreeMesh

This is the XY slice through the model - where the coterminal manners: (ignore the title, this is the spherical result)

Old (with -)

New (without -)

Really seems to improve getting smooth direction.

from simpeg.

That improvement just seems odd to me...
for reference here are the three methods that we've been talking about:

from simpeg.

The "modulus" is the most correct way of doing this, the current method will over-do angle differences larger than $2\pi$, but that shouldn't happen with how the inversion will reset angles larger than that. The proposed method is incorrect for angles beyond $\pi$, and the negative for those values is not taken into account in the derivative.

from simpeg.

Also, scary behavior here is that the coterminal calculation actually modifies it's argument in-place.

from simpeg.

Agree on the modulus, although angle > pi would never happen in the inversion since we always reproject on [-pi, pi].

from simpeg.

The angles themselves are always projected onto the interval $[-\pi,\pi]$, but it’s certainly possible the difference of two angles would then be on the interval of $[-2\pi,2\pi]$

from simpeg.

True

from simpeg.