Working group number 1 (Alexandre, Sebastian, Simon , Ali, Stefano): use case implementation

[swhite2401]

Here we put some ideas on possible new use cases to be implemented and feedback on running the existing ones

[Amoutardier]

Idea of what to do :

• Chromaticity tuning: Relatively simple, as it is similar to tune tuning
• Screen analysis: Not possible yet, as there are no images implemented in the simulators
• Generic scans: good idea, but too hard to have something working at the end of the day

Thus: Chromaticity tuning

[swhite2401]

Feedback BESSY-II use cases:
-having to set the prefix in the configuration file is annoying, can this be done automatically?
-tune and chromaticity examples are running fine
-the vertical orbit correction is not very efficient, maybe there is an issue?

[TeresiaOlsson]

I agree with the prefix. It is super annoying. Not sure how to fix it though. Maybe need to add some way in the yaml file to specify an environment variable to read or something like similar?

For the orbit correction I don't think it entirely works correctly. In MML we normally use all singular values but if I do that in this example it doesn't work. One reason could be that the unit of the BPMs are currently wrong. They come out from the control system in nm but we don't yet have the functionality to convert from that into the units used by pyAML. So a temporary fix was to put in a gain factor of 1e-9 but this can have caused other problems. Benchmarking against the orbit correction in MML would be a good idea after the unit problem has been fixed.

[swhite2401]

There are unused import in the bessy orbit example:

from pyaml.tuning_tools.orbit_response_matrix import ConfigModel as ORM_ConfigModel
from pyaml.tuning_tools.orbit_response_matrix import OrbitResponseMatrix

can be removed

The gain is set 1.0e-9 this is odd, why does the gain need to be so low?

Possible improvements for the orbit correction function:
-set the the gains for the 2 planes idividually: allow for the gain to be a list or numpy array
-override the number of eigenvectors with kw argument, allow different values for H and V

[TeresiaOlsson]

The gain is because the unit of the BPM from the control system is in nm and pyAML doesn't yet have the functionality to convert from that to the units used in pyAML. So it's a temporary fix suggested by @JeanLucPons which eventually should go away.

[swhite2401]

ESRF example:

The readme file suggests to install dummy_cs: is this outdated? Isn't it sufficient to install tango-pyaml? It seems to work for me
The configuration file is in the test folder, shouldn't there be a copy in the ESRF example folder?

Made a bump it works

Running examples writes ORM files in the git folder, maybe this should be avoided as it adds untracked files in the folder that could be commited by mistake. A possible alternative is to comment out the line where the file is written and add instead a figure

The orbit correction function lacks flexibility, key parameters should be editable dynamically and not only through the yaml files

[swhite2401]

Handling of magnet family in config files is cumbersome, is it possible to use wildcards?
Is it possible to create magnet families in the python script directly?

[TeresiaOlsson]

This would be great! I would also like the feature to do something like accelerator['VS*'] to get all the devices with some name like you can do in pyAT rather than using the get_magnet function.

[gubaidulinvadim]

@swhite2401 currently you can do the following to define the families with a Python script. I think the first part of manually looking up the name could be replaced by a wildcard expression.

hcorr_names = [mag.get_name() for mag in control_mode.get_all_magnets() if mag.get_name().endswith('hcorrector')]

vcorr_names = [mag.get_name() for mag in control_mode.get_all_magnets() if mag.get_name().endswith('vcorrector')]
 
control_mode.fill_magnet_array("HCORR", hcorr_names)

control_mode.fill_magnet_array("VCORR", vcorr_names)