| PSA-hit Energy [message #17694] |
Mon, 22 December 2014 15:38  |
RiccardoAvigo
Messages: 14
Registered: July 2014
Location: Milano
|
occasional visitor |
From: *mi.infn.it
|
|
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)
|
|
|
|
| Re: PSA-hit Energy [message #17758 is a reply to message #17694] |
Wed, 14 January 2015 13:51  |
miree
Messages: 71
Registered: June 2014
|
continuous participant |
From: *ikp.physik.tu-darmstadt.de
|
|
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...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: PSA-hit Energy [message #17945 is a reply to message #17831] |
Tue, 24 February 2015 21:23 |
mlcortes
Messages: 41
Registered: July 2014
Location: Darmstadt
|
continuous participant |
From: *ikp.physik.tu-darmstadt.de
|
|
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
Li^2
|
|
|
|
| Re: PSA-hit Energy [message #17946 is a reply to message #17694] |
Wed, 25 February 2015 11:36 |
miree
Messages: 71
Registered: June 2014
|
continuous participant |
From: *ikp.physik.tu-darmstadt.de
|
|
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
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
