GSI Helmholtzzentrum für Schwerionenforschung
Dear all, which is the exact meaning of the "strict-merge" option in the preplay code? As far as I understood "strict-merge" means we consider only events in which we have something in both the ancillaries and AGATA, while without requiring it we can have also events with only, let's say, FRS information. Is that right? Thanks, Alberto
Hi Alberto, that is right: if the strict-merge option is active, an event is only analyzed if both, AGATA and MBS data are present. What data is present is determined during the merging procedure: the lowest GTS timestamp opens a time window (default is 3us can be adjusted with the --replay-merge-time-window= option). If any other data set comes within this time window, it is put into the event. Typically, a MBS event comes first (opens the time window), followed by one or more AGATA events (PSA-frames). Best regards, Michael
Thanks Michael! So for our cross section measurement, since we want to know the total number of incoming ions, we need to sort without this strict-merge option right? Another question: how can we take into account the detectors dead time? We need: 1) the total number of incoming ions: we obtain this from the FRS ID plot, requiring trigger 10 (FRS downscaled) and no strict-merging 2) the number of gammas in the peak. Here we require coincidences between AGATA-FRS-LYCCA. I suppose the dead time of the system is different in these two situations, so it will not cancel out in the cross section calculation. Do you have any idea about this? Thank you very much!! Cheers, Alberto
Hi Alberto, This is an interesting and difficult question and most of what I write here has to be labeled with "as far as I know". I was trying to get the cross section from the gamma yield and the number particles in the commissioning data. So far without much success (I see about 3 times less counts in the gamma spectrum as I would expect based on number of particles and AGATA efficiency). The number of particles can be obtained: 1) Take the sum of Sc41 scaler. This doesn't take the dead time into account because the scaler module scales, even when the DAQ is busy. 2) Count reduced trigger 10. This should take the dead time into account because the event is only recorded if the DAQ was not busy. But to be honest, I really don't know how to reliably estimate the number of incoming particles: in principle I agree, for counting number of trigger 10 one should not use strict merge to not loose some trigger 10 that by chance did not get any gamma. But I think it is not that simple. MBS and AGATA DAQ were not always started at the very same time. So there is in the beginning or end of the data stream always a number of events that don't have a "partner" (i.e. either AGATA only or MBS only). I think you do not want to count the trigger 10 for these parts of the data. Another question that bothers me a bit: shouldn't there always be a gamma recorded, when MBS validated the trigger? At least in case of trigger 9 or 10? What is the meaning of a trigger 9 or trigger 10 event, that doesn't have AGATA data? Additionally, you mentioned already the different dead times in different situations. But this is even worse: the dead-time depends on the size of data that MBS reads in the slowest VME crate and this is different from event to event. So the dead time differs from event to event. I was thinking if it is not more promising to use strict merge, i.e. select a subset of events where all information is present. From this subset of data, one takes the fully identified particles and selects the desired channel, e.g. Coulex by gating on the same isotope in incoming and outgoing ID. For this subset one should be able to (somehow) calculate an excitation probability for Coulomb excitation (given the cross section) and estimate the expected yield (given the AGATA efficiency). The best method (in my opinion) until someone finds out how to count the particles: produce target and projectile peak under the same conditions and make a relative estimate of the cross section. I hope more people could contribute their opinion/experience to this point. Maybe this deserves its own topic in the forum. Cheers Michael
Thank you Michael, I will open a new topic on the forum and copy there your reply! Alberto