Spørgsmål:
Betydning af FORMAT-felterne i VCF-filen, der kommer fra GIAB-projektet
J. Velazquez-Muriel
2018-06-27 21:56:17 UTC
view on stackexchange narkive permalink

Efter at have læst GIAB-papiret i https://www.biorxiv.org/content/early/2018/05/25/281006 og dets figur 1, har jeg stadig problemer med at forstå dataene inde i GIAB VCF-filen til HG001 (HG001_GRCh38_GIAB_highconf_CG-IllFB-IllGATKHC-Ion-10X-SOLID_CHROM1-X_v.3.3.2_all.vcf). Især skal jeg forstå de oplysninger, der førte til en FILTER-værdi af PASS for nogle varianter.

Den første sag, som jeg gerne vil diskutere, er følgende variant: 

  chr1 110176467. AG 50 PASS-platforme = 3; platformnavne = Illumina, CG, 10X; datasæt = 3; datasætnavne = HiSeqPE300x, CGnormal, 10XChromium; kaldesæt = 4; kaldesætnavne = HiSeqPE300xGATK, CGnormal, HiSeqPE300xfreebayes, 10XGATKhapplo; = CS_HiSeqPE300xGATK_callable, CS_CGnormal_callable, CS_HiSeqPE300x freebayes_callable GT: PS: DP: ADALL: AD: GQ 0/1:.: 512: 114,106: 145,148: 760

Oversættelse til engelsk i informationen, oversættelse af oplysningerne i informationen i den dette er hvad jeg får:

  • Vi overvejede data fra følgende sekventeringsteknologier: Illumina, CG, 10X, IonExome, SolidPE50x50bp og SolidSE75bp.
  • Af dem manglede nogle af dem (IonExome, SolidPE50x50bp, SolidSE75bp) opkaldet, så vi kasserede dem.
  • Derfor kommer dataene til varianten fra 3 platforme (Illumina, CG, 10X), 3 datasæt (HiSeqPE300x, CGnormal, 10XChromium) og 4 kaldesæt (HiSeqPE300xGATK, CGnormal, HiSeqPE300xfreebayes, 10XGATKhap ), fordi vi analyserede data fra HiSeqPE300x med GATK og også med Freebayes.
  • Imidlertid havde opkaldssættene fra CS_HiSeqPE300xGATK, CS_CGnormal og CS_HiSeqPE300x freebayes dette opkald i en region med lav dækning af høj MQ-læsning. li>
  • På tværs af alle platforme kommer DP = 512
  • ADALL (Værdier 114,106) kommer fra “alle” datasættene. Er disse “alle” sættet (HiSeqPE300x + Cgnormal + 10XChromium), eller sættet (Illumina + CG + 10X + IonExome + SolidPE50x50bp + SolidSE75bp).
  • AD (værdier 145,148) kommer fra de samme "alle" datasæt som ADALL, men de er ufiltrerede, så 145> 114 og 148> 106.

Alt dette giver mening, men jeg vil gerne vide, hvilken sag i figur 1c, der blev anvendt for at nå frem til PASS-værdien.

