Add progress bar to phonon calculations

[RastislavTuranyi]

Closes #268

Adds a progress bar to phonon calculations using tqdm, which is already a dependency. A new argument was added to Phonons.__init__ to control the presence of this feature, disabled by default to minimise impact on code in general. However, the progress bar is always enabled for CLI.

One issue that I and @ajjackson have noted is that the bar only shows the progress over displacements, meaning that when bands, DOS, or PDOS are chosen to be calculated, the 100% bar just continues sitting there despite the prolonged calculations. This could be confusing to users. One solution could be writing to stdout before/after the progress bar appears, saying what the bar is for, but we weren't sure what the best path forward is. What do you think?

Additionally, I should probably mention that I ran into #316 while working on this despite only running janus only in serial.

[ElliottKasoar]

Thanks for this!

One issue that I and @ajjackson have noted is that the bar only shows the progress over displacements, meaning that when bands, DOS, or PDOS are chosen to be calculated, the 100% bar just continues sitting there despite the prolonged calculations. This could be confusing to users. One solution could be writing to stdout before/after the progress bar appears, saying what the bar is for, but we weren't sure what the best path forward is. What do you think?

I agree it's a bit confusing, so I'd say yes we probably do want some kind of output labelling the progress bar.

Additionally, I should probably mention that I ran into #316 while working on this despite only running janus only in serial.

Thanks for the report! If you still encounter this after updating with the latest fixes, please open a new issue.

[oerc0122]

I agree it's a bit confusing, so I'd say yes we probably do want some kind of output labelling the progress bar.

tqdm allows you to pass a label.

desc: str, optional
Prefix for the progressbar.

-- tqdm docs

[RastislavTuranyi]

I am looking into rich at the moment, as per suggestion, and it can also have a label. The progress bar can also be made to disappear at the end, so I think a text could be displayed in its place to indicate that further calculations may be ongoing. Unfortunately, since the bands/DOS/etc. calculations are handled entirely by Phonopy, I don't think there is a way to display a progress bar there, though we could maybe do like a spinner or something of that sort, if desired.

[RastislavTuranyi]

I have pushed the rich version, though we chose the one with the customisations as we thought that having the number counter for the progress through displacements is much nicer (and more helpful!) than the %. For niceness, all the customisation bit was placed into a separate function that works just like rich.progress.track, so that in the main code it's just a one-liner. I wasn't sure where to place this function, so for now I put it to helpers.utils with the rich imports inside the function in order to avoid polluting the entire file with the (apparently slow) rich imports (since I believe rich might not necessarily be imported when using Python API).

Additionally, as can be seen in the pictures I posted earlier, my terminal was interpreting the colour of the finished progress bar as grey (even though it should be a dark green), the same as the empty progress bar. Since I might not be the only one to run into this, we decided to change the colours of this progress bar to the janus (logo) colours of light (#FBBB10) and dark orange (#E38408).

I have also run ruff, so that should hopefully be ok, and I have also added rich as a dependency.

Please let me know if you have any comments/suggestions/etc.!

[ElliottKasoar]

This looks great, thanks!

I've added one suggestion that I think should fix the docs.

I think in terms of imports, I'd maybe move them to the top still, to be consistent with our current approach elsewhere.

We definitely want to address imports for the CLI (#272), since it's a much more noticeable issue for autocompletion, but otherwise it's not clear that it's a problem (I mentioned it just as something to keep in mind), and I think maintaining consistency will make it easier if we do decide to change our approach later.

[RastislavTuranyi]

Sure! I can definitely move the imports among the other imports; should I leave it in the helpers.utils or put it elsewhere? I wasn't really sure

[ElliottKasoar]

Sure! I can definitely move the imports among the other imports; should I leave it in the helpers.utils or put it elsewhere? I wasn't really sure

Thanks! helpers.utils is perfect

[RastislavTuranyi]

Should be fixed now

[ElliottKasoar]

Looks good to me, thanks for this!