Upgrade Software University and INFN Catania Upgrade Software Alessia Tricomi University and INFN Catania CMS Trigger Workshop CERN, 23 July 2009

Upgrade SoftwareUpgrade Software

Alessia Tricomi University and INFN CataniaUniversity and INFN Catania

CMS Trigger WorkshopCERN, 23 July 2009

DisclaimerDisclaimer

More than a real presentation this talk is meant to “trigger” discussion about future software developments/strategies

CMS Trigger Upgrade Workshop, 23 July 2009 A. Tricomi (Catania)

2


3

Goals for SLHC Software(Re)use as much of the code in CMSSW as possibleCause zero disturbance (or confusion) for standard CMS codeLow maintenance for upgrade code (releases)Enable upgrade simulation studies by non-code expertsCommon code base for meaningful comparisons of studies from different people/working groups

SLHC software: where we are?SLHC software: where we are?During May workshop we had a first session on SLHC workshop

Overall a positive experienceFirst time we met “officially” with offline expertsMany ideas came for the first strategies

In the last two months much more experience gained

The code is becoming more and more complexThe code is becoming more and more stableWe went through a dedicated production phase (see Dave’s talk)

• Very good experience• But many points were raised


4

Strategies for SLHC Software: Strategies for SLHC Software: status as May workshopstatus as May workshop

Two possible strategiesDedicated release

• Heavy in term of maintenance – need dedicated manpower resources

CVS Branches• We decided to adopt this strategy

Manage upgrade code through CVS branchesPossible due to limited number of packages/files modifiedStart CVS branch (each time!) at a stable releaseUpgrade-only files in separate SLHCUpgradeSimulations CVS package

• SLHCUpgradeSimulations/Geometry• SLHCUpgradeSimulations/L1Trigger• SLHCUpgradeSImulations/Utilities• SLHCUpgradeSimulations/Validation


5


6

SLHC Upgrade Software: status up today!

Overall a positive experience so far with current method of working

PRO: Can use all new CMSSW code and features easily• Much less effort than keeping a separate copy of CMSSW for

upgrades• Direct connection to standard code for comparisons

– Easier to get help from experts (Thanks to all experts for all help so far!)

• Surprising how much of the software can be used (thanks to Offline!)

CON: needs recompile (change to e.g. data format need care)CON: Need to create new branch for each stable release

• Can have many changes between stable releases to adapt upgrade sw to

Continue to work with CVS branches at least until we have a more stable code

SLHC sw strategy: PRO/CONSLHC sw strategy: PRO/CONThis strategy was adopted for our first production since there was

urgency to produce samples using existing codeneed to share samplesNo manpower to go towards a dedicated releaseCode still in a debugging phaseDave will report on such experience…

However some limits of current strategies (already well known) are becoming more and more important

No official release means no official productionOnly partial use of GRID facilities CVS branches/tags growing more and more


7

How to move onHow to move on……

Longer timescale (but not too longer!) – we need to produce the first TDR for PhaseI in April-May 2010

Need to quantify resource requirements• CPU

• Memory

• Storage


8

CPU/Time issueCPU/Time issueCommon to all sub-detectors - just an examples…


9

Memory issueMemory issueCommon to all sub-detectors - just an examples…


10

Storage etc.Storage etc.

Very large files especially with high PUThis is true both with full and fast simulation

We need to set the minimum info needed for performance studies that we would like to save on fileVery large production of minimum bias needed

I/O problems?How to access these data from remote?


11

SLHC sw: how to move onSLHC sw: how to move on……For the next months

We need dedicated Monte Carlo productionsWe need to exploit a whole use of GRID resourcesWe need to build up an efficient production/validation chain for large MC productionWe need to share our dataLast but not least we need to solve problems with memory/cpu

• Not easy to find farm with needed resources• Also storage could become an issue• We need to revisit our sw code development to solve

memory issue– We need experts help


12

AAction items/Discussion pointsction items/Discussion pointsWe need to target a set of “good” GRID sitesWe intend to set up an ‘SLHC group’ (in CMS computing terms)

Proposed contacts: D. Newbold / A. TricomiThis already agree with Offline/Computing managers

Should we move to 3_1_x?Advantages:

• keep in touch with experts• Ask for a dedicated release and so also for official production• Experts claim that many issue with high PU are solved

Disadvantages:• Migration is a very expensive in time• Still not very stable


13

Action items/Discussion pointsAction items/Discussion points

My personal opinion is that we should move to 3_1_X and try to easy all the machineryHowever, since it is very time consuming and we need also to produce first results, I suggest we wait September before starting to moveTo plan future production/work it could be useful to know for each sub-detector

How many events we needWhich is the size of one full eventHow long it last to produce one eventHow many memory is neededDo you need fast or full sim?Do you need standalone or global detector info?

All together we should decideWhich sample we are interested in for global detector simulationHow many eventsTimescale


14

It is really time to start to It is really time to start to organize and better integrate organize and better integrate our software/efforts!our software/efforts!

15CMS Trigger Upgrade Workshop, 23 July 2009 A. Tricomi (Catania)

Documents

Upgrade Software University and INFN Catania Upgrade Software Alessia Tricomi University and INFN Catania CMS Trigger Workshop CERN, 23 July 2009