Read the PROCNO spectroscopy fids as interleaved float64 - #212
Merged
Conversation
`ruff format --check` reported twelve files as unformatted, so any change touching one of them dragged unrelated reflow into its diff. Run the formatter once, on its own, so subsequent changes show only what they actually change. Formatting only: no behaviour changes, and `ruff check` is clean before and after. The suite is unchanged at 2140 passed, 12 skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017SNrm3jFhpTPShP8xGkePC
fid_proc/"64" was declared a supported dataset type but wired to the raw-fid
recipe set, so on PV360 the word type resolved to int32 through
ACQ_word_size and the storage shape came from the acquisition block model
(block_size = ACQ_jobs[0][0], block_count = NI*NR). The computed size was
exactly half the real file, and every fid_proc.64 in the corpus was rejected:
InvalidDataset: expected 16384 bytes for shape (4096, 1) and dtype int32,
got 32768 bytes
Had the two sizes coincided the file would have been silently reinterpreted
as int32 noise instead.
Spec 3.5 describes these as 64-bit doubles with real and imaginary
interleaved, 8 * 2 * PVM_SpecMatrix bytes -- one complex pair per spectral
point -- so give them recipes of their own: float64 from BYTORDA, the point
count from PVM_SpecMatrix (falling back on the file when the method omits
it), and SchemaFidCompanion, which already decodes exactly this shape. The
id names the reconstruction, as a 2dseq id does, because these live in the
PROCNO rather than the EXPNO.
fid_refscan.64, listed in the same spec row, was not a supported type at all;
it is the same format, so it shares the recipes.
All ten .64 files in the corpus now load as 2048-point complex spectra,
matching their PVM_SpecMatrix. Folder discovery is unchanged -- its default
dataset_index is fid/2dseq/rawdata -- so nothing else moves.
Closes isi-nmr#198
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017SNrm3jFhpTPShP8xGkePC
gdevenyi
force-pushed
the
fix/fid-proc-64
branch
from
August 8, 2026 20:51
7684b41 to
45056bf
Compare
Contributor
Author
|
Rebased onto #213 ( Integration check across all eleven conformance PRs merged together: 2164 passed, 12 skipped; corpus load test 3202 → 3207 of 3478 with zero newly broken datasets. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #198.
Spec 3.5:
fid_proc/"64"was declared supported but wired to the raw-fidrecipe set, so on PV360 the word type resolved toint32viaACQ_word_sizeand the shape came from the acquisition block model. The computed size was exactly half the file:Had the two coincided the file would have been silently reinterpreted as int32 noise.
Change
properties_fid_proc_core.json/_custom.json: float64 fromBYTORDA, the point count fromPVM_SpecMatrix(falling back on the file when the method omits it), and an id that names the reconstruction as a2dseqid does — these live in the PROCNO.SchemaFidCompaniondecodes them; it already handles exactly this shape, so no new schema.fid_refscan.64, listed in the same spec row, was not a supported type at all. Same format, same recipes.All ten
.64files in the corpus now load:matching each scan's
PVM_SpecMatrix = 2048.Folderdiscovery is unchanged — its defaultdataset_indexisfid/2dseq/rawdata— so nothing else moves.Test
test_the_procno_spectroscopy_fids_are_interleaved_float64, parametrized over both stems: writes a known 8-point complex spectrum interleaved as float64 and asserts it reads back exactly. Both fail on master.Suite: 2140 passed, 12 skipped.