Skip to content

September 2020

Alexandru Săvulescu edited this page Feb 11, 2021 · 7 revisions

Time: 18.9.2020, 16:00 CEST; 10:00 EDT Place: Zoom

NOTE: Please contact one of the NEURON dev members for the link if you are interested to join.

Agenda

  • Introduction from "new" members
  • NEURON News / Announcements
  • Efficient dataset saving from large simulations
  • NEURON recent changes
  • Moving to Modern C++
  • GPU support update
  • Better backtraces
  • Differentiate Netcons while in NET_RECEIVE
  • Summary of Important Issues
  • Next Meeting

Slides

https://docs.google.com/presentation/d/12sfu6UrrlR8MIC-Z-MFlVPMCHgATJ9YgPV7Lljpu7MM

Attendees

  • Omar Awile
  • Alessandro Cattabiani
  • Ted Carnevale
  • Joe Graham
  • Michael Hines
  • James Gonzalo King
  • Pramod Kumbhar
  • Bill Lytton
  • Ioannis Magkanaris
  • Robert McDougal
  • Adam Newton
  • Fernando Pereira
  • Alexandru Savulescu
  • Felix Schuermann

Meeting Minutes

NEURON News / Announcements

Discussion of a potential NEURON course this year in place of the traditional one day SfN course, maybe shorter sessions spread over 2-3 days to take place online with limited registrations. The online chat is very useful for keeping people engaged and answering questions. Breakout rooms have the advantage that someone who is having problems can share their screen, but the downside is they become disconnected from the main meeting.

Efficient dataset saving from large simulations

BlueBrain group had previously been using a custom data format but their focus has shifted to SONATA and efficient export and reading the simulation results.. Discussions suggested that NWB being used for experimental data rather than simulated data. While HDF5 is moving in the wrong direction for simulation data, with more of a focus on long term data storage.

NEURON recent changes

Recent developments of the communication between NEURON and CoreNEURON allow transfer of spike time raster, weight and vector records to NEURON after a CoreNEURON run. Currently there are two models, but this maybe address by refactoring, to divided data (which may have to be transferred multiple times) from structure (which may only need to be transferred once). Completing the connection between NEURON and CoreNEURON, together with solving the units problem (to allow backward compatibility to older version of NEURON) are the only two tasks left before NEURON version 8 can be released, maybe in the next few months.

Moving to Modern C++

Switching to C++14 is the minimum required to provide GPU support in Python wheels. All source code should be moved from c to cpp except third party libraries. extern c should only be used when essential, e.g. when interfacing with 3rd party libraries. A cpp branch is available and working for MacOS with CMake. Autotools may be a problem, it could be removed or fixed once the update is complete under CMake.

GPU support update

Benchmarking NEURON against CoreNEURON using the olfactory bulb model, showed a ~4.5 times speedup using CoreNEURON with ~8 times less resources. However the performance on the model does not scale well which could be because the simulation is too small size or due to communication bottlenecks.

Better backtraces

Errors in mod file do not produce useful information for debugging but does provide different signal handler Issue 733. Using backtrace and backtrace_symbols provides more useful information (see branch enh). This can be improved further by using __cxa_demangle (cxxabi.h) to demangle C++ symbols and dladdr (dlfcn.h) to provide the line in the source code (not the mod file but the file produced by nrnivmodl). This functionality might not be available in the windows build, as some methods are missing in mingw.

Differentiate Netcons while in NET_RECEIVE

There is a use case where a synapse has multiple NetCon providing e.g. a point process for spontaneous release, another imitating a particular firing pattern and a connection to a presynaptic cell. If you want to update the weights for only one of the sources, how should you indicate the source in the NET_RECEIVE block? Should a NetCon's gid be passed to NET_RECEIVE, or use a flag, by assigning a constant to weight[index]?

Next meeting October 16, 2020, 16:00 CEST; 10:00 EDT

Clone this wiki locally