1. Survey on User’s Computing Experience
Artem Trunov
EKP

2. Consideration
Motivation: to improve user's experience with regard to access to data, running jobs…
Questions
Where do you run jobs?
How do you submit them?
How do ou manage grid submission to different sites?
Do you use CRAB? Is it convinient for you?
Where do you keep logs from the jobs?
If your jobs produce data, how to do you get it back?
Where do you store it?
How often do you have problems with grid jobs? What kind of problems?
Where do you seek help for grid problems?
Do you think you'd do a better/faster debugging of your problems if you had access to corresponding sites, etc? Would you really try to debug your jobs at this level?
Your ideal model of your work environment.
9 full answers, 2 general (from new entrants)

3. Where and how people run jobs
Grid is used by majority.
One person so far managed to only use local batch exclusively.
Clear preference to limit a number of sites where jobs run
CERN, FNAL are the choice for high avalability
DESY, Aachen, GridKa – as home or “friendly” sites, where the environment is familiar and people are willing to help
Black/white list and “edg-job-submit –r” is used to steer jobs to prefered sites.
CRAB is used by almost all, but some people also or exclusively use direct edg-job-submit through own automation scripts.
CRAB is not (and can not be) used by people running on unofficial datasets or producing own MC.
People use their local (institute) UI to submit jobs.

4. CRAB experience 6 – use it 3 - don’t use it 3 – like it
2 – report problems
3 - don’t use it
1 never used Grid
1 avoids using Grid and Crab for problems
1 need to run on official data

5. Logs and Data Personal logs – in the home dir
CRAB users keep them mostly where CRAB brings them – in a job dir.
Production logs – in dCache
Small data output – back to home
Big data output – copy to an SE
Local or friendly SE is preferable

6. Notes on storage
Individual opinions
Copying from a job to an SE presents a point of failure
Noticed that handling data grid way is not convenient and could be improved.
Prefer to analyze data locally at institute cluster to avoid grid problems. Wi

7. Grid Problems 70 – 80 – 90% efficiency Trouble points CRAB
4 Data or SW published but not available
Environment not correctly set
2 Problem with output to an SE
2 “Black holes”
3 RB problems updating job status, not matching sites, SEs, aborts jobs

8. Grid problem addressing
6 directly to site experts
1 CMS forums
4 GGUS
1 fix him/herself the system
1 fix him/herself a problem with own setup
2 could not resolve at all, don’t believe that problems could be solved 

9. Notes on Grid problems Simples grid job submission takes 5-10 minutes
Individual opinions
Simples grid job submission takes 5-10 minutes
Reporting properly (GGUS, Savannah) is too much work
Many problem are specific and time consuming
Many problems are transient, no one adresses those “usual” problems.
It’s accepted as “natural” that 70% of jobs fail.
Impossible to report every single problem – too many.

10. Opinions on access to site for debugging
5 believe in advantage debugging at a site
2 want access to at least one grid site
1 want access to worker nodes
1 want access to a portal machine(s)
4 doesn’t believe in advantage of debugging at a site

11. Ideal work environment
2 Prefered all grid
3 Prefered all non-grid
3 Prefered both, split tasks
1 workgroup servers (incl. UI)
4 local batch farm
3 local access to storage
Also
1 Proof
1 Better support
1 Better debugging options

12. My humble conclusions
Grid is difficult, and in some cases preventing people from successful work
However, most anyway believe in it and would use it if not completely, then partially.
Most would prefer to do analysis w/o the Grid
Generally, people would be happier with local access to our T2, T3 resources, where they would find:
Easy access to storage
Access to local batch farm
Debugging options