GSI Forum - RDF feed
type: channel
description: GSI Helmholtzzentrum für Schwerionenforschung
items: PSA-hit Energy
items: Re: PSA-hit Energy

PSA-hit Energy
type: item
description: 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)
creator: RiccardoAvigo
date: 2014-12-22T14:38:30-00:00

Re: PSA-hit Energy
type: item
description: 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...
creator: miree
date: 2015-01-14T12:51:03-00:00

Re: PSA-hit Energy
type: item
description: 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
creator: RiccardoAvigo
date: 2015-01-29T11:10:25-00:00

Re: PSA-hit Energy
type: item
description: Hi Riccardo, can you post the section of the config file (in particular the display line) that produces this plot? Michael
creator: miree
date: 2015-01-29T12:21:58-00:00

Re: PSA-hit Energy
type: item
description: Hi Michael, in attachment the config file cheers Riccardo
creator: RiccardoAvigo
date: 2015-01-29T13:04:11-00:00

Re: PSA-hit Energy
type: item
description: 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
creator: miree
date: 2015-01-29T14:50:01-00:00

Re: PSA-hit Energy
type: item
description: 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?
creator: miree
date: 2015-01-29T15:01:46-00:00

Re: PSA-hit Energy
type: item
description: 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?
creator: miree
date: 2015-01-29T15:33:14-00:00

Re: PSA-hit Energy
type: item
description: 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
creator: RiccardoAvigo
date: 2015-01-29T15:37:37-00:00

Re: PSA-hit Energy
type: item
description: Ah, ok, then I would like to see the "broken" adf file.
creator: miree
date: 2015-01-29T15:45:47-00:00

Re: PSA-hit Energy
type: item
description: I sent you the folder, the "broken" file was the one I sent you Riccardo
creator: RiccardoAvigo
date: 2015-01-29T15:47:52-00:00

Re: PSA-hit Energy
type: item
description: 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
creator: RiccardoAvigo
date: 2015-01-30T15:18:37-00:00

Re: PSA-hit Energy
type: item
description: 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
creator: mlcortes
date: 2015-02-24T20:23:52-00:00

Re: PSA-hit Energy
type: item
description: 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 ru…
creator: miree
date: 2015-02-25T10:36:59-00:00