1 / 7

AliRoot survey: General suggestions

AliRoot survey: General suggestions. P.Hristov 11/06/2013. Comments & suggestions. In the perspective of the ALICE upgrades, I am wondering about the retro-compatibility of our whole software framework : say, imagine in 2023, one would like to analyze 2011 data.

helki
Download Presentation

AliRoot survey: General suggestions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. AliRoot survey:General suggestions P.Hristov 11/06/2013

  2. Comments & suggestions • In the perspective of the ALICE upgrades, I am wondering about the retro-compatibility of our whole software framework : say, imagine in 2023, one would like to analyze 2011 data. • The documentation should be as up-to-date as possible • Please, improve the overall documentation ofAliRoot, in all possible levels. • better online documentation of ALIROOT • Better debugging tools

  3. Comments & suggestions • As a more general comment, the communication between the analysis framework developers and the users could be improved: when new functionalities of the framework are put in place they "reach" the final users quite late or only upon explicit question. • The documentations related to Analysis need to be organized properly. They are scattered over twiki, if it is possible there should be common up-to-date help pages (like track selections, AOD info, PID info, basic info about MC/Kine etc...) for Analysis in one place. Which would help to new user, also for advanced user to find out few info easily. • Proper training of (detector) developers should be organized on technologies to be used in the years to come : • HLT • parallelization (multi-threading, vectorization) • AliRoot and AliEn user manuals with working examples (à la Root) • The ALICE offline webpage at http://aliweb.cern.ch/Offline/ is outdated and full of old information. This makes it impossible to find any useful information there.

  4. Comments & suggestions • Robust benchmarking is necessary, to tag revisions of higher quality and reliability. Preparation of productions must be made simpler, by modularizing it and documenting it better, including the commit of the files effectively used. The templates must be simpler and documented. One could consider also benchmarking of the analysis performance. Remark: compliments for the LEGO trains. • QA standardization Standard "expert" QA Performance benchmark standardization Common repositories -standard place to find the information Too much time wasted for something what should be automatically available. • We have lots of code duplication between ESD and AOD, and recurrent problems because of similar-but-not-identical behaviour of AOD and ESD functions. How about storing subset of ESD rather than AOD. Launch a study!

  5. Comments & suggestions • 1) Overall memory consumption of aliroot is too high and the speed is too low. A simple example: event generators can generate 1e+9 events per day, but once they are interfaced to AliGenerator, at maximum 1e+6 events can be generated. Use of TClonesArray kills the performance. • 2) Another example: digitization of TPC takes about 80% of simulation (I know that the number of channels is large, but maybe noise generation can be simplified or parallelized. • 3) Config.C is not well documented and changes too often from release to release. • 4) AliEn is almost completely undocumented, most of documented commands do not work anymore. For example, a command ps does not work, master job works only for a half of documented options. • 5) CAF is not reliable and requires too often intervention of sysadmins.

  6. Complains • Re: analysis lists: There is one individual who replies to me virtually every time I write a message to the list without having actually read what I wrote. He always claims I made a stupid mistake in an obnoxious tone and it takes an enormous amount of time to refute him. If I don't refute him, everyone assumes that, yes, I did something stupid. Basically to get him to shut up, it takes someone else (male) chiming in and seconding what I've said. He's done this to others, mostly women. I'm not really sure if he's sexist or an equal opportunity arrogant jerk who just happens to find women easier prey, but either way it's counter productive and harmful to the experiment. This has gotten so bad that I now don't use the mailing lists because even if I have a simple issue I don't want to spend a couple days documenting publicly that I haven't, in fact, done a beginning grad student level mistake. It's insulting and demeaning and counter productive. Someone needs to police the lists so that the rest of us can get some work done.

  7. Proposed questions • Do you have gained any experience/ come to know practice from other HEP collaborations in terms of data processing, QA, analysis, simulations... that could be considered in ALICE ? • Do you see the need of standardized testing/benchmarking of root/aliroot using data/MC?

More Related