Blog from June, 2010

Reason for change

To enable processing of LCI data and fix a couple of bugs in FastMon.

Test Procedure

We have processed runs in the DEV pipeline with this version of L1Proc.

Rollback procedure

We can easily switch back to the previous version of L1Proc.

CCB Jira

SSC-256@JIRA

Details

L1Pipeline: L1Pipeline v1r85

Complete set of tags for L1Proc 1.85
Code Versions
GlastRelease (sim/recon): GlastRelease-v15r47p12gr11
ScienceTools (Level 2) : v9r16p1
Science Ops (task defs, scripts):
Level 1 pipeline code and applications running in L1:

svac/L1Pipeline: L1Pipeline v1r85

• Modernize XML for doLci subTask.
• Don't check whether verify found missing data for LCI runs (we don't run verify on LCI).

calibTkrUtil v2r9p1

calibGenTKR v4r5

dataMonitoring/AlarmsCfg: AlarmsCfg-05-26-01

dataMonitoring/FastMonCfg: FastMonCfg-02-01-01

• Bug fix for preventing the FastMon from crashing on empty input M7 files. GDQMQ-347@JIRA
• Minimal changes in order to prevent the orbit line from disappearing with ROOT 5.26. GDQMQ-346@JIRA

dataMonitoring/DigiReconCalMeritCfg: DigiReconCalMeritCfg-01-04-06

dataMonitoring/Common: Common-06-08-00

dataMonitoring/FastMon: FastMon-05-01-01

dataMonitoring/IGRF: IGRF-02-01-00

svac/Monitor: Monitor-01-06-01

svac/EngineeringModelRoot: v4r4

svac/TestReport: TestReport-10-07-00

users/richard/pipelineDatasets: v0r6

ft2Util: v1r2p31

evtClassDefs v0r14

GPLtools: GPLtools-01-15-01-fo06

Here are some notes for the june 10 tagup

Philippe's email report

I won't be able to attend the meeting today. Here is my short written report, based on the results I already posted (https://confluence.slac.stanford.edu/display/SCIGRPS/2010/06/02/First+look+to+periodic+trigger+events+responsible+for+the+loss+of+effective+area)

• The production of OVRLY and FAKEOVRLY is very helpful to understand the reasons why overlay events prevent simulated events to pass the selection;
• The tracker activity in a PT event is not the main problem : the cal and acd activities are more often the cause of the loss of the MC events
• One of the main issue is the fact that the cal direction is is very badly reconstructed because of the PT additional crystals. As a consequence, the track is badly reconstructed as well.
• This problem can only be solved by a smart clustering, able to find ghost clusters. This is not easy because the ghost clusters are very often large and not so clustered.
• On top of that, when there is a ghost track, the ghost track and the ghost cluster are very often unrelated. It means that, in most cases, we can't use the ghost track to tag the ghost cluster.
• All this should help us in defining/optimizing the cal clustering.

Some considerations about the clustering :

• If there is a ghost track, we know how to find it and remove the ghost hits. It means that for all events, we can end up with a clean tracker information, i.e. hits only due to the main event. This clean tracker information points to the main cluster.
• When there is a ghost cluster, we want to find two clusters, that can be more or less extended. The goal is to separate the two clusters well enough so that the cal direction is not too bad. It seems to me that this separation is better seen when using the direction of the main event : when projecting the crystals onto the plane perpendicular to the direction, we should end up with two blobs (more or less compact). When using a different axis, the projected cal clusters should be more blurred.
• The issue is that we don't know the main event direction before performing the track finding, which needs the cal direction as an input.
• One possible solution is to perform a cal+tkr cluster : find the direction that makes the projected tkr ckuster and cal clusters less blurred. Since the ghost cluster is not related to the track information, the projected ghost cluster is likely more blurred than the main event projected cal cluster. The main event cal cluster is related to the track information, so the projected tkr cluster and the main event projected cal cluster should be on top of each other. So the goal is in fact to find the axis that makes the projected tkr cluster and the related projected cal cluster (which is on top of the projected tkr cluster) less blurred.
• After the axis is found, it can be used to refine the main event cal cluster. Then, the cal direction can be computed and sent to the track finder.
• Another possibility is to use the found axis to perform the track finding, without using the cal direction.

Some comments from Luca L

I started looking at some events from Philippe's skim (i.e. those PT that make the overlaid gamma to fail the rejection cuts), which Leon put in users/lsrea/overlay4/MC/.

I basically confirm Philippe's comments for the PT evts that are clearly bound to kill an overlaid gamma:

• many have lots of activity in the CAL, in some cases with very large clusters extending to several modules
• several have ACD tiles corresponding to tracks
• a good number have only TKR activity, unrelated to CAL activity

But I also noticed quite some evts which apparently have no visible signal at all in the ED, and the only non-zero quantity in the merit is from some ACD tile; it is hard to believe that these will kill a good gamma event. This is a non negligible fraction of the evts, but I cannot make a more quantitative statement right now.
Carmelo warned me that in some cases FRED looses sync between digis and merit when moving back and fwd between evts, so I should recheck this

Live notes from the actual tagup

Bill: working with Tracy on a new sim of CAL xtal adding 2 effects

