Atlas-connect-l mailing list

[Rob Gardner <rwg AT hep.uchicago.edu>]

Yongsheng, 

We had problems with the storage system yesterday, which also took down some other services.  So this morning we are scrambling a bit to recover from that, and I’d expect login.usatlas.org to be little unstable until later today.  

A question arose about altas-connect-l.  Should it be for admins, or users.  Since we’re not “open for business” for the casual user, lets continue to use this for both admin purposes, and testing. 

I think its important for us to understand how far this approach can go in bringing resources to US ATLAS users, what its limitations are, what might be good about it.  For the Arizona meeting, any testing we can do in advance I think would be the most effective thing we can do.   

To that end, we need some solid but progressively more realistic user analysis examples.  We need to set boundaries of what can be done on AtlasConnect in order to set expectations.   We do not have the effort to support the wild west of every use case imaginable, especially since this is a distributed computing environment, not a local cluster.  So I believe we need to be build a “bank” of well-tested programs that we know just work.  A toy Monte Carlo would be an excellent start.  Or a cpu-intensive fitting program.   Blessed examples that we can train our support staff to run for themselves and catch problems before users do.  I would prefer to restrict what can be done, but what is permitted is very reliable.  

(Side note: forget AAA — Any data, Anytime, Anywhere… that is just science fiction, especially with ROOT as we know it.)

We need to lay this down as a philosophy from the start.  So we need good examples and good testing and we need to profile some simple job types:

cpu only

cpu with minimal input and output data requirements

cpu with heavy input but minimal output 

cpu with both heavy input and output

Is the data local to the cpu? 

Do we define cpu-data “zones”, and restrict (or advise or broker or advertise) appropriately?  

Which data are important to “take home”, and what is the best means to get it there?

How do we guarantee the infrastructure is always working.   

How do distinguish infrastructure from user problems?   This is the most important thing we can do the the users, our staff, and the support experts.

We are starting with a baby service.  It can’t walk through a full analysis chain.  We need to plan what it can do and when.

- Rob

On Dec 3, 2013, at 11:16 AM, Yongsheng Gao <yogao AT csufresno.edu> wrote:

Hi Rob and others,

Thanks for generating the ATLAS CONNECT mailing list. A reminder of our weekly ATLAS CONNECT phone meeting this Thursday at 9am Pacific time. Please let us know what you’d like to hear from CSU Fresno side and what to prepare for the Arizona workshop. The phone conference information is below (same as before):

1) Dial Toll-Free Number: 866-740-1260

2) Enter 7-digit access code: 4766859 followed by “#”

Best,

Yongsheng

Yongsheng Gao
Associate Professor
Department of Physics
California State University, Fresno
Email: yogao AT csufresno.edu
Phone: 559-278-4554
_______________________________________________
Atlas-connect-l mailing list
Atlas-connect-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/atlas-connect-l

---

Rob Gardner • Skype rwg773 • 312-804-0859 • University of Chicago