additional particle diagnostics

[aeriforme]

Hi all!

It could be convenient to have the following particle diagnostics:

• chi
• fields interpolated at the particles' positions
• <diag_name>.particle_fields.<field_name>(x,y,z,ux,uy,uz) and such also depending on the field values at the particles' positions - in this case, one could avoid saving a lot of data, especially if using the histogram feature

What do you think?

[ax3l]

Hi @aeriforme,

Great ideas, do you like to discuss this in one of our user meetings (Monday 2PM PST) or developer meetings (Tuesday, 9AM PST)?

Generally, we do not store the E and B field on particles in memory, since that incurs a significant memory cost and slow-down of the code (as we found it in 2019/20). But we can derive fields on particles realitively cheaply on the fly, as we do for particle push, QED physics as well as a "FieldProbe" reduced diagnostics that we have.

A few ideas how this could be added:

Add One More Attribute to Particles & Populate it

Generally, you can add user-generated parameters to particles, which can also be dumped.
You add them in inputs files via <species_name>.addRealAttributes: https://warpx.readthedocs.io/en/latest/usage/parameters.html#particle-initialization
Implementation details & conventions: https://warpx.readthedocs.io/en/latest/developers/particles.html#particle-attributes

We don't yet have a way to do arbitrary assignments during the PIC loop to particles and their new attributes from pure user inputs. Most people that need this functionality use our Python (PICMI) input and add a callback, on which they manipulate the particle attributes:
Similar to

WarpX/Examples/Tests/ParticleDataPython/PICMI_inputs_2d.py

Lines 149 to 152 in c8202e4

	new_pid_vals = sim.extension.get_particle_arrays(
	'electrons', 'newPid', 0
	)
	for vals in new_pid_vals:

But this example does not yet include interpolation that you probably would like.

Interpolate & Output the sum of the attribute on-the-fly into cells

<diag_name>.particle_fields.<...>: good idea, if all you currently need is a spatial sum per cell of a particle attribute, then one could extend this interface - interpolate for each particle the fields on the fly - and use add it together into the spatial (cell) bin of particle_fields. For that functionality, we don't even need to add a user attribute for each particle (saves GPU memory - allows larger sims - nice).

[aeriforme]

Hello @ax3l,
Thanks for your indications!
I would certainly like to discuss it with you in one of those meetings, maybe the developer one is more convenient for us (a Ph.D. student may join if it's ok) since we are CET, but we are flexible.

Having a spatial sum per cell of an arbitrary particle attribute would be very useful. In that case, for example, we could get frequent maps of chi directly, without having to store all the fields and the maps of each velocity component.

An even more flexible diagnostic would be a multi-dimensional histogram with arbitrary axes so that the user could choose to deposit any attribute against any other pre-binned attributes. In this way, for example, we could get the distribution of the particles in chi and gamma (which, right now, is what we ultimately want to do with relatively high frequency, thus without saving all the particles' and fields' data).

Does it make sense?

[ax3l]

Discussed today.

We have 1D histograms, but they do not yet support user-defined attributes in the parser. I opened #3051 to track this.

We work on 2D histograms via #2876, but the same limitation as #3051 will generally apply for the first implementation.

As a workflow you could try today, I would suggest a cool new Python feature by streaming the data via openPMD-api (using ADIOS2 SST). I opened openPMD/openPMD-api#1248 to discuss this further.