Progress and notifications

[thesamovar]

It would be nice to have slightly more sophisticated progress reporting and notification when the simulation is complete.

For progress reporting:

• [ ] Progress reporting that allows you to recursively subdivide tasks, i.e. a big simulation that runs 10 smaller simulations, which in turn each run 10 smaller simulations. Brian's ProgressReporter almost has this, but it's not recursive.
• [ ] Improve the GUI option for progress reporting.
• [ ] Integrate with the notification system (below)?

For notification, the idea would be to let the user know a long-running simulation has finished which doesn't require them to monitor a console. For example, a pop up notification on the system tray in Windows, or an email.

• [ ] Cross-platform pop-up notification
• [ ] Send an email when the task is finished

There might be standard apps that you can use for notification - so perhaps it's not worth adding it to Brian?

[mstimberg]

I think -- similarly to what we talked about for visualisations, analysis, etc. -- we should focus on making the core clear and extensible. In my view: The progress report should have support for subtasks as you say and should be able to call arbitrary reporting functions when something is to report. Of course we should provide the standard text-based report (and maybe something HTMLy for the ipython notebook?) but even the GUI (did anyone ever actually use this...?) is somewhat out of scope IMO. Notification at the end could be handled by the 100% progress notification or with standard tools (e.g. you could simply do python my_script.py; notification_script)

[thesamovar]

A possible idea: what about having a new package brian_extensions which is basically add-ons for Brian that more people can contribute to, and we don't officially support? A bit like the failed neuroscience cookbook? There are some things like this which it seems a shame if everyone is implementing for themselves.

[mstimberg]

A possible idea: what about having a new package brian_extensions which is basically add-ons for Brian that more people can contribute to, and we don't officially support? A bit like the failed neuroscience cookbook? There are some things like this which it seems a shame if everyone is implementing for themselves.

Sounds good to me -- even though for stuff that is Brian-independent (spike train statistics, visualisation), I'd rather make Brian play nicely with external tools and make users contribute to them. It would then be more of a documentation issue, e.g. a wiki (which would make it more similar to the cookbook again :) ) But maybe you are right, being able to call a function from a non-standard standard package is better than copy/pasting it from a website.

[thesamovar]

I really don't know what is the best way of doing it. I feel like having code in a repository is better than using a wiki though. For a start, it allows you to track changes, submit bug reports, etc.

Another name idea for the package: brian_community. And we'd allow many more people commit rights to that repository. Or maybe brian_community for the team name, and several different repositories. Oh, the possibilities!

[mstimberg]

I really don't know what is the best way of doing it. I feel like having code in a repository is better than using a wiki though. For a start, it allows you to track changes, submit bug reports, etc.

Yes, having it in a repository is probably better. It would also have a couple of infrastructure advantages to separate it (including examples) from the main repo -- e.g. an addition to the examples does not trigger the whole testing machinery.

Another name idea for the package: brian_community. And we'd allow many more people commit rights to that repository. Or maybe brian_community for the team name, and several different repositories. Oh, the possibilities!

Well, we don't have to necessarily allow many more people to commit, they could still do pull requests but it wouldn't have to go through a scrutinizing code review. But yes, there are quite a number of possibilities...

[thesamovar]

Two more ideas for this:

• [ ] As well as dividing up tasks into subtasks, allow setting an expected total simulation time so that if you know you will break into 10 runs of 1s each your expected total simulation time would be 10s, and percentages calculated appropriately.
• [ ] Option to only print progress if it deviates substantially from the expected end time. So for example you launch a simulation at 12.04 and it prints out after a few seconds that it expects to finish at 12.08. If that estimate doesn't change at 12.05 it doesn't print anything, but if it changes at 12.06 to 12.09 then it prints it out.