Skip to content

Instantly share code, notes, and snippets.

@Saransh-cpp

Saransh-cpp/FinalGSoC2021Report.md

Created August 21, 2021 16:06
Show Gist options
  • Save Saransh-cpp/5f61540819b8c8d552c12b1609915f5d to your computer and use it in GitHub Desktop.
Save Saransh-cpp/5f61540819b8c8d552c12b1609915f5d to your computer and use it in GitHub Desktop.
Download ZIP
Final report for Google Summer of Code 2021 (Organization - NumFOCUS, Sub-organization - PyBaMM)
Raw
FinalGSoC2021Report.md

Final Report for Google Summer of Code 2021

Python Battery Mathematical Modelling (PyBaMM), NumFOCUS


An Automated Twitter Bot to run PyBaMM Simulations


Details

Name: Saransh Chopra
Organization: NumFOCUS
Sub-Organization: PyBaMM
Mentors: Robert Timms, Valentin Sulzer, Ferran Brosa Planella

Abstract

PyBaMM (Python Battery Mathematical Modelling) solves physics-based electrochemical DAE models by using state-of-the-art automatic differentiation and numerical solvers. The Doyle-Fuller-Newman model can be solved in under 0.1 seconds, while the reduced-order Single Particle Model and Single Particle Model with electrolyte can be solved in just a few milliseconds. Additional physics can easily be included such as thermal effects, fast particle diffusion, 3D effects, and more. All models are implemented in a flexible manner, and a wide range of models and parameter sets (NCA, NMC, LiCoO2, ...) are available. There is also functionality to simulate any set of experimental instructions, such as CCCV or GITT, or specify drive cycles.
- pybamm.org

PyBaMM or Python Battery Mathematical Modelling is a Python library that is centered around the science of batteries. The library is being extensively used in research and is a big part of Twitter's battery community.

The main aim of this project was to extend PyBaMM's code to Twitter so that users can directly see PyBaMM's wide range of abilities like plug-and-play physics in action. A stretch goal was to accept requests from Twitter and reply with the appropriate simulation without the need of writing code.

More formally, the project aimed to create an automated Twitter bot that can -

  • Tweet random battery simulations (with/without degradation) regularly.
  • Reply to a Twitter simulation request with an appropriate plot.

Both of these functionalities should have had minimum or no human inputs (except for the tweet texts).

This in turn would have also helped PyBaMM by -

  • Stumbling upon undetected bugs
  • Increasing the overall visibility and publicity of the library itself

Work done

Some quick links -

