PR #76 removed the Digital Rocks Portal data repository because their SSL certificate is messed up. We should add it back eventually when the site is back up. Here is the entry:

- [Digital Rocks Portal](https://www.digitalrocksportal.org/) – Powerful data portal for images of varied porous micro-structures

For any developers who want to develop custom supplements, they need to have a src subdirectory, some C codes, and most importantly, a CMakeLists.txt file.

Here is a full list of all CMake settings that can be included in the CMakeLists.txt:

# SUPPL_NAME [required]
#	name of the supplement package. It can be different from the directory name.
set (SUPPL_NAME newsuppl1)

# SUPPL_PROGS_

Description of the problem

Even though it's in the title, our map 🗺️ tutorial for setting map frames, ticks, titles and labels doesn't actually teach us how to set a title!

Bug report

Bug summary

The example shown here:

https://yt-project.org/docs/dev/visualizing/plots.html#plots-of-2d-datasets

shows the classic windtunnel with a step test problem. In this problem, the l

#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

Description of the desired feature

Verde has utilities for selecting scattered spatial data based on windows and blocks (block_split and the new rolling_window). We don't really have any examples or tutorial

Analogous to dict.get but with extra "add" kwarg.

SectionItems.get should accept strings or HeaderItem objects for the "default" arg. If it is a string, it should be converted to a HeaderItem with the appropriate mnemonic.

Always returns a HeaderItem.

If add is True, the returned value should also be appended to the SectionItems instance.

How do we handle CurveItems? Set the data attribute to

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

Right now only does 3. Should be easy.

Should maybe just be able to pass in a list of logs.

Calling it a bug.

I think the following methods should take a keys argument (e.g. in case you want the All and Each tests to run on some subset of curves... or would that be confusing?):

• qc_curve_group()
• qc_data()
• qc_Table_html()

We need to refactor a lot of internal code to leverage PyVista over the native VTK dataset adapters and custom array converters that we have in here which should drastically speedup some filters.

The PVGeo.interface module will need to be completely overhauled to use PyVista as everything in there should have a better implementation in PyVista at this point.

IDL> a=hdf_open(/create)

a=hdf_open(/create)
                   ^
% HDF_OPEN: Incorrect number of arguments.

GDL> a=hdf_open(/create)
% HDF_OPEN: Variable is undefined: <Undefined>
% Execution halted at: $MAIN$  

Probably a bug.

Right now the seismic image has to be smaller than the stained paper.

Could save 'stupid' at a max width, if that's easy to do.

First off, the amount of documentation for MTfit is really excellent. Thank you for putting in the time. It makes the package accessible to a wider audience.

There are a couple of places where the input parameters could benefit from additional details.

On the following page: https://djpugh.github.io/MTfit/inversion.html

Azimuth: numpy matrix of azimuth values in degrees

Is this f

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