[Halld] Proposed intensity scan for Fall 2018

Mon Nov 19 16:48:40 EST 2018

Hi Justin,

Note also that at this high current we will have to reduce the HV in the drift chambers. I expect this will affect mostly the CDC tracking efficiency where we have less redundancy, compared to the FDC. 

Therefore, I propose to start with the highest current to set the HV in the drift chambers so that they can operate reliably. Then we can go down using the same HV setting.

Lubomir 

----- Original Message -----
From: "Justin Stevens" <jrsteven at jlab.org>
To: "Graham Heyes" <heyes at jlab.org>
Cc: "halld" <halld at jlab.org>
Sent: Monday, November 19, 2018 4:32:18 PM
Subject: Re: [Halld] Proposed intensity scan for Fall 2018

Thanks for the additional feedback.  I agree that, for simplicity, we can prescale the main trigger at the highest currents.  The spreadsheet is updated with a prescale factor for runs with current >= 400 nA.  

There was also a request to record some data with “Sergey’s version” of the DAQ software for comparison to the production data at these high intensities, which is added to the list as well.  

FYI, The total time required is now more than 34 hours at 100% efficiency (~3 days calendar time).

-Justin

> On Nov 19, 2018, at 2:09 PM, Graham Heyes <heyes at jlab.org> wrote:
> 
> Just to point out, the current DAQ software in production use is limited because it writes one file at a time to disk. We have tested running multiple files with speeds and stability comparable with “Sergey’s version”. Unfortunately we could not have beam for those tests. We identified a few things that we would like to fix but are very close to exceeding GLUEX requirements using the standard software.
> 
> 	Regards,
> 		Graham
> 
>> On Nov 19, 2018, at 1:50 pm, Eugene Chudakov <gen at jlab.org> wrote:
>> 
>> Let me remind you that with the currently used DAQ software we would
>> be limited to about 1GB/s, or about 400nA without prescaling (or somewhat
>> lower for reliable operations).
>> 
>> The front-end limit would be about 80kHz, or also 400nA.
>> 
>> We may try to use a new DAQ software (the Sergey's version), which can go
>> to >2GB/s. The front-end limits would still apply.
>> 
>> Eugene
>> 
>> On Mon, 19 Nov 2018, Sean Dobbs wrote:
>> 
>>> Hi Justin,
>>> 
>>> If the high intensity points are cheap, maybe it would be useful to have a finer grained scan, just in case we find something that we need to investigate in more detail?  Say, adding 400 and 600 nA points?
>>> 
>>> Cheers,
>>> Sean
>>> 
>>> On Mon, Nov 19, 2018 at 11:56 AM Justin Stevens <jrsteven at jlab.org<mailto:jrsteven at jlab.org>> wrote:
>>> Hi Richard,
>>> 
>>> Thanks for your feedback.  See below ->
>>> 
>>> On Nov 19, 2018, at 11:34 AM, Richard Jones <richard.t.jones at uconn.edu<mailto:richard.t.jones at uconn.edu>> wrote:
>>> 
>>> Hello Justin,
>>> 
>>> If we want to understand rate-related systematics, wouldn't it be better to push the upper limit of the scan higher? This way we learn something about what starts to go wrong at lower intensities, where we might want to run during the high-intensity period.
>>> 
>>> If it doesn't break anything, we should take some data at higher intensities, even if we have to prescale the trigger. I propose running two or three more points up to 700 nA on this diamond. This 700uA comes from the original design intensity for GlueX which was 1e8 photons per second on the target in the range 8.4 - 9.0 GeV (or 8.2 - 8.8 GeV with the present endpoint).
>>> 
>>> Sure, high intensity points are “cheap”, so this puts us at ~30 hours at 100% efficiency.  I added these points to the scan, if we’re comfortable going to this high an intensity (from a detector safety and trigger point of view).
>>> 
>>> I realize that this 5e-4 radlen in the spreadsheet for this diamond is just a placeholder, but that value should be closer to 3e-4. Radiation length is not really a valid metric for a coherent bremsstrahlung spectrum, but in the low-energy tail it is valid, where the radiation length of diamond is close to 15um as long as you stay away from the channeling condition. To get this, you cannot just take amorphous carbon and rescale it by the density, of course, as the crystal structure modifies the radiation length at all orientations.
>>> 
>>> I agree the diamond radiation length is a bit of a fudge, but it actually cancels in my calculation of the expected run time.  The only thing I use is the total trigger rate for the nominal intensity (~45 kHz for diamond) and scale by the current to get the time required.
>>> 
>>> -Justin
>>> 
>>> 
>>> -Richard
>>> 
>>> On Mon, Nov 19, 2018 at 10:11 AM Justin Stevens <jrsteven at jlab.org<mailto:jrsteven at jlab.org>> wrote:
>>> Dear Collaborators,
>>> 
>>> Following the discussion at this morning’s RC meeting for an intensity scan this Fall, here is what I would propose: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spreadsheets_d_1UT3o4yJ-2DavlIQzmZKJo2nRrgVPzYKJvGPJ0oqAn81Oo_edit-3Fusp-3Dsharing&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=Mwj7jqW_Gg8VvugDHdwA5w&m=_X3Z46cZYdB3Mq0066MeIIqspYRtV5uWmIdE3DKDD9E&s=27qXEoJLy9v6wZ7LpbadD07mVXM1aWPiEZiTuLYtHlE&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fspreadsheets-252Fd-252F1UT3o4yJ-2DavlIQzmZKJo2nRrgVPzYKJvGPJ0oqAn81Oo-252Fedit-253Fusp-253Dsharing-26data-3D02-257C01-257Crichard.t.jones-2540uconn.edu-257C2a054bc8dc824538f06908d64e314804-257C17f1a87e2a254eaab9df9d439034b080-257C0-257C0-257C636782370905211494-26sdata-3D9Sov7Fn68-252F0EsSrmdAiZ-252BHwwCC8KslfwMZPmqOufmqM-253D-26reserved-3D0&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=cIyw2PFFtpuc0ZvlKFxF6UnQ9C9dChESxxwL_XrGKB8&m=5x60TVJ8MWSM9A2jrjY1xKIskHZbATEXmLaQNxYDIk0&s=VNrl0oRFsfR28nvFv8Oyp7omkfKi-EFVp6gylZAv0yI&e=>.  There are two sheets at this link: RunPeriod-2018-08 (the proposal for this week) and RunPeriod-2018-01 (the data we've collected previously).  As a reminder, in Spring 2018 we did not have any high-statistics intensity scan with the final Tungsten foil installed in the beamline.
>>> 
>>> The proposal covers the same range of intensity (Beam current x RL) as we had in Spring 2018, with 100M events at each setting (aside from the very low intensity, where the rate is too low).  As Sergey requested, this also includes a raw mode run at each setting of 1M events, assumed to run at ~3 kHz.  The goal is to have a complete set of intensity scan data for efficiency studies with this Fall 2018 data.
>>> 
>>> The estimated beam time required for this proposal is ~28 hours at 100% efficiency, so it would likely take at least 2 days of calendar time to complete.
>>> 
>>> Comments/suggestions welcome,
>>> Justin
>>> _______________________________________________
>>> Halld mailing list
>>> Halld at jlab.org<mailto:Halld at jlab.org>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmailman.jlab.org-252Fmailman-252Flistinfo-252Fhalld-26amp-3Bdata-3D02-257C01-257Crichard.t.jones-2540uconn.edu-257C2a054bc8dc824538f06908d64e314804-257C17f1a87e2a254eaab9df9d439034b080-257C0-257C0-257C636782370905221499-26amp-3Bsdata-3DFroliv7F0Jnk20FMX8aATVGAmY71cXVkFDNwpcY-252BI7k-253D-26amp-3Breserved-3D0&d=DwIGaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=Mwj7jqW_Gg8VvugDHdwA5w&m=_X3Z46cZYdB3Mq0066MeIIqspYRtV5uWmIdE3DKDD9E&s=r1qcsX6lRIsI9K4UdNbb_t8RVdpicbbFmAogXglEABo&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmailman.jlab.org-252Fmailman-252Flistinfo-252Fhalld-26amp-3Bdata-3D02-257C01-257Crichard.t.jones-2540uconn.edu-257C2a054bc8dc824538f06908d64e314804-257C17f1a87e2a254eaab9df9d439034b080-257C0-257C0-257C636782370905221499-26amp-3Bsdata-3DFroliv7F0Jnk20FMX8aATVGAmY71cXVkFDNwpcY-252BI7k-253D-26amp-3Breserved-3D0&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=cIyw2PFFtpuc0ZvlKFxF6UnQ9C9dChESxxwL_XrGKB8&m=5x60TVJ8MWSM9A2jrjY1xKIskHZbATEXmLaQNxYDIk0&s=LN4Y_llWNgLKJqLykMqSSELJdzoIU0V4nUzKf6U4m9o&e=>
>>> _______________________________________________
>>> Halld mailing list
>>> Halld at jlab.org<mailto:Halld at jlab.org>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.jlab.org_mailman_listinfo_halld&d=DwICAg&c=HPMtquzZjKY31rtkyGRFnQ&r=bxTPW7N21WY8eJ2MkW85CQ&m=p02IS1RN4jW600tkFMdS3tUhhlVdJSEkbH8JwSrsOUk&s=DNsAsgDyfyeEK0lhQCMtl0W5--7e8LG3va8ih2fswSE&e=
>> _______________________________________________
>> Halld mailing list
>> Halld at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld
> 
> 
> _______________________________________________
> Halld mailing list
> Halld at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld

_______________________________________________
Halld mailing list
Halld at jlab.org
https://mailman.jlab.org/mailman/listinfo/halld