Presentation is loading. Please wait.

Presentation is loading. Please wait.

Event display monitoring Giuseppe Zito : Infn Bari Italy Beliy Nikita : University of Mons-Hainaut Belgium.

Similar presentations


Presentation on theme: "Event display monitoring Giuseppe Zito : Infn Bari Italy Beliy Nikita : University of Mons-Hainaut Belgium."— Presentation transcript:

1 Event display monitoring Giuseppe Zito : Infn Bari Italy Beliy Nikita : University of Mons-Hainaut Belgium

2 Index - Which programs will be available for next CRAFT - Creating a visual report of each run : a procedure to better exploit all available programs. - Apply the procedure to run 69343 - How fast is this procedure? - Who can do this?

3 Which programs will be available for next CRAFT There will be three general purpose event display tools available to CMS users: Iguana, Firework and Frog. 1)Iguana has two versions: fully embedded in CMSSW and a light (outside CMSSW) version iSpy(*) 2)Fireworks uses FWLite to optimize event access 3)Frog works completely outside CMSSW like iSpy (*) We will use also the trackermap (a synoptic view of tracker) implemented both in iguana(fully embedded) and outside iguana as a class created, filled and printed without using other CMSSW services, as a root histogram. *In order to work outside CMSSW Frog and iSpy work in parallel with a normal CMSSW task (the Analyzer) that provides the events in a special format.In fact Frog and iSpy are light-weight graphics clients. We will refer to them as “Visualizer”.

4 General purpose event display tools performance Iguana embedded8 min 30 sec iSpy(*)30 sec Fireworks2 min Frog 30 sec Time to scan 551 events on the same computer with local access from disc to events. For each event we look at a minimum of 3 windows included a 3D window iSpy tested only as a prototype: not yet available in CMS software

5 Iguana https://twiki.cern.ch/twiki/bin/view/CMS/WorkBookEventDisplay

6 Fireworks https://twiki.cern.ch/twiki/bin/view/CMS/WorkBookFireworks

7 Frog https://twiki.cern.ch/twiki/bin/view/CMS/FROG

8 Trackermap http://webcms.ba.infn.it/cms-software/cms-grid/index.php/CMSTrackerVisualizationSoftware/TrackerMap

9 Creating a visual report of each run What ? A procedure to systematically study with available programs every run Who? I will start to perform it myself during next CRAFT to validate it. When and where : offline when RECO and DQM T1 results are available Why offline? – online not all events available and resources are scarce How : 4 phases 1)Look to trackermaps and other DQM results to see if unusual features are present that need to be explained. 2)Fast and interactive event selection with a root macro on all files of run. 3)Look at selected events with all three available programs. 4)Write a report

10 Applying the procedure to run 69343 Phase 1) Cluster occupancy shows some strange pattern in barrel: try to explain looking at events.

11 Phase 2:Selection of interesting events from root files using frogFilter.sh Retrieve file list (using get_files.py) Initialization Processing files Root script applied to each file Run (and dataset)

12 Phase 2:Selection of interesting events from root files using frogFilter.sh

13

14

15 Phase 3:Looking at selected events

16

17

18

19

20

21

22

23

24 Phase 4) The report :Cluster occupancy completely biased by monster events produced by random electronic noise

25 Phase 4) The report 1)Pattern in TIB1 and TOB cluster occupancy explained by single monster events. 2)Selection of events with more than 1 tracks OR number of hit modules > 100 shows around 10 "monster events“ per file that completely fill TOB or TIB+TEC+TID 3)These few monster events completely bias cluster occupancy trackermap. If a pattern is present in one of this, it will show up in total trackermap. 4) there are also around 20-30 (per file) small size "monster events“(a few hundreds of modules interested): the event with maximum number of reconstructed tracks(26) is one of this. These seem to have a random pattern of clusters that doesn’t create any pattern in cluster occupancy.

26 How fast is this procedure? Running in parallel Selection script,Analyzer and Visualizer, you can look at first events after a few minutes How does it scale to million events runs? Selection script, Analyzer and Visualizer can run in parallel on different computers. The selection script is the bottleneck. Until 1 million events, one or two hours are sufficient. During this time you are in any case busy looking at events. For 10 million events runs it should still be kept to a reasonable time by exploiting parallelism of multicore machines in lxplus (i.e. running more than one selection script on different files of the same dataset). Taking in account that the script uses limited resources this shouldn’t create problems to other users).

27 Who can do this? Anyone on his graphics enabled computer with a good network connection to lxplus. I can describe the installation and prepare a public installation in Meyrin Control Centre.


Download ppt "Event display monitoring Giuseppe Zito : Infn Bari Italy Beliy Nikita : University of Mons-Hainaut Belgium."

Similar presentations


Ads by Google