New policy 'round_robin_halt'

[jlubo]

Introduces the new policy round_robin_halt. This enables to halt at the current item until the policy round_robin is called again.

Related to issue #1749.

[brenthuisman]

Hi @jlubo, sorry for taking a while to respond. Is it feasible to add a unit test for this?

[jlubo]

Okay, I'll try to do that in the next few days.

[brenthuisman]

Great, thanks! I see an error (twice) in the run:

ERROR: test_multiple_connections (test.unit.test_multiple_connections.TestMultipleConnections)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/arbor/arbor/python/test/fixtures.py", line 30, in wrapper
    return func(*args, **kwargs)
  File "/home/runner/work/arbor/arbor/python/test/fixtures.py", line 30, in wrapper
    return func(*args, **kwargs)
  File "/home/runner/work/arbor/arbor/python/test/fixtures.py", line 30, in wrapper
    return func(*args, **kwargs)
  File "/home/runner/work/arbor/arbor/python/test/unit/test_multiple_connections.py", line 116, in test_multiple_connections
    data_mem, _ = sim.samples(handle_mem)[0]
IndexError: list index out of range

This is because you are collecting all results on one node. Unfortunately, that won't work; through samples you can only access results that were computed on the node your script is running, see also this page in the docs. At the moment, there is no other solution than to collect the results yourself: i.e. return the results and collect, or write to disk and read back. See the above documentation for how you could handle it.

I admit this isn't great, but for the moment there is no way around it.

[jlubo]

Thanks @brenthuisman for pointing that out. To avoid the error in MPI setups, I've now added a condition that prevents running the related assertion (which is anyway not crucial for this test) if the data is not available on the current node. In the future this condition may be removed if #1892 is solved.

[jlubo]

The next problem was quite hard to wrap my head around... It seems that the tests (as of commit 417bd5e) did sometimes not pass because the relationship between lid and state in label_resolution.cpp can differ across machines. On my local machine, for example, if round_robin_state.state == 0 then lid.value() == 1. On the machine running the PR check, however, round_robin_state.state == 0 corresponded to lid.value() == 0, causing different synapses to be targeted and leading to different results.

This problem has now (as of commit a8627a5) been solved for the tests by considering instances of synapse mechanisms that are indistinguishable upon initialization (when the lid indices are determined) before evolving differently. In order to test the effect of the round_robin_halt policy, it is necessary to observe such differences between the instances of the same mechanism, and I have now implemented them by using a synapse mechanism that features plasticity (expsyn_stdp).