Miscellanea

[giadarol]

This issue contains notes on needed/planned developments:

• Mad-ng interface needs to support slice elements (or remove slice elements in the line)
• Need to deprecate Line.unfreeze Line.vars.load_madx_optics_file Line.vars.set_from_madx, Line.insert_element, Line.append_element
• Need to have brho calculated from reference particles available for expressions
• Add num_multipole_kicks to Sextupole and Octupole
• Add Yoshida mode to Quad, Sext, Oct as done in Bends
• Add twiss4d and twiss_default to Environment
• At the moment TwissTable.plots extracts the strengths at the time of the plot, which could be inconsistent
• On large lines (100k elements, TwissTable.plot is very slow) (extracts and plots the strengths). Should we maybe remove the strengths when the line is very big?
• Extraction of the strengths is quite slow, especially the first time. Can we do anything about it?
• Need to implement LineTwisser to mask selected elements, give results at centers etc. Could also match particles

[freddieknets]

Did you plan for the LineTwisser to handle the versatility with (non)-collective elements as well?

In that case, can we also provide the option to define this at the class level such that elements of a certain type are always or never included in a twiss?

If we would keep this at the user level when calling a twiss, then every basic function that is using twiss internally will fail. Not only particles generation, but also orbit search, matching, and any other function that needs to twiss). Keeping it at the user level might not only generate mistakes that pass silently, it is also non-robust and complicated as every function that twisses internally will need to be updated to accept the new option for this to work...

[freddieknets]

Also, can you add the new implementation of ele_start and ele_stop to the list? It's been a while since we discussed this, so we should check that we still agree with the plan and if it is still compatible with all new changes etc.

I know this one is my responsibility to finally do it, but it's still an open point ;-).

[giadarol]

Also, can you add the new implementation of ele_start and ele_stop to the list? It's been a while since we discussed this, so we should check that we still agree with the plan and if it is still compatible with all new changes etc.

I know this one is my responsibility to finally do it, but it's still an open point ;-).

Didn't add it here as it has a dedicated issue: https://github.com/xsuite/xsuite/issues/459

[giadarol]

Did you plan for the LineTwisser to handle the versatility with (non)-collective elements as well?

In that case, can we also provide the option to define this at the class level such that elements of a certain type are always or never included in a twiss?

If we would keep this at the user level when calling a twiss, then every basic function that is using twiss internally will fail. Not only particles generation, but also orbit search, matching, and any other function that needs to twiss). Keeping it at the user level might not only generate mistakes that pass silently, it is also non-robust and complicated as every function that twisses internally will need to be updated to accept the new option for this to work...

Yes, I would use the LineTwisser to handle this as well. The line could have a default Twisser used for Line.twiss(...) so that the behavior defined in the twisser is propagated to all calls of twiss. Yes, for elements that always need to be skipped in twiss this could be specified by a flag in the class.