Switch propagation per particle (partial)

[RudolfWeeber]

Aim of this project is that virtual sites relative and inertialess tracers canbe used simulatenously.

This will become part of #4015, but has to be addressed now, because it is needed in a research project.
The aim is, to do it such that the code can be re-used (or kept) for #4015

Add a typed enum class named Propagation in the core and in Python to store available propagation types. For now, this will be:

• SYSTEM_DEFAULT (i.e., whatever is set via thermostat and integrator setup, e.g. Langevin or Langevin-LB)
• VIRTUAL_SITES_RELATIVE
• INERTIALESS_TRACERS

Note: Once the main propagatros such as Langevin or Brownian are refactored, they can be added here.
Locations:

• core: src/core/Propagation.hpp
• src/python/espressomd/integrate.pyx, I guess

Add a data member propagation of type to the ParticleProperties struct (not sure if there is a better place)

src/core/Particle.hpp (or sth included there)
Add the data member to the ParticleProperties serialization

Add the functions

Propagation propaggation() const;
void set_propagation(Propagation); 

to the Particle class (src/core/Particle.hpp)

Add the head-node setter for the particle propagation

This is used by the Python interface to set the property.
See src/core/particle_data.cpp/hpp. Use set_particle_q() as template.

Add setters/getters for propagation to the Python ParticleHandle class

This is in src/python/espressomd/particle_data.pyx. Use the
property q
or similar as template. The setters/getters should take the Python version of the Propagation enum class from the 1st step.

Used filtered iterations in the different integration and virtual sites codes to act on the propagation particle property

Write a function

auto filter_by_propagation(Propagation propagation, ParticleRange& particles)
which uses boost filtered iterator to return an iterator over the particles that have a specific propagation flag.
See https://www.boost.org/doc/libs/1_66_0/libs/iterator/doc/html/iterator/specialized/filter.html for an example.
Use the new function in integarte.cpp in the integrator_step_1() and integrator_step_2() functions, to pass only particles that are propagated via Propagation::SYSTEM_DEFAULT to the integration kernels.

Use the same function in virtual_sites/VirtualSitesRelative.cpp/hpp in the update_...() methods, to only act on particles that have Propagation::VIRTUAL_SITES_RELATIVE

Remove virtual flag checks in integration kernels

Since, with the filtering, only non-virtual particles are passed to the integration kernels, the checks for the virtual flags in
src/core/integrators
can be removed.

Splitting of propagation kernels

• Currently, in src/core/integrators/... there are functions fro proagating ALL particle with a given scheme, say Borwnian or Velocity Velet.

• This should be changed such that, for each integrator, there are individaul funcitons taking a single particle and propagating that, e.g. velocity_verlet_trans_step1(Particle& p).

• There should be separate functions for translational and rotational degrees of freedom

• This is NOT possible for proagations schemes that act collectively:

  • Stokesian dynamics
  • Steepest descent (which, in the long run schoudl not be treated as propagation scheme, anyway)
  • LB particle coupling

• Teh Velocity Verlet steps of NPT can be formulated per particle. There remains some additional code that has to be called at the end of the integraiton loop

Split the virtual sites kernels

• In src/core/virtual_sites, there are the classes for placing the virtual sites and back-transferring the forces.
• The funcitons for updating the positions of virtual sites should be free funciotns taking a singel particle, e.g., void place_virtual_site_rlative(Paritlce& p)
• The force back transfer funcitons shoudl be free functions taking a ParticleRange.
• Once that's done, the entire class hierarchy for Virtual Sites + the corresponding script interface component can be removed

Sketch of the integraiton loop

• First iteration over particles

  • Based on the particles' propagation flag, run per particle propagation kernels for Velocity Verlet/Brownian etc
  • Check if any of the particles has the propagation for translation and/or rotation set to virtual sites relative (this requires a second pass)

• Run collective schemes such as Stokesian Dyanmics for particles with the resspective propagation scheme, using the filter_particles() described above

• Second pass: if particles with propagation set to virtual sites relative have been encountedred in the first pass, those need to be updated in a second pass (once all other particles hav been propagated)

• Run end-of-integraiton-loop collective code for NPT et al