The merge function in assign_color can flip the order of SNPs where one rsid is a substring of the other, e.g. rs123456 and rs1234567. In the following if statement, the line color[rsid == snp,'color'] = 'purple' should then colour the lead SNP (snp = "rs123456") purple; however, it colours rs1234567 purple instead.
The core issue is that the line color[rsid == snp,'color'] uses the input structure rsid (which is just a renaming of merged$rsid) to mask color, rather than color$rsid. Since rsid has the ordering of SNPs prior to the reordering by merge and color$rsid the ordering post merge, it changes the colour of the wrong SNP.
This can be fixed simply by changing color[rsid == snp,'color'] to color[color$rsid == snp,'color'].
I'm not sure if this only happens for SNPs with rsids that are substrings of other SNP rsids, or why the merge function does this at all, but this fix should ensure that any change in ordering during merge is irrelevant.
The
mergefunction inassign_colorcan flip the order of SNPs where one rsid is a substring of the other, e.g. rs123456 and rs1234567. In the followingifstatement, the linecolor[rsid == snp,'color'] = 'purple'should then colour the lead SNP (snp = "rs123456") purple; however, it colours rs1234567 purple instead.The core issue is that the line
color[rsid == snp,'color']uses the input structurersid(which is just a renaming ofmerged$rsid) to maskcolor, rather thancolor$rsid. Sincersidhas the ordering of SNPs prior to the reordering bymergeandcolor$rsidthe ordering postmerge, it changes the colour of the wrong SNP.This can be fixed simply by changing
color[rsid == snp,'color']tocolor[color$rsid == snp,'color'].I'm not sure if this only happens for SNPs with rsids that are substrings of other SNP rsids, or why the
mergefunction does this at all, but this fix should ensure that any change in ordering duringmergeis irrelevant.