The value means three different things at once. It is the unit of writer parallelism - whole files go round-robin to the writers, (image_number / images_per_file) % socket.size() in ZMQStream2Pusher::SendImage and TCPStreamPusher - it multiplies writer memory linearly, since every data-file plugin reserves per file, and it decides whether a legacy master is readable at all, because dxtbx follows only the first data file of one. That last point is what makes a flat default wrong. Measured with DIALS on a 2500-image rotation sweep written as legacy: split into five files it reports 2500 images and then raises IndexError beyond image 499, so it half-works silently; in one file all 2500 read. AutoPROC does not read VDS, so legacy has to stay the default, which leaves the file count as the only lever. So make it optional and resolve it from the acquisition. A rotation sweep of at most 20000 images goes into one data file - rotation datasets are small enough, and one writer keeps up with them. A grid scan splits on whole fast-axis rows, so a file is a meaningful piece of the grid. Stills and serial keep 1000, where the image count far exceeds it and the parallelism and the bounded writer memory are what matter. An explicit value is always taken literally. GetImagesPerFile is the single place this is resolved, and it must always return a fixed non-zero number, because everything downstream - receiver, pusher, puller, writer - requires one. That was already true of the old 0 = "one file" spelling; 0 is now gone from the API and omitting the field says the same thing better. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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:
esbuildGHSA-gv7w-rqvm-qjhr is a Deno-specific RCE viaNPM_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.wsGHSA-96hv-2xvq-fx4p only matters whensimple-websocketopens 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.