Implement object types 2029 and 2030 - auxiliary traces

[cbigo68]

I would like to have the possibility to display also auxiliary traces, that are stored in two distinct data blocks in sim_telarray output files: 2029 Digital auxiliary traces 2030 Analog auxiliary traces

We can provide test files containing such data blocks

[maxnoe]

@cbigo68 Test files, preferably rather small (e.g. < 2 MB or so) would be great, yes.

Alternatively, you could provide me the simtel array options needed to enable these

[maxnoe]

Found an old email by @kbernloehr (originally in German):

Types 2029, 2030 are only written if sim_telarray is compiled with -DWITH_AUX_TRACES, for debugging or illustrating what happens internally in intermediate stages. At runtime, it also needs the AUX_TRACES parameter (undocumented, 8 integer values 0 or 1 for the different traces, not every trace is available for each triggery type)

[maxnoe]

Just for my curiosity, could you maybe comment a bit what the use case for these objects is for you?

[kbernloehr]

The AUX_TRACES parameter actually is documented in the manual:

AUX_TRACES (type: int, items: 8, default: "0,0,0,0,0,0,0,0", minimum: "0", maximum: "1") This parameter is dedicated to debugging and illustration of the camera trigger logic. It is only available if sim_telarray got compiled with WITH_AUX_TRACES de- fined. This compilation option comes, at run-time, with a significant impact on mem- ory usage and output data size, and, to a lesser extend, also on CPU usage. Each in- teger value disables (0) or enables (1) a particular trace of raw (analog, float value) or digitized signals internal to the simulation. Digitized signals cover the time range of the FADC simulation, analog signals the time range of the discriminator/comparator simulation at the higher time-resolution used for that part of the simulation (typi- cally four times as many samples per trace as with digitized signals). The first four switches represent digital traces, of which only the first is implemented. Availability of the four ‘analog’ traces depends on the trigger type(s) in a camera. The individual switches are for enabling/disabling: 1 Digitized traces of simulated ADC values over the full FADC_BINS range, as scaled, shaped, clipped, added-up in each digital-sum trigger group, before the final decision. Limited to cameras with a digital-sum trigger. 2-4 Reserved, not used. 5 The raw signal at the input of each comparator/discriminator or the input stage of an analog sum. Limited to cameras with majority or analog-sum trigger type(s). 6 The added-up signal for the analog-sum trigger groups, after shaping and clip- ping. Limited to cameras with analog-sum trigger. 7 The discriminator or comparator output signal in percent of the nominal output. Limited to cameras with majority trigger. 8 The majority signal in units of pixels. With logic-type majority (no rise and fall times), this will be integer values (represented as floats) while for a fully analog majority electronics, this will be the added-up outputs of the discrimina- tor/comparator outputs in each trigger group. Limited to cameras with majority trigger.

[cbigo68]

Thanks @kbernloehr I was just going to add that part of the manual. In our case, having a majority trigger, we are interested in cases 7 and 8.

[cbigo68]

Just for my curiosity, could you maybe comment a bit what the use case for these objects is for you?

Sure. I'm trying in our simulations two distinct pulse shapes for High Gain and Low Gain channels, as used in our camera. The very first attempt doesn't reproduce the behaviour observed in data. According to our expert this could be due to a wrong timing of the slow-shaper, so I would like to check the position of the peak of the LG channel pulse shaper w.r.t. the trigger signal.

[cbigo68]

@cbigo68 Test files, preferably rather small (e.g. < 2 MB or so) would be great, yes.

Alternatively, you could provide me the simtel array options needed to enable these

You have already found by yourself that you need also to compile the code with -DWITH_AUX_TRACES, on top of using the AUX_TRACES at running time. I have already a version od the sim_telarray package compiled with -DWITH_AUX_TRACES, so I can provide you a file (or more if needed) with auxiliary traces. Concerning the file size I was thinking about simulating just one telescope with a handful of low-energy events. Is it ok for you ?

[maxnoe]

Concerning the file size I was thinking about simulating just one telescope with a handful of low-energy events. Is it ok for you ?

Yes, perfect! The energy doesn't really affect the file size, so you can simulate a single event that triggers for example by using limited viewcone, impact range and a high enough energy.

You can check if the 2029 and 2030 objecs are present using

eventio_print_object_information <path>

[cbigo68]

Concerning the file size I was thinking about simulating just one telescope with a handful of low-energy events. Is it ok for you ?

Yes, perfect! The energy doesn't really affect the file size, so you can simulate a single event that triggers for example by using limited viewcone, impact range and a high enough energy.

You can check if the 2029 and 2030 objecs are present using

eventio_print_object_information <path>

Ok, I go ahead. Thanks for the suggestions

[maxnoe]

@cbigo68 I opened #276, could you give it a try?

[maxnoe]

@cbigo68 did you have a chance to try out the PR and see if it works for you?

[maxnoe]

@cbigo68 pyeventio 1.13 has been released with support for these two types