80 likes | 177 Views
Overwhelmingly the feedback is very positive!. User feedback on SAN. Summary of collected experiences of several groups and individuals including: Bruckman, Brandt (Oxford) Polesello (Pavia) Lefebvre (Victoria) Casadei (NYU)
E N D
Overwhelmingly the feedback is very positive! User feedback on SAN • Summary of collected experiences of several groups and individuals including: • Bruckman, Brandt (Oxford) • Polesello (Pavia) • Lefebvre (Victoria) • Casadei (NYU) • Small group of early adopters so far (“new technology”) … but … Alan Barr Analysis Model Forum 1st June 2007
Typical comments “I found it easy to follow and modify the setup” “In development I can modify, compile and run a small job in less than 2 minutes” “Interface is very similar to Athena so should be easy to port” “Speed and simplicity of analysis program very useful for trying out different options ” “Convenient access to data using the standard methods as for the AOD EDM, code much simpler and neat than for flat AANT ” “Trivial to browse with ROOT” “Added my own variables easily” “My SANs were used by others in my analysis group” “Analysis on a laptop as I hoped it to be”
Why are people using SAN? • Typical responses: • “If these had not existed I would have had to have written them myself” • “I’d already written something similar/not quite as good myself, but happily migrated to the common/central SAN format when it became available” Generally users were people previously doing physics analysis on custom AANTs • Advantages over custom AANT • Standardisation eases collaboration • E.g. SANs produced by Oxford then used by Giacomo • “Central” help in migrating between releases • Thanks to Ketevi • Interfaces “look and feel” like Athena EDM • Easy to port code into Athena for more complex analysis on AOD/ESD Clearly needed!
What we like about SAN • Common themes: • No extra Athena dependencies during analysis stage • Fast analysis code development • Fast initialisation at run-time • Fast learning curve • Fast IO • Lightweight • Didn’t try to “do the analysis for me” • Easily configurable from UserAnalysis • Can add my own data types/objects easily “In development I can modify, compile and run a small job in less than 2 minutes” Lefebvre Any future development must retain these basic required features if it is to be successful
Relationship with Athena analysis • Desire to have a “simple” DPD does not mean the user is poorly-informed/low-level/dumb • DPD is accessible to new people • Users know Athena analysis is necessary for complex tasks • Still, almost everyone chooses to use some form of non-athena ntuple for routine stage of analysis • Based on simplicity/speed/convenience/turn-around as per previous page • The roles of DPD and Athena/AOD analysis are different • The SAN is an excellent format for DPD
Future for SAN • It is important that SAN or something very much like SAN is available in to the future • Users want a lightweight DPD • If it isn’t kept, then multiple clones will develop • SAN is sufficiently new that many custom AANT users have not even yet had a chance to try it • I’m confident they will like it if/when they do • “Killing” the current official DPD would add to feeling that the ground is always moving under user’s feet It would seem sensible to support SAN at least until pAOD is tried, used, proven & tested KEEP SAN FOR RELEASE 13!
Features of any successor • It is important that any successor dose not lose the good features of SAN • ROOT ntuple • browsing • Common basic class structure • collaboration/transparency • Independent from heavy weight EDM dependencies • speed • “Look and feel” of EDM interfaces • portability • Customisation to allow easy skimming/slimming/thinning as well as addition of custom variables • Flexibility • Reduce disk space
Conclusions Giacomo’s conclusions ring true: • Excellent ease of installation and use. • Great improvement in power with respect to AANT, while having an extremely compact and lightweight distribution, and great ease in program development and debugging. For me this lightness is a key feature which should be retained by any alternative. • Excellent format for writing out DPD/private ntuples for final analysis. If not supported I would seriously consider developing a private ntuple format based on the same principles. • Less powerful than AOD, even in simple analysis I bumped into things I could not do, but things like e.g. extrapolation obviously only available inside Athena, so for root-level analysis this kind of work should be done at AOD level and the results written out to DPD. Keep SANs at least until pAODs are proven! For more on individual experiences see TWiki: FeedbackOnSAN