17th July 2013 : Topical meeting on technology, software and computing, in preparation of the ECFA HL-LHC workshop October 2013
------------------------------------------------------------------------------------------------------
THIS IS NOT A SUMMARY. These are rough notes on the discussions to complement the transparencies.
Audience reached 30 people in the room plus 5 on vidyo
Bernd Panzer : technology
- Bernd : the 14nm technology in Intel roadmap is probably late
- DavidR : you quote : 25% better CPU performance per CHF per year. Is this without sw improvement or with ? A: this is with the same efficiency as today (so not guaranteed without sw improvements)
- Bernd : seek time on HDD will remain unchanged (unless new technology)
- Bernd : SSD will not replace HD (always too expensive)
- Vincenzo : we hear since decades about new breakthrough technologies for storage but they never appear on the market. Bernd : right, only incremental improvements.
- Bernd : tapes might disappear in 10 years (and be replaces by cheap disk)
- Pierre : you did not mention network estimate ? Bernd : no sign of network being a limiting factor. P: but it could matter for online applications.
- DavidR : for installed disk server storage, what is the justification for going from observed 10% improvement per year to the forecasted 20% ?
Predrag Buncic : Alice vision
- Predrag: bringing online and offline together has been quite a challenge, not just for technological reasons.
- DavidR : storing reco data and dropping raw data is bold. Predrag : not really, this is only a sophisticated zero suppression using coarse track reconstruction. In particular, finer calibration and alignment can still be applied later.
? : you reconstruct "time frame" with many events overlapping (TPC). Don't you have a problem at the edges ? Predrag : yes but negligible.
I. Ueda : Atlas vision
- Vincenzo : xrootd is not more efficient than copying to node for IO bound jobs. Other disagree, it is generally more efficient, except in some cases
- Event Server slide triggered lots of discussion. Some cannot see how it can be efficient for analysis (not efficient to ship event one by one). A : true but this is for production, not analysis. Is the Event Server only a source ? A: also a sink. The underlying storage technology is unchanged (large root files). ?:you're reinventing large event databases which have failed in the past. A: scope much more limited.
Ian Fisk : CMS vision
-? : wrt slide 19: it is unlikely that filtering offline (to have an "active dataset" smaller than the original one) would gain a lot. This was studied in atlas (only for run2, not for HL-LHC) and was not deemed worth it. ?: you would be adding another layer of complexity on top of the hundreds odd trigger menu items. IanF: to be studied still.
-? : HPC usage worth it ? IanF : cost benefit analysis to be done. Amount of work wrt amount of resource gained.
Marco Cattaneo : LHCb vision
-IanB : why is lhcb using its own framework (dirac). Marco : Dirac is used beyond LHCb.
-Elizabeth : your cpu increase linearly with pileup ? while in CMS/Atlas it is at least quadratic ? Marco : the new tracker was designed for this.
Ian Bird : WLCG vision
- Vincenzo : we cannot sell HEP for its side product. IanB : granted, but we should nevertheless share our big data knowledge with other field and get resources from it.
- Pete : So you say we need to have sthg like WLCG for all HEP, how will this happen. IanB : We will organise a workshop in the coming months.
Pere Mato : Software paradigm shift
- DavidR : what about new languages ? Pere : there has been a demonstrator in go but this is not active now. For GPU and the like we might need dedicated language because of the issue of maintenance. E.g. rewrite alg in Cuda, validate vs C++, not nice.
- ? : concurrent programming is not the same as thread safeness. Pere : true the handling of thread should be done by the framework, hidden to the average physicist. Still the average physicist should be aware of the environment he is working with. ? : then we need an agreed set of clear guidelines, no global variable etc...
- Vincenzo : multithreading will not help because of concurrent memory access. Pere : it will help but not, granted, not by factors. E.g. Arm today have 4 cores and we know we cannot use them efficiently with 4 independent jobs.
- DavidR : you said parallellism among algorithms will not help a lot ? Pere : yes with LHCb or CMS reco we can only run less than 3 alg simultaneously in average. But it should be better once we are able to stagger events.
Federico Carminati : R&D for the next generation simulation toolkit
- DavidR : is it always true that all particles can be treated independently in whatever order ? Federico : Yes, but result may change due to rounding errors. So validation is more difficult.
- Vincenzo : why not use surface rather than volumes ?
- AndreasS : fast simulation should be in the picture, because we expect much more overall gain from increased use of fast simulation, than from any improvement of full sim.
Benedikt : Software consolidation tasks
- Vincenzo and others : static analyser (or modern compiler) is more useful than software review, given our existing large code base.
- Elizabeth : training is very important, we should understand what people should be taught (also student who have only be exposed to Matlab). This should be part of the HEP sw collaboration (last talk)
Thorsten Kollegger : GPU in Alice and elsewhere
- Vincenzo : you mention piping directly data to the GPU (bypassing the CPU), but the data should be prepared first right ? Yes, but in our case the cluster finding is done before by FPGA so the data is ready to be used.
- DavidR : is the output a full fledge track ready to be used ? Thorsten : the GPU output is the final track fit, which only needs to be cast into a proper C++ object.
- ? : you say GPU is less expensive but by how much ? Thorsten : need 3 times less core, calculation to be done
- Vincenzo : could think of making the algorithm generic, and only rewrite memory management.
- Thorsten : use generic library might not give the full performance but is much more manageable for maintenance
Nick Styles : high lumi tracking in Atlas and elsewhere
- Elizabeth : for FTK, you mention speed but what about fakes and efficiency. Nick: indeed fakes is an issue, but manageable. Markus : effi of FTK is worse but OK for phase 1 upgrade. Not tested yet with phase 2 (=HL-LHC)
- Vincenzo : why FPGA rather than GPU ? Hans: latency, 1 track per ns is the number to keep in mind.
Ian Bird : HEP software collaboration
- Andreas Salzburger : we should ask ourselves why was simulation (Geant) is common since a long time but not reconstruction ?
- Elizabeth : do you propose a common framework or common algorithms ? Common algorithms more difficult because very detector dependent. Federico : should definitely start with the framework. DavidR : what about a common toolkit used by different algorithms ? (given the success of fastJet) E.g. track extrapolation and fitting. Vincenzo : kalman filtering is just 40 lines.
All : definitely we need a place to discuss such things.