Den anden variant, som jeg gerne vil nævne, er denne: 

  chr1 5705293. TC 50 PASS-platforme = 3; platformnavne = Illumina, CG, 10X; datasæt = 3; datasætnavne = HiSeqPE300x, CGnormal, 10XChromium; opkaldssæt = 4; kaldesætnavne = HiSeqPE300xGATK, CGnormal, HiSeqPE300xfreebayes, 10XGATKhpall; = CS_HiSeqPE300xGATK_callable, CS_CGnormal_callable, CS_HiSeqPE300x freebayes_callable; filt = CS_HiSeqPE300xGATK_filt GT: PS: DP: ADALL: AD: GQ 0/1:.: 599: 121,139:  oversættelse ville være:  
     
  •  
     Vi overvejede data fra følgende sekventeringsteknologier: Illumina, CG, 10X, IonExome, SolidPE50x50bp og SolidSE75bp. 
  •  
     Af dem manglede nogle af dem (IonExome, SolidPE50x50bp, SolidSE75bp) opkaldet, så vi kasserede dem. 
  •  
     Derfor kommer dataene til varianten fra 3 platforme (Illumina, CG, 10X), 3 datasæt (HiSeqPE300x, CGnormal, 10XChromium) og 4 kaldesæt ( HiSeqPE300xGATK, CGnormal, HiSeqPE300xfreebayes, 10XGATKhaplo), fordi vi analyserede data fra HiSeqPE300x med GATK og også med Freebayes. 
     
    •  
  •  Opkaldssættene fra CS_HiSeqPE300xGATK, CS_CaCe, CS_Ca region med lav dækning af høj MQ-læsning. 
    •  
  •  Data fra CS_HiSeqPE300xGATK_filt blev også filtreret / kasseret 
    •  
  •  På tværs af alle platforme, DP = 599 
    •  
  •  ADALL ( Værdier 121,139) kommer fra “alle” datasættene. Jeg antager (Cgnormal + 10XChromium), fordi CS_HiSeqPE300xGATK_filt blev filtreret. 
    •  
  •  AD (Værdier 49,28) er ufiltrerede. 
    •  


 Men bemærk at 49<121 og 28<139. Hvorfor kommer der mindre ufiltrerede læser (AD)? Bør det ikke være tilfældet, at AD> ADALL i alle tilfælde? 
 
 Jeg ved ikke, hvordan jeg kan forene de to varianter. Leverer de ikke modsat information i AD og ADALL felterne? Hvilke specifikke datasæt og kaldesæt er involveret i at få AD og ADALL til hver variant? 
 
 Jeg vil også sætte pris på svarene på et par andre spørgsmål: 
  •  
     Hvorfor er disse to varianter en PASS, hvis der er 3 "kaldbare" datasæt i regioner med lav dækning? 
  •  
     Har varianterne fulgt en voldgiftsproces? Jeg antager ikke, hvis INFO-flaget "arbitreret" mangler. 
     
    •  
 
 Til reference er her beskrivelserne i overskriften på VCF-filen, som jeg har brugt: 
 
  ## INFO = <ID = platforme, nummer = 1, type = heltal, beskrivelse = "antal forskellige platforme, hvor mindst et kaldesæt kaldte denne genotype, uanset om det var filtreret eller ikke" > ## INFO = <ID = platformnavne, Number =., Type = String, Beskrivelse = "Navne på platforme, for hvilke mindst et kaldesæt kaldte denne genotype, uanset om de var filtreret" > ## INFO = <ID = datasæt, Number = 1, Type = Heltal, Beskrivelse = "Antal forskellige datasæt, hvor mindst et opkaldssæt kaldte denne genotype, uanset om det var filtreret" > ## INFO = <ID = datasætnavne, Number =., Type = String, Beskrivelse = "Navne på datasæt, til hvilke mindst et kaldesæt kaldte denne genotype, uanset om den var filtreret eller ikke "> ## FORMAT = <ID = ADALL, Number = R, Type = Integer, Description =" Netto alleldybder på tværs af alle da tasets "> ## FORMAT = <ID = AD, Number = R, Type = Heltal, Beskrivelse =" Netto alleldybder på tværs af alle ufiltrerede datasæt med kaldet genotype "> ## FORMAT = <ID = DP, Number = 1, Type = Integer Beskrivelse = "Samlet læsedybde opsummeret på tværs af alle datasæt, undtagen MQ0 læser" >
## INFO = <ID = datasetsmissingcall, Number =., Type = Integer, Description = "Navne på datasæt, der mangler et opkald eller har et forkert opkald på dette sted, og opkaldet med høj tillid er en variant" > ## INFO = <ID = kaldbar, nummer =., Type = streng, beskrivelse = "Liste over opkaldssæt, der havde dette opkald i en region med lav dækning med høj MQ-læsning." > ## INFO = <ID = filt, Number =., Type = Streng, beskrivelse = "Liste over opkaldssæt, der havde filtreret dette opkald." > ## INFO = <ID = arbitreret, Number = 1, Type = String, Description = "TRUE hvis kaldesæt havde uoverensstemmende opkald, så der var behov for voldgift." >
To svar:
Bioathlete
2018-06-28 02:35:14 UTC
view on stackexchange narkive permalink

Filtreringskriterierne skal defineres i overskriften på VCF-filen. Kan du medtage overskriften fra din VCF-fil?

