Investigating the response of Tête Rousse glacier to basal contact loss: implications for glacier instability

Malo Landrain - Master Thesis - February to July 2026 Institut des Géosciences de l'Environnement IGE Supervised by Olivier Gagliardini and Julien Brondex

This repo contains all the scripts and data used to conduct the study as well as the manuscript the reader can refer to

Use the command below after cloning the repository to get a view on the old history before cleaning up the scripts, it might give more insights into the work done

git switch full-history

Please do not hesitate to reach out if anything remains unclear to this address: malo.landrain@gmail.com

For an updated email address, go to the author website: malolandrain.com

Various thoughts about tools and good practices for working with Elmer/Ice or other Ice flow models for better Reproducibility and Open Science

This section is meant for the curious reader who wants to save a bit of time when working with the various tools existing in Linux or MacOS but in general in the terminal world. In parallel of my internship work, I started my journey in the rabbit hole of Linux that is both scary and fabulous. In my eyes, keeping updated about methods that allows better reproducibility, FAIR and true Open sciences is a need for every researcher as we don't get the right training right after university (or at least I didn't). To go further, the world of DevOps and in general developers is the best ressource one might want to check as those communities already solved many problem that we may face in Earth Sciences and modelling.

• Use something like Docker, Podman or even better Nix or Guix to manage the working environment

  • Right now, relying on engineers who know how to install the different modules but changes depending on the HPC infrastructure and doesn't allow for proper repoducibility - the end goal should be to be able to do the exact same experiment again, knowing that we have the tools to do so
  • To one experiment, one should attach the working environment that was used in order to conduct it

• Use git as much as possible, and in the proper way, yes formations might be needed for the new comers but this allows for proper following of what has been done in the code and why. Moreover, it allows for proper collaboration and having the habit of pushing regularly on git avoid the issue of keeping the code lost on a computer somewhere, unusable for the next developers.

  • In the case of Nix or UV or Dockerfile use, it is possible to push the working environment or the file allowing to build the environment used for one experiment

• When archiving, one might want to use something like Software Heritage linked to HAL to get a citation leading to the source code.

  • This allow for being independant on which forge (github, gitlab, codeberg) you use and how it will evolve with time especially under the pressure of big tech companies

• Use a terminal multiplexer like tmux, zelij or else when working with ssh connexion

  • On the local machine, before ssh, allows to detach without losing a session on the ssh connection
  • On the HPC front, use tmux before going in an interactive session allowing to detach but keeping the session live even when the computer is shut down

• Use GNU Stow and a git repo for the .dotfiles containing all the configurations used on one machine at a time.

  • This allows for keeping the configurations between different linux machines even when forced to change

• In terms of IDE, everything is fine as long as you know how to use it. However, learning tools like VIM motions may be a must for efficiency. You can use it in most of IDEs such as VSCode, (better to use VSCodium in this case - open source, not own by microsoft) and of course Vim or Neovim.

  • I started with VSCode and Jupyter notebooks as this is the way I learned how to code and I never have seen any other alternatives
  • But, Truly Neovim changed drastically the way I worked with a distro like LazyVim allowing to be much more focused in the coding but also the writing of the master thesis.
  • The real advantage appears in a tipycal development workflow where I would use tmux for splitting windows inside of a terminal session (using Ghosthy or Kitty by the way) with one window dedicated for coding (using Neovim), one showing the HPC connexion and where I can start the simualation and finally one for managing git pull and push from the local machine to the HPC.
  • I also have seen in UFEMISM model, a warning appearing when a simulation starts but the git commit is not done for the code: "This experiment might not be reproducible, be careful"

A various list of tools

• Then here is a list of the various tools I recommand when working with the terminal as you might do with HPCs:
  • Ghossthy or Kitty -- Terminal emulator allowing for more colors, coded in Rust: faster and allow more functionality
  • Fish or Zsh for a better shell (compared to bash) - autocompletion, act as a real help when navigating in the terminal
  • fzf - fuzzyfinder super useful to search for a specific file using keywords and more
  • tmux or zelij - When working with different shells, sessions, ssh connections - a must
  • Neovim with the LazyVim distro -- Good looking terminal, easy to work with for every file, extremely customizable
  • Docker, Podman (Open source) Nix - To build complex environment -- docker for smaller project with less dependencies - Nix or Guix for perfect reproducibility with a quite steep learning curve. I also have seen Apptainer which is vastly used specifically for HPC and scientific context - used at Uppsala University
  • Use aliases in your .bashrc or equivalent (config.fish)
  • yazi for file management in the terminal - just fantastic
  • typst as an alternative to latex, in general easier to use and more natural but latex do work fine, typst is just faster and more natural
  • Obsidian for taking notes and keeping them sorted and easy to access as everything is written in Markdown (but you might want to use at this point something also in the terminal - Neorg could then be an option but need another language to learn...)
  • Better ls and tree: exa and exa --tree with aliases=ls and tree
  • Better find: fdfind with alias=fd
  • customization of the terminal prompt: starship
  • management of docker containers: lazydocker
  • easy git management within the terminal: lazygit
  • For lighter virtual environment management - e.g. python: uv