Sigmon 60 multi signal nxcals
Context
Project readme, and api documentation.
The goal of these changes was to introduce a multi-signal query with NXCALS API. The existing solution involved a sequential query of a single signal at a time. This is not efficient with NXCALS. For long lists of U_EARTH/U_DIODE signals for main dipole circuit (154 magnets) and main quadrupole circuit (49/51 magnets) this resulted in a very long query duration. With help of Jakub, we figured out a more performant NXCALS API query; see support request. This reduces by a factor 10x the query time needed to get long lists of signals. The attached html report contains NXCALS API for each use case along with timing and result of our work (pyeDSL).
We took this opportunity to refactor the dbsignal
module to reflect our experience in how we interact with logging databases:
(i) we only read signals; (ii) CALS was discontinued.
What was done
- We proposed a new abstract class for reading logged signals: SignalDbQuery. This class is extended by:
- The database implementation classes are created with a Factory SignalDbQueryFactory
- The factory is then used while executing queries with pyeDSL in DbQueryBuilder. In particular, L526, for PM, L622 and L658 for NXCALS. Note that we still keep a distinction between
signal_query
andmulti_signal_query
, which allow for a query of a list of signals. The reasons for that are two-fold: (1)signal_query
has been used in all queries so far, so that would allow for backward compatibility; (2)signal_query
allows for sequentially querying signals with switchingNxcalsVariableSignalDbQuery
orNxcalsDevicePropertyQuery
depending on the query metadata whilemulti_signal_query
assumes that the system and property (if applicable), signal (if applicable) are the same and uses one of the twoNxcals
classes. - Renamed and moved NxcalsFeatureDbQuery to a more suitable location
- Extracted KeyTypeValidation
TODO
- Update NqpsQuery,
signal_query
->multi_signal_query
. In particular, query_voltage_nxcals and query_voltage_nxcals - Update API User guide
QA
- template link to sonar issues
- code was unit tested
- acceptance tests were written; see the attached report. In addition, we ran two HWC notebooks to assert if this change would have introduced any performance regression - not observed.
Review objectives
The main objective is to get your feedback on the proposed design. Furthermore, we would like to get feedback on:
- assessment of code functionality (validation of user input in builder methods, error handling in case of a query failure in read methods)
- assessment of code quality (see project coding conventions)
- identifying potential refactorings / logic common to other projects
- knowledge sharing