VCF-format og eksempelhoved: 

  FILTER, der er anvendt på dataene, skal være beskrevet som følger: ## FILTER = <ID = ID, Beskrivelse = ”beskrivelse” >

header: 

  ## fileformat = VCFv4.0 ## fileDate = 20090805 ## source = myImputationProgramV3.1 ## reference = 1000GenomesPilot-NCBI36 ## phasing = partial ## INFO = <ID = NS, Number = 1, Type = Integer, Description = "Antal prøver med data" > ## INFO = <ID = DP, Number = 1, Type = Heltal, Beskrivelse = "Total dybde" > ## INFO = <ID = AF, Number =., Type = Float, Beskrivelse = "Allelfrekvens" > ## INFO = <ID = AA, Number = 1, Type = String, Description = "Ancestral Allele" > ## INFO = <ID = DB, Number = 0, Type = Flag, Description = "dbSNP membership, build 129" > ## INFO = <ID = H2 , Number = 0, Type = Flag, Beskrivelse = "HapMap2-medlemskab" > ## FILTER = <ID = q10, Beskrivelse = "Quality be lav 10 "> ## FILTER = <ID = s50, Beskrivelse =" Mindre end 50% af prøverne har data "> ## FORMAT = <ID = GT, Number = 1, Type = String, Beskrivelse =" Genotype "> ## FORMAT = <ID = GQ, Number = 1, Type = Heltal, Beskrivelse = "Genotypekvalitet" > ## FORMAT = <ID = DP, Number = 1, Type = Heltal, Beskrivelse = "Læs dybde" > ## FORMAT = <ID = HQ , Number = 2, Type = Integer, Description = "Haplotype Quality" >
Tak for hjælpen. Jeg har sendt de overskriftsfelter, som jeg har problemer med.
Geraldine_VdAuwera
2020-04-23 22:49:56 UTC
view on stackexchange narkive permalink

For dit andet spørgsmål tror jeg ikke, at varianten matcher nogen af ​​eksemplerne vist i figur 1c. Bemærk, at panelets billedtekst siger, at det viser fire eksempler på voldgift. Efter dit sidste subspørgsmål tror jeg ikke, at denne variant blev udsat for voldgift.

For dit andet spørgsmål mener jeg, at subtiliteten er i feltbeskrivelserne:

ADALL = Netalleldybder på tværs af alle datasæt

AD = Netto alleldybder på tværs alle ufiltrerede datasæt med kaldet genotype

Min forståelse er, at ADALL er en optælling af alleldybder, der inkluderer prøver, hvor varianten blev filtreret ud, eller genotypen ikke var overensstemmelse; noget dertil. Så generelt ville jeg forvente ADALL> AD.

Jeg er ærligt talt ikke helt sikker på, hvad de betyder med "ufiltrerede datasæt". Det kan betyde "at tælle alle læsninger uden at filtrere efter kvalitet" eller "kaldesæt, hvor variantfiltrering endnu ikke var anvendt". Måske er der en anden subtilitet der, der forklarer, hvorfor de to varianter har modsatte AD vs ADALL-proportioner.

For dine yderligere spørgsmål:

Hvorfor er disse to varianter en PASS, hvis der er 3 "kaldbare" datasæt i regioner med lav dækning?

Ifølge papiret er det ikke diskvalificerende at have varianten i regioner med lav dækning, hvis genotypeopkaldene er konkordante, hvilket giver mening for mig. Lav dækning gør mig mere mistænksom, men hvis flere opkaldssæt er enige, er jeg stadig villig til at betragte opkaldet som godt (medmindre de selvfølgelig alle udviser den samme fejltilstand, hvilket er den største potentielle svaghed ved konsensusmetoden, der bruges af GiaB ).

Har varianterne fulgt en voldgiftsproces? Jeg antager ikke, hvis INFO-flaget "arbitreret" mangler.

Højre, hvis dette flag ikke er til stede, betyder det, at voldgift ikke var nødvendig / anvendt.

Tak. Jeg tror også, at der er en subtilitet et eller andet sted. Logisk er det ikke fornuftigt, at ADALL> AD, uanset om det kaldes eller ej.


ⓘ
Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 4.0-licens, den distribueres under.
Loading...