Simulate trigger channels for RNO-G

[fschlueter]

This PR is based on #716 and #741.

Currently the "everything regarding the trigger channels happens in the triggerBoardResponse module and the trigger module. I will also add a script which shows how to simulate the trigger.

[fschlueter]

@cg-laser that highlights the idea I have - feel free to comment. Currently everything happens in the triggerBoardResponse.py but in principle we could also do it in the HardwareResponseIncoperator. The one downside with how it is implemented right now is that I first fold in the radiant response and a cable and later fold them out which is somewhat awkward.

[sjoerd-bouma]

I'll try to have a look at this later this week but just so we don't forget - if we go with this implementation the trigger channel should probably be serialized as well, right? Right now I don't think it would be stored if you write to a .nur file.

[fschlueter]

I'll try to have a look at this later this week but just so we don't forget - if we go with this implementation the trigger channel should probably be serialized as well, right? Right now I don't think it would be stored if you write to a .nur file.

good point. this is missing yet. I will add it today!

[cg-laser]

@cg-laser that highlights the idea I have - feel free to comment. Currently everything happens in the triggerBoardResponse.py but in principle we could also do it in the HardwareResponseIncoperator. The one downside with how it is implemented right now is that I first fold in the radiant response and a cable and later fold them out which is somewhat awkward.

My main critique here is that this is not only awkward but could make things impossible as bandpass filters can't be inverted. As the bandpass for the FLOWER is narrower than for the RADIANT would work for the current RNO-G,but for other systems it might break.

[fschlueter]

@cg-laser that highlights the idea I have - feel free to comment. Currently everything happens in the triggerBoardResponse.py but in principle we could also do it in the HardwareResponseIncoperator. The one downside with how it is implemented right now is that I first fold in the radiant response and a cable and later fold them out which is somewhat awkward.

My main critique here is that this is not only awkward but could make things impossible as bandpass filters can't be inverted. As the bandpass for the FLOWER is narrower than for the RADIANT would work for the current RNO-G,but for other systems it might break.

Fair point! Let me see if I can easily change this to the hardware response incorperator.

[cg-laser]

is there a way to automatically determine the bandwidth of the trigger channel signal chain? Currently, we detect all modules that have get_filter (or similar) implemented and multiply all filters together on-the-fly to calculate the bandwidth. This is used in NuRadioMC to calculate the Vrms from the noise temperature.

It seems that this is no longer possible now. I guess, the triggerBoardRespone module could just implement the get_filter function which provided the "diff" to get from the DAQ signal chain to the trigger signal chain.

Or we do it all in the hardwareResponseIncorporator. However, for pure simulation studies, it would be nice to have a generic "triggerBoardResonse" module that would create additional trigger channels. Right now, we do this within the custom user detector simulation code and never save the trigger channels anywhere. I'm thinking of a triggerBandpassFilter module.
Or, this can be done in the usercode (https://github.com/nu-radio/analysis-scripts/blob/main/gen2-tdr-2021/detsim/D01detector_sim.py#L124) Instead of making a copy of the station, we would directly copy the trigger channels, apply an additional bandpass, and save them as trigger channels. But having a triggerBandPass module would simplify this code substantially.

[cg-laser]

we could also not implement this function to make clear that trigger_channels are not saved at station level, but are a sub-element of a channel. Users would need to write station.get_channel(id).get_trigger_channel() instead of station.get_trigger_channel(id)

[fschlueter]

I added this interface for connivence because it makes the diff necessary to the trigger module minimal (I have not applied it to any but the hi-lo one yet). We could delete it for the reason you mention..

[fschlueter]

@cg-laser, have a look at NuRadioMC/examples/08_RNO_G_trigger_simulation/simulate.py where I calculate the thermal noise rms for the trigger channels. We can add such a function to response class for example.

[fschlueter]

@cg-laser that highlights the idea I have - feel free to comment. Currently everything happens in the triggerBoardResponse.py but in principle we could also do it in the HardwareResponseIncoperator. The one downside with how it is implemented right now is that I first fold in the radiant response and a cable and later fold them out which is somewhat awkward.

My main critique here is that this is not only awkward but could make things impossible as bandpass filters can't be inverted. As the bandpass for the FLOWER is narrower than for the RADIANT would work for the current RNO-G,but for other systems it might break.

This is now resolved. I am now creating and applying trigger responses in the hardwareResponseIncorperator.

[fschlueter]

Besides the issue #770 this PR is almost done. We can modify more trigger modules to use the trigger channel getters. So feel free to comment.

[fschlueter]

@cg-laser, Sjoerd and I just had a zoom call to discuss this issue. A short summary:

• The unit tests are failing because now we add the cable delay after we added noise instead of before. That means that even if after adding the cable delay the signals are at the exact same sample/position in time as before, they are different relative to the noise we added. This explains the failing unit tests.
• We agreed that we still want this change although it might be difficult to verify that everything is okay (because of the failing tests) for a couple of reasons. As already discuss is it easier when adding trigger channels, it is conceptually more clean, and if we start adding coherent noise (for example galactic noise) adding the cable delay before we add noise is simply wrong.
• The way forward would be to double check my code and verify that the failing tests/differences in the results are within the tolerance we expect when changing noise.

Any thoughts comments?