GSoC’21 — Week 3 and 4 — Getting the bot ready for official deployment
The last two weeks were all about making small but important changes in the bot before it goes live. We also decided on the bot’s name through a fun Twitter poll:). Here are some of the relatively big additions I made during this period —
The first half of the third week was all about modifying the already existing code to make way for the degradation comparisons. The code was modified successfully but while checking the sensitivities for the shortlisted parameters, the summary variable plots were coming out a bit weird. This was later discussed in a meeting and was eventually fixed by my mentors, but, I couldn’t continue with that branch because I started working on other parts of the codebase (which I will be talking about below). I will be continuing with the branch this week, adding the sensitive parameters and implementing the degradation comparisons.
Playing with the time-out and removing some plots
After the degradation comparisons, I tried to implement a dynamic time-out for the simulations (I mentioned this in my last blog as well) but there was no progress even after trying out various different options. At last, we decided to implement a time-out based on what simulation is going on but that was discarded when it was decided to remove some plots. Now the plots that the bot will be tweeting will be of the comparison type and they have been given a time limit of 1200 seconds.
Adding sensitive parameters and Tweet status
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+decription tweets started getting better attention than the only plot tweets.
Storing the random configurations and letting anyone play with it
All the random configurations that we were tweeting, were not stored anywhere (except the Tweet status) and the configurations were something that we wanted to store somewhere for the following reasons —
- Creating a database of such configurations for future studies
- Letting the users see what configuration was tweeted
- Creating a notebook for the user to play with the tweeted configuration
This was worked upon in week 4, where I added a
config.txt file to store the latest Tweet configuration and a
data.txt file to store all the data with date and time. The data present in
config.txt was then pulled in the Notebook which after going through a lot of
if-else conditions showed the user the latest Tweeted plot. This also meant changing the workflows to push the changes which were made in these
txt files after every Tweet, which was a problem as it would have resulted in an infinite loop on the main branch (A Tweet happens —
txt files are updated — these changes are committed and pushed by the workflows — this push triggers the CI again — everything repeats). To tackle this, I decided not to run CI on the commits made by the workflow by editing the workflow itself and after a lot of YAML errors, it worked! Once the branch is merged, you will be able to run the latest tweeted configuration on your local environment as well as on Google Colab.
Other than these changes, some issues and bugs like the “Twitter API issue” and the “Deleting the leftover plots” were also worked upon. Documentation was also added to make this repository more suited for contributions and the repository will be moved to the official pybamm-team account in the next couple of days!
For the fifth week, I plan on adding the degradation comparisons and completing the “Tweeting” capability of the bot so that I can move to the “Replying” feature for the second half of the coding period.