Below are most of the pull requests (I decided not to add some small pull requests here, as they would've cluttered the report) that were made during Google Summer of Code 2021. The number of pull requests may seem greater than other GSoC projects as the BattBot repository was created from scratch. For further reference, a good amount of documentation, available in the README.md and CONTRIBUTING.md files, has also been added to the bot's repository.

  • Cleaning up the already written code - I created a simple working prototype of the bot before GSoC, these PRs were made to add and clean up that code (which acted as a base for the bot), thus making it ready for test-driven development. After these PRs were merged, the bot started tweeting some simple plots using GitHub Actions (Note: In the starting, the bot was hosted on my Twitter account and this repository was on my GitHub account).

    Relevant blog posts - Community bonding, Week 1-2
    #1 - Refactor the code and add a basic template for experiments.
    #4 - Restructure the bot, add tests and update the workflows to extract Twitter API keys from repository secrets.

  • Adding degradation and implementing GIF tweets - Adding degradation in the bot aligned with the original project proposal, that was, creating random battery degradation plots. Implementing GIF tweets was something that my mentors suggested, as it would have been better to tweet the whole simulation in a GIF instead of tweeting a PNG at some random value of time (x-axis).

    Relevant blog posts - Week 1-2, Week 3-4
    #5 - Add degradation, restructure the tests for codecov, add a timeout for simulations.
    #8 - Implement GIF tweets, remove tweepy, minor refactor and add a way to upload large files to the Twitter API endpoint in chunks.

  • Running tests in a subprocess, covering the same, and adding a small workaround for a Twitter API error - Some of the tests were running on the functions which were solving some random simulations, and these functions often crashed. Hence, adding a time-out to these tests was necessary so that they can be re-run if the time-out is hit. This, however, created a code coverage issue, as the coverage library cannot run tests in subprocesses by default which was also fixed in these PRs.

    Relevant blog posts - Week 1-2, Week 3-4
    #9 - Implement timeout and use coverage to run tests in subprocesses.
    #12 - Fix Twitter API internal error bug.

  • Adding non-degradation comparisons, removing some simple plots, and adding some parameters to vary - The simple plots that were initially implemented in the bot were removed and some comparison (comparing 2 or more models or parameter values) plots were added to the bot.

    Relevant blog post - Week 3-4
    #10 - Add comparisons with no degradation involved.
    #17 - Remove some simple plots.
    #18 - Shortlist and add some sensitive parameters to vary.

  • Adding tweet status for different possible configurations and a minor bug fix - Dynamic tweet statuses/texts were added to the bot that would be tweeted with the GIFs. A bug where some images were never deleted from the bot was fixed.

    Relevant blog post - Week 1-2
    #20 - Add tweet statuses.
    #21 - Delete leftover plots.

  • Store the random configurations and let users play with them - Till now, the random configurations that were being tweeted out were not stored anywhere, they could only be extracted from the tweet's text, and hence, users might've found reproducing that simulation a bit difficult. The following PRs updated the workflows to automatically save the configurations and added a notebook that could be used to run and play with the saved configurations.

    Relevant blog post - Week 3-4
    #22 - Update the workflows to store configurations and add a notebook.
    #30 - Fix a bug where the configurations aren't getting stored, update some parameters which are giving errors.
    #35 - Add a personal GitHub token to push to protected branches.

  • Tweet twice a day, vary C-rate and Ambient temperature, and scale functions - Tweet frequency and the time at which the tweets were sent out (with some randomness obviously) were updated. A bug, where functions were being replaced by float values, was fixed. To make the GIFs more random, C-rate and "Ambient temperature [K]" were now varied in every model comparison. At this point, the repository was moved to pybamm-team's account and the CI started failing because of some accessibility issues, some documentation errors also surfaced up, which were also fixed in the following PRs.

    Relevant blog post - Week 5-6
    #34 - Update the tweet time and frequency to store configurations and fix the broken links in documentation.
    #38 - Refactor parameter_generator and get it working for functional parameters, split the tests into 2 directories - with_keys and without_keys and update workflows to run without_keys tests on a PR from a fork.
    #40 - Vary "Current function [A]" and "Ambient temperature [K]" in all model comparisons.

  • Some minor bug fixes - For some random configurations, the generated tweet text was too long and for some random configurations, the tweet text had an extra (wrong) term which was fixed. The bug where sometimes the workflows, where the changes made to data.txt and config.txt files were being pushed, failed because of extra code in the repository, was also fixed.

    Relevant blog post - Week 5-6
    #44 - Fix the tweet text while varying "Current function [A]" and "Ambient temperature [K]".
    #45 - Pull the latest code before pushing.
    #46 - Fix the long tweet text bug.

  • Creating a base for the reply feature - The tweeting functionality was almost ready and now it was time to implement the replying functionality. For this, I started by adding a Reply class where all the reply stuff will occur and then refactored all the random parts of the codebase into a single function (separating the random part from the simulation and solving part). So now, a configuration could either be randomly generated (tweet) and solved or could be read from a tweet text (reply) and solved using the same code. In the end, I decided to create a super class for Tweet and Reply classes which would have all of the common code (the code where GIF is uploaded to Twitter API's endpoint).

    Relevant blog post - Week 7-8
    #41 - Add all the required files for Heroku, and add the Reply class.
    #48 - Refactor randomness out of the codebase to a single function, and transform the comparison_generator function to a class (ComparisonGenerator).
    #58 - Create a super class for Tweet and Reply, and add "model comparison" replies for testing the added code.

  • Adding print_name to functional parameters and fixing a major bug - The FunctionLike class missed a __str__ method and it would have been cleaner to print the symbol of a function in latex in the legend of the GIF. The Heroku deployment was also going out of sync with GitHub Actions deployment in the terms of last_seen_id which, combined with Heroku's ephemeral filesystem, created an infinite reply bug.

    Relevant blog post - Week 7-8
    #51 - Add the sync_last_seen_id function which now runs on GitHub Actions.
    #56 - Add the __str__ method and print_name for functional parameters.

  • Adding more reply types and varying C-rate and "Ambient temperature [K]" always - Now that the Heroku deployment was working fine, it was time to add more reply types. To make things more random, C-rate and "Ambient temperature [K]" were varied in every plot.

    Couldn't create a blog post for weeks 9 and 10 :( but the PRs are well documented.
    #60 - Allow users to pass experiments in their requests.
    #61 - Vary C-rate and "Ambient temperature [K]" always.
    #63 - Allow users to request parameter comparisons.

  • Saving memory on Heroku and degradation comparisons - The degradation comparisons were finally working without any errors with Mohtat2020 chemistry and Single Particle Model, hence, the branch was finally merged. Heroku deployment was not working because of memory issues which were also solved.

    Couldn't create a blog post for weeks 9 and 10 :( but the PRs are well documented.
    #36 - Implement degradation comparisons.
    #64 - Fix Heroku deployment.

Work left

Almost all of the work has been done, proper documentation and tests have been added, and the bot has evolved beautifully with time. The only thing that is somewhat incomplete is the degradation comparison. The branch, with proper implementation, has been merged but the number of random configurations that the bot can generate is very small. I'll be adding more configurations (just adding them to a list of already existing items, the code will take care of combining them randomly) as soon as some small bugs are fixed in PyBaMMM's degradation mechanisms. With this, I'll also look forward to adding degradation comparisons to the replying functionality.

Future work

  • Maintaining the bot.
  • Implementing some of the bot’s functionalities in PyBaMM (Plotting summary variables, comparing summary variables, etc.).
  • Working on and closing some open issues in PyBaMM.
  • Implementing more plots and replies in the bot.
  • Adding more degradation mechanisms to the bot.

Some final words

It has been an absolute delight to work with PyBaMM's team, and the last 3-4 months have been incredible! In such a short period, I learned a lot, ranging from clean code practices to battery physics to collaborating over code. I am extremely grateful to my mentors who have been the driving force behind my journey. The PyBaMM community has always been extremely inclusive, welcoming and has acknowledged and solved all of my doubts no matter big or small. This was the best summer I could ask for and I am looking forward to making more contributions to PyBaMM:)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment