- "Sandbox" Moore version running HLT2-like tracking.
Turns out the nice little Moore trick made by Sebastian to simplify the running of Moore will only be 100% available from Moore v22r0 (a future version to be released in around 2 weeks). We could mimic it's behaviour with sufficient amount of various local checked-out packages, but might be best to stick to Brunel for this first set of tests, to setup the tools you want to use.
If you're running on lxplus you can run a Brunel test quite easily, but I think you want to be flexible enough not to have to run there, so I've copied a test file to our local system for you:
/data/bfys/rlambert/2012_raw_nu6_125745_0000000007.raw
To use it:
SetupProject Brunel v44r9 --build-env getpack PRConfig head make SetupProject Brunel v44r9 gaudirun.py --option="from Configurables import Brunel; from PRConfig import TestFileDB; from GaudiConf import IOExtension; TestFileDB.test_file_db['2012_raw_nu6'].run(configurable=Brunel()); IOExtension().inputFiles(['/data/bfys/rlambert/2012_raw_nu6_125745_0000000007.raw'],clear=True); Brunel().SkipEvents=27; Brunel().EvtMax=10;"
Which I think is the simplest way to do it...
Notice that the input file, the number of events, and the name of the output file are steered here. You will end up with some file matching WilcoTestBrunel*.dst in the directory where you run.
This input file has a lot of very large events in it, so in general I expect the events to take a long time to process and several events to be aborted due to too-high occupancy. However I think the events 27->37 are a reasonable example set with no aborts in them.
Now, this Brunel will probably run more than you really want it to run, it will spend a lot of time in particle identification and less than 50% of the time in tracking, but it will give the most realistic memory layout, that's for sure.
To eliminate the algorithms that you don't really need to be running yourself, you could also add the options:
Brunel().Detectors=['Velo','PuVeto','TT','IT','OT','Muon','Magnet','Tr']; from Gaudi.Configuration import *; GaudiSequencer('RecoCALOSeq').Enable=False; GaudiSequencer('RecoRICHSeq').Enable=False; GaudiSequencer('LumiSeq').Enable=False; GaudiSequencer('RecoPROTOSeq').Enable=False;"
And then the tracking will take the majority of the time (at the moment, PatVeloTT takes the lions share... I don't really know why that is, probably exploding combinatorics from high TT-occupancy).
Cheers,
Rob
------------------------------------------ Robert Lambert FOM-VU-NIKHEF-Bfys LHCb Email: rob.lambert@cern.ch ------------------------------------------ Nikhef N251 Tel: +31 20 592 2131 Fax: +31 20 592 5155 ------------------------------------------ CERN, 13-1-018 Tel: +41 22 767 4024 Fax: +41 22 766 8109 ------------------------------------------
________________________________________ From: ltop-bounces@nikhef.nl [ltop-bounces@nikhef.nl] on behalf of Rob Lambert [Rob.Lambert@cern.ch] Sent: 10 February 2014 15:47 To: Jeff Templon Cc: ltop@nikhef.nl Subject: Re: [Ltop] Recent news
A summary of the stand-up meeting.
This week we will aim to define our baseline, answering the following questions.
A) What performance gains can we simulate in a realistic toy, what are the tools and numbers we can extract which demonstrate the improvement most effectively? B) What is the current situation in tracking in HLT2 applying those same tools to the real tracking?
For this we need three ingredients.
1) Performance monitoring tools [insert favourite performance checking tools here] - also see: https://twiki.cern.ch/twiki/bin/view/LHCb/CodeAnalysisTools
2) Gerhard's "toy" to validate those tools: - This toy allocates some memory and then tests how fast we access it through current techniques versus accessing the exact same data with redesigned data layout redesigned with data-orientated techniques. - needs extra playing with to sparsify the accessed memory by an order of magnitude in order to make it more realistic - needs attaching to the tools from part (1)
3) "Sandbox" Moore version running HLT2-like tracking. - Rob will provide this (might need to talk to Sebastian Neubert to finalize) - needs attaching to the tools from part (1)
Cheers,
Rob
------------------------------------------ Robert Lambert FOM-VU-NIKHEF-Bfys LHCb Email: rob.lambert@cern.ch ------------------------------------------ Nikhef N251 Tel: +31 20 592 2131 Fax: +31 20 592 5155 ------------------------------------------ CERN, 13-1-018 Tel: +41 22 767 4024 Fax: +41 22 766 8109 ------------------------------------------
________________________________________ From: Jeff Templon [templon@nikhef.nl] Sent: 10 February 2014 13:22 To: Rob Lambert Cc: ltop@nikhef.nl Subject: Re: [Ltop] Recent news
sory meeting with director but go ahead without me.
JT
On Feb 10, 2014, at 13:10 , Rob Lambert Rob.Lambert@cern.ch wrote:
Wilco responded that 15:15 would be good for him. Jeff?
Rob
Robert Lambert FOM-VU-NIKHEF-Bfys LHCb Email: rob.lambert@cern.ch
Nikhef N251 Tel: +31 20 592 2131 Fax: +31 20 592 5155
CERN, 13-1-018 Tel: +41 22 767 4024 Fax: +41 22 766 8109
From: ltop-bounces@nikhef.nl [ltop-bounces@nikhef.nl] on behalf of Rob Lambert [Rob.Lambert@cern.ch] Sent: 10 February 2014 10:05 To: Jeff Templon Cc: ltop@nikhef.nl Subject: Re: [Ltop] Recent news
Hi All,
Today at 11, or 15:15? It would be a good start to the week Gerhard+I think.
Cheers,
Rob
Robert Lambert FOM-VU-NIKHEF-Bfys LHCb Email: rob.lambert@cern.ch
Nikhef N251 Tel: +31 20 592 2131 Fax: +31 20 592 5155
CERN, 13-1-018 Tel: +41 22 767 4024 Fax: +41 22 766 8109
From: Jeff Templon [templon@nikhef.nl] Sent: 06 February 2014 16:27 To: Rob Lambert Cc: Wilco Baan Hofman; ltop@nikhef.nl Subject: Re: [Ltop] Recent news
yo
next week :-)
J " just getting back to my email" TOn Feb 6, 2014, at 15:23 , Rob Lambert Rob.Lambert@cern.ch wrote:
Hi Jeff,
Sorry, I didn't see any confirmation of "let's do this!" I was very much available.
I could pass by right now if you would like.
Thanks,
Rob
Robert Lambert FOM-VU-NIKHEF-Bfys LHCb Email: rob.lambert@cern.ch
Nikhef N251 Tel: +31 20 592 2131 Fax: +31 20 592 5155
CERN, 13-1-018 Tel: +41 22 767 4024 Fax: +41 22 766 8109
From: Jeff Templon [templon@nikhef.nl] Sent: 06 February 2014 15:20 To: Wilco Baan Hofman Cc: Rob Lambert; ltop@nikhef.nl Subject: Re: [Ltop] Recent news
We were there. i guess it was a stand up meeting because we got stood up ;-)
JTOn Feb 6, 2014, at 12:52 , Wilco Baan Hofman wilcobh@nikhef.nl wrote:
On 05/02/14 17:47, Rob Lambert wrote:
Hi Wilco, etc.
Some useful progress from my side:
a) We now have a configuration of the trigger (Moore) which runs only the tracking sequence, which should be a nice compliment to any tests we want to do in Brunel (the much simpler reconstruction application).
b) We also have gotten together a set of "high-occupancy test files" which should be very useful for this proof-of-principle, and eventual profiling, examining memory footprints/patterns, since this is when it should be the most stressed out with lots of hist and tracks per event.
c) We're thinking of providing a script where you can slice out an algorithm from a complicated Gaudi set of options for stand-alone running, which should further simplify the making of a sandbox (but since you're probably changing the data structures themselves it is unclear how useful this will be for you).
Perhaps we should have a 15-minute coffee meeting in the next few days to discuss our first targets? Thursday or Monday would be good for me.
Sure. I can make it today at 15:00h. Not much to report from my side, still haven't found a full day to work on this, though next week is looking pretty good (I've reserved the entire week for this project).
-- Wilco
Ltop mailing list Ltop@nikhef.nl https://mailman.nikhef.nl/mailman/listinfo/ltop
Ltop mailing list Ltop@nikhef.nl https://mailman.nikhef.nl/mailman/listinfo/ltop
_______________________________________________ Ltop mailing list Ltop@nikhef.nl https://mailman.nikhef.nl/mailman/listinfo/ltop
On 10/02/14 18:00, Rob Lambert wrote:
- "Sandbox" Moore version running HLT2-like tracking.
Turns out the nice little Moore trick made by Sebastian to simplify the running of Moore will only be 100% available from Moore v22r0 (a future version to be released in around 2 weeks). We could mimic it's behaviour with sufficient amount of various local checked-out packages, but might be best to stick to Brunel for this first set of tests, to setup the tools you want to use.
If you're running on lxplus you can run a Brunel test quite easily, but I think you want to be flexible enough not to have to run there, so I've copied a test file to our local system for you:
/data/bfys/rlambert/2012_raw_nu6_125745_0000000007.raw
To use it:
SetupProject Brunel v44r9 --build-env getpack PRConfig head make SetupProject Brunel v44r9 gaudirun.py --option="from Configurables import Brunel; from PRConfig import TestFileDB; from GaudiConf import IOExtension; TestFileDB.test_file_db['2012_raw_nu6'].run(configurable=Brunel()); IOExtension().inputFiles(['/data/bfys/rlambert/2012_raw_nu6_125745_0000000007.raw'],clear=True); Brunel().SkipEvents=27; Brunel().EvtMax=10;"
Which I think is the simplest way to do it...
Notice that the input file, the number of events, and the name of the output file are steered here. You will end up with some file matching WilcoTestBrunel*.dst in the directory where you run.
This input file has a lot of very large events in it, so in general I expect the events to take a long time to process and several events to be aborted due to too-high occupancy. However I think the events 27->37 are a reasonable example set with no aborts in them.
Now, this Brunel will probably run more than you really want it to run, it will spend a lot of time in particle identification and less than 50% of the time in tracking, but it will give the most realistic memory layout, that's for sure.
To eliminate the algorithms that you don't really need to be running yourself, you could also add the options:
Brunel().Detectors=['Velo','PuVeto','TT','IT','OT','Muon','Magnet','Tr']; from Gaudi.Configuration import *; GaudiSequencer('RecoCALOSeq').Enable=False; GaudiSequencer('RecoRICHSeq').Enable=False; GaudiSequencer('LumiSeq').Enable=False; GaudiSequencer('RecoPROTOSeq').Enable=False;"
And then the tracking will take the majority of the time (at the moment, PatVeloTT takes the lions share... I don't really know why that is, probably exploding combinatorics from high TT-occupancy).
Thanks Rob,
I'll get to work on this tomorrow and report back :)
-- Wilco
-
Rob Lambert -
Wilco Baan Hofman