copy_number_findings
Read-only
Scan every indexed chromosome of an Affymetrix copy-number container and report what the file itself called: gains, losses and stretches of homozygosity, with their positions, marker counts and spans, plus a per-chromosome summary. Reads the file's own CNState and LOH columns and infers nothing — for a second opinion computed from the log2 ratios, use copy_number_segment. A chromosome that was read and carries nothing is reported as clean, which is a different answer from one that could not be read. NO GENOME BUILD IS ASSUMED: positions are the file's own.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | which copy-number file in this project, by name. Unset, it is the project's only one — and it refuses rather than guessing when there is more than one. | |
| _files | No | The project: record references shaped like _subject. Their records become library documents a tool names in sequences/parts/document; a trace or alignment is found by file name. | |
| _subject | No | The record to act on: exactly one of sequence, accession (+source), sample (an id from list_samples) or file ({name, text} or {name, base64}); record_index picks one record of several. | |
| data_set | No | which data set to scan, by name. Unset is the file's FIRST, which is what the panel opens on. | |
| min_bases | No | ignore any run spanning fewer bases than this. Default 0, for the same reason as min_markers. Note a single-marker run spans 0 bases. | |
| min_markers | No | ignore any run shorter than this many markers. The default counts everything the file called, including single markers, because a reporting floor belongs to the laboratory and not to this tool. |
Output Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| bed | Yes | the same calls as a UCSC BED track, ready for IGV, the UCSC browser or bedtools: 0-based half-open, one row per finding, colored by kind through itemRgb, with the producer's confidence in the score column (0 where the file states none) and the genome build on the `track db=` line when the container names one. The JSON `findings` above carry the file's own inclusive marker positions; this output is the same calls converted once, by the same writer the Export panel uses | |
| source | Yes | which route answered: `segments` means the producer's own segment calls, which is what a CYCHP written by ChAS carries; `markers` means the per-marker state columns, which is what a CNCHP carries. Different provenance for the same question, so a pipeline comparing two files can tell which it got | |
| summary | Yes | what was found, across how many chromosomes and markers | |
| findings | Yes | every gain, loss and stretch of homozygosity, as the file called them: kind, chromosome, startPosition, endPosition, markerCount, bases, and — where the file states them — state and stateLabel (the copy-number state; absent on an LOH finding, which is not a copy-number call), confidence (the producer's own, 0..1) and mixture (mosaic fraction, signed as the file signs it, so a mosaic loss and a mosaic gain stay distinguishable). No cytoband: naming a band needs a genome build, and this node is given none | |
| chromosomes | Yes | per chromosome: markers read, and the counts and spans of gains, losses and LOH runs |