TRestRawSignalShapingProcess problems

REST version : v2.2.10

Hi,
When I use TRestRawSignalShapingProcess, I find the energy of the TRestRawSignalEvent goes up several times.
Maybe we need Gaussian normalization for convolution and Rounding when save charge into the TRestRawSignal.
So I do this in the TRestRawSignalShapingProcess.cxx. then everything
seems to be fine.

Hi Tao, thanks for reporting this.

Actually, what it is the sum variable in your image? I cannot find this variable on the code at the repository.

From my perspective, I don’t understand this correction you are adding, but this is probably because I don’t know what means the sum.

I guess, this problem should be solved on the generation of rsp at the gaus definition.

// Line 207
if (fShapingType == "gaus") {
   ...
   Double_t amp = fShapingGain;
   rsp = new double[Nr];
   for (int i = 0; i < Nr; i++)
          rsp[i] = (amp * TMath::Exp(-0.5 * (i - cBin) * (i - cBin) / sigma / sigma));
}

The integral of rsp should be 1 in order to do not affect the integral of the convoluted result. But there is also the option to insert a given amplitude through the gain parameter.

I believe, the gaussian is not properly normalised, when defining the rsp and it should be something like this.

rsp[i] = (amp / sigma / TMath::Sqrt( 2 * M_PI ) * TMath::Exp(-0.5 * (i - cBin) * (i - cBin) / sigma / sigma));

but actually I believe the actual implementation is wrong, is missing the normalisation factor, as it is

rsp[i] = (amp * TMath::Exp(-0.5 * (i - cBin) * (i - cBin) / sigma / sigma));

If you apply/correct this factor, and you define the gain parameter to be 1 your output result should not be affected.

// See parameter fShapingGain registered by InitFromConfigFile
fShapingGain = StringToDouble(GetParameter("gain", "1"));

Could you then test this?

Thanks for replying. I’m sorry I missed the definition of the “sum” in the image.


on the other hand, I also did what you suggested.

Judging from the results of the two kinds of corrections, it seems the energy of the two corrections is similar. But I think normalizing the gaussian is more appropriate.
However, after both of the two corrections, the signal gets strange. when I used
“restViewEvents *.root TRestRawSignalEvent”, I can’t understand the waveform.
before correction of the gaussian, waveform is right except energy.

after correction of the gaussian. I don’t know why.

Actually, the rsp[] vector integral should always be equal to 1. Therefore, what you propose in your first post makes sense, and one would in principle no need to worry about normalisation at the gaussian definition.

The most appropriate then would be to renormalise directly rsp to be 1, just before line 238 in the code.

for( int n = 0; n < Nr; n++ )
    rsp[n] /= sum;
for (int n = 0; n < fInputSignalEvent->GetNumberOfSignals(); n++) {
    TRestRawSignal* shapingSignal = new TRestRawSignal();

Could you re-do it disabling the process adding the noise? Then, include in your post an image of the rawSignalEvent before and after the shaping process.

Note that the total energy of the event is preserved, but not the amplitudes at each sampling bin. Therefore, the width of the gaussian, the shaping time, will affect those amplitudes.

Yes, you’re right. It seems I made a mistake.

Now I removed the “TRestRawSignalAddNoiseProcess” and everything is ok.

before shaping:

after shaping:

Thanks so much for your help.

Ok, good. Seems that after shaping the signal is probably hidden at the level of the noise.

Still, we agree that we should just add this to the process code to keep the energy preserved except for a gain factor.

for( int n = 0; n < Nr; n++ )
    rsp[n] /= sum;

I will just commit that change then.

Just crosscheck that the integral of the event before shaping is the same as the integral after shaping.

rawSignalEventBefore->GetIntegral();

compared to

rawSignalEventAfter->GetIntegral();

Tip: If you use TRestRawSignalAnalysisProcess this is the FullIntegral observable. You need to define an analysis process before and after the shaping in your analysis chain.

I would expect, because your output event amplitudes are so low that you must get some rounding errors. Thats why it is convenient to adjust the amplitude of your output amplitude by adding a gain value different from 1

Still, one needs to be careful when applying a high gain not to exceed a Short_t range, i.e. (-32768,32768).

I have added those changes to the following commit

https://pandax.physics.sjtu.edu.cn:8443/pandax-iii/REST_v2/commit/117e87a73090f7052842024c28e211e83270b38e

in branch v2.2.11_dev

I have got the commit, Thank you.

as you said, the energy will get large rounding errors after shaping if “gain” was set 1.

In my analysis work, I will use this process with Gain about 1000 which makes the error much more small.

thanks again for your kind help.