Aperture changes

[meguiraun]

Small fixes:

• When the aperture changes outside mxcube (via MD application) the ui was not getting the most recent value
• When the aperture changes in mxcube, the beam size drawn in the canvas had wrong unit (resulting in the beam not being displayed)
  • this one is making me crazy, is it only me seeing this? It seems there is a unit mismatch (ApertureInput components expects '5', '50' whereas the makeImageOverlay has to divide that by 1000...)

[fabcor-maxiv]

It seems there is a unit mismatch

We should aim for millilmeters if possible: https://mxcubeweb.readthedocs.io/en/latest/dev/contributing.html#units

[marcus-oscarsson]

Hm, I need to double check but but I'm fairly certain we don't have this and we express our beam size in mm. We are not dividing with 1000 and the beam size is as far as I know displayed correctly. Can it be that there simply a mismatch between how you set the corresponding beam size when you select a aperture ?

[meguiraun]

tack, you are correct! The issue comes from our aperture being set as um all the time, and how the internal mxcube translates the size_x and size_y (dividing by 1000).

I fixed by changing our beam_info.get_value to

return current_aperture / 1000, current_aperture /1000, BeamShape.ELIPTICAL, current_aperture

current_aperture is 10, 50... etc.

But I still have the issue when the aperture is changed via MD3. Mxcube does not get the value. I will redo this MR with the changes I had to apply

[marcus-oscarsson]

👍 Ok, I see. I have to take a closer look we made a fix for this some time a go that we have not pushed yet. One thing you can look at is if the beam_changed "event" is called when you change the beamsize.

mxcubeweb/ui/src/serverIO.js

Line 190 in f513f24

this.hwrSocket.on('beam_changed', (record) => {

[meguiraun]

yes, that's where I was digging! I updated the MR with few lines, let me know if it fits your needs.

I kept it simple, the beam definer / beam info / aperture changes coming from @beteva will bring more changes in ui I believe

[marcus-oscarsson]

yes thats true, it looks like you guys did a really nice work on that part. It seems to handle the different scenarios we have here nicely

[beteva]

the beam definer / beam info / aperture changes coming from @beteva will bring more changes in ui I believe

@meguiraun, the beam definer is developed on top of your code, so we share the work. I believe that the changes in the ui are mostly renaming aperture to beam definer if we want to be consistent, but it does work even without doing this.

[meguiraun]

yes, But we migth want to display things in the UI differently

[meguiraun]

is this MR ok then?

[marcus-oscarsson]

I think there is some sort of mismatch that will need to deal with later, what you have called aperture we have called label, @beteva can probably explain better but the idea is that we might have other beam defining devices apart from aperture and thus thus we called this label.

https://github.com/mxcube/mxcubeweb/pull/1336/files#diff-22456c616d884b4272eb374bb11c54f640069290c55658dfd53f03a5dd96f009R658

[beteva]

@marcus-oscarsson You are right. The output of the beam HO get_value() is a dictionary
{"size_x": beam_width (float), "size_y": beam_height (float), "shape": beam_shape (BeamShape enum), "label": definer_label (str)}
So indeed what is called aperture should rater be called label.

[marcus-oscarsson]

Ok, so to avoid future conflicts it would probably be better if this is:

            "shape": _beam[2].value,
            "label": _beam[3],
        }

[marcus-oscarsson]

The suggested updates would result in a minimal conflict (if any) later.

[meguiraun]

I can live with the suggested changes :)

[marcus-oscarsson]

There was a indentation mistake in my suggestion, I fixed it, sorry @meguiraun. Ill merge when the pipelines have finished