BPM model simplification ?

[JeanLucPons]

Hello,

Today we have a BPM model which is not used (it is an identiy model).
My question is: Do we want to keep this model for instance to be able to implement DoS (or other model) from electrode voltage or can we simplify the BPM configuration ?

At ESRF, we implemented a more accurate model than DoS mainly for machine commissioning purpose but we don't need this to be implemented in PyAML.

Actual config:

- type: pyaml.bpm.bpm
  name: BPM_C21-08
  model:
    type: pyaml.bpm.bpm_simple_model  # Identity model
    x_pos: srdiag/bpm/c21-08/SA_HPosition
    y_pos: srdiag/bpm/c21-08/SA_VPosition

which could allow:

- type: pyaml.bpm.bpm
  name: BPM_C21-08
  model:
    type: pyaml.bpm.dos # Or any other model
    va: srdiag/bpm/c21-08/SA_Va
    vb: srdiag/bpm/c21-08/SA_Vb
    vc: srdiag/bpm/c21-08/SA_Va
    vd: srdiag/bpm/c21-08/SA_Vb

Simplified config (no model):

- type: pyaml.bpm.bpm
  name: BPM_C21-08
  x_pos: srdiag/bpm/c21-08/SA_HPosition
  y_pos: srdiag/bpm/c21-08/SA_VPosition

[kparasch]

I think it is important to have a way to define bpm models. It will also help for simulated commissioning where BPM errors cannot be handled at the level of the tracking code. At some point we also have to think about turn-by-turn data.

I would find the following more natural:

- type: pyaml.bpm.bpm
  name: BPM_C21-08
  x_pos: srdiag/bpm/c21-08/SA_HPosition
  y_pos: srdiag/bpm/c21-08/SA_VPosition

- type: pyaml.bpm.dos # Or any other model
  name: BPM_C21-08
  va: srdiag/bpm/c21-08/SA_Va
  vb: srdiag/bpm/c21-08/SA_Vb
  vc: srdiag/bpm/c21-08/SA_Va
  vd: srdiag/bpm/c21-08/SA_Vb

[JeanLucPons]

I'm thinking to this way of presenting thing which is interesting but a bit in disagreement with magnet models.
We can go to this scheme which is more natural with a bpm superclass to handle bpm common functions.

[JeanLucPons]

It is not really the purpose of the BPM model. The purpose of the BPM model is rather to handle a conversion from hardware (electrode voltage) to position.

For errors, we will add methods (similar to offset or tilt) that will be independent of underlying models.
For instance, on the internal simulator side, today additional AT fields are used here but the position is not updated (to be done). I plan to use similar technique for errors.

Rougly speaking, we can imagine:

sr.design.get_bpm("BPM_C01-01").offset.set(1e-3)
sr.error[0].get_bpm("BPM_C01-01").position_error.set(sigma=100e-6,cut_off=2.0) # Add an offset error using seed defined for simulator #0

TbT is no yet implemented but other methods will be added from them, similarly to instant popsitions.

[gubaidulinvadim]

but the position is not updated (to be done).

@gubaidulinvadim as you are the author of this, could you fix it ?

sr: Accelerator = Accelerator.load("../tests/config/bpms.yaml")
bpm = sr.design.get_bpm("BPM_C01-01")
print(bpm.positions.get())
bpm.offset.set(np.array([0.1, 0.2]))
print(bpm.positions.get())

do not add the offset.

I would suggest to create all offset and rotation attributes at the lattice loading time to avoid time consuming getattr() calls and then to add offset and perform rotation after find_orbit() calls

I do not see where this code is from. I've checked tests/bpm/test_bpm.py and tests/bpm/test_bpm_controlsystem.py

[JeanLucPons]

This is just a simple example.
Here the position remains unchanged and I expect that the offset is added to the position.

[gubaidulinvadim]

Ah, sorry I missed the quoted message

[gubaidulinvadim]

This is just a simple example. Here the position remains unchanged and I expect that the offset is added to the position.

I can fix it on Monday. Is this something only for the sr.design/simulator part? I think , I was assuming that the device already gives BPM position with subtracted offset and that the offset is only used to be set after the BBA.

[JeanLucPons]

Yes you are right. Only design. AT does not handle those fields.
Nothing urgent.