Problem
Steering is intended to calculate a set of corrector magnets setting (BDES) values which, if implemented (trimmed), would reduce the RMS of the beam orbit as read by BPMs. The problem is steering only reads the existing BDES settings of the correctors when it begins a calculation. From that point on, it thinks that the extant settings (BDESes) of the correctors don't change, even though the calculation may take a number of minutes. That means if steering takes a long time to calculate new settings, the real extant BDESes of the correctors in the db may have changed due to external influences, such as someone implementing a "bump", before steering has the chance to implement the values implied by the calculation it made. If the bump is "closed" (if its effect is local in the beamline), then it should be ok for steering to implement its correction even though the bump is in effect.
However, since steering has only recorded the extant corrector BDESes before it started its calculation, and the bump changed those values, and steering then implements its calculated change to the corrector settings assuming that change is the change to the BDESes it recorded, the effect is to undo the BUMP.
By the way, steering does reacquire the extant BDESes at the beginning of each steering iteration, so it isn't true that over a long period of steering, such as in GOF, that the real values drift from those steering has recorded. The problem is confined to the time it takes steering to make one orbit correction calculation.
Objective
Make steering set the values of corrector magnets as changes from their extant values at the time of the implementation of the orbit correction solution (when the user actually hits TRIM or in the case of AUTO steering immediately after the calculation has been completed; GOF uses AUTO steering), rather that as changes from values acquired from the database when steering was initialized.
Information
ref_strshr:str_cor_db_in.for
This function gets the extant bdes secondary values of the corrector magnet
database. If it is called with INIT argument it sets up the dblist ptrs for subsequent non-INIT calls. Its primary job is to set the global array "BDES" - steering's understanding of the extant settings of the correctors.
ref_strshr:str_cor_db_out.for
This function puts the CALC_BDES value in the database (DBLPUT only, the magfunc is handled by other functions). If it is called with INIT argument for susequent non-INIT calls. Its primary job is to set the bdes secondary of the corrector magnets to new values reflecting the calculated bdes.
CALC_BDES is to be interpreted as an absolute value to be implemented, so like a replacement BDES rather than a change to it. But the actually implemented BDES
is
old_BDES + ( CALC_BDES - old_BDES) * factor
where factor is a fraction to implement the correction, so say .5 says only do half the calculated correction.
Possible Implementation
So, one way to implement this fix is for str_cor_db_out to call str_cor_db_in (with the INIT param set false) immediately before using the BDES values to make the sum above.
Care however must be taken not to set the BDESes to values which exceed BMAX. It looks like STR_COR_DB_OUT already does that at least by the brute force mechanism of binding to the bmax. That may well be all that's needed.
Testing
The following sanity checks made by steering should still work:
- trim followed by a trim with no intermediate calc, results in an err msg
- can't trim until calc completed
- untrim works
- can't untrim unless a trim has been done