Restored lattice-names doc

[JeanLucPons]

This PR restore lost doc about lattice-names parameters.
However, i don't know how to test it. The documentation about testing documentation is incomplete or unclear to me.
Thanks for help

[JeanLucPons]

An other issue is the fact that dt4acc seems to use example files of the pyaml repo. I was not aware of this and I though that the VA should be independent of the pyaml repository (including example).
Would it be possible to move config file for dt4acc compatible with flagged backend(s) to avoid such issue ?

[gupichon]

Yes, there is a test checking that the example files can be loaded. The one for BESSY II fails, but I haven't checked why yet. I believe it's been happening since the backend releases. I'll take a look at it.

[gupichon]

Otherwise, the VA is independent of the repository. The purpose of the failing test is to verify that the examples are still loadable. The matching lattice isn't even loaded. This is done during the integration phase because the environment is capable of doing so. Maybe we should set up a dedicated pipeline to test the documentation examples to ensure they stay up to date, independently of the integration tests.

[JeanLucPons]

The problem comes from the update of the dynamic catalog by default #49
And I updated BESSY2 example to this new feature.
Which means dt4acc loads bessy2.yaml example from pyaml repo but of course, that means that dt4acc needs last pyam-cs-oa or use an old bessy2.yaml files.

[gupichon]

The error comes from an outdated test environment. It should be resolved by replacing the following line in dt4acc-integration.yml:

• "pyaml-cs-oa @ git+https://github.com/python-accelerator-middle-layer/pyaml-cs-oa.git@0.2.0"
  with
• "pyaml-cs-oa @ git+https://github.com/python-accelerator-middle-layer/pyaml-cs-oa.git@0.3.0"

[gupichon]

@JeanLucPons, would you prefer to move this kind of test into a dedicated pipeline, or should I just update the pyaml-cs-oa release we use?

[JeanLucPons]

In an ideal world i would prefer that the VA stay fully independent from pyaml. It is supposed to be a VA that exports magnets bpm and so on. Then it will force us to maintain backward compatibility in pyaml and allow new feature to be developed in pyaml without breaking dt4acc integration tests.
This use case that we face is a good example. The new pyaml-cs-oa is still able to load old file but the old pycam-cs-ao cannot load files with new features.

[gubaidulinvadim]

In an ideal world i would prefer that the VA stay fully independent from pyaml. It is supposed to be a VA that exports magnets bpm and so on. Then it will force us to maintain backward compatibility in pyaml and allow new feature to be developed in pyaml without breaking dt4acc integration tests. This use case that we face is a good example. The new pyaml-cs-oa is still able to load old file but the old pycam-cs-ao cannot load files with new features.

I'm not sure I understand. The VA is independent; what fails is the integration test because pyAML in the test used the wrong pyaml-cs-oa backend (for new config files). But what is tested is pyAML running in "live" mode with VA.

[gupichon]

I'm not sure I understand. The VA is independent; what fails is the integration test because pyAML in the test used the wrong pyaml-cs-oa backend (for new config files). But what is tested is pyAML running in "live" mode with VA.

It's actually a test I introduced by mistake, but it's still useful. It verifies that the examples are loadable and doesn't use the dt4acc simulator at all. It was copy-pasted from a small sandbox project where I tested the pipeline when building it. It can be fixed by upgrading the test environment in the pipeline. I suggest creating a dedicated pipeline, without the VA, to ensure the provided examples stay up to date. In the meantime, I'll open an issue and update the versions used in the integration environment.

[gupichon]

In an ideal world i would prefer that the VA stay fully independent from pyaml.

It is.

[TeresiaOlsson]

The error comes from an outdated test environment. It should be resolved by replacing the following line in dt4acc-integration.yml:

* `"pyaml-cs-oa @ git+https://github.com/python-accelerator-middle-layer/pyaml-cs-oa.git@0.2.0"`
  with

* `"pyaml-cs-oa @ git+https://github.com/python-accelerator-middle-layer/pyaml-cs-oa.git@0.3.0"`

If they are switched to always use the latest release on PyPI I think it should work. Or at least I could validate the BESSY II example configuration when I tested it.

I think eventually the problem will go away because when the examples are moved into the documentation the integration test no longer need to do this test. The documentation can be used as the integration test for it. So far it has actually been quite good for this purpose too. Turns out that when you add a tutorial you get a test of that part of the code for free since the documentation needs to run it.

[JeanLucPons]

OK so that's good that dt4acc is fully independent.
But it will be heavy to add a new feature in backend as i will have to make a new release for the backend and update the github workflow each time. I would prefer that the github workflow loads configuration file compatible with tagged backend or do not try to load example. May be possible solution by targeting stable branch or pyPI as Teresia suggest.

[gupichon]

OK so that's good that dt4acc is fully independent. But it will be heavy to add a new feature in backend as i will have to make a new release for the backend and update the github workflow each time. I would prefer that the github workflow loads configuration file compatible with tagged backend or do not try to load example. May be possible solution by targeting stable branch or pyPI as Teresia suggest.

I agree, I solve that immediatly.

[gupichon]

The test will pass if you merge from main.

[JeanLucPons]

I rebased on main.
Seems OK !
Rendering of the doc is ok.