Fixing bad coding pattern in loops in connection creation

[JanVogelsang]

We cast to int in a loop so that we can do --i to counteract the loops ++i if a connection is not created. Instead, target_number_connections should just be counted down in a while loop here.

[jougs]

This is indeed much nicer. @heplesser: can you please also review?

[jougs]

There's another one in lines 737-750. Please also change that.

[heplesser]

This looks good. Could your add const for local variables in the loops that lack it but could be const, e.g., random_id or source_id.

[jougs]

@JanVogelsang: friendly ping!

[JanVogelsang]

Cancelled after 360min, how could that happen?

[jougs]

I have no clue how this could take so long. I have restarted the jobs (again, after they timed out again after my first restart attempt). Let's see what happens.

[heplesser]

The problem causing the timeout is here:

nest-simulator/nestkernel/connection_creator_impl.h

Lines 765 to 771 in f17346d

	// We bail out for non-local neurons only now after all possible
	// random numbers haven been drawn. Bailing out any earlier may lead
	// to desynchronized global rngs.
	if ( not kernel().node_manager.is_local_node_id( target_id ) )
	{
	continue;
	}

Before the continue, we need to insert --target_number_connections to account for connections created on other VPs (this is fixed_outdegree which does not parallelize: all VPs need to draw all connections and then just skip creating those they are not responsible for).

[JanVogelsang]

Thanks Hans Ekkehard, I'm mad at me to not notice this myself earlier. I fixed it, let's see if the testsuite runs through now.

[heplesser]

@JanVogelsang Thanks! Just a small suggestion for a better comment so we won't wonder a year from now why we decrease the counter half-way through the loop.