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

Improve the mechanism that choses a numerical integration algorithm #351

Closed
mstimberg opened this Issue Oct 28, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@mstimberg
Member

mstimberg commented Oct 28, 2014

Currently, if no integration algorithm is chosen, the list of state updaters is tried one after the other until a suitable updater is found. There are several issues with the current system:

  • The exact integrators might take a long time until they realize they can't integrate the equations
  • One might want to use different defaults for "normal" neurons and multicompartment neurons
  • conditionally linear equations will use exponential Euler integration therefore users might think Brian 2 is slower than Brian 1 where the simpler forward Euler algorithm is used by default (but exponential Euler is also particularly slow in numpy or weave without --fast-math currently because we don't optimize the generated code, a term like exp(-dt/tau) will appear quite often)

We still want to keep the system simple and extensible but maybe something where we don't just order algorithms in a list but instead store some information about their accuracy (and assuming that this is inversely related to their run time)? The user could then chose between a "performance-first" or an "accuracy-first" strategy.

@mstimberg mstimberg added this to the 2.0beta2 milestone Oct 28, 2014

@thesamovar

This comment has been minimized.

Show comment
Hide comment
@thesamovar

thesamovar Oct 28, 2014

Member

I like the idea of the user prioritising performance versus accuracy.

We can also sort some of these problems by cacheing the results of the symbolic work (see #124).

Member

thesamovar commented Oct 28, 2014

I like the idea of the user prioritising performance versus accuracy.

We can also sort some of these problems by cacheing the results of the symbolic work (see #124).

@mstimberg mstimberg modified the milestones: 2.0beta3, 2.0beta2 Feb 2, 2015

@mstimberg mstimberg self-assigned this Mar 2, 2015

@mstimberg mstimberg modified the milestones: 2.0beta2, 2.0beta3 Mar 2, 2015

@mstimberg

This comment has been minimized.

Show comment
Hide comment
@mstimberg

mstimberg Mar 2, 2015

Member

We discussed this a while ago and agreed that the best approach for now is a very simple one: each class that takes a method keyword argument (e.g. NeuronGroup) will have a list of methods that will be tried in order as the default argument, e.g. for NeuronGroup it could be ['linear', 'euler', 'milstein']. This allows us to have different defaults for different classes and is also very clear for the user (e.g. you see directly in the class documentation what methods will be tried). In principle, the user could even replace the list by a list of their own, but I don't really see a use case for that.

Member

mstimberg commented Mar 2, 2015

We discussed this a while ago and agreed that the best approach for now is a very simple one: each class that takes a method keyword argument (e.g. NeuronGroup) will have a list of methods that will be tried in order as the default argument, e.g. for NeuronGroup it could be ['linear', 'euler', 'milstein']. This allows us to have different defaults for different classes and is also very clear for the user (e.g. you see directly in the class documentation what methods will be tried). In principle, the user could even replace the list by a list of their own, but I don't really see a use case for that.

mstimberg added a commit that referenced this issue Mar 2, 2015

Change the system that decides which state updater algorithm is used
Now, each object defines its own list of algorithms that are tried in order. Closes #351
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment