<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <br>
    Hi Graham.<br>
    <br>
    &nbsp;&nbsp;&nbsp; Certainly we should be able to put forward a set of
    requirements. I'd have to point out though that we are already
    developing expertise using certain GRID technologies between at
    least 4 of our universities (if I'm counting right). The thing that
    has me confused though is that this idea of it taking so much
    manpower to support it. I know of a certain collaborator in GlueX
    who, in addition to maintaining a full teaching schedule,
    maintaining his own computing farm, and heading a group responsible
    for one of our major detector systems in GlueX, has still managed to
    get his farm on the GRID and use it as well as other GRID resources
    for simulation studies. I can't imagine him spending more that
    15-20% of his time on this. Why do we expect it to take a JLab IT
    person (with a CS degree) to have to spend so much more time? I must
    be missing something.<br>
    <br>
    Regards,<br>
    -David<br>
    <br>
    On 2/15/11 3:09 PM, Heyes Graham wrote:
    <blockquote cite="mid:A47CCB00-E7A8-4E8D-AB76-9703381FBBA1@jlab.org"
      type="cite">Physics division does maintain quite a few packages
      but it is done by gentleman's agreement, i.e. nobody is explicitly
      paid to support ROOT etc. The issue with GRID is that it is big
      and ugly enough that you will have to pay out someone (probably
      more than one) to support GRID at the JLab end if we are anything
      other than a client on someone else's GRID implementation.
      <div><br>
      </div>
      <div>Without putting words in his mouth I think that is what Chip
        was talking about at the end of last week. We should write down
        what resources we (Physics in 12 GeV era) expect to have
        available to us offsite, what rates we need to those sites and
        other related parameters. Again, implementation neutral so not
        explicitly GRID. If it turns out that GRID is the best way to go
        then so be it. The perennial argument is that it isn't
        worthwhile to the lab to pay salaries and overhead for a couple
        of people to support something unless it gives the lab access to
        resources that are at least greater than you could buy with the
        same funds. So at least that argument needs to be fleshed out.
        What exactly is on the non-JLab end of such a "GIRD"?</div>
      <div><br>
      </div>
      <div>There'll probably be much discussion of this...</div>
      <div><br>
      </div>
      <div>Graham</div>
      <div><br>
        <div>
          <div>On Feb 15, 2011, at 2:53 pm, David Lawrence wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div bgcolor="#ffffff" text="#000000"> Hi Mark,<br>
              <br>
              &nbsp;&nbsp;&nbsp; This is a great start. I have one quick question: have
              we verified that the reconstruction rate for the 10^8 data
              is the same as the 10^7? Even though the event rate to
              disk will be the same, I can imagine the 10^8 data being
              busier and therefore, take longer to process. They are
              hopefully comparable, but we should verify it if it hasn't
              been already. <br>
              <br>
              &nbsp;&nbsp;&nbsp; I'd also like to follow up a little on the discussion
              started a while back on the how the GRID is to be included
              in the computing plan. It seems clear that our
              collaborators feel this will be an important part of the
              GlueX experiment's operation. Chip has indicated though
              that supporting it from the JLab side has significant
              resource costs and must be clearly justified. Has there
              been any discussion as to what exactly these costs are? I
              thought from earlier conversations that this was a
              manpower cost on the JLab side, but at this point, I don't
              know what is required. The Physics Division maintains
              several software packages already (ROOT, CERNLIB,
              Xerces,...) are there additional resources besides
              software maintenance? I know the our original CDR called
              for something like an OC24 connection due to the
              anticipated high bandwidth usage. Are there other hardware
              costs involved?<br>
              <br>
              &nbsp;&nbsp;&nbsp; We'll need to start gathering cost information as we
              develop the benefit argument in order to make a valid
              cost-benefit analysis.<br>
              <br>
              Regards,<br>
              -David<br>
              <font class="Apple-style-span" color="#000000"><font
                  class="Apple-style-span" color="#144fae"><br>
                </font></font></div>
          </blockquote>
        </div>
      </div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Halld-offline mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></pre>
    </blockquote>
  </body>
</html>