New features to particle_tracerET

[Leonardo Werneck]

We propose the following enhancements to particle_tracerET:

• Introduces computation and output of particles' four-velocity;
• Enables output in binary format;
• Minor adjustments to the code (e.g., printf -> CCTK_VINFO);
• Whitespace cleanups;
• The number of particles is no longer limited to 10000, and now instead is set by the usual parameter num_particles.

We also provide a small code that converts binary output files to ASCII.

These features are part of this pull request.

[Gabriele Bozzola]

There is a copy&paste error at line 43 in https://bitbucket.org/zach_etienne/wvuthorns_diagnostics/src/master/particle_tracerET/src/file_output_routines.C

I’ve never used this thorn, but it would be nice if it used standard output systems instead of rolling out its own (so that tools like kuibit could support it out of the box instead of having to write custom parsers).

[Leonardo Werneck]

The thorn’s output is non-standard because it deals with arrays, not grid functions. Each particles' position is evolved using the thorn’s own RK method. Thus each line of the output file looks like “time x_1 y_1 z_1 x_2 y_2 z_2 …” where the subscript is the particle ID and (x,y,z) the particle position.

I do not see the typo in line 43 of file_output_routines.C. Could you be more specific? Also note that you are looking at the master branch, but the proposed changes have not been merged yet.

I could work on a kuibit module that is able to read the file, but it would have to be in the near future.

[Gabriele Bozzola]

        CCTK_VWarn (1, __LINE__, __FILE__, CCTK_THORNSTRING,
                    "VolumeIntegrals_GRMHD:file_output_routines.C Problem creating directory '%s' "
                    "for output", actual_dir);

The thorn name here is VolumeIntegrals_GRMHD which is not the correct one.

The thorn’s output is non-standard because it deals with arrays, not grid functions. Each particles' position is evolved using the thorn’s own RK method. Thus each line of the output file looks like “time x_1 y_1 z_1 x_2 y_2 z_2 …” where the subscript is the particle ID and (x,y,z) the particle position.

The positions are already grid arrays, why not outputting those with Carpet directly? E.g., one could directly output particle_tracerET::particle_position_xas an HDF5 file in CarpetIOHDF5 (or as an ASCII file in CarpetIOASCII). (In that case, it would be nice if the size of the array was not hardcoded in the interface.ccl).

[Gabriele Bozzola]

(The thorn name and the hardcoded number got fixed in the PR, so ignore my first and last points!)

[Leonardo Werneck]

We can add the standard Cactus output as an option as well, but as far as I know the default output will have to remain as is for the sake of backwards compatibility.

[Leonardo Werneck]

Gabriele---

Upon further discussion, the functionality you seek is already provided by the thorn, although it is not its default behavior. For example, the following non-standard output configuration:

particle_tracerET::output_freq   = 4
particle_tracerET::output_format = "ascii" # Default

can be made standard by doing

particle_tracerET::output_freq = 0
<...>
CarpetIOASCII::out1D_every = 128 # Or whatever
CarpetIOASCII::out1D_vars  = "
  <...>
  particle_tracerET::particle_position_arrays{out_every=4}
"

Note that in the standard output the particle positions would be in the file particle_traceret-particle_position_arrays.x.asc, while the non-standard output file is named particles.asc. Note also that the standard output file can be ~4x larger than the non-standard one.

One can also enable both outputs at the same time using e.g.,

particle_tracerET::output_freq = 4
<...>
CarpetIOASCII::out1D_every = 128 # Or whatever
CarpetIOASCII::out1D_vars  = "
  <...>
  particle_tracerET::particle_position_arrays{out_every=particle_tracerET::output_freq}
"

Granted, this is not well documented, so we should add this to the thorn’s documentation.

[Roland Haas]

Not having read most of the remainder of the ticket nor looked at the code. it can also be useful to in cases like this, add:

CarpetIOASCII::compact_format = yes

which removes a lot of the extra whitespace and comments (but also changes the column mapping so you must not rely on say column 10 being “time” and have to parse the header on top for a column name to column mapping).

[Leonardo Werneck]

@Zach Etienne will be the reviewer.

[Roland Haas]

With the inclusion progressing, would it be possible to add push hooks so that commit emails are sent to the ET commits mailing list? See here: https://docs.einsteintoolkit.org/et-docs/Services#git