1. User feedback on SAN Alan Barr
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 …
Overwhelmingly the feedback is very positive!
Analysis Model Forum
1st June 2007

2. 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”

3. 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!

4. 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

5. 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

6. 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!

7. 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

8. Conclusions Excellent ease of installation and use.
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