Progress Report 2017-3-28¶
Since the previous progress report (delivered live at Scripps during the summit in August 2016; see link at bottom of page) there has been much activity. Due to Wessel going on a research cruise from November to January our quarterly report has been delayed. Here are the biggest developments since the last report:
- We successfully carried out the recruitment of a post-doctoral researcher to take the lead on building the Python GMT module. On February 15. 2017, Dr. Leonardo (Leo) Uieda joined our team and is now working with Wessel at UH on this task.
- We have released several GMT versions (4.5.15, 5.3.0, 5.3.1., 5.3.2), culminating with version 5.3.3 on March 23, 2017.
- We have researched and procured a new GMT server that will allow us to implement Continuous Integration (automatic test suite every time repository changes, across all operating systems) and Florian is (remotely) configuring the new server. We hope to move all server operations to the new server this spring, Florian's schedule permitting. Leo will also help with this task.
- We are addressing many of the topics that the steering committee brought to our attention (see link to their report at bottom of page). One particular issues was the backwards compatibility. This is a tricky issue because of finite resources. We have to move forwards and some things will be left behind. However, we will re-implement the old-style GMT 4 arrow symbol to allow existing GMT4 scripts to produce the expected plot, and we will hold our collective noses in the process.
- We are also making changes to simplify GMT. To this end we are experimenting with a new GMT_RUNMODE setting which can be either classic or modern. Classic is what you are all familiar with. Modern adds numerous simplifications that especially new users will find very appealing (and even old-timers may like this). I will elaborate on this below. It is to a large extent driven by needs from the emerging standards for using GMT from MATLAB, Octave, Julia, and soon Python.
- We are starting to use the GMT API within the GMT modules more. For instance, grdimage typically takes an external grid for intensities (shading) but in 99% of the cases this is derived from the grid to be imaged (via a separate grdgradient call). We now have shorthands via grdimage's -I option that automatically calls grdgradient for you. The same applies to grdview, and we are adding additional features through GMT. This will become part of GMT 5.4.
- Both the GMT team and Dave Sandwell (GMTSAR) contributed sub-contract proposals to the National Geophysical Observatory proposal by UNAVCO. If funded it will provide long-term support for GMT in that NGO will be the stewards of GMT and take over all the aspects of maintaining servers and wikis and offer workshops, leaving the GMT developers to what they are most suited for: develop and maintain. Hopefully this will survive the Trump axes.
To give you an idea of what the modern mode entails, here are the highlights:
- The GMT cake-baking recipe of having to juggle -O -K is no longer used. Those options are ignored.
- The PostScript that is being produced is maintained under the hood: there is no longer any redirection and appending to a file.
- Options -R -J are only needed the very first time to set the region and projection. No longer need to give empty -R -J to indicate the previous setting.
- We are experimenting with auto-generating a valid -R from the input data itself.
- A plot is finalized when gmt psconvert is called. It will produce whatever product the user wants, which may be the PostScript file but more likely the PDF or an image
As you can imagine, this greatly simplifies scripting and eliminates the two hardest problems in GMT usage: Not mess up with -O -K, and not mess up with bad redirection and appending. Using this syntax by default in the new external APIs will make GMT more appealing to such users as well.
I expect that my next report this summer will give you an update on this aspect. Leo has started writing a Python script for converting classic scripts to the modern syntax. Our main concern is our 600+ test and documentation scripts which follows a set layout (standardized way of assigning plot output name, etc) but eventually it will handle any classic script. The code for this is hosted at https://github.com/GenericMappingTools/gmtmodernize.
For the GMT Team,
Paul Wessel, March 28, 2017