Skip to content
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

Better progress bars #52

Open
Datseris opened this issue Mar 22, 2023 · 0 comments
Open

Better progress bars #52

Datseris opened this issue Mar 22, 2023 · 0 comments
Labels
ux user experience

Comments

@Datseris
Copy link
Member

Taking as an example the RecurrenceSeededContiniation, the whole compitation process can take hours if one requires very high solver accuracy, FSM accuracy, or just a lot of initial conditions. Not only that, but it can take an hour to just go from one parameter to another. The progressbar in this case is effectively completely stuck giving no information on the progress.

I think we need to rework the progress bar to not be updated only when the parameter is updated. There are two ways I can think:

  1. Allow for a subprogress bar to be displayed by the internal basins_fractions calls. This would be much more informative for the user, but would also require a bit of findlking with ProgressMeter.jl to see how it is possible. I think ProgressMEter.jl has an offset keyword for something like that.
  2. Re-work the progress code, so that a progress bar is given to the basins_fractions!. The internal function just calls next! on the progressbar and the overarching progressbar has n*spp total stepping values.
@Datseris Datseris added the ux user experience label Mar 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ux user experience
Projects
None yet
Development

No branches or pull requests

1 participant