Making a PyPI package

Recently, I have had a paper accepted which presents PyTrx, a new Python toolset for use in glacial photogrammetry. Over the course of getting this published, it has been suggested by co-authors and reviewers alike to use a package manager for easy download and implementation of PyTrx. I therefore wanted to package the toolset up for distribution via PyPI (‘pip’), thus making is easily accessible to other Python users with the simple command pip install pytrx. Whilst I found the tutorials online informative, there were some pitfalls which I found hard to solve with the given information. So here is an account of how I got my package on PyPI. The associated files for the PyTrx package are available on a branch of PyTrx’s GitHub repository, if you want to see this walkthrough in action.

Defining the package files

First and foremost, the file structure of the toolset is crucial to it being packaged up correctly. The top directory should contain a folder containing your package, and several other files containing the necessary setup information:

 master_folder
   - PyTrx
   - LICENSE.txt
   - README.md
   - setup.py 

This is one of the first slip-ups I made, putting all my toolset scripts in the tol directory rather than a folder of its own. If the Python scripts that make your package are not placed in their own folder then they will not be found when it comes to compiling the package.

So let’s go through each of these elements, beginning with the folder that contains the Python scripts we wish to turn into a PyPI package. An initialisation file needs to be created in this folder in order to import the directory as a package. This is simply an empty Python script called __init__.py, so our folder structure will look a bit like this now:

 master_folder
   - PyTrx
       - __init__.py
   - LICENSE.txt
   - README.md
   - setup.py 

Moving on to the LICENSE.txt file, it is important to define a license with any Python package that is publicly distributed in order to inform the user how your package can be used. This can simply be a text file containing a copied license. A straightforward and popular license for distributing code is the MIT license which allows code to be used and adapted with appropriate credit, but there are greate guides for choosing a license appropriate for you online (e.g. choosealicense.com). This file has to be called ‘license’ or ‘licence’ (uppercase or lowercase) so that it is recognised when it comes to compiling the package.

Similarly with the README.md file, this has to be called ‘readme’ specifically so that it is recognised when it comes to compiling the package. This file contains a long description of the Python package. It might be the case that you already have a README.md file if you have hosted your scripts on GitHub, in which case you can merely adopt this as your readme. Just remember that this should be hardcoded in HTML code, and the readme file will form the main description of your package that people will read when they navigate to the package’s PyPI webpage.

And finally the setup.py. The setup file is probably the trickiest file to define, but the most important as here we outline all of the metadata associated with our Python package; including the package’s recognised pip name (i.e. the one used in the command pip install NAME), its version, author and contact details, keywords, short package description, and dependencies. Here is PyTrx’s setup.py file to serve as an example:

import setuptools

with open("README.md", "r") as fh:
    long_description = fh.read()

setuptools.setup(
    name="pytrx", 
    version="1.1.0",
    author="Penelope How",
    author_email="pennyruthhow@gmail.com",
    description="An object-oriented toolset for calculating velocities, surface areas and distances from oblique imagery of glacial environments",
    long_description=long_description,
    long_description_content_type="text/markdown",
    url="https://github.com/PennyHow/PyTrx",
    keywords="glaciology photogrammetry time-lapse",
    packages=setuptools.find_packages(),
    classifiers=[
        "Programming Language :: Python :: 3",
        "License :: OSI Approved :: MIT License",
        "Development Status :: 5 - Production/Stable",
        "Intended Audience :: Science/Research",
        "Natural Language :: English",
        "Operating System :: OS Independent",
    ],
    install_requires=['glob2', 'matplotlib', 'numpy', 'opencv-python>=3', 'pillow', 'scipy'],
    python_requires='>=3',
)

Most of the variables are straightforward to adapt for your own package setup.py file. The ones to watch out for are the classifiers variable where metadata flags are defined, and the install_requires variable where the package’s dependencies are. PyPI offers a good resource that lists all of the possible classifiers you can add to the classifiers variable.

