Skip to content

Sigmon 60 multi signal nxcals

Michal Maciejewski requested to merge SIGMON-60_multi_signal_nxcals into master

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 and multi_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 switching NxcalsVariableSignalDbQuery or NxcalsDevicePropertyQuery depending on the query metadata while multi_signal_query assumes that the system and property (if applicable), signal (if applicable) are the same and uses one of the two Nxcals classes.
  • Renamed and moved NxcalsFeatureDbQuery to a more suitable location
  • Extracted KeyTypeValidation

TODO

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

Report

NXCALS_MultiSignalQuery.html

Edited by Michal Maciejewski

Merge request reports