Today marks an end to the community bonding period of Google Summer of Code 2021, and hence I decided to document my journey in the form of a blog. I’ll try to make this blog fun, short and to the point, buckle up!

Back story!

I entered the open-source world in December 2020 as a complete beginner, I knew some high school C++, python in bits and pieces, and had some experience with hybrid-app development, and honestly, at that point, I just wanted to contribute to some open-source software.

While contributing to some Flutter apps, I stumbled upon a project that was participating in Mexili Winter of Code, long story short - I participated and learned a lot about open-source, and this in the end, motivated me to look for some bigger projects in which I can contribute.

PyBaMM (Python Battery Mathematical Modelling)

“PyBaMM (Python Battery Mathematical Modelling) solves physics-based electrochemical DAE models by using state-of-the-art automatic differentiation and numerical solvers.”

While working on random configurations, 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. Two, it also causes the Tweeting functionality to fail sometimes in a similar fashion. A few measures using 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

I discovered PyBaMM through NumFOCUS’ sub-organizations list and though the huge codebase was intimidating at first, some of the terms looked familiar as I had electromagnetism and electrochemistry in my high school from which I graduated a few months back. I decided to take up a small issue with no prior knowledge of the codebase and the whole PyBaMM community turned out to be very supportive and welcoming. Soon the example notebooks started making some sense to me and I started communicating regularly with the community by solving some more small issues.

With some progress in understanding PyBaMM’s codebase and the things it is capable of, I decided to work on a project idea that was listed in the discussions tab for GSoC. This again resulted in me learning a lot of new things with the help provided by the organization and the mentors.

Fast forward to the result day, all the hard work from my side and the organization’s side paid off, and I was finally selected for a project named “Automated Twitter bot to run PyBaMM simulations”!

Community Bonding time

The community bonding period started with some discussions on which simulations should be added to the bot initially, and I realized that the discussions would go in vain if I don’t actually try out the features that are being discussed, in the code. This took some extra time but in the end, I enjoyed the whole process and did somehow manage to construct a basic structure for the “Tweeting” functionality of the bot.

I was also invited to be a part of the GitHub organization (this was really exciting) and, I was also invited to the weekly PyBaMM meeting and weekly project standup/discussion meeting. I was actually scared to attend these meetings initially but it all went away after attending the first meeting, where I introduced myself and learned about how a meeting in PyBaMM usually proceeds.

Last but not the least, I will list out some major things that were discussed or some major things that I worked on during the community bonding period -

  1. Discussed the simulations that should be added to the bot.
  2. Refactored and updated the already written code.
  3. Added tests and documentation for the already written code to make the project ready for test-driven development.
  4. Integrated codecov and wrote workflows for continuous integration and continuous deployment.
  5. Decided that using GitHub actions for the “Tweeting” functionality and Heroku for the “Replying” functionality would be a better deployment structure.
  6. Added degradation to the models and introduced summary variables in the bot.
  7. Replaced the plot PNGs with GIFs for better clarity and understanding.
  8. Replaced the Twitter API wrapper tweepy with built-in python libraries.
  9. Added a way to resize GIFs and to upload them in chunks before finally tweeting them out.
  10. Discussed some possible comparisons with and without degradation mechanisms.
  11. Learned some battery related terminologies and concepts :D

The repository can be found here.

Overall, the experience has been great:), it actually feels good to contribute and collaborate on a project that is being used by people worldwide, and also where the mentors and every organization member is so welcoming and is always ready to help!

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