Add a public diagnostic holder

[gupichon]

Description

Adds a public diagnostic property (DiagnosticHolder) on ElementHolder, mirroring RFHolder and ToolHolder. It exposes diagnostic.get(name)/diagnostic.get() for name-based/untyped access to all configured diagnostics, plus a betatron_tune property resolving the monitor registered as BETATRON_TUNE (the existing default name, already the value of pyaml.tuning_tools.tune.DEFAULT_BETATRON_TUNE_MONITOR) and validating its type, raising PyAMLException when it is missing or of the wrong type.

Related Issue

• Fixes Feature: Add a public diagnostic holder #372

Features/issues described there are:

• new feature: DiagnosticHolder was added (pyaml/common/holders/diagnostic_holder.py) and wired up as ElementHolder.diagnostic, because diagnostics were only reachable through get_betatron_tune_monitor(name), with no type validation and no discoverable entry point grouping them.
• new feature: diagnostic.get(name=None) returns a named diagnostic or, when no name is given, all configured diagnostics as an ElementArray, mirroring the same get() convention already used by tool.get() and the other sub-holders.

Changes to existing functionality

• None. get_betatron_tune_monitor(name) and add_betatron_tune_monitor(tune_monitor) are unchanged, kept as the backward-compatible, untyped named lookup, per the issue.

Testing

The following tests (compatible with pytest) were added to tests/diagnostics/test_diagnostic_accessors.py (new file, new tests/diagnostics/ directory):

• test_diagnostic_get_returns_named_monitor
• test_diagnostic_get_with_no_name_returns_all_configured_diagnostics
• test_diagnostic_betatron_tune_returns_default_monitor
• test_diagnostic_raises_when_default_missing
• test_diagnostic_raises_when_default_wrong_type

Verify that your checklist complies with the project

• New and existing unit tests pass locally (1 pre-existing unrelated failure: tests/tuning_tools/test_tuning_orm.py::test_tuning_orm, a Windows-only NamedTemporaryFile double-open issue)
• Tests were added to prove that all features/changes are effective
• The code is commented where appropriate (NumPy-style docstrings, including the DiagnosticHolder class docstring so diagnostic and betatron_tune are discoverable via help())
• Any existing features are not broken

[gubaidulinvadim]

For me BPMs are part of the diagnostic and we can also move them in the project structure to be under diagnostic. When BPMs where created, there was no other diagnostics and BPM itself was more complicated (with model). @JeanLucPons do you think it's ok to move BPMs in diagnostics and make BPM holder part of diagnostic holder?

[JeanLucPons]

Yes I would prefer to have BPM in diag.

[GamelinAl]

For me BPMs are part of the diagnostic and we can also move them in the project structure to be under diagnostic. When BPMs where created, there was no other diagnostics and BPM itself was more complicated (with model). @JeanLucPons do you think it's ok to move BPMs in diagnostics and make BPM holder part of diagnostic holder?

@gubaidulinvadim
Your proposal mean that the BPMsHolder would be a sub-holder of the DiagnosticHolder ?

[gubaidulinvadim]

For me BPMs are part of the diagnostic and we can also move them in the project structure to be under diagnostic. When BPMs where created, there was no other diagnostics and BPM itself was more complicated (with model). @JeanLucPons do you think it's ok to move BPMs in diagnostics and make BPM holder part of diagnostic holder?

@gubaidulinvadim Your proposal mean that the BPMsHolder would be a sub-holder of the DiagnosticHolder ?

Yes, and, additionally, to move bpm module to be a submodule of diagnostics. This can be done in another PR.

[gupichon]

Would you like to keep the current design.bpm in addition to design.diagnostic.bpm, or should we keep only design.diagnostic.bpm?

[gubaidulinvadim]

For me only sr.design.diag.bpm is fine.

[GamelinAl]

For me only sr.design.diag.bpm is fine.

Yes, and at some point we will have the clean the API so there ONE good way to do things.
Otherwise the number of methods is too large I think.