...
Steering is intended to calculate values for corrector magnets whose
effect will be to 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 (BDES) of the correctors o`
when it 's initializedbegins a calculation. From that point on, it thinks that the extant settings
(BDESes) of the correctors are the values which it last calculated. That
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 BDESes, the effect is to undo the BUMP.
By the way, steering does reaquire teh reacquire the extant BDESs BDESes at the beginning of each steering iterationsiteration, so it isn't true that over a long period of steering, such a 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 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.
...
ref_strshr:str_cor_db_in.for
This function gets the extant bdes secondary values of the corrector magnet`magnet
database. If it is called with INIT argument it sets up the dblist ptrs
for susequent 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
...
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 BDESs BDESes to values which exceed BMAX. This condition is nominally checked in each steering method's function (It looks like STR_COR_RMS and STR_SVD), but now, since it may have changed, it has to be checked again.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