Species Plugins: Multi & --<name>.filter

[ax3l]

One thing I realised during the last years of large scale runs is the following:

Objective

Make every plugin that run over species should be multi plugins (that can be called multiple times) and should define an optional argument <name>.filter=<filterName> (default=all).

Advantage

The same plugin can be run multiple times over a species but only selects a sub-selection of that species by user defined filters. These filters can be something like position, direction of propagation, energy, ... or what ever might be interesting for a user.

Implementation

We should provide a speciesFilter.param where the user can define very simple functors of the form bool isRelevant( T_Particle& particle ). Additionally, we need a getName method so we can use it on the cmd line.

Of course we pre-define and include an all filter that is the default fallback in case no filter was used.

As with other "multi" plugins, the plugin is simply run multiple times (even if the calculation could be done in one swipe over the particle list) since this is the easiest and most generic implementation.

Functors should be designed to easily allow filters based on the simple access to the particle's attributes (and its frame's attributes) but should be also not too strict so we can also forward field attributes later on.

Examples

select only particles:

• in a certain direction and solid angle
• use more than one energy binning detector in a simulation, e.g., individually forward & transversal
• in a certain energy range
• inside the moving window Plugins: analysis on selected window only #89
• store N videos zooming on various places of the simulation (see long shot vs. close-up vs. detail etc.) for offline (or live) analysis as in the bullet time paper
• ...

[n01r]

👍 Need that one, too.
To be able to compare PIConGPU to PICLS we would need to have cut-off on the electron energy to be able to compute the "temperature" of the thermalized electrons for the Thomas-Fermi pressure ionization model.

[n01r]

I would say that we need filters for more than just plugins namely also to be able to implement certain models in the main code.

[ax3l]

yes, the "filter" kernels should of course be general PMacc methods (we have some already but need to generalize them so they fit the above mentioned requirements). Also, it is not planned to re-write them for each particle plugin ;)

[PrometheusPi]

Sounds like a great idea 👍.

[steindev]

Will close this issue. There is a particleFilter.param allowing to define filters. These can be applied to most of our plugins via a <species>_<plugin>.filter <filterName> argument. Except for openPMD, where the option is called --openPMD.source <dataSource>.
Plugins that use the filter are for example <species>_energy, <species>_emittance, <species>_energyHistogram, <species>_calorimeter, and <species>_phaseSpace. All of these are multiplugins and can be called several times on the same species w/ different filters.