per particle quantity update in parallel simulation

Hi,

I have written a fix that records/stores a number of per-particle
quantities (among them the last 10 particle positions), calculates some
function of these and outputs a local array based on a threshold criterion.
Please excuse this amount of detail, but the temporal component is
essential for my problem: An "event" starts when the function (normally
small values) becomes larger than the threshold and ends when the
threshold is crossed again. The "event-time" is recorded as the time
step with the largest function value during the event. The event-time
and other associated values are written to a local array when the event
ends. -- all these calculations are done locally and without any mpi
reduce commands.
The problem is, that the local dump output sometimes shows that a
particle has 'two' events (dumped at different but close by time steps)
with the same event-time but slightly different other associated
values(like last particle position).
When an event ends, then one of the stored per-particle quantities is
overridden with -1 - to indicate that the event ended and a new one can
begin. This alone should make this 'double dump' impossible.
Furthermore, when I lengthen the interval at which the fix is called
sufficiently, then the 'double dump' disappears.

My only explanation is that two processors are calculating the fix for
the same particle(!) and that the per-particle quantities are not
communicated in time (the time between the two local dumps is e.g. 150
steps).
Is a fix calculated for all owned and all ghost particles of each
processor? I checked and my fix only loops over atom->nlocal.
Could it be that a not updated ghost-particle is reset to be owned,
whereupon the event could be ended a second time?

Stressing one point again: The bug disappears when the fix is called
only every 100 time steps, compared to every 10 or 50. I believe that
this indicates that my code is ok, apart from not triggering some
inter-processor communication that is eventually triggered by another
part of lammps.

Any help is hugely appreciated

I don't understand all your details, but if your
fix is storing per-atom information, then it likely
needs to account for reneighbing happening
during your time window (10 steps), so that
the info is carried along with the particle if
it moves to another processor. I presume
you also need to account for multiple
"events" happening within your time window.

Steve