Need feedbacks on the Jupyter lab for trying GMT and its wrappers online

[seisman]

This repository sets up a single Jupyter lab environment, with the latest/stable GMT, PyGMT, and GMT.jl installed. The idea and some contents of this repository are from our older projects, gmt6demo, try-gmt-python, and foss4g2019oceania.

Anyone can run GMT commands (i.e., in bash), PyGMT, and GMT.jl in this online Jupyter lab, with no need to install anything locally.

I believe this Jupyter lab would be useful for both new and old GMT users who want to try GMT and its wrappers before spending some time setting up a local environment. It also provides a uniform environment for future GMT workshops and short courses, so that we don't have to spend hours solving the GMT installation problems (I'm not sure about its performance if dozens of peoples use it simultaneously).

The Jupyter lab is freely hosted by Pangeo Binder. You can try it by clicking the badge below:

it usually takes <30 s to launch the Jupyter lab, the you can try the three demos for bash, Python, and Julia, respectively.

Future Plans

Here are some of my thoughts to improve it:

• [x] Cache the low-resolution (>06m) earth relief data so that users don't have to wait for downloading them [Done in #4]
• [ ] Install a few extra Python packages (e.g., scipy, matplotlib) and Julia packages to make it more suitable for practical plots
• [ ] Create a dev branch and set up another Jupyter lab environment with the master/unstable/developing GMT, PyGMT, and GMT.jl installed.
• [x] Host it on Google's colab servers (also free), which seem faster.
• [x] Post it on the GMT forum to increase its visibility (https://forum.generic-mapping-tools.org/t/try-gmt-pygmt-gmt-jl-online-at-pangeo-binder/561)
• [x] Add a "Try it online!" menu on the GMT homepage to increase its visibility (https://github.com/GenericMappingTools/website/pull/71)
• [ ] Add "Try it online!" badges to the README file of GMT, PyGMT and GMT.jl repositories?

Any thoughts and suggestions? @GenericMappingTools/core @GenericMappingTools/gmt-contributors @GenericMappingTools/python @GenericMappingTools/python-contributors

[PaulWessel]

This is very cool! I support having a link to this on the webpage. I tried the Python example and wonder if we can improve the colorbar. It defaults to the full range and the number of slices but these are not good annotation markers in the colorbar. Might you default to the equivalent of -Baf if no arguments are set to avoid this?

[seisman]

I tried the Python example and wonder if we can improve the colorbar. It defaults to the full range and the number of slices but these are not good annotation markers in the colorbar. Might you default to the equivalent of -Baf if no arguments are set to avoid this?

That's a known issue of GMT 6.0.0 and was already fixed in GMT master branch. With GMT master branch, it looks like:

[liamtoney]

This is awesome. Will be very helpful for e.g. https://github.com/GenericMappingTools/pygmt/issues/433

[joa-quim]

Thanks a lot, this will be very useful. Will explore later. Now must dive in the debugger for a while.

[weiji14]

Great work! We should definitely increase the visibility of this on the forum and website :smile:

It also provides a uniform environment for future GMT workshops and short courses, so that we don't have to spend hours solving the GMT installation problems (I'm not sure about its performance if dozens of peoples use it simultaneously).

I've tested Pangeo binder during the FOSS4G 2019 Oceania workshop on 9 people, and it seems to work well. The only snag is that it will time out after 30 minutes of inactivity, i.e. no long coffee breaks :laughing:

There's also the non-Pangeo binder , which feels somewhat slower (and defaults to Jupyter notebook instead of Lab) as more people use it, but is useful as a backup in case the Pangeo one doesn't work for some reason. I think the non-Pangeo binder allow up to 100 people according to https://mybinder.readthedocs.io/en/latest/user-guidelines.html#maximum-concurrent-users-for-a-repository, not sure about the Pangeo binder, but I don't expect us hosting a 100+ people workshop anytime soon.

* Cache the low-resolution (>06m) earth relief data so that users don't have to wait for downloading them

Yes, this is definitely a must, though it might slow down the initial build time. Just need to trigger the docker build before a workshop/hackathon/whatever, and subsequent launches will be super fast.

* Host it on [Google's colab servers](https://colab.research.google.com/) (also free), which seem faster.

Here's the button: . Cons are you'll need a google login, and it doesn't install the dependencies like Pangeo Binder does. Pros are it's faster (I guess?), and you can save your notebooks.

[joa-quim]

@seisman can you also install the pyjulia package. That allows to alternatively run the julia wrapper from python.

[leouieda]

Thanks @seisman this is really cool! Yes, Jupyter Lab would be the way to go. You could have gmt scripts, run them in the built in terminal and open the output png/pdf files in Jupyter lab.

Since it’s only meant as a demo, there is no problem if it times out after a while. We should probably warn people not to use this for actual work.

[maxrjones]

Each of the environments hosted on MyBinder take 2-4 minutes to start. @seisman, do you know if this is should be expected? Upon starting, I receive the warning

Build Recommended 
JupyterLab build is suggested: 
jupyter-offlinenotebook needs to be included in build.

This warning does not pop up for the Google Colab version, which loads in a few seconds.

[seisman]

Each of the environments hosted on MyBinder take 2-4 minutes to start. @seisman, do you know if this is should be expected?

Yes, the one hosted on pangeo may be the fatest one, usually less than 30 seconds.

Upon starting, I receive the warning

Build Recommended 
JupyterLab build is suggested: 
jupyter-offlinenotebook needs to be included in build.

I think this is something new in recent jupyter versions (see https://github.com/jupyterhub/mybinder.org-deploy/issues/1607). I haven't find the solution yet.

This warning does not pop up for the Google Colab version, which loads in a few seconds.

Yes, but for Google colab, users have to install conda and all packages themselves, which may take one or more minutes after starting up.

[maxrjones]

Thanks for the clarification. This is a great resource, I agree that it will be really useful.

[maxrjones]

The launch time seems much slower than before (~15 minutes before), which seems to be related to a non-zero exit code for the RUN JULIA_PROJECT command.

In a more general sense, do you have expectations for whether the launch time is much greater for all three programs (GMT, PyGMT, GMT.jl) versus if these had separate environments? i.e., is most of the time associated with installing core GMT and its dependencies or the Julia/Python environments? I am not sure how often people would want to try all three, versus being interested in a particular flavor of GMT, while I expect launch time is important for most people.