TDiff calibration and CFT for MuSc

[benkrikler]

I'm looking at the config file timeoffset_calib.cfg which I'm guessing was used to produce the TDiff values we're now using, right?

In it, the MuSC is analysed with 7 different Constant Fractions. Does this mean that each TDiff is calculated using the same fraction for MuSc and the other channel?

I'm guessing since the fraction values were optimised by comparing the time back to muSc, we were unable to produce an optimum value for the CFT fraction for the muSc (there was nothing to compare it to). But perhaps now that we've fixed the values of the other channels, we could go back and look at the widths of the TDiff peaks if we vary the MuSc fraction? Then we could fix that value for muSc as well.

[AndrewEdmonds11]

The reason for 7 different constant fractions in the muSc was because we had to match the generators with the exact same configuration as the other detector.

I think we discussed this in issue #219. It looks like we may have solved this problem so I guess what you're suggesting is a good idea (although, personally, I would rather we soldier on and come back to do these optimisations if we need to do them (but then I am getting worryingly close to the end...)).

[benkrikler]

I can see discussions that are related to this on #219, but couldn't find a specific reason why we wanted to match CFT fractions between both channels in the TDiff plot.

personally, I would rather we soldier on and come back to do these optimisations if we need to do them (but then I am getting worryingly close to the end...)

Sorry Andy, I often forget your time constraints. If we want to plough on with other things then I'm fine that we can refine this later, provided the MuSc timing isn't too affected by the fraction we use (it's a scintillator so I guess it's not a big effect).

[AndrewEdmonds11]

why we wanted to match CFT fractions between both channels in the TDiff plot.

It was only because the code wouldn't work otherwise. (e.g. Ge-S#ConstantFraction#{constant_fraction=0.40} wouldn't match muSc#ConstantFraction#{constant_fraction=0.60} which is explained more in issue #220 and #221 (which kind of got linked at the time so apologies if the discussion is fragmented))

If we want to plough on with other things then I'm fine that we can refine this later,

We should also have a place to store these issues that we want to come back to. Another milestone?

[benkrikler]

That's a bit of a man-made issue then. Provided there is only one configuration of per type of generator per channel I would guess we could ignore the configuration. If we see multiple generators for a single channel with the same type then we would want to check the configuration I guess. Wouldn't that be preferable behaviour for pairing sources?

Another milestone?

I suppose the long-term milestone fulfils this. It would be nice to have a priority for issues as well. We could do that with labels I suppose, though probably just the long-term milestone is good enough.

[jrquirk]

...which I'm guessing was used to produce the TDiff values we're now using, right?

Exactly.

Does this mean that each TDiff is calculated using the same fraction for MuSc and the other channel?

Yes.

...provided the MuSc timing isn't too affected by the fraction we use (it's a scintillator so I guess it's not a big effect).

The rise time is often 2 bins maybe, with 4 ns per bin. So also yes.

That's a bit of a man-made issue then.

There was a reason for this, essentially this way was the path of least resistance and the effect is as small as stated above. Putting this on the long term docket seems good.

[benkrikler]

Thanks for clearing that up!