ExperimentalDesign cannot express two multiplexing dimensions (SILAC inside TMT), and the QPX guard for it is untested

Start with ExperimentalDesign.cpp, especially isValid_(), setMSFileSection(), and the fromConsensusMap/fromFeatureMap/fromIdentifications factories. Then read ProteinGroupArrowExport_impl.h, ProteinGroupArrowExport.cpp, QPXCollectionExport.cpp, and their tests; run the relevant exporter tests. Done means the inconsistent derived-design behavior is resolved or explicitly decided, and the guard is covered with a two-header, one-file fixture through both export paths.

Two multiplexing dimensions in one experiment — SILAC nested inside TMT channels — cannot be expressed in an ExperimentalDesign, and the guard that would catch such a design in the QPX exporter is untested. Filing to double-check whether the limitation is intended and whether the guard is reachable.

[!NOTE]
Status 2026-08-08 — re-verified against develop 1131d8f618.

Question 1 is answered: the limitation stands, and it is not just an OpenMS one. Per @jpfeuffer: the shape was never anticipated when ExperimentalDesign was written, no OpenMS tool can handle it (IsobaricWorkflow has no notion of a 3D feature, and its quantifier knows nothing about labelling-mod → sample), and QPX cannot express it either — its label would have to be split into channel × labelling-mod, or concatenated (H_126N, L_126N, …). Supporting it would mean a design-model change, a QPX-model change and a FeatureFinderMultiplex-style mass-shift check, in that order. Filed as an observation from an SDRF/ExperimentalDesign consistency sweep, not as a request — not planned.

Questions 2 and 3 are still open, and both were re-confirmed today. They are small, local, and independent of the SILAC-in-TMT question that produced them — they are the part of this issue worth acting on.

Line drift: the loader throw is now ExperimentalDesign.cpp:770 (was :712).

The data shape

bigbio/sdrf-annotated-datasets datasets/PXD040455/PXD040455.sdrf.tsv (1178 rows, CI-validated) puts a SILAC pair inside every TMT channel:

('Chip1_K562HeLa_F2.raw', 'TMT127N') -> ['Chip1_F2_TMT127N_heavy', 'Chip1_F2_TMT127N_light']

Measured over the whole file: 551 of 627 (comment[data file], comment[label]) pairs carry more than one source name. So the isobaric channel alone does not identify the sample — it takes (channel, SILAC state).

Where it stops

1. sdrf-pipelines crashes. parse_sdrf convert-openms -s PXD040455.sdrf.tsv -t1 -l (0.1.6):

File ".../sdrf_pipelines/parse_sdrf.py", line 93, in openms_from_sdrf
    raise ValueError(msg) from ex
ValueError: Error: list index out of range

No design is produced and the message says nothing about the cause. Reporting separately against sdrf-pipelines; noting it here because it means the shape cannot reach OpenMS through the SDRF route today.

2. The OpenMS loader refuses it. ExperimentalDesign has a single Label column, so both dimensions have to share it. Hand-writing the shape:

Fraction_Group  Fraction  Spectra_Filepath  Label  Sample
1               1         Chip1_F2.mzML     1      1
1               1         Chip1_F2.mzML     1      2      <- same channel, SILAC partner

throws at src/openms/source/METADATA/ExperimentalDesign.cpp:770 (inside isValid_, :747–):

(Fraction Group, Fraction, Label) combination can only appear once

So this class of experiment cannot be analysed by ProteomicsLFQ / ProteinQuantifier / IsobaricWorkflow via a design file at all.

The bit I would like double-checked

ProteinGroupArrowExport's QPX 1.1 quantification-unit model assumes (run, label) -> one sample, and refuses otherwise:

the experimental design assigns several samples to one (run file, label) combination

Given the loader refuses the same shape first, that guard looks unreachable from a loaded design — but it is not unreachable in general, because ExperimentalDesign::fromConsensusMap() does not run isValid_(). Two column headers on one file with the same channel_id but different sample_name meta values produce duplicate (path, label) rows with different samples, and nothing rejects them.

Both halves re-confirmed on 1131d8f618:

• isValid_() has exactly one caller: the two-argument ExperimentalDesign(msfile_section, sample_section) constructor (ExperimentalDesign.cpp:41-49). setMSFileSection (:608-612) only assigns and calls sort_() — it does not validate. fromConsensusMap (:98-191), fromFeatureMap and fromIdentifications all build through setMSFileSection, so none of the three derived-design paths is validated at all. In fromConsensusMap the duplicate arises in the sample_name branch (:160-173), which maps each distinct sample_name to its own index with no uniqueness constraint on (path, label).
• The guard itself is units.inconsistent() — set at ProteinGroupArrowExport_impl.h:132 (if (!inserted && it->second != entry.sample)), read at ProteinGroupArrowExport.cpp:251 and mirrored at QPXCollectionExport.cpp:106. Still no test exercises it. ProteinGroupArrowExport_test.cpp and QPXCollectionExport_test.cpp between them pin raggedUnit, missingCell, invalidSample, ambiguousLabel, droppedRuns and the merge-index refusal — but nothing builds two headers on one file that disagree about the sample.

Adjacent and already handled, so do not conflate the two: ExperimentalDesign::annotateColumnHeaders (:51-, added by #9836) does guard the reverse collapse — two headers of one file resolving to the same design row, which is what the Multiplex tools produce when a light/heavy pair has no channel_id and both collapse onto label 1. That is a different failure and it is covered.

Questions:

1. Is the single-Label limitation intended and permanent? Answered — see the status note at the top. It is a real limitation of the OpenMS design model and of QPX's label; supporting SILAC-in-TMT is a multi-repository model change and is not planned.
2. (open, and wider than first stated) Should the derived-design factories validate what the file loader validates? It is not only fromConsensusMap — fromFeatureMap and fromIdentifications skip isValid_() too, because all three go through setMSFileSection and only the constructor validates. Right now a programmatically built design can hold a shape that a design file cannot, and that is the only route by which the exporter guard below can fire.
3. (open) The exporter guard has no test. Worth pinning precisely because the only route to it is the unvalidated one: a test has to build the ConsensusMap directly, since no design file can produce the shape.

Suggested definition of done for 2 and 3. For 3: a ProteinGroupArrowExport_test section that builds one file with two column headers sharing a channel_id and carrying different sample_name values, and asserts the export refuses with the "several samples to one (run file, label)" message — plus the same through QPXCollectionExport::requireExportable. For 2: decide whether fromConsensusMap should reject or repair; if it rejects, 3's test has to move to a hand-built ExperimentalDesign instead, so do 3 first and let its fixture tell you what 2 would break.

Reproduce

curl -sL https://raw.githubusercontent.com/bigbio/sdrf-annotated-datasets/main/datasets/PXD040455/PXD040455.sdrf.tsv -o PXD040455.sdrf.tsv
python3 - <<'PY'
import csv, collections
rd=list(csv.DictReader(open('PXD040455.sdrf.tsv'), delimiter='\t'))
cell=collections.defaultdict(set)
for r in rd: cell[(r['comment[data file]'], r['comment[label]'])].add(r['source name'])
print(len(cell), 'pairs;', sum(1 for v in cell.values() if len(v)>1), 'with >1 source name')
PY

Found while making the QPX -out_qpx pg view spec-conformant for bigbio/qpx#220 (see #9817).