<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
from Graham ...<br>
<br>
<div><br>
<div>Begin forwarded message:</div>
<br>
<blockquote type="cite"><br>
  <div style="margin: 0px;"><span
 style="font-family: 'Helvetica'; font-size: medium;"><b>From: </b></span><span
 style="font-family: 'Helvetica'; font-size: medium;">Heyes Graham <<a
 moz-do-not-send="true" href="mailto:heyes@jlab.org">heyes@jlab.org</a>><br>
  </span></div>
  <div style="margin: 0px;"><span
 style="font-family: 'Helvetica'; font-size: medium;"><b>Date: </b></span><span
 style="font-family: 'Helvetica'; font-size: medium;">May 17, 2010
7:35:36 am EDT<br>
  </span></div>
  <div style="margin: 0px;"><span
 style="font-family: 'Helvetica'; font-size: medium;"><b>To: </b></span><span
 style="font-family: 'Helvetica'; font-size: medium;">Richard Jones <<a
 moz-do-not-send="true" href="mailto:richard.t.jones@uconn.edu">richard.t.jones@uconn.edu</a>><br>
  </span></div>
  <div style="margin: 0px;"><span
 style="font-family: 'Helvetica'; font-size: medium;"><b>Cc: </b></span><span
 style="font-family: 'Helvetica'; font-size: medium;">Chip Watson <<a
 moz-do-not-send="true" href="mailto:watson@jlab.org">watson@jlab.org</a>>,
"Mark M. Ito" <<a moz-do-not-send="true" href="mailto:marki@jlab.org">marki@jlab.org</a>>,
"halld-off >> HallD Software Group" <<a moz-do-not-send="true"
 href="mailto:halld-offline@jlab.org">halld-offline@jlab.org</a>><br>
  </span></div>
  <div style="margin: 0px;"><span
 style="font-family: 'Helvetica'; font-size: medium;"><b>Subject: </b></span><span
 style="font-family: 'Helvetica'; font-size: medium;"><b>Re:
[Halld-offline] Offline computing plan for JLab Physics, FY10</b><br>
  </span></div>
  <br>
  <br>
  <div style="">Richard, Chip et al, 
  <div><span class="Apple-tab-span" style="white-space: pre;"> </span>healthy
discussion was the whole point in putting the document out there. As I
wrote to Chip earlier it is very much a first pass that was written
last fall as both a snapshot of the status of the system, our current
thinking and the understanding of requirements at the time of writing.
Next week there will be a CLAS12 workshop at Richmond where, I hope,
more of their requirements will be fleshed out. I expect/hope that the
same will happen with GLUEX.</div>
  <div><br>
  </div>
  <div>We have discussed the SRM and similar tools at great length in
various offline related meetings here and it always comes down to cost
effectiveness. As Chip pointed out Grid tools require more manpower to
develop, implement and maintain than we have had available.</div>
  <div><br>
  </div>
  <div>Regards to all,</div>
  <div><span class="Apple-tab-span" style="white-space: pre;"> </span>Graham</div>
  <div><br>
  </div>
  <div><br>
  <div>
  <div>On May 15, 2010, at 2:27 pm, Richard Jones wrote:</div>
  <br class="Apple-interchange-newline">
  <blockquote type="cite">
    <div text="#000000" bgcolor="#ffffff">Chip,<br>
    <br>
I fully agree with this requirements-driven approach.  It is the way we
achieve and justify designs of experimental apparatus.<br>
    <br>
This message from me that you responded to was following up on a
discussion that took place during the collaboration meeting earlier
this week, where I brought up the concern that offsite access to data
at Jlab is (in my experience as a user) antequated and laborious.  My
concern was that our own (GlueX) offline computing plan has not clearly
articulated our requirements for ease of offsite access to data at
Jlab, and that if we do not write it in black and white in our
requirements, it does no good for us to ASSUME that it is just going to
happen automatically.  If it is not written in the requirements, we
have no grounds to expect it to be there.<br>
    <br>
Over the past decade we have read in CC documentation that the SRM tool
would be coming soon to meet this need.  However we have learned
recently that support at the laboratory for offsite SRM access to MSS
has atrophied.  No doubt this is the result of strain on existing
resources and lack of a clear message from users that this capability
is needed.  I asked Sandy why support for SRM is going away, with GlueX
depending on it, and she pointed out that there is no mention of it in
our offline computing plan. Touche.<br>
    <br>
