DiamondLightSource/SynchWeb

Refined Beam Positions from `fast_dp` are flipped and `SynchWeb` is wrongly flipping them back.

Closed this issue · 2 comments

If you look at lines 37-66 of client/src/js/templates/dc/dc_autoproc.html you will notice some pretty dubious coding.

 <table class="reflow bc">
        <thead>
            <tr>
                <th>Beam Centre</th>
                <th>X</th>
                <th>Y</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>Start</td>
                <td><%- BEAM.XBEAM ? BEAM.XBEAM : '- -' %></td>
                <td><%- BEAM.YBEAM ? BEAM.YBEAM : '- -' %></td>
            </tr>
            <!-- these are flipped, not sure why? -->
            <tr>
                <td>Refined</td>
                <td><%- BEAM.REFINEDYBEAM ? BEAM.REFINEDYBEAM : '- -' %></td>
                <td><%- BEAM.REFINEDXBEAM ? BEAM.REFINEDXBEAM : '- -' %></td>
            </tr>
            <tr>
                <td>&Delta;</td>
                <td><%- BEAM.REFINEDYBEAM && BEAM.XBEAM ? (BEAM.XBEAM - BEAM.REFINEDYBEAM).toFixed(2) : '- -' %></td>
                <td><%- BEAM.YBEAM && BEAM.REFINEDXBEAM ? (BEAM.YBEAM - BEAM.REFINEDXBEAM).toFixed(2) : '- -' %></td>
            </tr>
        </tbody>
    </table>

    <% if (BEAM.REFINEDYBEAM > 0 && (Math.abs(BEAM.XBEAM-BEAM.REFINEDYBEAM) > 0.5 || Math.abs(BEAM.YBEAM-BEAM.REFINEDXBEAM) > 0.5)) { %>

The table headers and the starting values look OK:

        <thead>
            <tr>
                <th>Beam Centre</th>
                <th>X</th>
                <th>Y</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>Start</td>
                <td><%- BEAM.XBEAM ? BEAM.XBEAM : '- -' %></td>
                <td><%- BEAM.YBEAM ? BEAM.YBEAM : '- -' %></td>
            </tr>

But the refined position is backwards... with refined beams switched from x,y to y,x:

<td><%- BEAM.REFINEDYBEAM ? BEAM.REFINEDYBEAM : '- -' %></td>
<td><%- BEAM.REFINEDXBEAM ? BEAM.REFINEDXBEAM : '- -' %></td>

and there is even a comment in the code from @stufisher from 7 years ago wondering why:

 <!-- these are flipped, not sure why? -->

The delta calculations are also messed up:

<td>&Delta;</td>
<td><%- BEAM.REFINEDYBEAM && BEAM.XBEAM ? (BEAM.XBEAM - BEAM.REFINEDYBEAM).toFixed(2) : '- -' %></td>
<td><%- BEAM.YBEAM && BEAM.REFINEDXBEAM ? (BEAM.YBEAM - BEAM.REFINEDXBEAM).toFixed(2) : '- -' %></td>

I think the root of the problem comes from fast_dp swapping the refined beam positions from the initial starting ones.

So it appears that at some point instead of hunting down the root of the problem, someone just swapped the variable in the SynchWeb code.

I first noticed this oddity when I started upserting autoPROC.xml results and saw that the start and refined beam_x/y positions were swapped. I thought maybe autoPROC was somehow misinterpreting our image headers etc. etc. but I now think autoPROC is doing things correctly and fast_dp has flipped the refined beam_x/y and that SynchWeb then flips them back in order to display the results to the users.

autoPROC will present the values as used during actual processing. This can be identical to meta-data from the raw diffraction data (especially if the raw diffraction data contains a fully self-contained and well defined description of the whole experiment).

However, we also maintain a database of known instrument configurations (based on timestamp and detector ID) to potentially swap values for a consistent description ... most of the time to have detector X/Y axes as (1,0,0) and (0,1,0) - but other systems are possible.

One historic note: MOSFLM and XDS direct beam conventions were very often swapped: see also here.

... not sure this helps here with regard to fast_dp (of which I have no experience) ...

No real fix expected. There are so many detector conventions for beam center and different transformations that happen in various software packages. I'll assume the code as-is works fine for DLS.