Added IRNL correction script

[JoschD]

Closes #73

[mihofer]

maybe adding a simple test(-s) to check and as examples
for some simple cases, one may also check that the corr values matches the integrated err of the triplet magnets

[mihofer]

What changes would be required to adapt this to a different machine, say FCC-hh, or a different configuration? Could be interesting to highlight this in some comments.

[mihofer]

Very superficial reading has shown no major critiqueable points

[JoschD]

What changes would be required to adapt this to a different machine, say FCC-hh, or a different configuration? Could be interesting to highlight this in some comments.

From the top of my head I can think of only two (and a half) things:

minor:

• add machine as accel input parameter/change allowed IP numbers
• define standard RDTs to correct (depend a bit on where the working point of the machine will be)

a bit more cumbersome:

• so far it only knows the names of the corrector magnets for lhc/hllhc so at that point you would have to have another map from corrector order to corrector name (e.g. b4 -> MCOXF?.3[LR]\d)

If the magnets are similarly named i.e. end in [LR]\d(\.b\d)?(\.\.\d+)?, the algorithm can find the magnets belonging to each side of the IPs and things should work. If the naming scheme is different, this also needs to be adapted.

But all of this is "just" naming conventions. Once it is clear which magnets are the correctors and which magents belong to which side of which IP, the rest should work automatically.

[fsoubelet]

Some minor detail comments but looks great to me! Merge away when you want.

If you have some extra time on your hands it would be nice to write a bit about this in the OMC website, but maybe when the paper is published then it will be enough of a documentation by itself.

Sorry for the late review :)

[fsoubelet]

Maybe, if it is not too much work, in time we parametrize this test to also include different orders. Definitely not merge blocking.

[JoschD]

I thought about that, but I don't think we need to test EVERY case that makes sense physically. It's more important to test different ways the algorithm works (and already here I have quite a few redundancies in the tests)

[JoschD]

There are two things I should test for though:

• use feed-down from corrector to correct lower order rdts
• use two sets of optics/RDTs to correct for at the same time.

Maybe I will add these before merge