1

User feedback on SAN Alan Barr

1st June 2007Analysis Model Forum

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!

2

Typical comments“I found it easy to follow and modify the setup”“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”

“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”

“Interface is very similar to Athena so should be easy to port”

“Trivial to browse with ROOT”“Trivial to browse with ROOT”

“Convenient access to data using the standard methods as for the AOD EDM, code much simpler and neat than for flat AANT ”

“Convenient access to data using the standard methods as for the AOD EDM, code much simpler and neat than for flat AANT ”

“Speed and simplicity of analysis program very useful for trying out different options ”

“Speed and simplicity of analysis program very useful for trying out different options ”

“Added my own variables easily”“Added my own variables easily”

“My SANs were used by others in my analysis group”

“My SANs were used by others in my analysis group”“Analysis on a laptop as

I hoped it to be”

“Analysis on a laptop as I hoped it to be”

3

Why are people using SAN?

• Typical responses:

1. “If these had not existed I would have had to have written them myself”

2. “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!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

Any future development must retain these basic required features if it is to be successful

Any future development must retain these basic required features if it is to be successful

“In development I can modify, compile and run a small job in less than 2 minutes” Lefebvre

“In development I can modify, compile and run a small job in less than 2 minutes” Lefebvre

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 future1. Users want a lightweight DPD

2. If it isn’t kept, then multiple clones will develop

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

4. “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 & testedKEEP SAN FOR RELEASE 13!

It would seem sensible to support SAN at least until pAOD is tried, used, proven & testedKEEP 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.

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

Giacomo’s conclusions ring true:

For more on individual experiences see TWiki: FeedbackOnSAN For more on individual experiences see TWiki: FeedbackOnSAN

Keep SANs at least until pAODs are proven!