#857 made me realize that there is no dedicated Reference-section in the SimPEG-docs.

Example of a reference section (shameless plug): https://empymod.readthedocs.io/en/stable/references.html

I vaguely remember having talked once with @lheagy about how I handle references in empymod. But I think that was some years ago and I don't remember what we concluded. So I post it here to keep it

The tests run by pytest -S doc_doctests don't actually seem to run the doctests in the doc source files (implementation here: https://github.com/odlgroup/odl/blob/b6ed3bcb067f57c4ea668f9cc73fdef811f29659/odl/test/test_doc.py#L62-L67).

Hi, there is a small typo in the documentation of the function

reduce_to_pole

in fatiando.gravmag.transform. A square is missing in the numerator at

    RTP(k_x, k_y) = \frac{|k|}{
        a_1 k_x^2 + a_2 k_y^2 + a_3 k_x k_y +
        i|k|(b_1 k_x + b_2 k_y)}

(i.e, it should be \frac{|k|^2}{ ), same for the link

https://www.fatiando.org/api/gravmag.transform.html#fa

So far a single damping factor (epsR and epsI) can be provided to pylops.avo.prestack.PrestackInversion. However as it is known that some parameters are more constrained than others in any AVO linearisation it is useful to provide different damping factors for the different parameters to invert for.

This paper has all that is needed and this repo contains R code that could be followed.

Discretize has the possibility to get a dict of the important properties via .serialize and .deserialize, and also possibilities to .save and .load_mesh, and probably more.

It would be great if these features were better documented, best with some examples.

Make the initial setup of UQ scripts easier, by inputting various paths and parameters using SCIRun first. This could even run a few examples of what the toolkit can do as well.

Describe the bug
If eps_r is shape (N,) then the fields solved are shape (N,1)

Either:

• disallow 1-D eps_r arrays
  Or:
• keep track of eps_r shape and reshape the fields to match.

Description of the desired feature

Currently Harmonica has functions to compute distances between points defined in Cartesian coordinates or in spherical geocentric coordinates. Would be nice if we add a function to compute Euclidean distances between points whose coordinates are defined in geodetic (ellipsoidal) coordinates (don't confuse it with great circle distances).
Worth noting that

We could consider allowing callbacks that enables custom, user-defined iteration stopping.

For example, there are cases where users may want to compare unfolded distributions to data distributions and stop unfolding iterations when some condition is met (e.g. a bias-variance tradeoff). I can imagine there are many possible stopping conditions, perhaps even different stopping conditions are app