-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add progress bar to phonon calculations #319
base: main
Are you sure you want to change the base?
Add progress bar to phonon calculations #319
Conversation
@@ -8,6 +8,7 @@ | |||
import phonopy | |||
from phonopy.file_IO import write_force_constants_to_hdf5 | |||
from phonopy.structure.atoms import PhonopyAtoms | |||
from tqdm import tqdm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tqdm
may be a dependency of a dependency and that's not a good thing to rely on. You need to add this explicitly to dependencies if you want to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, rich
is also a dependency of a dependency, that may be a better choice here since Jupyter notebooks and IPython are encouraged ways of using Janus
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know how rich compares in terms of performance/overheads?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea, but I should think minimal in relation to a phonon calculation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Supposedly, they should be pretty comparable nowadays. Regardless, as mentioned, the milliseconds are going to be negligible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's all fine if everyone's happy. The main thing was that it was an option which is why (although not necessarily obvious in the GitHub font) "may" was italicised.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, it does appear to me that
tqdm
integration with jupyter notebook could be non-trivial
Don't worry the integration is that it prints to the output perfectly happily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, to confirm, we are sticking with tqdm
, is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I obviously haven't seen how this specific one would look in comparison, but in general rich
maybe looks slightly nicer to me, and maybe fits stylistically with the typer interface better.
So, all things being equal (e.g. no immediately noticeable performance issues, which it sounds like there shouldn't be), I'd maybe tend towards rich
.
I am completely fine with tqdm
if it's more straightforward to finish this PR up though, as long as it addresses the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way, don't forget @oerc0122's original point to add the dependency to pyproject.toml!
Thanks for this!
I agree it's a bit confusing, so I'd say yes we probably do want some kind of output labelling the progress bar.
Thanks for the report! If you still encounter this after updating with the latest fixes, please open a new issue. |
@@ -258,6 +258,7 @@ def phonons( | |||
"write_results": True, | |||
"write_full": write_full, | |||
"file_prefix": file_prefix, | |||
"enable_progress_bar": True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"enable_progress_bar": True | |
"enable_progress_bar": True, |
To make ruff happy (best merged with other suggestion)
@@ -149,6 +150,7 @@ def __init__( | |||
write_results: bool = True, | |||
write_full: bool = True, | |||
file_prefix: Optional[PathLike] = None, | |||
enable_progress_bar: bool = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
enable_progress_bar: bool = False | |
enable_progress_bar: bool = False, |
To make ruff happy (best merged with other suggestion)
-- tqdm docs |
I am looking into |
Closes #268
Adds a progress bar to phonon calculations using
tqdm
, which is already a dependency. A new argument was added toPhonons.__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.