Finding out how to define dependencies was a little trickier though, as the main PyPI tutorial does not address this. This page gave a brief outline of how to define them with the install_requires variable, but I found that I still had problems in the subsequent steps with package incompatibilities. My main problem was that I had largely worked with conda rather than pip for managing my Python packages, so there were a number of discrepancies between the two in configuring dependencies with PyTrx. My main challenge was finding a balance with OpenCV and GDAL, two notoriously difficult packages to find compatible versions for – I had managed this with conda, finding two specific versions of these packages to configure a working environment. In pip, I found this proved much harder. The package versions used in conda were not the same for pip, and there wasn’t an official repository for OpenCV, only an unofficial repository called opencv-python. We’ll learn more about testing dependency set-ups a bit later on, but for now, just be aware to check that each PyPI package dependency is available and use the >= or <= to define if the package needs to be above or below a certain version. It is generally advised not to pin a dependency to a specific version (i.e. ==), I guess because it reduces the flexibility of the package installation for users.

Generating the distribution files

Once we have all of our files, we can now compile our package and generate the distribution files that will be eventually uploading to TestPyPI and PyPI. It is advised to use TestPyPI to test your package distribution before doing the real deal on PyPI, and I found it incredibly useful as an apprehensive first-time uploader.

If you do decide to test your package on TestPyPI, it is good etiquette to change the name of your package (defined in setup.py) to something very unique – there are many test packages on TestPyPI, and although they delete test packages on a regular basis, there are plenty of package names that yours could clash with. In the case of PyTrx, I defined the package name as pytrxhow (the package name with my surname), that way there was no chance of using a name that had already been taken. Additionally, you should take your dependencies out of the setup.py file as often the same packages do not exist on TestPyPI and therefore are not an accurate reflection of how your package dependencies will look on PyPI.

To generate the distribution files, two packages need to be installed into your Python environment, setup-tools and wheel. I already had versions of these packages in my conda environment, but I updated them using the same command (in Anaconda Prompt) as if I wanted to install them:

conda install setup-tools wheel

After these are installed, navigate to the directory where all of your files are (i.e. in master_folder) using the cd command, and run the following command to build your distribution files for TestPyPI:

python3 setup.py sdist bdist_wheel

This should generate two folders containing files that look something like this:

master_folder
   - PyTrx
       - __init__.py
   - LICENSE.txt
   - README.md
   - dist
       - pytrx-1.1.0-py3-none-any.whl
       - pytrx-1.1.0.tar.gz
   - pytrx.egg-info
       - PKG-INFO
       - SOURCES.txt	
       - dependency_links.txt	
       - requires.txt	
       - top_level.txt
   - setup.py 

The dist and egg-info folder should contain all of the information inputted into the setup.py file, so it’s a good idea to check through these to see if the files are populated correctly. The SOURCES.txt file should contain a list of the paths to all of the relevant files for making your packages. If you have taken out your dependencies, then the requires.txt file should be empty.

Testing the distribution

There are two ways to test that the distribution files work: 1. using TestPyPI to trial the distribution and the ‘look’ of the PyPI entry, and 2. using the setup.py file to test the package installation in your local environment (including dependency solving). Beginning with the test on TestPyPI, start by creating an account on TestPyPI and creating an API token, so you can securely upload the package (there is a great set of instructions for doing this here). Make sure to write down all of the information associated with the token as you will not be able to see it again.

Next, make sure that you have an up-to-date version of the twine package in your environment. Twine is a Python package primarily for uploading packages, which can easily installed/upgraded in a conda environment with the following command:

conda install twine

