Preserve ordering of thin elements placed in the same location in a sequence

[rdemaria]

The ordering of thin elements inserted with the same AT value when doing computations is not well defined and in general not preserved. Since the effects are not necessarily commutative it is useful to allow the user to control it.

A potential solution to be discussed:

1. add a real quantity call "order" associated to the node that is used as extra value to find an ordering. This value is created automatically when reading a sequence (0 by default and incremented by 1 for any element at the same location)
2. add an API to query and modify this value
3. the command "use" will take the "order" into account when creating a sequence.

[ldeniau]

A workaround it to add tiny values, e.g. n*1e-20 to AT to ensure the ordering, which is also preserved in the node. This workaround doesn't need any feature extension and it is not more cumbersome than defining an extra "order". Moreover, as it is a numerical order, this can be "automatised" by loops and/or variables, and new AT can always be inserted between exiting ATs, which is not the case for ordering by naturals.

[rdemaria]

It could work somehow but rather then n*1e-20 that would not work for a 100km machine, it should be n*1e-16*L where L is the length of the sequence but adding numbers that have an impact on calculations, even if not physically significant, can lead to situation for which a change of order that is not supposed to have an impact, will have an impact.

An explicit implementation is more robust in my opinion.

[ldeniau]

right, 1e-20 is far too small even for a 1m long machine... So yes, 1e-10 is a better choice, still negligible for the physics...

[rdemaria]

First investigations:

• at sequence definition the elements must have the correct order in the input
• seqedit,install installs in front (see https://github.com/MethodicalAcceleratorDesign/MAD-X/blob/master/src/mad_seq.c#L587). This could be changed, hoping there are no side effects