Particle counter per type broken

[fweik]

There is a mechanism for tracking the number of particles per type in the head node particle data interface. This does so by tracking type changes thru the front end, but does not register type/particles changes from other places e.g. by collisions. This count is used in the reaction ensemble (and exposed to the user), and wrong counts can lead to wrong results. There are concrete plans to use RE and reactions/collision together, so this has to be fixed.

The preferred way to fix this by calculating the particles counts on demand in the reaction ensemble on the front end, where also all the global information is available. I think the state tracking to brittle, and generally not a good idea.

[fweik]

Was #3495.

[jonaslandsgesell]

The preferred way to fix this by calculating the particles counts on demand in the reaction ensemble on the front end

What mechanism do you have in mind? The current state tracking is of O(1) and avoids looping over all particles to determine the number of particles of a given type. This state tracking, therefore, is fast compared to looping over all particles and reading their type which is O(N).

[fweik]

It has to be calculated once when the control transfers to the RE, then the changes done by the RE itself can be tracked without recounting. A linear term is no problem, considering that the RE e.g. also does linear searches for neighbor distances when inserting as well as energy calculations which are more expensive. Also I'm sure there are even faster methods to obtain an incorrect result :-)

[jngrad]

In addition, particles of type 0 created with system.part.add(pos=[1, 2, 3]) cannot react, because they are not tracked by the particle map (#4588). All ESPResSo versions since 4.0.0 are affected by this bug.

[jngrad]

The particle map is not cleared when the list of particles is cleared (#4645).