Waveform writer

[jmbenlloch]

This PR adds a writer for two tables:

• waveform: Table containing event_id, sensor_id and timestamp. For photons in the first 100 ps.
• total_charge: Table containing event_id, sensor_id and charge. Total photon count for each sensor and event.

There are no tests included yet.

I'm also trying to use a G4GenericMessenger to read the output file name from the config file, without any success yet. Maybe that config management could go in a different PR?

[jacg]

The config management /G4GenericMessenger business is a minor detail that can be done once the dust settles a bit. Far more important, and more difficult to solve, is the lack of tests.

These need to be done on a few different levels:

• Writer unit tests: write some fictitious data into the two new datasets (using the two new writer methods[*]), and read them back in. This should be completely independent of G4, and very easy. Amenable to property-based testing.

• Testing the 100ps cutoff. Don't need G4 for this either. Shouldn't be too difficult.

• The 100ps cutoff in the context of a simulation. Looking at the data, to a first-order (nay, to a 5th-order) approximation, all the 100ps sequences contain exactly one item. This seems odd. I have found sensors which register over a hundred photons, but only a single one in the 1st 100ps. Something seems fishy, either with the data we're getting, or with their suitability for the kind of analysis in which they are meant to be used.

• Full integration tests: a simulation that uses these writers and connects to a chain which ends up reconstructing images. Much like what we did with the simplified chain. There are a few big issues to solve here:

  • Not sure how to automate the verification: so far we've had a human looking at the images and confirming that they look like the input geometry.
  • This necessarily involves tools outside of this repository, so we need to think about a good home and organization for tests such as these, of which we will need more.
  • Generating enough events to get a decent image will be very expensive: another reason why this can't be part of the standard suite.

[*] I'm still not 100% convinced that we want a separate method for each dataset. I've already reduced the boilerplate copy-paste which was present in them (I'll push this, shortly), but they still irk me a bit. Perhaps the little bit of detail they hide is worth their existence. I need to think about it a bit more.

I'm also bothered by the need to keep track of the indices of each dataset. Surely we can get this from hdf5?

[Aside: I'm tempted to entrust the hdf5 interfacing to Rust. Originally I thought that driving G4 from Rust was going to be hopelessly painful. I'm less pessimistic now, especially if we can target nain4 instead of G4. If we get ahead of schedule on the milestone deadlines, I'll be able to give this a bit more thought. If it works, the idea will be to do pretty much everything on the Rust side.]