Find corpus samples for SYNAPT G2-S/G2/bare (HDMS and MS mode) to resolve #11

[Nathan-D-R]

#11 was closed as won't-fix because no reliable in-file signal exists to distinguish HDMS from MS acquisition mode for SYNAPT G2-S/G2/bare models, and more fundamentally because the corpus has zero sample files for any of these three models. This issue tracks acquiring real samples so #11 can be reopened and actually resolved.

What's needed: at least one HDMS-mode and one MS-mode .raw bundle from the same model (G2-S, G2, or bare SYNAPT), so the two can be diff'd the way PXD066594/PXD068881 (SYNAPT G2-Si IMS) were diffed against PXD058812/PXD075602 (non-IMS) during the original format RE work.

Where to look: PRIDE, filtered by instrument CV accession (same approach used to build the existing corpus - see re/CHATLOG.md's PRIDE instrument-CV filtering). The relevant accessions per psi-ms.obo:

• SYNAPT G2-S: MS:1001779 (HDMS) / MS:1001780 (MS)
• SYNAPT G2: MS:1001777 (HDMS) / MS:1001778 (MS)
• SYNAPT (bare): MS:1001781 (HDMS) / MS:1001782 (MS)
• SYNAPT G1 (older, separate terms, lower priority): MS:1003508 (HDMS) / MS:1003510

Ideally find a matched HDMS/MS pair from the same lab or even the same project (some PRIDE submissions include both acquisition modes for comparison), since that gives the cleanest diff. A single sample of any of these six accessions would still be useful for confirming the _HEADER.TXT Instrument: string format for these models, which is currently unknown (the corpus's one bare-QTOF sample reports Instrument: QTOF, not a Synapt string).

Once a sample is in hand: check whether _HEADER.TXT, _extern.inf, or _FUNCTNS.INF carries any field that differs between the HDMS and MS acquisition of the same instrument - that's the actual open question from #11.

[Nathan-D-R]

Found real corpus samples for two of the three target models, including a matched HDMS/MS pair from the same physical instrument, and confirmed a genuine in-file signal distinguishing acquisition mode.

Instrument strings (previously unknown per this issue)

Confirmed _HEADER.TXT's Instrument: field format for these models:

• Bare SYNAPT G2: SYNAPT-G2#<serial> (hyphenated, no space)
• SYNAPT G2-S: SYNAPT G2-S#<serial> (space before model)
• SYNAPT G2-Si (already known): SYNAPTG2-Si#<serial> (no space/hyphen)
• Bare SYNAPT (pre-G2, PXD021056/PXD013039, ~2013): field is completely empty. _extern.inf for these also uses an older/different schema (V Mode reflectron terms, Maldi fields, no IMS-hardware fields at all). Inconclusive whether this is genuinely bare-SYNAPT-HDMS hardware or a PRIDE mistag - lowest priority per the issue text, didn't chase further.

Matched HDMS/MS pair (SYNAPT G2-S#UEA042, same lab/instrument)

• PXD002393 / S130426_21.raw - MS mode (Res+ MSE 110min 06.EXP)
• PXD001175 / S121126_06.raw - HDMS mode (Res+ IMSE 120min 06.EXP)

Diffing _extern.inf: the HDMS file has a [MOBILITY] block under every Function Parameters section (Use Precursor Drift Times, Maintain Mobility Separation, Override IMS/Transfer Wave Velocity, etc.) that's completely absent from the MS-mode file - same instrument, same lab, only the acquisition mode differs. This is the first confirmed same-hardware signal distinguishing HDMS from MS acquisition, i.e. an actual answer to this issue's open question.

_FUNCTNS.INF (binary, 1248 bytes / 3 functions) also differs between the pair at consistent byte offsets, not yet decoded to a specific field - flagging for a follow-up if that file ever needs full decoding.

Caveat: this doesn't generalize cleanly. A second pair on bare G2 (PXD001123 DDA/MS vs PXD009047 IMMSeHi/nominal-HDMS, 2010-2016, different serials) shows neither file has a [MOBILITY] block or any IMS-hardware fields at all, regardless of the method name implying mobility. Both use a reduced _extern.inf schema that's missing the IMS section entirely - looks tied to a MassLynx/instrument-config generation, not to acquisition mode universally. Treat the UEA042 finding as "signal confirmed to exist in at least one real config," not "solved for all G2/G2-S data."

Method

PRIDE's project-level instruments CV tags are unreliable for per-file identity - e.g. PXD036904 is tagged "Synapt G2-S MS" at the project level, but its actual Waters bundle reports SYNAPTG2-Si#UGA455 (a G2-Si, already in corpus), and one of its other "raw" files was actually a Thermo Finnigan single-file RAW mixed into the same project. Had to check each candidate's real _HEADER.TXT, not just the project tag.

To avoid full multi-GB downloads just to read a few KB of header text, wrote a small HTTP-Range-based partial zip reader against PRIDE's FTP-over-HTTPS mirror (confirmed Accept-Ranges: bytes) that pulls only named entries from a remote zip's central directory. Made it practical to survey ~30 candidate projects.

Corpus additions

Added to corpus/ (metadata-only - _HEADER.TXT/_extern.inf/_FUNCTNS.INF only, not the full scan-data bundle; each has a NOTE.txt with the full-fetch command):

• PXD002393/S130426_21.raw (G2-S, MS mode)
• PXD001175/S121126_06.raw (G2-S, HDMS mode)
• PXD001123/SiRNA_21-2.raw (G2, MS/DDA mode)
• PXD009047/110810_UCA114_CD_JN018_02.raw (G2, nominal HDMS/IMMSeHi mode)
• PXD021056/W32517MP.raw (bare SYNAPT?, Instrument field empty)

Full writeup with all the peeked header/extern.inf diffs is in re/CHATLOG.md (local, gitignored).

Given the [MOBILITY] block signal is confirmed on a real matched pair, I'd suggest reopening #11 to implement the disambiguation using that field, scoped to instrument configs where _extern.inf has the fuller field set (and documenting the caveat for older/reduced-schema configs).