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.
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.
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
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
At the end of the third week, we decided to give the bot a good and dynamic description, to go with the plots that were being tweeted, and also added all the sensitive parameters which will be varied in the comparison plots. After this, the bot was almost ready for the first deployment and the new plots+description tweets started getting better attention than the only plot tweets.
Storing the random configurations and letting anyone play with it
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