################################################################
#
# "Analysis on the Grid"
# Panel Members: Roger Barlow, Giuliano Castelli,
# David Grellscheid, Mike Kenyon, Gennady Kuznetsov, Steve Lloyd,
# Andrew McNab, Caitriana Nicholson, James Werner.
# [notes recorded by: Giuseppe Mazza]
#
################################################################
----------------------------------------------------------------
#
# ToC
#
1] VOs do not want to contact each site; VOs shoud provide a list
   of requirements
2] Certificate management must be improved
3] Data management is quite difficult
4] Monitoring real file transfers
----------------------------------------------------------------
#
# Comments for each point considered above
#
1]
- We need a contact for each Tier2: for example we got Olivier
  and David in London.
- VO contacts do not complain in the weekly operation meeting (EGEE)
2]
- PhenoGrid: Each user has is own data set. Problem was in the submission tools.
  The VOMS transistion was not easy since the voms was storing the ca dn.
  Only 11 sites have now pheno enabled
- There were some problems with CAs upgrade at some sites.
3] 
- For example PANDA case is quite tricky: PANDA submits jobs at
  Brookhaven. It is difficult the file transfer between Brookhaven
  and Queen Mary (London). So computational and storage resources
  can not be fully used.
  Atlas data management is difficult. Trying to import data from brookhaven 
  but the catalog is not always consistant. Lack of disk space at RAL. Atlas data model based 
  on datasets which is hirachical and the middleware does not support it for the moment. 
  Getting the data somewhere is the problem. 
- It is important to have a well defined site where you can find
  the data whick you can do the analysis on.
- The command line interface has still got some quirks
- LHCB: Problem with FTS. Dirac is a complex system, the problem is usually to develop
  new services. There should be a container system. That is a VO box ? No it is mainly 
  to have a library that provides monitoring/security features. Like java entreprise. 
  It would be useful to have a container, a software system...
  like a framework, which makes the approch more transparent.
  This would not be a VO box. It would be like a Java Enterprise
- BABAR: Trying to do the skimming on the Grid. Efficiency is not high enough on the Grid. 
  When the job fail is there enough information ? Not really.Finding out why things are not working
  at the application level is difficult. 
- ATLAS Glasgow: Using tag to do an analysis. Sometimes the RB hangs... but the most 
  difficult is to get the data at the sites. 
  Users do not look through the log files, but they submit the failed
  jobs again, as soon as they can.
- It is difficult to submit jobs, but if you can do it then you
  realize that 90% jobs are successfully submitted. There
  is a lack of sync between LFC and SEs. Moreover it would be nice
  to have webpages where users can find references to solve the
  common problems which you need to cope with when submitting jobs.
  More about "Distributed analysis in Grid"
  can be found at http://www.hep.man.ac.uk/u/jamwer/
  that is EASYGRID: Problem with the LFC being consistent. See paper. 
- PhenoGrid: If you have a lot of individuals like in the NGS (500 users and 50 projects). 
  then it is rather difficult to get them to use portals which are ment to make the life easy
4]
- LHB is quite happy about file transfers
----------------------------------------------------------------
#
# Conclusion
#
-Data management is still a big issue
-Error reporting is not good enough. 

How do we report the issues with the middleware. Jeremy: There is the operation 
meeting. 
----------------------------------------------------------------
################################################################