Now, Twine can be used to facilitate the upload of your package to TestPyPI with this command (making sure that you are still in your master_folder directory:

python3 -m twine upload --repository-url https://test.pypi.org/legacy/ dist/*

Once the command has run, there will be a link to your TestPyPI repository at the bottom which you can click on to take you to it. You can use this to test install your package with no dependencies. In the case of PyTrx (pytrxhow, my test version), this could be done with the following command (just change ‘pytrxhow’ to specify a different package):

pip install -i https://test.pypi.org/simple/ pytrxhow 

This is all well and good for testing how a package looks on PyPI and testing it can install, however, I was more anxious about the package dependencies knowing the issues I had with OpenCV and GDAL previously in my conda environment. After checking your TestPyPI installation (and this may take a few tries, updating the version number every time), put your dependencies back into your setup.py file, run the distribution file generation again, and test the dependency configuration with the following command that will attempt to install your package locally:

python setup.py develop

This may take some time to run, but should give you an idea as to whether the dependencies can be resolved. I cloned my base conda environment in order to do this, giving a (relatively) blank environment to run off, and tested the installation by attempting to import the newly installed package in Spyder.

I found that I could not solve the environment, no matter what I specified in setup.py, and therefore had to play around with which package was causing the majority of the problems. I found that GDAL was the main cause of PyTrx unsuccessfully installing, so took it out of my dependencies, instead opting to install it after with conda. This seems to work much better, and although may not be a perfect solution, it will create fewer problems for users.

Uploading the distribution to PyPI

So at this point you should feel confident in the look and feel of your package, and its installation in your environment. Before proceeding with the final steps, just run through the following checklist to make sure you have everything:

  • Check that all the information is correct in the setup.py, changing the name (e.g. ‘pytrxhow’ to ‘pytrx’) and dependencies if you have been uploading to PyPI previously
  • If you change anything in the setup.py file, then run the distribution file generation again
  • Check your TestPyPI page to make sure all the information uploaded is correct and nothing is missing
  • Check on PyPI that there is no other package with the same name as yours

A thorough check is needed at this stage because an upload to PyPI cannot be changed. Further package versions can be uploaded if there is a major problem, but versions that you have uploaded cannot be edited or altered. Therefore it is best to try and get it right the first time. No pressure!

For uploading to PyPI, you need to create an account on PyPI. This account creation is separate to TestPyPI, so another username and password unfortunately. Again, create an API token in the same manner as done previously with TestPyPI, making sure to write down all of the details associated with it. To upload your package to PyPI, we are using Twine again and the following command:

twine upload dist/*

Once run, there will be a link to click through to your PyPI page and voila, your package is online and easy for anyone to download with the old classic command (in the case of PyTrx):

pip install pytrx

In the case of PyTrx, our PyPI page is available to view here, and our GitHub repository contains all of PyTrx’s scripts and the distribution files used for the PyPI upload, which might be useful for some. Hope this helps someone who has suffered any of the pitfalls of PyPI packages! 

Icebergs in Nuuk


Useful resources:

A broad overview and use of Test PyPI

Uploading to PyPI

More information about specifying dependencies and testing package installations

More information about PyPI classifiers

PyTrx’s PyPI page, GitHub repository, and publication

Subglacial hydrology at Kronebreen, Svalbard, published in The Cryosphere

The Cryosphere recently published our work on Kronebreen, a fast-flowing tidewater glacier in Svalbard (click here to see the article). The study examines subglacial hydrology and its influence on basal dynamics over the 2014 melt season, with simultaneous observations of water pressure at the bed, supraglacial lake drainage, meltwater plume activity, and glacier surface velocities. In addition, melt/runoff and hydraulic potential were modelled in order to estimate surface melt production, and the routing of meltwater at the bed. This built a nice record from which we could establish a robust, theoretical picture of how water is channeled at the bed.

One of the key findings is the difference in drainage beneath the north and south regions of the glacier terminus, which is linked to spatial variations in surface velocity. The study also shows a consistently high water pressure at the glacier bed throughout the melt season. These readings were collected from a borehole that was drilled approximately 3 km upglacier of the terminus. Borehole records from tidewater glaciers are rare but the few early studies that currently exist, including this one, suggest that bed conditions at tidewater glaciers are persistently pressurised, with a high hydraulic base-level that permits fast flow.

The Cryosphere Kronebreen site map figure

Figure 1 from the TC paper: The site map of Kronebreen, along with the location of the three groups of supraglacial lakes (C1, C2 and C3) that filled and drained during the 2014 melt season. These lakes were monitored by seven time-lapse cameras, which were installed on the rock outcrops surrounding the glacier tongue (denoted by the orange numbered locations). These lakes drained sequentially in an upglacier fashion, similar to the speed-up event at the beginning of the melt season. The starred location is where the borehole was drilled and the pressure sensor was installed.

The Cryosphere Kronebreen maps

Figure 5 from the TC paper: Sequential velocity maps (left) and velocity change maps (right) of Kronebreen, derived from TerraSAR-X imagery. The south region of the glacier tongue is faster flowing than the north region throughout the melt season. We argue that this reflects a difference in drainage efficiency. An early-season speed-up event is  depicted in the velocity change maps, which originates from the terminus and propagates upglacier. Similar speed-up events occur year-on-year at Kronebreen. These may reflect changes at the terminus early in the melt season which promote longitudinal stretching, and/or reflect a seasonal hydraulic overhaul which promotes basal sliding.


Further reading

The Cryosphere paper

Other studies at Kronebreen (here and here) which show early-season speed-up events

Borehole study at a tidewater glacier in Patagonia 

 

What is going on at Tunabreen?

Tunabreen is a tidewater glacier in Svalbard that has recently been displaying some exciting activity. It is known as a surge-type glacier, with discrete periods where it flows markedly faster and slower. Tunabreen entered a fast-flowing phase in December 2016, which is ongoing at the time of writing. The nature of this fast-flowing phase is atypical for Tunabreen though, throwing into question whether this phase is associated with surge dynamics. What is going on at Tunabreen?!

Tunabreen is an ocean-terminating glacier on the west coast of Svalbard. This glacier is particularly special because of its unique set of dynamics. A large number of the glaciers in Svalbard are known as surge-type glaciers. A surge-type glacier undergoes periods of fast-flow followed by very slow, inactive phases. The nature of this surging pattern is due to the glacier’s inefficiency in transferring mass from its upper regions to its terminus (Sevestre and Benn, 2015). It is an internally-driven process. The trigger of this process is unrelated to external influences (i.e. changes in air temperature, ocean temperature, and precipitation).

Time-lapse at Tunabreen using one image per day

Time-lapse images from the front of Tunabreen. This glacier terminates into a large fjord called Tempelfjorden, hence it is referred to as a marine-terminating glacier. This time-lapse image sequence was constructed using one image per day between July-August 2016. This work is part of Calving Rates and Impact On Sea level (CRIOS) project at UNIS.

Tunabreen is one of few glaciers in Svalbard to have been observed to undergo repeated surge cycles. It has surged in 1870, 1930, 1971, and between 2002-2005. We know these surges happened because each surge phase left a pronounced ridge on the seabed which defines the surge extent (Flink et al., 2015). As these surges have been spaced 30-60 years apart, the next surge was not expected for quite a while (at least until 2030).

Tunabreen was a very slow-moving glacier between 2005 and 2016, flowing between 0.1-0.4 metres per day (m/day). These velocities were largely derived from sequential satellite imagery. Distinct glacial features were tracked from image to image to determine surface velocities on the glacier. The highest velocities (0.4 m/day) were limited to the terminus area, with very little movement (0.1 m/day) in the upper section of the glacier tongue. It was often difficult to track glacial features from image to image because the glacier was moving so slowly.

A marked speed-up was initially observed at Tunabreen in December 2016. The entire glacier tongue suddenly flowed faster. The terminus flowed >3 m/day and velocities in the upper section increased to 0.3-2.0 m/day. This speed-up continues at the time of writing this blog post (March 2017). It is a dramatic difference from the months and years prior to this event. 

Speed-up at Tunabreen. Source: St Andrews Glaciology.

The speed-up at Tunabreen shown from feature-tracking through TerraSAR-X satellite images (from Adrian Luckman, Swansea University). Luckman also tweeted two images from this sequence here which nicely show the difference between 2015 and 2016. Source: St Andrews Glaciology.

So, is this a surge? is the question on everyone’s lips now. In short, we don’t know at the moment and this is a difficult question to answer with the short amount of time that we have witnessed these changes at Tunabreen. At the time of writing, there are 4 key observations that need to be considered:

  1. The timing of this speed-up coincides with record-high temperatures and precipitation for a winter season in Svalbard (as stated in this article by Chris Borstad, a glaciologist at UNIS). This could have had a significant influence on the presence of water at the bed of the glacier, which is understood to lubricate the interface between the ice and the underlying bedrock. This, in turn, promotes sliding and may also cause the glacier to flow faster.
  2. This winter, sea ice did not form in Tempelfjorden and the fjord area directly adjacent to the glacier front. Sea ice and melange is understood to provide a back-stress against the front of a glacier. This acts as an opposing force to ice flow. Without the presence of sea ice, this opposing force is absent at the front of Tunabreen. Lack of sea ice was also observed in the winter of 2015 (as noted here in a previous blog post).
  3. The spatial pattern of this speed-up propagated in an upward fashion i.e. an increase in velocity first occurred at the front of the glacier, with subsequent velocity changes progressing up the glacier tongue. The abundance of crevasses on the glacier surface has increased, with the crevasse field extending much further up the glacier tongue than previously. Also, the terminus has advanced roughly 400 m since December 2016, as shown from the sequence of Sentinel images tweeted by Adrian Luckman (and displayed in a post by St. Andrews Glaciology). These observations are indicative of surging dynamics, as stated by Sevestre and Benn (2015).
  4. This speed-up has occurred 12 years after the previous surge (2002-2005). Surges at Tunabreen have previously been spaced 30-60 years apart from one another. The next surge was not expected until at least 2030. If this speed-up is associated with surge dynamics then it has occurred much earlier than anticipated.
Tempelfjorden. This year we unfortunately could not visit Tempelfjorden and Tunabreen glacier with the students because of the lack of sea ice. Sea ice normally forms in Tempelfjorden up to the ice front over the winter, but this year it has not formed. This also happened in 2006 and 2012. For the first time ever though, there is no sea ice directly in front of Tunabreen, which will have massive repercussions for the glacier's dynamics

Tempelfjorden in March 2015. Sea ice normally forms in Tempelfjorden up to the ice front over the winter, but it did not form in 2015 and 2016. This also happened in 2006 and 2012. As well as having large implications for the dynamics of Tunabreen, this has also impacted on snow scooter routes across Svalbard. The sea ice in Tempelfjorden has previously been used as a major scooter route for tourist groups and for transporting goods.

These observations can be used as arguments for and against this speed-up being associated with surge dynamics. Whilst the behaviour of the glacier indicates that this may be associated with surge dynamics, there have also been significant changes in external factors which could have played a crucial role in this speed-up. It is important to continue monitoring changes to better understand the processes behind the abnormal behaviour at Tunabreen. It will be interesting to see if this speed-up is sustained through the spring of 2017, and to see how much the terminus will continue to advance into Tempelfjorden. One thing is for certain: all eyes will be on Tunabreen and what it does next!

Tunabreen in March 2017

The front of Tunabreen in March 2017. I was lucky enough to visit Tunabreen earlier this month as part of the Glaciology course that runs at UNIS each year. It was incredible to see this glacier again. We have time-lapse cameras positioned on the mountain ridge (Tunafjell) that is visible in this picture. Hopefully they will give us some insight into the dynamics associated with this speed-up.


Further Reading

St. Andrews Glaciology blog: Unexpected ‘surge’ of a Svalbard tidewater glacier

UNIS post by Chris Borstad on the changes at Tunabreen

Sevestre and Benn (2015) – A comprehensive study on surge-type glaciers and their distribution around the world.

Flink et al. (2015) – Past surge extents at Tunabreen determined by topographic features on the sea bed, derived from multibeam-bathymetric surveying over Tempelfjorden.

Tweets by Adrian Luckman showing the speed-up from TerraSAR-X imagery and Sentinel imagery

Using meltwater plumes to infer subglacial hydrology at tidewater glaciers

PhD update: January 2017. Meltwater plumes are the upwelling of fresh water in front of a tidewater glacier. These are known to influence submarine melt rates, which are suggested to have a significant impact on the calving rate of glaciers that terminate in sea water. Recent work has suggested that meltwater plumes can also be used to infer the subglacial hydrology at the front of a glacier.

At land-terminating glaciers, water is evacuated via flow outlets which form large rivers on the adjacent land. It is therefore relatively straightforward to measure the amount of water leaving the glacial system. Things are a bit more complicated at glaciers which terminate in water (i.e. a fjord, sea, or ocean). Fresh water exits from the glacier at depth and interacts with the salty seawater. The fresh water moves upwards due to the density difference between freshwater and saltwater, forming a turbulent column of mixing water. This is a meltwater plume (and can also be referred to as a ‘submarine plume’, or simply just a ‘plume’).

An example of a meltwater plume at Tunabreen, a tidewater glacier in Svalbard

An example of a surfacing meltwater plume at Tunabreen, a tidewater glacier in Svalbard. Note the distinctive shape and the dark colour (indicating sediment content) of the surface expression.

The freshwater in a meltwater plume will continue to flow up through the water column and entrain surrounding saltwater until it is thoroughly mixed (i.e. there is no difference in the density between the plume and the surrounding water). At this point, a meltwater plume will reach its neutral buoyancy and the water will cease flowing upwards and flow horizontally away from the glacier front.

A meltwater plume can reach the sea surface if the neutral buoyancy exceeds the depth of the fjord. The surface expression of a meltwater plume is normally very distinctive, distinguished by its sediment-laden colour and turbulent flow away from the glacier. We have lovely images of meltwater plume activity at Tunabreen, a tidewater glacier in Svalbard, showing a surfacing plume which has entrained very rich red/brown sediment.

The neutral buoyancy point of a meltwater plume is influenced by a number of factors:

  1. The temperature/density difference between the freshwater in the plume and the surrounding saltwater
  2. The geometry of the fjord, such as how deep it is
  3. The stratification of the surrounding saltwater
  4. The rate at which meltwater is exiting the glacier (also referred to as discharge)

The first three of these listed influences undergo relatively little change compared to discharge over short time-scales (e.g. a summer season). Assuming this, the activity of a meltwater plume can be used as a signal for the rate at which meltwater is exiting a glacier over the course of a melt season.

Meltwater typically exits into a fjord/sea/ocean at the bed of a glacier. The meltwater can either be directed through a given number of big channels or a series of intricate, small cavities. Channels can typically accommodate large volumes of meltwater, hence they are known as an efficient drainage system. Linked cavities are not as effective at transporting meltwater and tend to hold water at the bed for much longer durations, so they are aptly referred to as an inefficient drainage system.

Kronebreen (centre) viewed from the west. Kronebreen shares its southern (right) margin with Kongsvegen, a slow-moving surge-type glacier that has been fairly inactive for the past couple of years. The glacier adjacent to Kronebreen, separated by the mountain Collethøgda (left), is called Kongsbreen. Kongsbreen has been retreating from the fjord onto land since approximately 2014 (September 2016)

A meltwater plume at the front of Kronebreen, a fast-flowing tidewater glacier in Svalbard. The surfacing plume  is situated on the north side of the plume (left side of the terminus in this image). This plume entrains sediment which gives it a red/brown colour. A plume also surfaced intermittently on the south side of the terminus during the melt season of 2014 (not pictured here). Photo taken: September 2016.

Timeline of surfacing plume activity at Kronebreen, Svalbard, monitored from time-lapse imagery. Plumes P1, P2 and P3 were present at the north side of the terminus, with P1 being active for the entire monitoring period (gaps are where there was no visibility in the images). Plume P4 surfaced at the south side of the terminus, showing intermittent activity throughout the melt season.

Timeline of surfacing plume activity at Kronebreen, Svalbard, monitored from time-lapse imagery. Activity began on the 23 June and continued through till the end of September. Plumes P1, P2 and P3 were present at the north side of the terminus. P1 (pictured in the above image) was active for the entire monitoring period (gaps are where there was no visibility in the time-lapse imagery). Plume P4 surfaced at the south side of the terminus, showing intermittent activity throughout the melt season.

An efficient drainage system can quickly channel a large volume of meltwater into the adjacent sea water. It is therefore likely that the neutral buoyancy of a meltwater plume from an efficient drainage system can exceed the depth of the fjord, so the plume will surface and will be visible. An inefficient drainage system is much more limited in the rate at which it can deliver meltwater into the adjacent sea water. It is therefore likely that the neutral buoyancy of a meltwater plume from an inefficient drainage system will be at depth, so the plume will not surface and will not be visible. We can thus infer what type of drainage system is present at the front of a glacier by monitoring meltwater plume activity over short durations.

We have been monitoring meltwater plume activity at the front of Kronebreen, a fast-flowing tidewater glacier in Svalbard. Two sets of plumes were present over the 2014 melt season, on the north and south side of the terminus. It is assumed here that a meltwater plume is likely to surface in the fjord if a channel is active based on the known fjord depth (∼80 m) and modelled runoff outputs. The set of plumes on the north side of the terminus persistently surfaced throughout the melt season, whereas the plume on the south side only surfaced intermittently.

A plume may not be able to consistently surface because meltwater is not leaving the glacier through a stable efficient drainage system. This could suggest that two different drainage systems preside at the north and south side of the glacier – a stable efficient drainage system on the north side, and an unstable system that switches between efficient and inefficient drainage on the south side.

Velocity map of Kronebreen over an 11-day period in April 2014 (Luckman et al., 2015)

A velocity map of Kronebreen over an 11-day period in April 2014 (Luckman et al., 2015). These velocities are derived from feature tracking between image pairs, and these images are TerraSAR-X satellite images. Higher surface velocities are present at the central/south side of the terminus compared to the north side. This is possibly related to a difference in subglacial drainage beneath these two regions. Source: UNIS.

In this situation, you would expect to see other differences between the north and south side of the terminus such as surface velocity. A large amount of subglacial meltwater is in contact with the bed in an inefficient drainage system, which enhances lubrication at the bed and promotes ice sliding. In an efficient drainage system, the water is channelled through a discrete area of the glacier and thus there is less basal lubrication as a smaller amount is in contact with the bed.

Surface velocities over the 2014 melt season show a distinct difference between the north and south side of the glacier terminus – the south is much faster flowing than the north, with the south exceeding velocities of 4 metres per day whilst the north remains relatively slow (see an example velocity map above). It is likely that a difference in drainage efficiency could facilitate this difference in surface velocities. The presence of an inefficient drainage system at the south side of the glacier tongue may be promoting faster velocities.

This idea is being further explored with additional datasets to better understand glacier hydrology and dynamics. The main take-home message from this post is that meltwater plume activity could be a reliable signal for meltwater outflow. This activity can be effectively monitored using time-lapse photography. Observations of plume activity can help us to diagnose the nature of subglacial drainage beneath tidewater glaciers, which is not accessible for direct measurements at this time. Kronebreen appears to have two different drainage systems active near the glacier terminus, as reflected in the differing plume activity, and this could be facilitating fast velocities in discrete areas of the glacier.


Further reading

Slater et al., 2017 – A newly-published study looked at meltwater plume activity at Kangiata Nunata Sermia (KNS) in Southwest Greenland using an in-situ time-lapse camera. They predicted from model simulations that a meltwater plume from a single channel should be able to surface in the adjacent fjord water, knowing the rate of discharge through the drainage system. However, the time-lapse imagery showed that the meltwater plume was only visible for brief periods throughout a melt season (May to September 2009). They argued that a plume was not consistently surfacing because meltwater may not leaving the glacier through a stable efficient drainage system. An efficient drainage system may not be able to persist at the front of KNS because it could be repeatedly disrupted by basal deformation, which is facilitated by the fast-flowing nature of the glacier. This paper has been neatly summarised by ice2ice.

Time-lapse sequences from Kronebreen. Note the visible plume activity seen from cameras 1 and 2 through the melt season.