Implement activation events to reduce memory usage in the e-prop mechanism

[akorgor]

In the NEST implementation of the e-prop plasticity rule, all variables required to calculate weight updates are archived at every time step. When a spike activates an e-prop synapse, the archived history is retrieved from the postsynaptic neuron, and the used section is marked as no longer needed by that synapse in update_history. Once no synapse requires a specific part of the postsynaptic history, that part is deleted and the memory is freed. In biologically plausible scenarios, neurons often fire infrequently or stop firing during the learning process, causing their histories to accumulate indefinitely because they are never released. This PR resolves the issue by introducing activation events that, similar to spike events, trigger synapse activation so that obsolete history segments can be deleted, while not being sent to the postsynaptic neuron unlike spike events. Users can configure the interval for sending these activation events since the last spike.

Memory and runtime comparison for 100 training and 10 test iterations of the N-MNIST task with the eprop_iaf neuron model:

• Enable this mechanism also for static synapses, which would make a dedicated eprop_input_neuron / eprop_parrot_neuron obsolete.
• Resolve the issue that the activation interval of the presynaptic neuron has to be larger or equal the eprop_isi_trace_cutoff of the postsynaptic neuron.
• Preserve flush event flag in set_sender_node_id_info during spike delivery.
• Document erase_used_history.
• Document activation event mechanism.
• Benchmark the runtime with HPC benchmark.

[heplesser]

@akorgor Thanks for the PR! I have reviewed and commented on some points. I wonder mainly now if all changes in the neuron models are essentially the same (would make reviewing easier). I also wonder if the activation mechanism is placed in the right place in the neuron class structure. For review and long-term maintainability, it would also be advantageous to have more technical documentation on how the activation mechanism works. The emission of spikes from the neurons after intervals of inactivity looks straightforward, but the consequences for the gradient computation less so. Finally, I am a bit unsure about the term "activation spike". After all, it does not really activate anything, it is only there to flush the history, isn't it?

[akorgor]

Finally, I am a bit unsure about the term "activation spike". After all, it does not really activate anything, it is only there to flush the history, isn't it?

I agree with your concern. Alternative names could be HistoryFlushEvent, HistoryPruneEvent, MaintenanceEvent, ServiceEvent, CleanupEvent, UpkeepEvent. I would avoid names involving Trigger since this would pose the same problem as Activation. Also, I would avoid Service and Cleanup because of their prevalence in the NEST code. Do you have a preference?

[JesusEV]

Leaning Dynamics

Hi, I tried a simple stress test to probe robustness and parameter safety.

Reproduction Details

• Branch/Commit: [Current PR Branch]
• Script: pynest/examples/eprop_plasticity/eprop_supervised_regression_sine-waves.py
• Baseline: Standard tutorial parameters (Loss decreases as expected).

Observed Behavior

By introducing a small activation_interval to the recurrent neuron parameters, the learning curve deviates significantly from the baseline.

Baseline Loss:

Stress Test Loss (activation_interval = 1 step):

Modified Parameter Snippet:

params_nrn_rec = {
    # ... existing params ...
    "V_th": 0.03,
    "activation_interval": 1.0 * duration["step"],  # So to trigger high freq housekeeping
}

My understanding is that activation events are purely a "housekeeping" mechanism to flush old postsynaptic history and should not behave like standard spikes. However, the simulation results suggest they are not entirely "learning-neutral" when the interval approaches the simulation step.

I would like to clarify the following:

1. Semantics: activation events are strictly intended to be transparent to the learning process, or is a minor influence on learning acceptable?

2. Safeguards: If they should be neutral, maybe should we consider:

   • Implementing a lower bound validation for activation_interval?
   • or adding documentation warning regarding a proper safe range of this parameter relative to the simulation step?

[JesusEV]

Naming

(I just noticed that something along these lines has already been discussed, but I'm keeping it because I think my post is somewhat more general.)

Regarding naming, I think that, for people coming from ML/Deep learning, "activation" is very very strongly associated with activation functions or neuron outputs.

But in this PR, "activation" is about periodic and synthetic triggers of synaptic bookkeeping and history cleanup during silence, which feels almost as the opposite of what ML people could expect from term "activation". Therefore I feel terms as:

• activation
• get_activation
• activation_event
• previous_event_was_activation

could be confusing for those unfamiliar with this PR idea. Since this mechanism focuses on maintenance during silence, using terms as "inactivity", "cleanup", "maintenance", and "flush", might better convey the intent for the casual user/reader and avoid confusion for users/readers coming from ML/DL backgrounds.

[JesusEV]

Spike recorder test

I suggest adding an explicit test to verify that the spike_recorder does not "catch" or log activation events. This could serve as a safeguard against future problems if the event delivery logic or the spike recorder implementation is refactored. This could prevent activation events from leaking into the recorder, which could corrupt firing rate calculations and analysis for any user unaware of the underlying housekeeping mechanism.

[akorgor]

I would like to clarify the following:

1. Semantics: activation events are strictly intended to be transparent to the learning process, or is a minor influence on learning acceptable?

2. Safeguards: If they should be neutral, maybe should we consider:
   
   * Implementing a lower bound validation for activation_interval?
   * or adding documentation warning regarding a proper safe range of this parameter relative to the simulation step?

Thank you for catching this.

1. Activation events should not have any influence on the learning dynamics.
2. When moving the activation event mechanisms up into EpropArchivingNode in 60b9a6e , I forgot to transfer the BadProperty throws, which require activation_interval > eprop_update_interval and activation_interval > eprop_isi_trace_cutoff, which prevent the behavior that you are seeing. These checks can in principle be moved up to EpropArchivingNode as well, the only problem being the distinction between the bsshslm and the non-bsshslm model, which I am still unsure of how to handle best.

[akorgor]

Spike recorder test

I suggest adding an explicit test to verify that the spike_recorder does not "catch" or log activation events. This could serve as a safeguard against future problems if the event delivery logic or the spike recorder implementation is refactored. This could prevent activation events from leaking into the recorder, which could corrupt firing rate calculations and analysis for any user unaware of the underlying housekeeping mechanism.

Added in c221d9e.

[heplesser]

Looks good, just two small suggestions.

[heplesser]

@akorgor Great, thanks! I am happy with the code now, but will wait for benchmark results before giving formal approval.

[heplesser]

Benchmark results obtained by @JanVogelsang on JURECA with the hpc_benchmark indicate no loss of performance (one simulation for each of three different seeds for different numbers of compute nodes, 2 MPI processes @ 64 threads per node, weak scaling: problem size scales 32x, runtime only approx 3.5x). Results indicate that there is no performance loss due to introduction of the flush-event mechanism.

[heplesser]

Benchmark results seems satisfactory, thus approving.