[Sbs_gems] Fwd: [EXTERNAL] Upper limits in terms of beam current for the GEM study planned for tomorrow

[Sean Jeffas]

Hi Arun,

I think this is the response you are looking for from Nilanga. I think he
forgot to include you when he sent it.

Best,
Sean

---------- Forwarded message ---------
From: Liyanage, Nilanga K (nl8n) <nl8n at virginia.edu>
Date: Sun, Feb 6, 2022 at 3:12 PM
Subject: Re: [Sbs_gems] [EXTERNAL] Upper limits in terms of beam current
for the GEM study planned for tomorrow
To: Holly Szumila-Vance <hszumila at jlab.org>, Rathnayake, Anuruddha (adr4zs)
<adr4zs at virginia.edu>
Cc: Sbs_gems at jlab.org <Sbs_gems at jlab.org>


Dear All

My objectives for the high current study are to learn about challenges in
high occupancy running such as pileups in both time and space,  two signals
on the same strip separated by a short time) and two  hits on nearby strips
causing the clusters to merge. Even if we solve all hardware problems like
gain drop, we are sure to be limited by the occupancy issues in GEp.

Like Kondo said the highest beam current we can take will be limited by the
1 mA limit on the GEM power supplies. The baseline GEM current is about 735
uA, and we are running around 780 uA now  (with 5 uA of beam current on
LH2) ;  this is about 45 uA excess current in GEM. Given this  we should be
able to go five  times higher or more in beam current before we hit this
limit.

So I would like to try to go up to 25 uA on LH2 and also on LD2, if we can
get those beam currents.

We can do this in a few steps, say 5 uA steps in beam current. All we need
are short runs, say 10 min at each setting

I agree with Alex that it is best to take these without zero suppression.

As Kondo suggested, at each setting we can first take a run with only one
UV chamber turned on. After that run, if things look OK, turn the rest of
the GEMs and take another run, and then repeat this procedure at the rest
of the beam currents.

If we only take  the high current runs with only one chamber on, and not
take the tracking runs with the other chambers on, then there is nothing we
can learn about pileup and this exercise would not be very useful.

So we must take tracking data to as high beam current as we can

Best

Nilanga

Arun: Given accelerator limits and Hall C running, how much maximum beam
current can we take ?



------------------------------
*From:* Sbs_gems <sbs_gems-bounces at jlab.org> on behalf of Holly
Szumila-Vance <hszumila at jlab.org>
*Sent:* Sunday, February 6, 2022 10:45 AM
*To:* Rathnayake, Anuruddha (adr4zs) <adr4zs at virginia.edu>
*Cc:* Sbs_gems at jlab.org <Sbs_gems at jlab.org>; Arun Tadepalli <arunts at jlab.org
>
*Subject:* Re: [Sbs_gems] [EXTERNAL] Upper limits in terms of beam current
for the GEM study planned for tomorrow

To be clear, the question is what current limits are we willing to test up
to for the gem test tomorrow on swing- probably a question for Nilanga
and/or Kondo. I think this is for coordination with MCC purposes.

On Feb 6, 2022, at 9:52 AM, Anuruddha Rathnayake <adr4zs at virginia.edu>
wrote:


Dear All,

There is a discussion going on between our current RC (Arun) and some of us
here in Jlab about what would be the beam current limits that we should
adhere to, if it is possible to come into such a limit looking at the
observations we have made so far.

I'm attaching the GEM linearity studies we have done so far, if that helps
to make a decision. https://logbooks.jlab.org/entry/3932489

I believe if you use linearity studies done at SBS-11, that would be the
best as our current spectrometer angles at SBS-9 are similar to what we had
at SBS-9 (Please correct me if I am wrong, I know this more of as a word of
mouth rather than referring to any official documentation).

Best,
Anu

_______________________________________________
Sbs_gems mailing list
Sbs_gems at jlab.org
https://mailman.jlab.org/mailman/listinfo/sbs_gems

_______________________________________________
Sbs_gems mailing list
Sbs_gems at jlab.org
https://mailman.jlab.org/mailman/listinfo/sbs_gems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/sbs_gems/attachments/20220207/3198de29/attachment.html>