Files
Jungfraujoch/frontend
leonarski_f 54f2de31bb grid scan: say how the stationary spindle angle is stated, and pin it
A grid scan is a set of stills at a stationary spindle, and the angle it stood
at is what relates one grid to another taken elsewhere on the circle. Users were
finding an all-zero omega in the file and concluding the angle could not be
recorded at all.

It already can, and has since the goniometer and the grid scan stopped being
alternatives: send the axis with step 0 and its start angle, and that angle is
written per image into the NXmx sample chain, read back by reader/, and taken by
dials.import as a set of stills. Measured on a generated 12-image grid: the
placeholder file carries omega = 0 x 12, the same file with the axis sent at
step 0 carries omega = 90 x 12, and dials.import reports "still: 1, sweep: 0"
for both. Nothing in the code needed changing, so nothing was; what was missing
was that nobody could tell, and that no test held the behaviour down.

So: the API and the HDF5 documentation now say it in as many words, and three
tests pin the three legs the value crosses - the OpenAPI request (which used to
drop the grid scan whenever an axis was present, unpinned until now), the CBOR
start message, and the file round trip.

Also corrects a claim two comments and the HDF5 page were making. NXmx can
express "no rotation" perfectly well - a sample may depend_on "." - so the
placeholder is not there for the standard's sake. It is there because dxtbx
cannot read a sample chain of translations alone: strip the rotation axis from a
grid scan master and dials.import dies in get_dxtbx_goniometer with a matmul
dimension mismatch. Recorded so nobody removes the placeholder on the strength
of the standard.

One thing the change does not fix, because it cannot: a stationary angle is
invisible to DIALS when a grid scan is present. dxtbx picks the first varying
axis as the scan axis, which is a grid translation, so the oscillation reads
(0, 0); and with exactly one rotation axis in the chain it builds a single-axis
goniometer whose fixed rotation is the identity, never consulting the angle. The
same angle IS visible when it is the only candidate (oscillation reads (90, 0))
or when a Smargon head puts a second rotation axis in the chain (the setting
rotation then carries it). The value is in the file and correct either way.
2026-09-02 11:04:29 +02:00
..
2026-07-11 07:19:11 +02:00
2026-06-23 20:29:49 +02:00
2024-10-05 13:14:49 +02:00
2025-11-28 12:47:35 +01:00
2026-06-23 20:29:49 +02:00
2026-08-31 09:11:22 +02:00
2026-08-31 09:11:22 +02:00
2026-06-16 14:13:29 +02:00
2024-10-05 13:14:49 +02:00
2024-10-05 13:14:49 +02:00
2024-10-05 13:14:49 +02:00

Jungfraujoch Frontend

Building

To build web interface:

cd frontend_ui
npm install
npm run openapi
npm run build

Available Scripts

In the project directory, you can run:

npm start

Runs the app in the development mode.

The page will reload if you make edits.
You will also see any lint errors in the console.

npm test

Launches the test runner in the interactive watch mode.
See the section about running tests for more information.

npm run build

Builds the app for production to the dist folder.
It correctly bundles React in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes.
Your app is ready to be deployed!

npm run openapi

npm audit findings

npm audit currently reports 17 advisories (3 high, 13 moderate, 1 low). All of them live in build-time tooling and never reach the production bundle shipped to the browser. Summary of the chains:

Source dep Vulnerable transitives When it runs
@redocly/cli @opentelemetry/*, dompurify (via redoc), ws (via simple-websocket), js-yaml, protobufjs, @babel/core npm run redocly / redocly4broker — static OpenAPI HTML generation
vite esbuild@0.27.x Dev server and dep pre-bundling. Production build uses Rollup.
vite-plugin-svgr @babel/core, js-yaml (via cosmiconfig) Vite build plugin
openapi-typescript-codegen js-yaml npm run openapi — TS client generation

Notes on the high-severity items:

  • esbuild GHSA-gv7w-rqvm-qjhr is a Deno-specific RCE via NPM_CONFIG_REGISTRY; GHSA-g7r4-m6w7-qqqr is an arbitrary-file-read in the dev server on Windows. Neither applies to a Linux build of the production bundle.
  • ws GHSA-96hv-2xvq-fx4p only matters when simple-websocket opens a socket, which happens during docs generation, not at runtime.

npm audit fix cannot resolve any of these without downgrading @redocly/cli (no real fix) or jumping vite to a major that switches the bundler to Rolldown.