# PyGMT v0.12.0

**URL:** <https://forum.generic-mapping-tools.org/t/pygmt-v0-12-0/4864>\
**Category:** Announcements\
**Created:** [May 4, 2024, 7:14am UTC](https://forum.generic-mapping-tools.org/t/pygmt-v0-12-0/4864 "2024-05-04T07:14:05Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![yvonnefroehlich](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/yvonnefroehlich/32/5064_2.png) [@yvonnefroehlich](https://forum.generic-mapping-tools.org/u/yvonnefroehlich)\
**Post date:** [May 4, 2024, 7:14am UTC](https://forum.generic-mapping-tools.org/t/pygmt-v0-12-0/4864/1 "2024-05-04T07:14:05Z")

</div>

**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](https://www.pygmt.org/v0.12.0)! Here are some of the highlights 🎉:

- 🚀 Almost all module wrappers (with a few exceptions) now use in-memory GMT _virtual files_ instead of intermediate temporary files to improve performance ([#2730](https://github.com/GenericMappingTools/pygmt/issues/2730))
- Almost all module wrappers (with a few exceptions) now have consistent behavior for table-like output ([#1318](https://github.com/GenericMappingTools/pygmt/issues/1318))
- Adopt [SPEC 0](https://scientific-python.org/specs/spec-0000/) policy for minimum supported versions of GMT, Python, and other core dependencies

Read through the [changelog](https://www.pygmt.org/v0.12.0/changes.html) for the full list of changes. Installation/upgrade ⬆ instructions are at [Installing — PyGMT](https://www.pygmt.org/v0.12.0/install.html)! Note that this version is cross-compatible with GMT 6.3 - 6.5, but it requires 🐍 Python 3.10+, NumPy 1.23+, Pandas 1.5+ and Xarray 2022.06+ following [SPEC 0](https://scientific-python.org/specs/spec-0000/). Go try it online at [try-gmt](https://github.com/GenericMappingTools/try-gmt) 🚀.

As usual, please feel free to report any bugs 🪲 with the [issue template on GitHub](https://github.com/GenericMappingTools/pygmt/issues/new?assignees=&labels=bug&template=bug_report.yaml). Your feedback is what helps us to improve! For example, this bug report at issue [#3104](https://github.com/GenericMappingTools/pygmt/issues/3104) sparked off a major refactoring by @seisman in PR [#3132](https://github.com/GenericMappingTools/pygmt/pull/3132) that removed a ton of workarounds in PyGMT’s codebase related to spaces and funny characters!

### 💡 Updates on Intros, Tutorials, and Gallery examples

- Gallery example [Custom symbols](https://www.pygmt.org/v0.12.0/gallery/symbols/custom_symbols.html) 🌋⚡⭐🌀: Add information on creating and plotting your _own_ Custom symbols by @yvonnefroehlich (PR [#3186](https://github.com/GenericMappingTools/pygmt/pull/3186)).
- Tutorial [Plotting text](https://www.pygmt.org/v0.12.0/tutorials/basics/text.html) 📋: Rewritten to improve the structure and to mention the support of list input for the `angle`, `justify`, and `font` parameters by @yvonnefroehlich (PR [#2760](https://github.com/GenericMappingTools/pygmt/pull/2760)).
- Intro [Table inputs](https://www.pygmt.org/v0.12.0/get_started/04_table_inputs.html) 📈: Mention the support of a list of file names, pathlib.Path objects, URLs, or remote files by @seisman (PR [#3214](https://github.com/GenericMappingTools/pygmt/pull/3214)).
- External resources [Examples from Publications and Posters](https://www.pygmt.org/v0.12.0/external_resources.html#examples-from-publications-and-posters): Add GitHub repository [gmt-pygmt-plotting](https://github.com/yvonnefroehlich/gmt-pygmt-plotting) by @yvonnefroehlich (PR [#3213](https://github.com/GenericMappingTools/pygmt/pull/3213)).

| Custom symbols | Plotting text | Table inputs |
| --- | --- | --- |
| [![Custom symbols](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/8/814c3e7624e36a7d955996c6c32b7868d2d69a15.png)](https://www.pygmt.org/v0.12.0/gallery/symbols/custom_symbols.html) | [![Plotting text](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/0/0c812e4bbd49ef17818c632d47c341a635ec8494.png)](https://www.pygmt.org/v0.12.0/tutorials/basics/text.html) | [![Table inputs](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/5/550277cc0be400c42f8d5dfb9d1a7bc0ac364bf8.png)](https://www.pygmt.org/v0.12.0/get_started/04_table_inputs.html) |

### 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](http://forum.generic-mapping-tools.org/t/paul-wessel-31-august-1959-26-march-2024/4777) 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](https://doi.org/10.1029/2023CN000231)

### 🛤 Roadmap to [v0.13.0](https://github.com/GenericMappingTools/pygmt/milestone/19)

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](https://github.com/GenericMappingTools/pygmt/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) on GitHub or the list below for things you can help with!

- Features/enhancements ✨

- Documentation improvements 📖

Please don’t be shy to [reach out on GitHub](https://github.com/GenericMappingTools/pygmt) if you’re interested in contributing 😄!

### ⚠ 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](https://github.com/GenericMappingTools/pygmt/pull/1316))

The compatibility matrix is listed at [Minimum Supported Versions — PyGMT](https://www.pygmt.org/v0.12.0/minversions.html), so make sure you keep things up to date!

### 🗺 Conference presentations/workshops/sprints

We’re looking at organizing an [AGU pre-conference workshop for GMT/PyGMT](http://forum.generic-mapping-tools.org/t/agu-2024-pre-conference-workshop/4817) this December at Washington D.C. 🏛, 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](https://www.generic-mapping-tools.org/workshops) once the schedule is confirmed around June/July.

**P.S.** Share the word on Instagram [@genericmappingtools](https://www.instagram.com/genericmappingtools/) 📸 and ResearchGate!

---

<div class="post-metadata">

**Author:** ![Joaquim](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/joaquim/32/16_2.png) [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)\
**Post date:** [May 6, 2024, 12:52pm UTC](https://forum.generic-mapping-tools.org/t/pygmt-v0-12-0/4864/2 "2024-05-06T12:52:01Z")

</div>

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

```auto
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.

---

<div class="post-metadata">

**Author:** ![seisman](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/seisman/32/4_2.png) [@seisman](https://forum.generic-mapping-tools.org/u/seisman)\
**Post date:** [May 7, 2024, 4:27pm UTC](https://forum.generic-mapping-tools.org/t/pygmt-v0-12-0/4864/3 "2024-05-07T16:27:13Z")

</div>

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.
