# Presentation: 151219

## Status on Beam Spot Monitoring & Feedback

**Yi Dai**
** ****STT Meeting**
**October 27, 2000**

**Notes:**
Purpose:  to collect inputs and feedback from online group 
(1). General design
(2). Database storage
(3). Communication

## Beam Spot Monitoring and Feedback 

**Action for a store of beam -- **_**Beam Position Calibration**_
**To provide the store-specific beam parameters ******** the beam position reference point**
**Done for each store of Tevatron beam**
**Beam parameters kept in the online calibration ORACLE database**
**Action for a data run -- **_**Beam Parameter Update and Downloading**_
**Update beam parameters if a change (compared to the “store” values) takes place**
**Used as run-specific configuration parameters for L2STT etc**

_**Planned Procedures**_

**Notes:**
(1). Where and when the Beam position calibration should be done is the main concern. They agree that the beam parameters should be kept in the online database(Oracle). It would sound quite unreasonable if we devoted the precious beam time just to this calibration. One solution is this calibration is carried on in some runs(could be data taking runs) but with L2STT  off. As long as the calibration is done, the rest of data taking runs could be with L2STT turned on.
(2). They agree that the updated beam parameters be kept in the database

## Beam Spot Monitoring and Feedback 

**Action during data taking -- **_**Beam Position Monitoring and Feedback**_
**Continuous monitoring – ****EXAMINE**
**   ****(How often the update?)**
**For daily shifters**
**For accelerator control people**
**Feedback triggers when deviations exceed preset thresholds**
**To ACNET dipole correctors for bringing back the beam spot**** **
**New beam parameters will be entered into online/offline database after feedback correction**
**To be used for beam parameter update**** **
**For later-on beam history study**

_**Planned Procedures (cnt’d)**_

**Notes:**
1). One major concern about Beam monitoring is from the Data Distributor(DD). It seems the load(client requests) on the present DD is already heavy. The continuous monitoring scheme might add extra load on DD. In that case, the Online group might consider adding another DD to handle the load. No matter of which scenario, they’d like to know how much load the Beam Vertex EXAMINE will create. This certainly needs to talk to Vertex group(Meenskshi). For DD, the expert is Gerald Guglielmo(gug@fnal.gov, x3724) or Stu Fuess.
2). The feedback triggering scheme might needs to be included into the present Dzero significant event frame.
(Geoff Savage, savage@fnal.gov)
3). Again, new beam parameters will be kept in the online database.

## Beam Spot Monitoring and Feedback

**Concern about data stream traffic load on DD (Data Distributor) ******** ****Vertex EXAMINE**
**How many events(or tracks) are needed for each primary vertex reconstruction?**
**How often do we need to update Vertex EXAMINE monitoring?**
**Do we need to put the beam information into the event record? ******** ****A general issue of whether slow data be put into the event stream**
**Probably not?**

_**Feedback from Online Group**_

**Notes:**
(1). All parameters will be stored in the online database. They also need to be available on the offline database, too for potential customers.
(2). Information from Lumberjack dataloggers can be made accessible. To do that, Michael Begel needs the requirements. This information, for example, can be used as a cross check of the beam spot position.
(3). Some one mentioned the Vertex EXAMINE is already there. Is that true?

## Beam Spot Monitoring and Feedback

**Access from D0 control to ACNET**
**EPICS/ACNET interface already in place**
**Permission needed for ACNET device access**
**Exception Handling**
**Needs to be integrated into D0 SES (Significant Event System)**
**Contacted Paul Derwent (CDF)**
**D0 dipole correctors(C4 and D1) have the same correction range as CDF **

_**Feedback from Online Group (cont’d)**_

**Notes:**
(1). Communication
1). EPICS Channel Access Client call should use C since EXAMINE is written in C++.  Need to talk to Savage and Michael Begel on how to implement it.
2). No one knows how to get the access to ACNET devices. This might need to obtain the permission from Fermilab accelerator group or beam division. Should I talk to Paul Derwent?
3). EPICS/ACNET communication interface is already there. How does it work? Might need to talk to people such as Michael Begel.
(2). Exception handling should be included into the Dzero significant event frame. Need to talk to Savage.

## Beam Spot Monitoring and Feedback

**Communication software **
**An overall draft design: including feedback communication and link to SES etc**
**  **
**To build a client running on the EXAMINE machine to talk to ACNET (via EPICS Channel Access calls in C)**
**Further planning**
**Integration with Vertex EXAMINE**
**Offline testing and future online beam testing**
**Others etc...**

_**Future Plan**_

**Notes:**
(1). Communication
1). EPICS Channel Access Client call should use C since EXAMINE is written in C++.  Need to talk to Savage and Michael Begel on how to implement it.
2). No one knows how to get the access to ACNET devices. This might need to obtain the permission from Fermilab accelerator group or beam division. Should I talk to Paul Derwent?
3). EPICS/ACNET communication interface is already there. How does it work? Might need to talk to people such as Michael Begel.
(2). Exception handling should be included into the Dzero significant event frame. Need to talk to Savage.