• add edge effect taking into account solid angle effects and reflection
• getting details of the xtal edge and materials into the sim, with info from NRL people (Eric Grove on chat: n = 1.46 (for one of DC's other elastomers)
  qualitatively it explains what we see in the data, I think we are on the right track
  Eric G: we tried modeling this long ago, qualitatively you can get it, but actual roughening of this joints, which vsary from xtal to xtal has a huge effect on the actual light taper, so I think you can get close but don't think you can get it right as we don't know what the roughness is; remember there was an engineer from France who claimed to be able to get the light taper curve exactly, but in fact came out with an inverted curve.
  Turn-down is a measure of the transverse location of the deposit across the xtal
  Bill: agree, but I am more optmistic here

Luca L: Johan is simulating evts with the latest asimetry calibration from Sasha and reconstructing with the calibration from L1proc; it seems CTBCORE is screwed to the extent we see in real data
Bill: would be good to quantify how much these CAL calibs are screwed; make a distribution of ? one can envision making a set of MIPs and run with old and new calibs and measure longitudinal residual positions vs tTKR track, take RMS and difference between old and new calibs for all xtals
Eric G: what strucks me is that the shower RMS did not change when doing this, DOCA moves from 2mm to 4 mm, while CTBCORE has a tremendous effect in shape
Bill: not surprising to me, given the weight of the directionality from the CAL at high energy; this effect on CalTrackDOCA may be a big part in the PSF issue, you can easily comeup with deviations of several mrads
Leon: and just to add to this, the lever-arm for back events is much shorter, so with the same effect and a shorter lever arm you could get the larger effect we actually see in the data

Bill: recent issue on availability of HIP for caibration (see C&A list), Eric can you comment about on-going investigations?
Eric C: distinction between FSW bits, which are fine, then the OBF instance that re-run on the ground; when we turned on the DIAG the OBF basically stopped agreeing with FSW HIP bits as they used to. Currently searching root cause. These evts were put into a special GCRCalib stream and they are available in the digis, Sasha should be able to use it if re-starting from there, so we did not loose them, it's a techincal issue to setup the CAL calib to use digis to access evts. But this needs someone to work on GCRCalib code
17:18:33 Richard Dubois and Tracy will investigate when he gets back from San Diego
Eric G: as I understand that is a non trivial effort, but we need to find out; whereas I presume fixing GCRCalib files is easier, but will take a while

Tracy: focusing on getting stuff on McIntegratingHits, not worked much on the Tree based pat-rec

Bill: anybody looked at the new G4 sims after you ran that?
Tracy: Johann working on runing that to Linux, with Heather; Francesco will become available to work on this next week

Leon: conversation with Sandro about mass model, he is setup to review all the numbers and check what has been included, he sent out a note last night which I have not reviewed yet. I will also work on the 200 micron vertical displacement.

AlexD: have a list of updates on TMine with Eric as requested during the meeting; having it to work on windows is priority for next 2 weeks

Leon on ED: requires input from Heather, and she is now tied to ongoing developments, so on-hold for now; we need to put together a set of more specific requirements
Elliott: I read from the workshop that WIRED will finally replace FRED, is this really going to happen? I personally use WIRED
Leon: we do not really have a choice, FRED is not supported anymore, to be honest FRED is more convenient on windows and I will use it until it works, but it will stop working eventually
17:37:52 Richard Dubois the support for WIRED will improve when we get 3 new FTEs into the data handling group.
17:38:02 Richard Dubois until then, support will not be great
17:38:17 Richard Dubois reqs are going out for those FTEs shortly
Richard: it will be at least 2 months, not weeks, but we ahve budget for this

Sidenote from Luca L: electrical power at INFN Pisa is cutoff for a fire in the nearby electrical cabine; not sure when we are back online, so we will not get emails for some time

Reason for change

To update ROOT version.

Test Procedure

We have processed runs in the DEV pipeline with this version of L1Proc.

Rollback procedure

We can easily switch back to the previous version of L1Proc.

CCB Jira

SSC-255@JIRA

Details

L1Pipeline: L1Pipeline v1r84

Complete set of tags for L1Proc 1.84
Code Versions
GlastRelease (sim/recon): GlastRelease-v15r47p12gr11
ScienceTools (Level 2) : v9r16p1
Science Ops (task defs, scripts):
Level 1 pipeline code and applications running in L1:

svac/L1Pipeline: L1Pipeline v1r84

• Switch to ROOT 5.26.
• Don't put thousands of run and delivery directories in the same subdirectory.
• Suppress run cleanup if verify detects missing data. (LONE-151@JIRA, LONE-152@JIRA)
• Fail earlier on some errors.
• Put prod dev and test logs in different places.

calibTkrUtil v2r9p1

calibGenTKR v4r5

dataMonitoring/AlarmsCfg: AlarmsCfg-05-26-01

dataMonitoring/FastMonCfg: FastMonCfg-02-01-01

dataMonitoring/DigiReconCalMeritCfg: DigiReconCalMeritCfg-01-04-06

dataMonitoring/Common: Common-06-08-00

• Fix to handle some misnamed variables correctly (normalized trigger engine rates).
• Brute force fix to handle some misnamed variables correctly.
• Relevant Jira(s): GDQMQ-342

dataMonitoring/FastMon: FastMon-05-01-01

dataMonitoring/IGRF: IGRF-02-01-00

svac/Monitor: Monitor-01-06-01

• Works with ROOT 5.26.

svac/EngineeringModelRoot: v4r4

svac/TestReport: TestReport-10-07-00

• Verify indicates missing data with a special exit code.

users/richard/pipelineDatasets: v0r6

ft2Util: v1r2p31

evtClassDefs v0r14

GPLtools: GPLtools-01-15-01-fo06