Excursions in Hall D beam positions
I think I should include the low intensity condition into AC:valid variable. I believe it needs to be done internally to AC calculations since the validity of the calculated numbers has to do with the beam current/radiator combination and the gains of the AC. When the signals on AC are too low (about the same as the pedestals values) the asymmetry calculation becomes problematic, basically it is 0/0 ratio, so based on some cuts the beam positions are assigned (0,0). I will include this condition of very low intensity on AC into AC:valid. Hopefully this will cover the TAC normalization running as well since then the AC gains are supposed to be raised to be sensitive to the photon beam from 1na beam (even from bleedthrough) on a 2x10^-5 rad. length radiator.
If the 5C11B BPM is used in the position lock then I guess it’s reading have to be valid too. What happens when we have 2nA mostly bleedthrough electron beam current during TAC normalization runs? Would it disable the lock? Should there be a different BPM enabling condition for these very low luminosity runs?
Hovanes.
From: Brian Bevins Sent: Thursday, September 22, 2022 3:28 PM To: Brian Freeman; Hovanes Egiyan; Edith Nissen Cc: Alexandre Deur; Igal Jaegle Subject: Re: Excursions in Hall D beam positions
The orbit lock does use AC:valid as a status indication for the AC. There seems to have been some misunderstanding about what the AC:valid PV means. Ops set up the PID locks (and I also assumed with the orbit lock) that "valid" meant that the positions reported by the AC were usable. It now seems that "valid" is a necessary but not sufficient condition to rely on the AC positions if I understand Hovanes correctly. Perhaps adding a current check into the AC:valid computation, or adding a new PV for that purpose, would improve the reliability.
The orbit locks do not check beam current directly. They rely on the BPM's to indicate whether or not beam is present. Since the new lock does use a BPM in addition to the AC, it won't run if the BPM says no beam is present even if the AC reads "valid". If IPM5C11B does erroneously light up from upstream field emission or rf noise, that would be a problem. It can be addressed by raising the wiresum zero threshold for that BPM. That value serves as a cutoff such that lower wiresum values are treated as beam off. This might create problems for very low current runs. But if real beam current is so low that it can be confused with field emission, the BPM is probably not reliable anyway. Adding an explicit current check to the lock server can also be done but will require significant software changes to the server.
--Brian
From: Brian Freeman <bfreeman@jlab.org> Sent: Thursday, September 22, 2022 12:13 PM To: Hovanes Egiyan <hovanes@jlab.org>; Brian Bevins <bevins@jlab.org>; Edith Nissen <nissen@jlab.org> Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle@jlab.org> Subject: Re: Excursions in Hall D beam positions
Brian,
Does the new lock look at the AC:valid PV? Does it use anything as a check for the Active Collimator?
Not sure if you were able to replace the BPM status word that the lock looks for in the BPMS, with anything for the Active Collimator. If not, It may be worth adding this. I could see a condition where D beam is off and the 5C11 BPM sees bleed though noise and indicates "OK", if the Active Collimator always appears "OK" too, the it the lock will drive the correctors.
-Brian
From: Hovanes Egiyan <hovanes@jlab.org> Sent: Thursday, September 22, 2022 11:53 AM To: Brian Bevins <bevins@jlab.org>; Brian Freeman <bfreeman@jlab.org>; Edith Nissen <nissen@jlab.org> Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle@jlab.org> Subject: Re: Excursions in Hall D beam positions
Hi Brian.
Thanks for looking into this. I can add the beam current to AC:valid condition. I assumed that the beam current is check by the locks separately and AC:valid was originally introduced to indicate if the AC was in the beam and if there is a radiator in the electron beam to produce photons. I can add beam current condition to it too, it is easy. That way it will be on us to set this value properly for TAC normalization runs with almost no beam current and for normal runs, which makes a lot of sense. This way we will eliminate the first type of drifts.
I do not know how damaging this drifts are to the experiments. The current experiment does not use diamond to produce linearly polarized photons, so it is mostly the loss of the statistics, meaning it depends how often this happens and how long it lasts. But for most of the GlueX run linearly polarized photon beam is used, and the amount and the direction of photon polarization get affected by these shifts. And the polarization enters the figure of merit quadratically, but the effect of the shifts on the photon polarization is not that easy to calculate. We may need to observe this new lock setup and see how often this happens with the new lock.
Hovanes.
From: Brian Bevins <bevins@jlab.org> Sent: Thursday, September 22, 2022 11:30 AM To: Hovanes Egiyan <hovanes@jlab.org>; Brian Freeman <bfreeman@jlab.org>; Edith Nissen <nissen@jlab.org> Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle@jlab.org> Subject: Re: Excursions in Hall D beam positions
Hi Hovanes,
I looked at some archiver data here and I can shed a t least a little light on this. Excursions of the first type seem to have been caused by the fact that the AC:valid PV continues to indicate that AC positions are valid even when the beam is off. The PID locks that saw only the AC would thus continue to ramp while the beam was off, giving the large excursion when beam was restored. The new dedicated orbit lock should not exhibit this behavior since it looks at BPMs as well as the AC and the BPMs always give a correct "no beam" indication. The underlying problem with AC:valid should still be addressed.
I cannot say what is causing the second excursion, but it is upstream of the orbit lock area. The attached plot shows the lock correctors initially behaving as expected after beam resumes. They then make large swings to bring the AC and BPM positions back where they should be and eventually drift back down to the values they had before the excursion. This sheds no light on what causes the excursion, but it does show the lock responding appropriately, if a bit too slowly to prevent trouble. More aggressive lock gains might help to mitigate the problem, at the risk of adding steady state noise to the beam position.
--Brian
From: Hovanes Egiyan <hovanes@jlab.org> Sent: Thursday, September 22, 2022 9:55 AM To: Brian Freeman <bfreeman@jlab.org>; Brian Bevins <bevins@jlab.org>; Edith Nissen <nissen@jlab.org> Cc: Alexandre Deur <deurpam@jlab.org> Subject: Excursions in Hall D beam positions
Hi,
at today's MCC morning meeting I mentioned that we see excursions on the Hall D active collimator as large as 1mm that reduce the photon flux on the target in the hall by quite a bit. Here I show two examples of that, I think the origins of these excursions are different. Hopefully they get addressed in this new position lock setup.
The first instance from September 15 you can see as a comment in the log entry https://logbooks.jlab.org/entry/4041917, but I also made a WAVE URL for it :
The 5C11B corrector magnets seem to drift when there is no beam, and when the beam is turned on the position are off, the vertical is off by over 3mm and the photon beam does not get through the collimator at all, as the bottom plot for the pair spectrometer rate shows.
The second instance from September 20th shows when the beam comes back after a trip at more or less OK positions but for some reason drifts by a large amount before it comes back to the nominal positions. The vertical shift is about 2mm. You can see it on this WAVE page:
The green graph on the bottom indicates how much the photon flux going through the collimator is reduced due to the position shifts.
In both cases the positions drifts are large enough for the large portion of the beam to miss the target in the hall because it is blocked by the collimator. I think the first case can be address by improving the condition for the AC lock being enabled. I do not know what happened in the second case that caused such a drift, other locks could have affected the AC positions before it got restored. Hopefully these cases can improve too.
Hovanes.
