1 / 73

Answers to the ROOT Users' Survey John Harvey CERN/PH/SFT 15 th – 18 th September 2015 Saas Fee

Answers to the ROOT Users' Survey John Harvey CERN/PH/SFT 15 th – 18 th September 2015 Saas Fee. Disclaimer. These slides contain an unfiltered summary of the feedback some of it is brutally frank ( ‘ …….. is awful) User comments range from quite general …

Télécharger la présentation

Answers to the ROOT Users' Survey John Harvey CERN/PH/SFT 15 th – 18 th September 2015 Saas Fee

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. Answers to the ROOT Users' SurveyJohn Harvey CERN/PH/SFT15th – 18th September 2015Saas Fee

  2. Disclaimer • These slides contain an unfiltered summary of the feedback • some of it is brutally frank (‘…….. is awful) • User comments range from quite general … • (‘improve the documentation’, ‘I would like to know how to use a debugger with Root’) … to quite technical • * API * object data export (as csv export for TGraph, TH1F, ...) * compatibility with std * fast way to process TTree: support to lambda function for TTree::Draw * support for reduce functions tree->sum("myvar", "myselection"), tree->reduce(function, "myvar", "myselection") * support for reduce function in TTreeDraw as tree->Draw("y:x", "selection", compute_mean). In this case it is equivalent to the present option "prof". • Need your input on • what are the most relevant comments to focus on • what response the users can expect

  3. Sections of the survey • Background of users • Communication within community including developers • How you use ROOT • PROOF • Learning to use ROOT • Areas would you like to see improved

  4. Background of Users

  5. Total number of Responses is 353 • 99% of users are physicists • 94% in HEP, 2% Nuclear Physics, 1% Computer science • Experience: <2y : 4% 2-5y : 28% 5-10y: 37% >10y : 30% • Frequency of use: every day 73%; several times/week 25% June 16 June 25 July 24 Aug 5

  6. Research Programme/Experiment CERN ATLAS(18), LHCb(3), CMS(3), ALICE(3), COMPASS(2), CLIC(1) Tevatron CDF(3), DZERO(4) Neutrinos DUNE(1), NOvA(1), MINOS(2), IceCube(2), T2K(2),JUNO(1) B-Physics BaBar (8), Belle1/II (12), Super-B(2), KEDR(1) DESY H1(1), Zeus(1) RHIC STAR(1) GSI/FAIR CBM(2), PANDA(1) Astrophysics Fermi(3), Fermi-LAT(4), Fermi-HAWC(1),   INTEGRAL(1), HESS(1), MAGIC(1), POLAR(1), CDMS(2) Software Geant4(1)

  7. Why do you use ROOT? I’m obliged It’s free I don’t know other tools ROOT is the best Other

  8. Which languages do you know?

  9. Which ROOT version do you use Master (head) 6.04 6.02 5.34 5.32 Expt. provided Other

  10. Which platforms do you like to use

  11. How did you install ROOT? download from ROOT website built from source

  12. Communication within community including developers

  13. Contact methods ROOT forum Jira roottalk@cern.ch rootdev@cern.ch in person direct email Other

  14. Are you happy with support? • nearly half of users are not using the forum or interacting with developers • ~ one half of the rest are fully satisfied, with most of the remainder partially satisfied • speed of response is perhaps one thing to focus on

  15. Comments on support • Improve the documentation! RooStats mentioned explicitly. • I wish tutorials were kept up-to-date and were more relevant to my needs • RooFit forum is a desert; ~no support • Having reproducible bugs open ‘for years’ is common • Sometimes need to spend ages explaining problem, whereas fix is very quick • Sometimes I’m not sure what to post where. • Some questions left completely unanswered • I often get “that’s the way it is – live with it” – surprising! • It can take very long from bug reports to fixes • Usually I find answer to my problem on forum (many agree) • I use it a lot but ~never need to post questions

  16. How you use ROOT

  17. Which Interfaces?

  18. Histogramming & Data Analysis Classes

  19. Histogramming & Data Analysis Classes

  20. Fitting interfaces • lessons learnt from this are …?

  21. Fitting algorithms • lessons learnt from this are …?

  22. RooFit and TMVA

  23. Which TMVA Methods do you use?

  24. What features do you miss in RooFit, TMVA? • RooFit documentation – mentioned several times! • Code examples that could be reused, tutorial like RooStats • Set of user guides, starting from basic, getting more sophisticated • When I need something that is missing I write it myself and incorporate it into an analysis level package. • e.g. data combination software like: http://blue.hepforge.org/ • TMVA good in general, but most algorithms train (and evaluate) so slow, that it becomes impractical for testing • No, there's way too much stuff in Root already, and plenty of other statistical packages that do the same thing. ROOT should focus on solid core functionality and interfacing with these other packages rather than reinventing the wheel.

  25. ..and there are plenty of specific suggestions… Deep neural networks (YAML, ..) Deep learning, TMVA only implements archaic techniques Need convenient tools for calculating p-values, limits. Existing tools either not documented well or are statistically incorrect. Miss tools to split likelihood minimization across machines TMVA: make possible different cuts for training/testing TMVA: Support for Cross-Validation, Grid-Search of Hyperparameters More flexibility in the TTree manipulation TFractionFitter with weighted events Genetic algorithms (e.g. NEAT) ……

  26. ….and more…. In some ROOT installation/distribution TMVA or RooFit are not included. HistFactory should provide by default a possibility to use parametric modelling, …. RooFit: Wavelets i.e. "fourier" in both frequency & position Can we have variable list and editor back in the same window in TBrowser, please? Random forests TMVA: Support for Cross-Validation, Grid-Search of Hyperparameters (OptimizeAllMethods does not work properly for me) TCLs - should exist! Multi-dimensional target using Boosted Regression Tree

  27. Graphics

  28. Graphics Producing publication ready plots

  29. GUI, Event Display

  30. I / O

  31. Trees Analysis

  32. Trees Analysis

  33. Usability of interfaces

  34. PyRoot Performance / need for PyPy

  35. Editing Features

  36. How do you debug?

  37. Interactivity: what would increase your productivity most?

  38. PROOF

  39. PROOF:selector

  40. PROOF: miscelanea

  41. General comments about PROOF • PROOF has a very steep learning curve and I would like to see improved tutorials focused on PROOF-lite. • Used it, but difficult to maintain and debug • Some failures produce no error message • PROOF seems very, very buggy and unstable. • Never managed to get it running in compiled code, without using CINT; stopped using it. • Great, but PoD needs more support or updates, or its successor needs to come out soon. • it would be nice if I could setup and start the jobs on my own, and only use PROOF to schedule which events get run on which node and to manage the I/O • Most of the tasks I'm working on are trivial parallel, no need for PROOF

  42. Learning to use ROOT

  43. How did you start with ROOT?

  44. How do you learn more about ROOT now?

  45. How would you like to learn more?

  46. Which areas would you like to see improved

  47. Language features • I think more fully embracing modern C++ styles is necessary to keep ROOT relevant in the future. Likely compability-breaking changes are necessary to shed our "C with Classes" style. • Proper compatibility with modern compiler features like templates (2x) • Removal of the need to write dictionary files (at least by hand), especially when working with python and C++ templates • Things like the micro-languages for histogram drawing (using strings of letters instead of proper arguments) have no place in modern C++ code • ROOT unnecessarily wraps a lot of features that are part of C++ (e.g. maths libraries) when it would be better to leverage the existing features which are already industry-hardened • I think that instead of aiming to provide everything itself, ROOT should at most wrap external libraries to standardise their interface. • Consistent naming of functionality. Why should some accessors start with Get and others not?

  48. Language features Use standard c++. Physicists can handle concepts like templates, so they shouldn't be hidden just because they can be confusing. Plus, this enables users to utilize more standard help sources (ie. I can find help on standard algorithms all over the web, but I can find root help in only a few places) The class hierarchy, especially for objects like histograms, is still very frustrating. Building standalone applications and not having to rely so much on CINT has become much easier over the years, and I would very much like to see this continue. Basically, I want to be able to use ROOT classes as easily as I would any STL class. Namespaces, support for multi-threading I would like to see memory management improved, which I recognize is no small feat. Memory management - many times I had to debug segmentation faults, because of unintuitive behaviour of ROOT garbage collector Memory management - never obvious what who owns the object, especially in standalone app which deals with many ROOT files.

  49. Code structure • I would like to see it broken apart into many smaller libraries, so that other codes could depend only on the tiny, tiny part of ROOT that they actually use -- and then work on removing that dependency. • “Improve code design. Simple things like using template classes instead of having inheritence from TH1 for example. Using namespaces …and getting rid of silly aspects due to bad use of inheritance • it makes no sense for a TH1F to have a z axis for example. “ • Desire for backward compatibility has hampered the development of ROOT in some areas. Whilst this is essential for data storage in ROOT formats, for analysis code it could be argued that some changes or deprecation of old functions would be manageable changes that could improve the framework overall. • “Compatibility" with PAW mentioned earlier is not necessary - maintaining the ability to convert a PAW file into a ROOT file is important, but other "compatibility" issues, where they can be decoupled from a purely file storage standpoint, should no longer be a design principle for ROOT development. • I have not yet used ROOT 6 much, but I am finding the changes in the C interpreter interesting, I am in favour of the stricter interpretation of the code in the interpreter, and my initial impression is that this is a positive step.

  50. Error Handling It would be good if root didn't always just blow up and show memory maps and incomprehensible stack traces. Decent error handling would make life phenomenally easier for everybody. “Most important: Better recovery from errors. Some ROOT crashes are such that the computer is paralyzed for a few minutes, until eventually the shell is lost.”

More Related