Refactor summation point logic in CPU neuron model to better align with GPU model

[NicolasJPosey]

The GPUModel.cpp has a calcSummationPoint method that implements the GPU version of the summation point logic. On the CPU side, this logic is embedded in the AllSpikingSynapses::advanceEdge method.

This should be pulled out into a calcSummationPoint method that the CPUModel.cpp implements. This method would then get called in the CPUModel::advance method after advancing the edges, similar to to how the GPUModel::advance method behaves.

Some other related changes that could be made:

• Since CPUModel and GPUModel would both be implementing a calcSummationPoint method, this could be added as a virtual method in Model.h for a derived type of model to implement.
• The name "calcSummationPoint" would not be an appropriate name for an NG911 model. Therefore, if we make change 1, we should rename "calcSummationPoint". I propose this method is named "updateVertexState".
• In addition, we wouldn't expect the NG911 model to have the same implementation logic as a neuron model for updateVertexState. I see two ways to resolve this issue:
  1. The first is that we could consider changing the current "CPUModel" and "GPUModel" classes to "NeuronCPUModel" and "NeuronGPUModel" respectively. This would allow us to define different logic for updating the vertex state in a NG911 model while keeping the changes relatively minimal. I estimate that at least the Simulator.cpp class and the Model classes would need to be changed (assuming we can get the derived type information from what is currently in the config files).
  2. The second is that we could add a updateVertexState method to the AllVertices class and call updateVertexState as a AllVertices method instead of a Model method. This would allow vertex-related stuff to live in a more appropriate place.

The last point can be summarized as such:

• Make Model be extensible for neuron and NG911 models
  • Pros: Implementation would mostly look like it currently does for the area we are trying to update.
  • Cons: Model type would contain vertex-related logic. Vertices are already extensible for neuron and NG911 models. Introduces new model types which may require changes to config files.
• Add current calcSummationPoint logic into AllVertices
  • Pros: Cleaner separation of model and vertex logic. No need to add new derived model types.
  • Cons: Less files being touched, but are touched more (e.g. the summation point kernel would need to be moved from the GPUModel.cpp into the AllVertices_d.cpp).

[NicolasJPosey]

@stiber I spent some time thinking about the calcSummationPoint logic issue and outlined my thoughts above. I believe we had worked up to bullet 2 in our last meeting, but didn't really discuss whether that required bullet 3 or not.

Let me know if the above makes sense or if there is anything that I am missing. My preference is towards moving the calcSummationPoint logic into AllVertices (and renaming it updateVertexState) rather than keeping it in Model. This has a better separation of concerns between the Model and AllVertices types and I think is less likely to result in us having to update config files. If we can already get the neuron vs NG911 type from a config file (either implicitly or explicitly), then I don't have a preference on which implementation we choose to pursue.

[stiber]

@stiber I spent some time thinking about the calcSummationPoint logic issue and outlined my thoughts above. I believe we had worked up to bullet 2 in our last meeting, but didn't really discuss whether that required bullet 3 or not.

Let me know if the above makes sense or if there is anything that I am missing. My preference is towards moving the calcSummationPoint logic into AllVertices (and renaming it updateVertexState) rather than keeping it in Model. This has a better separation of concerns between the Model and AllVertices types and I think is less likely to result in us having to update config files. If we can already get the neuron vs NG911 type from a config file (either implicitly or explicitly), then I don't have a preference on which implementation we choose to pursue.

I agree; let's move this into the Vertex class hierarchy.