Test bed for matrix solvers

[bcumming]

This task will set up a test bed for experimentation with the solution of Hines matrices. On completion, we will have a test bed for further experimentation and an understanding of Hines matrices.

Steps involved

• generate and store representative matrices from the miniapp
  • store in json file format
• start test bed in Python or Julia
  • class for Hines matrices
    • mimics storage used in NestMC (l, u, p and rhs vectors)
    • can load Hines matrices from file
    • also store the voltage solution v from the previous time step, which will be used as the starting point for iterative methods.
  • read and understand documentation on Hines method
  • Hines method implementation for solving linear system

[bcumming]

We have started to use Julia, and you can consider using it too.

Benefits:

• all of the basic mathematics tools are built in (like matlab), so no need to install packages like numpy.
• generates very efficient code

Cons:

• not widely available (you will have to install it yourself)
• not as widely understood as Python

[halfflat]

As a prelude to the upcoming GPU hackathon, we should have this test bed in a state where we can validate and benchmark CPU and GPU implementations of the solver across a number of configurations of sets of matrices.

A test configuration would consist of timing the performance across N matrices drawn from k sparsity patterns, each pattern corresponding to a different discretized neuron morphology. Three broad categories are of interest: uniform, with k=1; low diversity, with 1 < k ≪ N; and high diversity, with N ≤ k.

Subtasks (point estimate in [brackets]):

• Extend miniapp recipes to allow for diverse morphologies governed by a small set of parameters drawn from random distributions. For biologically reasonable populations, we could adopt an L-system approach such as that described in Ascoli et al. 2001. [8]
• Extend miniapp interface to specify mophological recipe. [2]
• Extend miniapp/nestmc core to allow for extraction and dumping of (l, u, p, rhs; vprev) systems; should include metadata that can allow them to be grouped by sparsity pattern. [2]
• Create test harness:
  • Loads set of dumped Hines matrices. [2]
  • Runs selected implementation in benchmark loop (interface should separate data packing/reformatting from solution phase) and validates result by multiplication. [4]
  • Implement standard serial Hines solver as a baseline. [1]

[pedrovalerolara]

We have a CUDA implementation which can deal with a large number of neurons, but not different. We are working on a version which can deal with different morphologies. We have a seq. version for Hines.

[bcumming]

For the test harness, instead of taking a dumped set of Hines matrices, how about feeding in the "recipe" directly?

• it would cut out the run miniapp -> dump -> run harness workflow
• it would familiarize people with NestMC internals a bit better
• it would also work directly with data in the same form as it comes into the simulator, which would make it easier to integrate the result back into NestMC

[halfflat]

It's a good approach — especially (as we discussed offline) if we leave out for now iterative schemes and tackle just direct solvers for the Hackathon, allowing us to pretty much ignore the 'correct' values of the matrix elements and just go straight from recipe → morphology → matrix sparsity → concrete but arbitrary diagonally dominant matrix, without having to extract data from the lowered cells.

[bcumming]

After having a scan through the paper on L-systems, I wonder if that is a bit too complex for our case? It would be nice to have a feature in our NestMC library for building such morphologies, but a time estimate of 8 unites seems a bit optimistic to me.

How about something much simpler with a couple of tunable parameters?

[halfflat]

The complexity is in the data representation, but I think using a fairly simple class hierarchy for the representation of the distribution parameters and corresponding json representation would suffice, and take about two days to code. Generation from that point should be straightforward, and we can pull the distribution parameters for some neurons directly from the paper.