The random normal delay distribution for weight update has a problem

[sebjameswml]

See SpineML_2_BRAHMS_CL_weight.xsl line 458.

In this code block, you have a number returned by a RNOR() call. That number can be positive or negative.

then:

delayForConn[i_BRAHMS] = round((RNOR(&this->rngData_BRAHMS)*delayForConnTemp[2]+delayForConnTemp[1])/most_delay_accuracy);

the problem here is that delayForConn is of type VUINT32, so if the RNOR() returns -ve, you get an overflow in delayForConn[i_BRAHMS];

Ok, that's the bug.

However, this code is presumably obsolete because the random delay distributions should have been expanded by SpineML_PreFlight, so need to check this happens then remove this code.

[sebjameswml]

Need to resolve this along with the other work on delays.

[sebjameswml]

Regarding my comment _"However, this code is presumably obsolete because the random delay distributions should have been expanded by SpineMLPreFlight, so need to check this happens then remove this code.":

Although SpineML_PreFlight could expand the delay distribution into a connection list with delays, SpineML_2_BRAHMS won't actually implement those delays.

So, the current system with connection delays for projections existing in the weight update will need to stand. @ajc158 any comments?

[sebjameswml]

It looks more or less like delayForConn[] is being populated suitably in the WU components. The use of delayForConn is in Analog Port Remapping - AnalogReceivePort and AnalogReducePort (and similar for impulse/event inputs)

[sebjameswml]

That appears to function also. 1aff527 makes sure user knows about any -ve delays being set to 0. Closing this issue now.