OceanParcels
Support Global Particle ID constructors
Currently, tracking a unique identifier of particles (the ID) is hardly possible. Some of the ID information is stored as class-static variable info (basically: every particle itself has a one static field called 'maxID' - which is unnecessarily), while this information is modified by each newly-created ParticleSet individually. Also, by time a lot of available IDs from deleted Particles remain unused, which means it is possible to reach the max. identifier number with long-running simulations that do a lot of particle removal and particle releases.
A base for a global ID generator can be found in #862, and it can be taken as a template or as inspiration for something similar in the master branch of Parcels.
Thanks to @CKehl for bringing this up
@ckehl; can you confirm whether this is now sufficiently implemented in #913?
no, because we did not actually implement that. For now, we said that 'IDs are forward running' and "IDs are not reused" - basically, nothing has changed. Also, those IDs are still initially co-locked by all MPI-processes.
Now, we still need to get rid of this static particle-ID generation in the Particle class. It will be done - either in a separate PR (ideally) or together when integrating the nodes-collection (not ideal, but that one need a provably-unique ID).
We can still disable the release and reuse of IDs, as we decided until now. It's not ideal cause it's wasteful to block IDs that are not used anymore, but on the other hand: we now have 64-bit IDs, so we will run out of memory and run into hundreds of other issues before we actually run out of available unique IDs.
OK, thanks for the update. I agree then that we should implement this soon, either as a separate PR or with the nodes-collection indeed
Note that I am not a fan of reusing particle IDs. The reason is that this may create havoc with users once they start analysing the output files. Particles are saved based on their Particle IDs, so if two particles have the same ID in the output, this could be seriously confusing. Of course, we could implement a way to have different IDs in the output as during runtime, but that sounds overly complicated to me