GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » NUSTAR » NUSTAR PRESPEC » PSA-hit Energy
PSA-hit Energy [message #17694] Mon, 22 December 2014 15:38 Go to next message
RiccardoAvigo is currently offline  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 Go to previous messageGo to next message
miree is currently offline  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 #17818 is a reply to message #17758] Thu, 29 January 2015 12:10 Go to previous messageGo to next message
RiccardoAvigo is currently offline  RiccardoAvigo
Messages: 14
Registered: July 2014
Location: Milano
occasional visitor
From: *mi.infn.it
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
Re: PSA-hit Energy [message #17819 is a reply to message #17818] Thu, 29 January 2015 13:21 Go to previous messageGo to next message
miree is currently offline  miree
Messages: 71
Registered: June 2014
continuous participant
From: *ikp.physik.tu-darmstadt.de
Hi Riccardo,

can you post the section of the config file (in particular the display line) that produces this plot?

Michael

[Updated on: Thu, 29 January 2015 13:22]

Report message to a moderator

Re: PSA-hit Energy [message #17820 is a reply to message #17819] Thu, 29 January 2015 14:04 Go to previous messageGo to next message
RiccardoAvigo is currently offline  RiccardoAvigo
Messages: 14
Registered: July 2014
Location: Milano
occasional visitor
From: *mi.infn.it
Hi Michael,

in attachment the config file

cheers

Riccardo
Re: PSA-hit Energy [message #17822 is a reply to message #17819] Thu, 29 January 2015 15:50 Go to previous messageGo to next message
miree is currently offline  miree
Messages: 71
Registered: June 2014
continuous participant
From: *ikp.physik.tu-darmstadt.de
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
Re: PSA-hit Energy [message #17824 is a reply to message #17822] Thu, 29 January 2015 16:01 Go to previous messageGo to next message
miree is currently offline  miree
Messages: 71
Registered: June 2014
continuous participant
From: *ikp.physik.tu-darmstadt.de
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?
Re: PSA-hit Energy [message #17825 is a reply to message #17824] Thu, 29 January 2015 16:33 Go to previous messageGo to next message
miree is currently offline  miree
Messages: 71
Registered: June 2014
continuous participant
From: *ikp.physik.tu-darmstadt.de
Hi, I put the file you send me through my analysis and everything looks fine
index.php?t=getfile&id=8267&private=0

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?
Re: PSA-hit Energy [message #17826 is a reply to message #17825] Thu, 29 January 2015 16:37 Go to previous messageGo to next message
RiccardoAvigo is currently offline  RiccardoAvigo
Messages: 14
Registered: July 2014
Location: Milano
occasional visitor
From: *mi.infn.it
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
Re: PSA-hit Energy [message #17827 is a reply to message #17826] Thu, 29 January 2015 16:45 Go to previous messageGo to next message
miree is currently offline  miree
Messages: 71
Registered: June 2014
continuous participant
From: *ikp.physik.tu-darmstadt.de
Ah, ok, then I would like to see the "broken" adf file.
Re: PSA-hit Energy [message #17828 is a reply to message #17827] Thu, 29 January 2015 16:47 Go to previous messageGo to next message
RiccardoAvigo is currently offline  RiccardoAvigo
Messages: 14
Registered: July 2014
Location: Milano
occasional visitor
From: *mi.infn.it
I sent you the folder, the "broken" file was the one I sent you

Riccardo
Re: PSA-hit Energy [message #17831 is a reply to message #17828] Fri, 30 January 2015 16:18 Go to previous messageGo to next message
RiccardoAvigo is currently offline  RiccardoAvigo
Messages: 14
Registered: July 2014
Location: Milano
occasional visitor
From: *mi.infn.it
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
Re: PSA-hit Energy [message #17945 is a reply to message #17831] Tue, 24 February 2015 21:23 Go to previous messageGo to next message
mlcortes is currently offline  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 Go to previous message
miree is currently offline  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
Previous Topic: prespec code
Next Topic: MHTDC of the AgataTime crate
Goto Forum:
  


Current Time: Thu Dec 05 17:32:39 CET 2024

Total time taken to generate the page: 0.00818 seconds