PyGMT v0.12.0

Announcements
1

Announcing PyGMT v0.12.0, faster than ever with the use of GMT virtual files!

The PyGMT team is pushing forward with version v0.12.0! Here are some of the highlights :tada::

  • :rocket: Almost all module wrappers (with a few exceptions) now use in-memory GMT virtual files instead of intermediate temporary files to improve performance (#2730)
  • Almost all module wrappers (with a few exceptions) now have consistent behavior for table-like output (#1318)
  • Adopt SPEC 0 policy for minimum supported versions of GMT, Python, and other core dependencies

Read through the changelog for the full list of changes. Installation/upgrade :arrow_up: instructions are at Installing — PyGMT! Note that this version is cross-compatible with GMT 6.3 - 6.5, but it requires :snake: Python 3.10+, NumPy 1.23+, Pandas 1.5+ and Xarray 2022.06+ following SPEC 0. Go try it online at try-gmt :rocket:.

As usual, please feel free to report any bugs :beetle: with the issue template on GitHub. Your feedback is what helps us to improve! For example, this bug report at issue #3104 sparked off a major refactoring by @seisman in PR #3132 that removed a ton of workarounds in PyGMT’s codebase related to spaces and funny characters!

:bulb: Updates on Intros, Tutorials, and Gallery examples

Custom symbols Plotting text Table inputs
Custom symbols Plotting text Table inputs

In memory of Paul Wessel

We’d like to take a moment here to reflect on the passing of Pål (Paul) Wessel, who has been instrumental in the development and maintenance of the Generic Mapping Tools (GMT) library over the past four decades. More details are at Paul Wessel, 31 August 1959 - 26 March 2024 on how you can visit the memorial website Pål’s family has shared to look over photos, share memories, donate to continue Pål’s legacy at SOEST (University of Hawaiʻi), and find out about the Pål’s Celebration of Life event planned for May 26th.

“I do hope that among the thousands of GMT users there will be a small subset who feel perhaps they should give back by involving themselves at some level in the GMT community and thus ensure GMT will not disappear overnight when I do.”

From: Wessel, P. (2024). The Origins of the Generic Mapping Tools: From Table Tennis to Geoscience. Perspectives of Earth and Space Scientists , 5 (1), e2023CN000231. https://doi.org/10.1029/2023CN000231

:railway_track: Roadmap to v0.13.0

While the team has been busy refactoring the internals of PyGMT in recent releases, there are still lots of documentation and new features we’d like to add! Check out the good first issue label on GitHub or the list below for things you can help with!

  • Features/enhancements :sparkles:

    • Wrap clip, coupe, earthtide, fitcircle, movie, polar, and sac
    • Implement high-level methods of Figure.plot and Figure.plot3d (#2797): Figure.scatter, Figure.hlines (#923) and Figure.vlines (#670), Figure.choropleth, Figure.errorbar, Figure.stem, Figure.fill_between
    • Implement high-level methods of Figure.basemap or Figure.coast (#2831): Figure.scale_bar, Figure.directionrose, Figure.magneticrose

  • Documentation improvements :book:

    • Add a beginner :beginner: friendly PyGMT tutorial that is a good roadmap for new GMT/PyGMT users (#770)
    • Add a tutorial explaining the generally accepted input types (#1268)

Please don’t be shy to reach out on GitHub if you’re interested in contributing :smile:!

:warning: Upcoming deprecations

  • v0.13.0
    • Figure.timestamp: Remove parameter justification, use justify instead (FutureWarning raised since PyGMT v0.11.0)
  • v0.14.0
    • Figure.grdcontour: Disallow passing list[str] arguments to the annotation parameter (e.g. [100, "e", "f10p", "gred"]), pass in a string like 100+e+f10p+gred instead (FutureWarning raised since PyGMT v0.12.0)
    • pygmt.helpers: Remove the build_arg_string function, use build_arg_list instead (FutureWarning raised since PyGMT v0.12.0)
    • Remove the sequence_plus converter, only used for the annotation parameter of Figure.grdcontour (FutureWarning raised since PyGMT v0.12.0)
  • v0.15.0
    • pygmt.clib: Remove the open_virtual_file method, use open_virtualfile instead (FutureWarning raised since PyGMT v0.11.0)
    • pygmt.clib: Remove the virtualfile_from_data method, use virtualfile_in instead
  • v0.16.0
    • Figure.grdcontour: Remove parameter interval, use levels instead (FutureWarning raised since PyGMT v0.12.0)
  • v1.0.0
    • Short form aliases (e.g. R) will not work if long form aliases (e.g. region) are available (SyntaxWarning raised since PyGMT v0.4.0, see #1316)

The compatibility matrix is listed at Minimum Supported Versions — PyGMT, so make sure you keep things up to date!

:world_map: Conference presentations/workshops/sprints

We’re looking at organizing an AGU pre-conference workshop for GMT/PyGMT this December at Washington D.C. :classical_building:, so mark your calendars! This will be an in-person, full-day workshop, and we will post more details on the forum and at Workshops — The Generic Mapping Tools once the schedule is confirmed around June/July.

P.S. Share the word on Instagram @genericmappingtools :camera_with_flash: and ResearchGate!

6 Likes
2

Congrats. That is a big evolutionary step.

I am curious about the virtual files usage now. Does it mean that we can now have grids, images, datasets objects available on command line for further manipulation or is its usage a internal implementation detail?

For example, if using GMT.jl in Python we can do

In [1]: from juliacall import Main as jl

In [2]: jl.seval("using GMT")

In [3]: G = jl.grdcut("@earth_relief_01d", R=(0,45,0,45))

In [4]: jl.info(G)
A GMTgrid object with 1 layers of type Float32
title: Produced by grdcut� v2.5.5 at 01 arc degree
remark: Reduced by Gaussian Cartesian filtering (314.5 km fullwidth) from SRTM15_V2.5.5.nc [Tozer et al., 2019; https://doi.org/10.1029/2019EA000658]
command: gmt grdcut @earth_relief_01d_g -R0/45/0/45 -G@GMTAPI@-S-O-G-G-G-N-000000
Gridline node registration used
x_min: 0.0      x_max :45.0     x_inc :1.0      n_columns :46
y_min: 0.0      y_max :45.0     y_inc :1.0      n_rows :46
z_min: -4909.0  z_max :2359.5
Mem layout:     BCB
PROJ: +proj=longlat +datum=WGS84 +units=m +no_defs
46×46 Matrix{Float32}:
 -4876.0  -4760.5  -4500.5  -4305.5  -4092.0  -3776.0  -3006.5  -2596.0  -2099.0   -437.5    107.0    334.0
...

and the G variable contains the in-memory grid.

3

Currently, only virtualfiles for grids and datasets are implemented (images and cubes are WIP), and these virtualfiles are only used for storing the output grids/datasets. So, it’s still an internal implementation detail and is not exposed to users like GMT.jl already does.