--merge-equal-pos

[freeseek]

According to the manual: "If two variants have the same position, PLINK 1.9 will always notify you. If you wish to try to merge them, use --merge-equal-pos. (This will fail if any of the same-position variant pairs do not have matching allele names.)"

However, if I generate the following dataset:

echo -e "1\trs1\t0\t10\n1\trs2\t0\t10" > plink.map

echo -e "F1 I1 0 0 1 -9 A G G G\n F2 I2 0 0 1 -9 G G G G\n F3 I3 0 0 1 -9 A G A G" > plink.ped

And then try the following commands:

plink --file plink --merge-equal-pos

cat plink.bim

... nothing really happens. The output still gives two variants which have the same position.

My guess is that this option runs only if two plink files are being merged. In fact the following hack:

plink --file plink --merge plink --merge-equal-pos

cat plink.bim

Achieves the goal of merging the variants.

I wonder if this is the expected behavior for --merge-equal-pos. This is a useful command even when not merging two datasets as often genotyping arrays have a subset of duplicated SNPs for internal quality control.

[Christopher Chang]

Yes, this is a modifier affecting the merge function, rather than something that can be used on its own.  I will edit the documentation to clarify this (with a mention of the "merge a file with itself" hack), and make plink error out when --merge-equal-pos is used without --merge/--bmerge/--merge-list.

[freeseek]

I have also noticed that if two variants are unplaced, i.e., chromosome number is equal to 0 (http://pngu.mgh.harvard.edu/~purcell/plink/data.shtml#map), --merge-equal-pos will attampt to merge the two variants. It seems more logical to avoid merging variants classified as unplaced.

With respect to chromosome naming convention, I have also noticed that plink107 will by default convert chromosome numbers outside of the 0-26 range to 0, while plink19 will fail unless the --allow-extra-chr flag is used, in which case no conversion will take place. This is not an issue, but I thought I would mention it as it makes the behavior between plink107 and plink19 different.

The following code can be used to see what I am observing:

echo -e "0\trs1\t0\t0\n0\trs2\t0\t-1\n-1\trs3\t0\t0\n-1\trs4\t0\t-1" > plink.map

echo "F1 I1 0 0 1 -9 A C G T A T C G" > plink.ped

plink --file plink --allow-extra-chr --make-bed --out plink19 && cat plink19.bim

plink107 --noweb --file plink --make-bed --out plink107 && cat plink107.bim

plink --bfile plink19 --allow-extra-chr --bmerge plink19 --merge-equal-pos --out merge

plink --bfile plink107 --allow-extra-chr --bmerge plink107 --merge-equal-pos --out merge

[Christopher Chang]

Agreed that it doesn't make sense for --merge-equal-pos to operate on unplaced variants; this is changed in today's development build.

"--allow-extra-chr 0" serves as a PLINK 1.07 backward compatibility mode re: handling of unrecognized chromosome codes.  Since that mode is almost always worse than plain --allow-extra-chr, I think it's best to error out and force users to make a decision when they run an old script on a file with nonstandard chromosome codes.