The First 2 weeks of Google Summer of Code 2021 are now over, and spoiler alert, these 2 weeks were more about development and less about battery mathematical modeling as compared to the community bonding time (if you missed that blog, read it here). Here is every major thing I did in these two weeks while working on my project (“Automated Twitter Bot to run PyBaMM Simulations”) —

GIF Tweets and the Twitter API

Marquis2019 parameter set, solved using CasADi solver with ‘safe’ mode with the experiment - [(‘Discharge at 3 C until 3.3 V’, ‘Rest for 1 minute’, ‘Charge at 3 C until 4.1 V’, ‘Hold at 4.1 V until 7 mA’, ‘Rest for 10 minutes’)]

At the end of the community bonding time, I and my mentors (their suggestion) decided to tweet GIFs of the plots rather than a single picture at some random time. Though it wasn’t that tough to generate them, it was tough to keep them in a certain boundary condition so that they can be tweeted using the Twitter API. While doing this, I learned a lot about image processing, resizing, and manipulation using Pillow and Imageio. I was able to tweet small GIFs or a big GIF but compressed to a smaller size using Tweepy, but we eventually thought of switching to the traditional way, where we can tweet bigger files by directly interacting with the API (without using a wrapper library like Tweepy).

The infinite crash issue

Me and the CI/CD pipeline I built using GitHub Actions for a couple of days

It didn’t take long for everyone to realize that a very small amount of these randomly put-together configurations crashes the solver in a way that the program starts printing warnings/statements infinitely, and never stops. This causes the tests to fail (as the integration tests do produce some random simulations) on GitHub Actions because of the 360-minute timeout. It also causes the Tweeting functionality to fail sometimes in a similar fashion. A few measures involving threading and multiprocessing have been implemented but I am still trying to implement an ever smarter time-out functionality. With this, coverage.py was also extended to account for the tests being run using a subprocess or a thread (initially, it did work on my machine but it took me another day to figure out why it was failing on GitHub Actions).

Comparison plots and the Sensitive Parameters

These plots are the ones I find the most interesting and they were implemented in these 2 weeks (working on the degradation comparison plots). With these plots, a lot of sensitive parameters and degradation parameters were discussed which will most probably be added to the bot in the upcoming weeks. Finally, some bugs and minor issues related to the comparison plots were also resolved. You can find the developing repository here.

In the next 2 weeks, I will implement the degradation comparisons, work more on the sensitive parameters with my mentors, and maybe shift the bot to an official Twitter account! Follow me and PyBaMM on Twitter to keep an eye on the bot’s official announcements.

(Same post, but on medium (I am migrating my blogs from medium to my website))