Term project: the ERA5vis package

Term project: the ERA5vis package#

This is the main project of the semester and will count for 30% of the final grade. The submission is going to happen in three stages:

  • Feedback meetings (after the Christmas break): We will arrange individual meetings with each group to receive some feedback. You will show me the structure of your package, the functionality of your code, which tests you are writing, who is writing what, a sample docstring, etc. You will also submit a first version of your package (one .zip file per group) at least 24 h before our meeting so that I can test it.

  • Final submission (Tuesday, 27 January 2026 at 00:00): Every group will upload one .zip file containing your version of the ERA5vis package. An upload folder will be available on OLAT.

  • Class presentations (Tuesday, 27 January 2026): Every group will briefly present their project to show what it can be used for. This is not graded. The goal is to simply share your amazing project ideas with the whole class.

Here is a tentative grading rubric.

Group grade (10 points):

  • Originality: 1 (did you do something more than following the list of suggestions)

  • Functionality of the code: 1 (can the package be installed and run on my computer)

  • Documentation: 2 (joint project documentation, e.g., README)

  • Traceability: 1 (who did what, are the author(s) name(s) provided in the function’s docstrings)

  • Coherence: 2 (how do the individual contributions fit together)

  • Joint task/tests: 2 (jointly written tool/tests)

  • Response to feedback: 1 (response to the received feedback)

Individual grade (10 points):

  • Narrative self-report: 1 (quality and honesty of the self-report)

  • Implemented tools: 3 (level and complexity of the implemented tools, i.e., the amount of programming work)

  • Functionality of the code: 1 (is your individual contribution running and doing what it is supposed to do)

  • Tests: 2 (tests for individual contributions)

  • Documentation: 2 (Individual contributions’ docstrings and comments)

  • Programming style: 1 (compliance to PEP 8)

Important

I will try and test the code (using pytest) on my computer - any new data or library that is necessary should be documented in the code, or in the command line utility documentation!

The ERA5vis package#

I have put together a small package called ERA5vis. Its structure is based on the template package and the ClimVis package written by Fabien Maussion.

Download the zipped package from here and extract it. Read the README and the package requirements first.

Now install the package in development mode:

pip install -e .

Try the command line interface (era5vis_modellevel -h) from a terminal. Now explore setup.py: can you find the line that makes the command available from the terminal? Where is the code that is being executed when you call era5vis_modellevel?

Familiarize yourself with the tool. Can you understand what the role of each function is?

Can you run the tests successfully? Probably not. Somewhere in cfg.py, a hard-coded path is pointing to a directory that does not exist on your system.

You can download an example ERA5 dataset from our OLAT course (folder Semester Project/data). This is the same dataset that we have already used for an earlier assignment.

Make sure you are able to run the command succesfully before moving on. For example, era5vis_modellevel -p z -lvl 500 should work fine and display a page in your browser.

Guided exercise: make the package more robust#

Here are two smaller tasks to get you started. Each of you should try to complete these exercises to familiarize with the package before you start the joint group project.

  • The package currently contains no check whether the user-specified variable, model level, time stamp actually exist in the data file. A function definition line has alrady been created in era5.py (function check_data_availability) and a call to this function has already been added to function core.write_html. Write the function code to check if variable, model level, and time stamp are in the data file and if not raise an exception.

  • Add a check to the code to make sure that the data file specified in cfg.py actually exists. If the data file does not exist, print the following message and exit the program:

    The specified data file does not exist. Please set a valid path in cfg.py.

Project: make the package better#

Now you should be ready to contribute to the package! As a group, add at least N+1 simple functionalities to it, where N is your group size. This functionality can be anything you want, as long as it makes you write some code.

Here are some ideas:

  • You could add a new command-line tool to plot vertical cross sections.

  • You could extend the existing command-line tool to cross sections in general depending on the user input, i.e., including vertical cross sections (you may want to rename the tool in this case).

  • You could add a command-line tool to plot time series or vertical profiles.

  • You could add the possibility to plot variables that have to be first calculated from fields within the dataset (e.g., wind speed).

  • You could add the possibility to interpolate to model levels that are not in the data file.

  • You could add an API data download option (Climate Data Store Api).

  • Come up with your own ideas that interest you!

Depending on the functionalities you are planning to add, you may want to download additional data. ERA5 data are available via the Climate Data Store, including the hourly data on pressure levels that we are using here (you can, however, also use other ERA5 datasets if you like). To download data, you need to create an account.

Expectations#

Every member of the group should add one functionality, including tests for the new functionality. It should be evident from the code (e.g., docstrings) who wrote which part of the code. Choose and distribute the tasks according to your respective programming skills. There is no minimum on the number of lines of code you should write, because producing many lines of code is not a measure of quality. The list of possible topics should help you decide on what to code, but aside from that here is a vague rule of thumb: if you coded 10 lines of code (without comments), it is probably not enough (unless they are very clever lines of code). If you coded 1000 lines of code, it is probably too much.

By this time, I have a relatively good feeling for your programming skills and I do not want to see code that was clearly not written by you but rather by ChatGPT or your colleagues. The goal is that you get better at programming during the project, regardless of your starting level. Try to find a project you like, and convince me that you pushed your own programming limit a little bit and that you learned something in the process. So it is okay to select an easy task, as long as you write something on your own, and write good code. The difficulty of the task will, however, influence the grade in addition to the quality of the code and the tests. If you pick an “easy” task, you could also pick two or three tasks instead of just one.

In addition, you should add one joint functionality to which all of the group members contribute. Again, don’t forget about the tests.

Make sure to combine your individual contributions so that the final package is coherent.

In addition to the joint package, each group member needs to write a short narrative self-report (a few lines per point) addressing the following points:

  • What task was assigned to you when you started?

  • What changed during the implementation, that is, what is the outcome of the project?

  • What was the biggest challenge you faced in the implementation?

  • What was the biggest challenge when merging everyone’s work into one package?

The narrative report can be submitted either in markdown format, simple text format, or a PDF, and will count towards your individual grade.

Contents