GSI Helmholtzzentrum für Schwerionenforschung
Dear All, I checked energy spectrum of every hit in AGATA from PSA frame, using prespec code. I noticed strange spikes at very low energy; so I sorted the same data with the previous version of "nearline" go4analysis and I saw that the spikes didn't appear. Therefore I suppose I am defining some parameters in prespec configuration files in a bad way. May I ask you if you have some suggestions about what .config file I should check? thanks for the help, Riccardo P.s. In attachment the energy spectrum for AGATA hits obtained with the previous code (the blue one)and also the spectrum obtained with prespec code (the red one)
Hello Riccardo, sorry for the late reply. I'm not completely sure what happens there. But I have a guess: The data written into the root files have the same format as all arrays inside the analysis framework, Here is an explaination of what I mean: https://forum.gsi.de/index.php?t=msg&goto=17154&&srch=array# msg_17154 If an array is written to a root file with the same picture in mind. The root tree gets the following entries: 1) one integer with the number of entries in the array (N) 2) one array with N entries, containing values 3) one array with N entries, containing indices (or channels) Essentially, the arrays can have different N for each event. If you are looking at gamma ray data, N is the gamma multiplicity. if you draw such a leaf with the Draw() function of Root, it assumes that all arrays in all events have the same length. The old code (new_prespec_Go4) used a different way of representing the data in root trees, namely a plain array with as many indices as the maximum expected multiplicity. All places in the array that were not filled, get a default value. I guess, to get rid of the spikes in the spectrum, you have to write an event-loop explicitely: for (int event = 0; n < Nevents; ++n) // loop over all events { for (int i = 0; i < gamma__energy_length) // loop over all gammas in one event hist->Fill(gamma__energy_value[i]); } I didn't test that code, that is just a suggestion...
Hi Michael, I tried to check the output of the AgataAdapter using a config file very similar to the one that was used in march 2014 to sort online data. In attachment you can find a scheenshot of the matrix I obtained (on the x axis there is psa hit energy) as you can see there are very well defined spikes. I don't know what I could check to solve the problem.... Riccardo
Hi Riccardo, can you post the section of the config file (in particular the display line) that produces this plot? Michael
Hi Michael, in attachment the config file cheers Riccardo
the config file looks fine. I cannot see anything wrong there. Do these spikes only appear for the psa_hit_e_all or do they come also for the individual crystals (display psa_hit_e::psa_hit_ct) ? Could you send me a (small) adf file that shows this behavior? Cheers, Michael
Sorry, I just saw that psa_hit_ct is not filled by the AgataAdapter... but if you plot just display psa_hit_e you should get one histogram for each crystal. Do these all show the spikes?
Hi, I put the file you send me through my analysis and everything looks fine I'm a bit puzzled where the problem could be. I would like to be able to reproduce this problem, otherwise it is hard to guess what could be wrong. Would it be possible to send me your analysis folder?
Hi Michael, ok, I'll send you it very soon, anyway I made the spectra you asked. It seems this problem affects just one crystal, the one I sent you, in attachment two spectra, on the top the one with the problem and on the bottom one of the others and this last one seems ok Riccardo
Ah, ok, then I would like to see the "broken" adf file.
I sent you the folder, the "broken" file was the one I sent you Riccardo
Hi Michael, probably I found the problem, I saw that for the run with that strange behaviour, in the Conf folder for the AGATA data replay with Femul there was a mistake in mapping a crystal to the ID number, therefore there were two crystals with the same ID. I corrected this and now also that strange spikes disappear, thanks for the help cheers Riccardo
Hi Ricardo, Today we found something that may be useful for you. Some time ago, Tom found out that the psa time was not passed through the framework. You can see the discussion here: https://forum.gsi.de/index.php?t=msg&goto=17386&&srch=psa+ti me#msg_17386 To solve this, the Psa unpacker and the AgataAdapter were modified, but only the ones inside the AGATA plugin folder (prespec/plugins/AGATA/). This means that if you are using the older version of the unpacker (out of the plugins) and the new version of the Adapter, you can have some issues (wrong energies, positions, etc.). I actually saw spikes at the beginning of the spectrum and we manage to correct them by changin my Crates.config (or unpack_agata.config). Instead of crate AgataPsaCrate # handle data inside the psa-crate procid 0 triggers all module agata AgataPsa end I use now, crate AgataPsaCrate # handle data inside the psa-crate procid 0 triggers all module agata AGATA.Psa end Hope is useful and we are sorry of not finding it before. Liliana
Hello everybody, Yesterday two problems were discovered. Both are related to a change in the prespec package, that I did on 10th of October 2014. I'll try to explain what happened. I do it here, because the problem is related to the spikes in Ricardo's spectrum (see his initial post in this topic). I silently introduced two problematic changes in the AgataAdapter (prespec/plugins/AGATA/process/AgataAdapter.cpp) and the Psa unpacker (prespec/plugins/AGATA/unpack/Psa.cpp) into the prespec repository: 1. For a reason that I don't remember, I changed the meaning of the parameter "psa_hit_t_source" in the AgataAdapter. This parameter decides which time value is copied into the time value of psa_hit_t. Before the change, there were 3 options: a) psa_hit_t_source == 0: psa_hit_t is coming from the values measured by multihit-TDCs in the AGATA crate b) psa_hit_t_source == 1: psa_hit_t is computed from the T1 in the psa crystal frame (the time from low-gain core signal), the GTS timestamp difference, and the time difference between Sc41 and AGAVA accepted trigger c) psa_hit_t_source == 2: psa_hit_t is computed from the T0 in the psa crystal frame (the time from high-gain core signal), the GTS timestamp difference, and the time difference between Sc41 and AGAVA accepted trigger (The difference between b) and c) is only T1 and T0) After the change there where four options a) psa_hit_t_source == 0: psa_hit_t is coming from the time values in the psa frame b) psa_hit_t_source == 1: same as psa_hit_t_source == 0 (before the change) c) psa_hit_t_source == 2: same as psa_hit_t_source == 1 (before the change) d) psa_hit_t_source == 3: same as psa_hit_t_source == 2 (before the change) This affected the behavior of the analysis after pulling these changes. I didn't mention this in the forum or even in the git commit message. This is really bad, because by this I have changed the behavior of any analysis that uses the AgataAdapter (the one inside the AGATA plugin). I have broken the rule of not introducing changes to behavior of existing processors. 2. The other change was introducing a subtle, but even more severe problem. The AgataAdapter gets input only from the Psa unpacker. Before the code change, the time information in the psa frame was ignored by the Psa unpacker, and also ignored in the AgataAdapter. In order to examine the time information of psa frames I decided to change both, the Psa unpacker and the AgataAdapter inside the AGATA plugin to handle the time values in the psa frames (and by this introduced the need for a 4th option for the parameter psa_hit_t_source). I was assuming that this change did not affect anybody, because the Psa unpacker and the AgataAdapter are always used together. However, I did not take into account, that there are older versions of Psa unpacker and AgataAdapter in use (especially in the configuration files from 2012 campaign). If your configuration was using an old Psa unpacker and the modified AgataAdapter, the result is that all but the first psa hit data is corrupted (the spectra have spikes). In the case of MGT or any other algorithm that makes use of the psa hit position and energy information this will completely screw up the result. Your analysis was affected in the following cases: * using old Psa unpacker with new AgataAdapter. * using new Psa unpacker with old AgataAdapter. Your analysis was not affected in the following cases: * using old Psa unpacker with old AgataAdapter. * using new Psa unpacker with new AgataAdapter. By "new" I mean any unpacker or processor, that inside one of the plugins AGATA/FRS/LYCCA/.... You can identify the "new" upackers or processors in the config file by the syntax "PLUGINNAME.unpackername" or "PLUGINNAME.processorname" crate anyCrate module Psa # an old unpacker end using AGATA libprespecAGATA.so crate anyCrate module AGATA.Psa # a new unpacker end Finally, I can only say that I really regret doing these changes... but I cannot revert time, so all I can do is apologize for any inconvenience that these have induced. Michael