Problem
: 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 effet effect is to undo the BUMP.Furthermore,
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 steering session like the GOF, steering never
reacquires the real corrector settings. So any number of external influences
will be causing steering to implement changes to magnets from nominal
values that don't in fact reflect the true settings of the mangets.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 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