bug in tracking with add_particles

[alexlib]

the bug is kind of obvious when we do tracking but it's not captured apparently by the py_bind tests. The number of particles in the buffer is increasing like every buffer is filled twice, (except the first and the last ones). Apparently it's not double reading from the file, but just internal filling the buffer somewhere.

the bug relates to the option [add particles] in the Tracking parameters. uncheck this option and the results are normal, but of course there are no "additional particles" in the ptv_is. or added. files

@yosefm please help here.

see below in the file 0003 there are 29 particles only, but after filling the buffer, the trackcorr_c_loop thinks there are 55 and so on.

if you run the sequence - the rt_is. file is 29 particles long, but after tracking it's 55. If you repeat the tracking run, the file will become above 80 and so on. every run will double the number of particles in the buffer.

reading frame frame_num 10000001
read from frame 10000001 and got 31 particles
reading frame frame_num 10000002
read from frame 10000002 and got 30 particles
reading frame frame_num 10000003
read from frame 10000003 and got 29 particles
orig_parts = 31
step: 10000001, curr: 31, next: 30, links: 26, lost: 5, add: 26
writing frame 10000001
reading frame frame_num 10000004
read from frame 10000004 and got 30 particles
orig_parts = 30
step: 10000002, curr: 30, next: 55, links: 27, lost: 3, add: 27
writing frame 10000002
reading frame frame_num 10000005
read from frame 10000005 and got 30 particles
orig_parts = 55
step: 10000003, curr: 55, next: 57, links: 44, lost: 11, add: 51
writing frame 10000003
orig_parts = 57
step: 10000004, curr: 57, next: 81, links: 27, lost: 30, add: 1
writing frame 10000004
tracking without display finished

[alexlib]

to reproduce the results use openptv/master and run any test case twice: without add_particles

step: 10000001, curr: 31, next: 30, links: 26, lost: 5, add: 0
step: 10000002, curr: 30, next: 29, links: 27, lost: 3, add: 0
step: 10000003, curr: 29, next: 30, links: 27, lost: 2, add: 0
step: 10000004, curr: 30, next: 30, links: 27, lost: 3, add: 0
Average over sequence, particles:  30.0, links:  26.8, lost:   3.2

and then with add_particles

step: 10000001, curr: 31, next: 30, links: 26, lost: 5, add: 26
step: 10000002, curr: 30, next: 55, links: 27, lost: 3, add: 27
step: 10000003, curr: 55, next: 57, links: 44, lost: 11, add: 51
step: 10000004, curr: 57, next: 81, links: 27, lost: 30, add: 1
Average over sequence, particles:  43.2, links:  31.0, lost:  12.2

as you see, the number in the frame doubles every step.

the results are also clear when observing rt_is. files after sequence and after tracking.

[alexlib]

it appeared before #165

[yosefm]

Which test was that? Could you add the command-line you used to get that output?
I'm trying to reproduce, and the information here is a bit sparse.

[alexlib]

Which test was that? Could you add the command-line you used to get that output?
I'm trying to reproduce, and the information here is a bit sparse.

the problem is that we never wrote the test ;) it is add_particle()

[alexlib]

Which test was that? Could you add the command-line you used to get that output?
I'm trying to reproduce, and the information here is a bit sparse.

please @yosefm take a look at this problem that was somehow related also to add_particles in the past. Maybe something is related to the way ANSI C works with DEFINED variables?

alexlib@22154c4