Orbit etc.. c/o Jorg

1- corrector polarity errors are not a serious issue by 'construction'. The idea is to use only 1 or 2 correctors at each step, and compare predicted and achieved correction. If you use 1 (or max 2) correctors you immediately spot a sign error of a COD. This becomes tricky if you start sending 10 correctors at the time - that why you should keep the number (very) small.

2- isolated BPM polarities and mega-offsets are similar : if you use 1/2 correctors the algorithm will not be able to build bumps around such faulty guys. As you progress you qickly identify such suspicious cases (again compare predicted and achieved traj). This way I found all TI8 polarity errors of BPMs during threading.

3- quadrupoles error are not a problem up to a few% errors. If their polarity is wrong, then the key is to get through that location somehow (by working on the trajectory before. By comparison of predicted and achieved traj, you can spot the ~ location where the problem occurs. If necessary you take a corrector in ti8 (or beginning of ring), launch a trajectory and compare prefiction and measurement [a sort of online response check]. Then you will easily spot the bad quad [this was used to locate the bottles in LEP]. Once you pass, the response matrix is again OK. Of course both 2 and 3 break down if it is not isolated faults, by when everything breaks down...

4- A significant dp/p offset is easy to spot by the systematic offset of the trajectory (I made some tests). Of course if your BPMs have systematic offsets, that becomes an issue. Concerning automated threaders : here the problem is 'simple'. If all elements are well behaved, then it is easy. But it is also easy to do it by hand, and there is not real gain. If there are problems (like 1) or 2)) it is hell of a job to develop (and test !) all algorithms - mayb eto find that they are not needed. At LEP we spend ~ 1 hour / run for threading. This was not worth an automatic program - so far I'm wait and see before dumping my time into such a 'beast'.

Another point are bump scans : also I could easily scan bumos with my program (it is almost the same as an orbit response measurement [at least from the principles]) because I have all the bump algorithms, I will not start to read out BLMs as well. One possibility is that I provide the sliding bump, but that the BLM data is just collected by the 'logging' and then you match offline a BLM set with the corrector settings (and therefore the bump amplitude and location...).