Plink behavior when bim-files contain zeroes instead of allele codes?

[Endre Bakken Stovner]

I have an old plink binary file, which bim file sometimes contains zeroes instead of allele codes, like so:

1       rs28645431      0       1911558 0       0
1       rs2459994       0       2024064 T       C 

It seems like plink rejects these snps when processing the file (desired behavior from my point of view), and they are not further processed nor outputted in the new files made.

Is this "conscious" behavior or a serendipitous fluke?

And has zero in the bim files ever had any meaning that you know of?

 

[Christopher Chang]

Zero indicates missing.  In the old .ped format, a missing call was indicated by "0 0".  A .bim file should only have both allele codes set to '0' when every sample has a missing call at that site.  More commonly, when every sample is homozygous major at a site, PLINK might not have any of knowing what the minor allele is supposed to be (for example, the old .ped/.map format didn't keep track of that), so it provisionally sets the minor allele code to '0' until the dataset is merged with sample(s) which aren't homozygous major there.

As far as I can tell, neither PLINK 1.07 nor 1.9 automatically removes "0 0" sites, but just about any standard QC filter (--maf, --hwe, etc.) will cause them to be removed.

[Endre Bakken Stovner]

You are right, I had a QC filter in my pipeline, that is why they were removed.

Endre

[Mike Miller]

I'm glad that PLINK 2 doesn't automatically remove the "0 0" loci. I
didn't agree with the OP that such behavior would be a good plan. Every
locus should stay in the data set, no matter how ugly it looks, unless we
remove it somehow (e.g., filtering, which seems to be what happened here).

Mike