John Omotani

Edited to note need to use `bndry_par_yup`, `bndry_par_ydown` or `bndry_par_all` settings.

Ah, I never thought about creating the metrics from an input file when I was writing the staggered coordinates stuff! I agree passing location to `Mesh::get()` is the way to...

Partially (?) fixed by #1097, #1661. Could be properly fixed by making use of corner cells after changes in #1885.

Yes, units would be very nice to have too. Should be easy to add in a similar way; I guess 'description' and 'units' should be enough, at least for standardised...

> If it doesn't have parallel slices, should it not just set the boundaries in the non-slice cells, i.e. don't use `yup/ydown`? Ideally yes, but the boundary value calculated is...

@ZedThree I think this PR still needs a test, and `periodicX` needs some mention in the docs. Do we want to fix those here, or get this merged now and...

@jonycastagna: * have you checked whether your build issue is related to this PR (e.g. can you compile the current `next` branch?)? I suspect it is not related to this...

Another possibly nice-to-have thing: if we allocated all our arrays with `fftw_malloc()` (using some change under the hood in `Array`), it's possible to use an FFTW plan with arbitrary input...

Thanks @ZedThree! The current labels look weird to me too (above the equation and centred).

Not sure it's a sphinx issue though - when I build the html docs on my laptop, the equation numbers look nice (placed to the right of the equations).