With these cost estimates in mind as ballpark figures, we are better
able to have this conversation as a collaboration and flesh out what
our requirements are for offsite access.<br>
    <br>
-Richard J.<br>
    <br>
    <blockquote type="cite" cite="mid:4BEEC005.2030000@jlab.org">Richard,<br>
      <br>
The cost of the items you are recommending is significant:<br>
      <br>
1.  The cost of developing location-independent access to MSS files is
probably an additional $100K above current capabilities, perhaps as
much as twice that depending upon details of requirements.<br>
      <br>
2.  The cost of storage is independent of where the work is done -- the
full requirements are meant to be in the 12 GeV Computing Plan, and if
you don't believe the requirements are correctly captured, please work
with Graham Heyes to correct that.<br>
      <br>
3.  The cost of maintaining such a full computational grid capability
is approximately $180K per year for staff, plus some modest hardware
costs for appropriately provisioned gateways, depending upon detailed
requirements.  (And if tier-N sites were to appear, they would also
require grid administrative overhead beyond JLab's costs.)<br>
      <br>
Jefferson Lab is committed to satisfying the requirements for 12 GeV,
but does not start a priori with an assumption of a multi-tiered grid
-- that is an implementation choice, not a requirement.  There are a
number of political and scientific reasons why LHC made that choice,
many of which are not valid for Jefferson Lab.  The current 12 GeV
requirements do not drive us toward a computational grid solution, and
so the laboratory has as its working plan a much more cost effective
mostly centralized solution.  Of course if the requirements are not
correct, the solution may not be correct, but any significant change in
the scale of the requirements will have to compete for funds with
detector enhancements, accelerator operations, and many other costs. 
Offline computing is not part of the construction project, but only the
operations budget.<br>
      <br>
I began the process of requirements collection so that Jefferson Lab
could move in the direction of a requirements driven solution, with
sufficient lead time so that it would not be left until the end and
thus under provisioned.  HEP has a history of long lead time
activities, with LHC being a premier example.  Bear in mind, however,
that our requirements are much less than 1% of LHC's, and our budget is
correspondingly much smaller.<br>
      <br>
regards,<br>
Chip<br>
      <br>
      <br>
Richard Jones wrote:
      <blockquote type="cite" cite="mid:4BEEB635.9020203@uconn.edu">Offline
folks,<br>
        <br>
One thing stands out to me in reading through this plan is the lack of
any accommodation for the  interaction between the Jlab computer center
and computing facilities at user institutions.  For comparison, it is
helpful to look at the computing plan for any of the LHC experiments,
where the plan is oriented around distribution and global access to
data and computing resources.  Things that I would like to see in the
Gluex Offline Computing Plan that eventually get propagated through
appropriate channels to someone like Graham Hayes are the following:<br>
        <ol>
          <li>Location-independent mechanisms for remote access to MSS
files
(with appropriate authentication/authorization) without logging in on a
Jlab machine over ssh, both reading and writing.</li>
          <li>Provision for allocation of space on MSS for archival of
intermediate data sets generated off-site, eg. MonteCarlo and final
data samples used in a PWA that was the basis of a particular
publication.</li>
          <li>Support of grid protocols for transparent scheduling and
migration of jobs across available resources within the collaboration,
so that when a particular resource is overbooked jobs can flow across
site boundaries to where resources are available.</li>
        </ol>
-Richard Jones<br>
        <br>
      </blockquote>
    </blockquote>
    </div>
  </blockquote>
  </div>
  <br>
  </div>
  </div>
  <br>
  <br>
</blockquote>
</div>
<br>
<br>
<pre class="moz-signature" cols="72">-- 

------------------------------------------------------------------------
 David Lawrence Ph.D.
 Staff Scientist                 Office: (757)269-5567   [[[  [   [ [       
 Jefferson Lab                   Pager:  (757)584-5567   [  [ [ [ [ [   
 <a class="moz-txt-link-freetext" href="http://www.jlab.org/~davidl">http://www.jlab.org/~davidl</a>     <a class="moz-txt-link-abbreviated" href="mailto:davidl@jlab.org">davidl@jlab.org</a>         [[[  [[ [[ [[[
------------------------------------------------------------------------

</pre>
<br>
</body>
</html>