GSoC’21 — Week 5 and 6 — BattBot is live!

With half of the coding period coming to an end, the bot is finally live! You can find it, tweeting Battery Simulations twice a day, here — BattBot. Once the repository was moved to pybamm-team’s account, and once the bot went live, a lot of things broke, and a lot of bugs surfaced up. Fixing these broken things was the main agenda for the last two weeks. Apart from the fixes, I also did make some substantial improvements in the bot in terms of reliability and user experience.

Starting the week with degradation comparisons

As I mentioned in my last and my last to last blog post, I wanted to implement the degradation comparisons in the 5th week which I did manage to, but the resultant plots were still coming out a bit weird. For instance, “Capacity [A.h]” was going up in some of the GIFs (with Marquis2019 parameter sets) instead of going down, and this was something that was not ideal.

“Capacity [A.h]” going up with Marquis2019 parameter sets

Interestingly, while simulating one random experiment, the degradation mechanisms started behaving even more weirdly. It seemed like the model had degradation for a cycle and then didn’t have one for the subsequent cycle.

Plotting Single Particle Model with Chen2020 parameters and reaction limited SEI, for the experiment: [(‘Discharge at 3 C until 3.3 V’, ‘Charge at 3 C until 3.8 V’, ‘Hold at 3.8 V until 63 mA’)]

We decided to pause with the degradation mechanisms branch to make sure that the bot doesn’t tweet out wrong or misguiding tweets. The branch is almost complete, and it will be merged whenever the plots start coming out without such errors (whenever the degradation mechanisms are fixed in PyBaMM).

BattBot is born

BattBot!

A lot of new accounts were created in the last two weeks, a new Gmail account for the bot, a new Twitter account for all the tweets, a new Twitter Developer Account, and finally, a new Heroku account to deploy the replying functionality. The repository was also transferred to pybamm-team’s account where all the existing API keys were replaced with the bot’s API keys. A lot of issues started coming up after the bot started tweeting out, which were somehow related to moving the repository. These issues were fixed immediately but, the CI started failing and kept on failing for almost a week which I will be discussing in the next section.

The failing CI

The CI initially started failing because of a missing __init__.py file in the PyBaMM repository which was fixed in a couple of days. But after that, the CI unexpectedly started failing again and the two major reasons for this were my repository access rights and 2 misplaced lines in the YAML file. Both of them were fixed and a PERSONAL_GITHUB_TOKEN was added to push directly to the protected branch but the tests were still failing. The main reason for this was the inaccessibility of repository secrets to a forked repository, as now I was making PRs from a fork. We never wanted to pass the repository secrets to a fork as they could then be exploited by writing a malicious script and creating a PR. Hence, to tackle this, we decided to run only the tests that don’t need Twitter API keys on PRs from a fork, and to achieve this, the tests directory was bifurcated into two sub-directories which were with_keys and without_keys . After this, the YAML file was again updated to account for these changes and finally, the tests started passing, after failing for almost a week.

A lot of other small changes were also made. Listing some of them here -

• Randomising Tweet time to some extent and changing the frequency
• Fixing parameter_value_generator to include functional parameters too
• Fixing a bug in the tweet text
• Varying “Ambient temperature [K]” and “Current function [A]” while tweeting out constant discharge plots
• And finally, adding a base for the replying functionality