Possible bug in filtering of indels

[gevro]

Hi,
In recent samples analyzed with v3.5.5, we see very high indel burdens.

I found several examples of indels that overlap the NOISE mask, but were not filtered out - they still show up with FILTER=PASS.

$ tabix NOISE.sorted.GRCh38.bed.gz chr1:43861432-43861436
chr1 43861434 43861453

In results.indel.vcf.gz:
chr1 43861434 . GCTGTCAGGACTTGTATAGA G 225.417 PASS INDEL;IDV=8;IMF=1;DP=8;VDB=1.33331e-05;SGB=-0.651104;MQSBZ=0;BQBZ=0;MQ0F=0;AC=1;AN=1;DP4=0,0,8,0;MQ=60;QPOS=97;RB=chr1,43861337,43861899,GGC,TAT;BBEG=43861337;BEND=43861899;DEPTH_FWD=5;DEPTH_REV=3;DEPTH_NORM_FWD=12;DEPTH_NORM_REV=12;DPLX_ASXS=119;DPLX_CLIP=0;DPLX_NM=19;BULK_ASXS=90;BULK_NM=0;NN=[0:118:0];SEQ=GGTGTGGAGCTGTCAGGA GT:PL:DP:DV:SP:DP4 1:255,0:8:8:0:0,0,8,0
chr1 43861434 . GCTGTCAGGACTTGTATAGA G 225.417 PASS INDEL;IDV=8;IMF=1;DP=8;VDB=0.125998;SGB=-0.651104;MQSBZ=0;BQBZ=0;MQ0F=0;AC=1;AN=1;DP4=0,0,4,4;MQ=60;QPOS=97;RB=chr1,43861337,43861546,AAG,TGA;BBEG=43861337;BEND=43861546;DEPTH_FWD=4;DEPTH_REV=4;DEPTH_NORM_FWD=12;DEPTH_NORM_REV=12;DPLX_ASXS=109;DPLX_CLIP=0;DPLX_NM=19;BULK_ASXS=90;BULK_NM=0;NN=[0:118:0];SEQ=GGTGTGGAGCTGTCAGGA GT:PL:DP:DV:SP:DP4 1:255,0:8:8:0:0,0,4,4

I am confident that I ran the pipeline with NOISE.sorted.GRCh38.bed.gz.

Is there a possible bug in applying the NOISE (and/or SNP) masks to indel results?

Thanks

[gevro]

Also, when you all created the human SNP filters, does it also include indels above a certain population AF threshold, or only SNPs? Per your paper you include population frequent indels that do not have the PASS flag in gnomad, but do you include indels that DO have the PASS flag in the SNP mask?

[gevro]

Just to add further confirmation - within that same sample there is an indel that was MASKED properly by the NOISE mask:
$ tabix NOISE.sorted.GRCh38.bed.gz chr1:4304586-4304592
chr1 4304586 4304598

In results.indel.vcf.gz:
chr1 4304586 . CGTGTGTGTGTGT C 225.417 MASKED INDEL;IDV=11;IMF=1;DP=11;VDB=2.26006e-08;SGB=-0.676189;MQSBZ=0;MQ0F=0;AC=1;AN=1;DP4=0,0,0,11;MQ=60;QPOS=58;RB=chr1,4304440,4304644,GAG,CTG;BBEG=4304440;BEND=4304644;DEPTH_FWD=5;DEPTH_REV=6;DEPTH_NORM_FWD=0;DEPTH_NORM_REV=15;DPLX_ASXS=84;DPLX_CLIP=0;DPLX_NM=14.2;BULK_ASXS=109;BULK_NM=1;NN=[0:209:0];SEQ=GATGTACACGTGTGTGTG GT:PL:DP:DV:SP:DP4 1:255,0:11:11:0:0,0,0,11

So this shows that the noise mask was applied correctly during the run configuration. So that leaves the question why the above indel (chr1 43861434) was not masked.

[gevro]

Another strange thing -- another sample analyzed in the same batch has the same indel artifact and it was masked:

chr1 43861434 . GCTGTCAGGACTTGTATAGA G 225.417 MASKED INDEL;IDV=15;IMF=0.9375;DP=16;VDB=0.0148393;SGB=-0.689466;RPBZ=-1;MQBZ=0;MQSBZ=0;BQBZ=0;SCBZ=0;MQ0F=0;AC=1;AN=1;DP4=0,0,8,8;MQ=60;QPOS=97;RB=chr1,43861337,43861545,AAG,GTG;BBEG=43861337;BEND=43861545;DEPTH_FWD=10;DEPTH_REV=6;DEPTH_NORM_FWD=13;DEPTH_NORM_REV=14;DPLX_ASXS=107;DPLX_CLIP=0;DPLX_NM=19.8;BULK_ASXS=109;BULK_NM=0;NN=[0:153:0];SEQ=GGTGTGGAGCTGTCAGGA GT:PL:DP:DV:SP:DP4 1:255,0:16:16:0:0,0,8,8

So it isn't clear why in one sample it was correctly masked by the NOISE mask, and not in another sample. The code to run the analyses of these samples was the same.

The only thing I can think of is if there is something in the indel masking code that "rescues" an indel even though it is in a region of the masks.

[fa8sanger]

Hi, that’s a rare but possible thing to happen. It’s because how the pipeline counts how many of the indel sites are masked. To count them it relies on information on duplex calls (passing all filters), which come with the masked/unmasked tag. It may happen that the same indel in one case comes with less information and in that case the masked filter may not reach the threshold. It’s a bit intricate and took me some time to understand. The ideal solution would be to load the mask information rather than relying on duplex calls information, but it is how it is at the moment, and from what I’ve seen it is a very rare undesired result. I may implement the ideal solution at some point Thanks for reporting this On 10 May 2024, at 03:05, gevro ***@***.***> wrote: Another strange thing -- another sample analyzed in the same batch has the same indel artifact and it was masked: chr1 43861434 . GCTGTCAGGACTTGTATAGA G 225.417 MASKED INDEL;IDV=15;IMF=0.9375;DP=16;VDB=0.0148393;SGB=-0.689466;RPBZ=-1;MQBZ=0;MQSBZ=0;BQBZ=0;SCBZ=0;MQ0F=0;AC=1;AN=1;DP4=0,0,8,8;MQ=60;QPOS=97;RB=chr1,43861337,43861545,AAG,GTG;BBEG=43861337;BEND=43861545;DEPTH_FWD=10;DEPTH_REV=6;DEPTH_NORM_FWD=13;DEPTH_NORM_REV=14;DPLX_ASXS=107;DPLX_CLIP=0;DPLX_NM=19.8;BULK_ASXS=109;BULK_NM=0;NN=[0:153:0];SEQ=GGTGTGGAGCTGTCAGGA GT:PL:DP:DV:SP:DP4 1:255,0:16:16:0:0,0,8,8 So it isn't clear why in one sample it was correctly masked by the NOISE mask, and not in another sample. The code to run the analyses of these samples was the same. The only thing I can think of is if there is something in the indel masking code that "rescues" an indel even though it is in a region of the masks. — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cancerit_NanoSeq_issues_96-23issuecomment-2D2103717217&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=VdIDijmkJGn28nV9QYvXSgSRrRdkNsVzGG8wCIi4CXZTM3CQ6AhKm3YRtMQqGXY5&s=h7Mmfg6SZS97VZZX2hBF4Z3TZ_VhQrWX-ulXqEWiWoA&e=>, or unsubscribe [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADNUT3PQH6OMESFEJCODJBLZBQTPXAVCNFSM6AAAAABHPRGUGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBTG4YTOMRRG4&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=VdIDijmkJGn28nV9QYvXSgSRrRdkNsVzGG8wCIi4CXZTM3CQ6AhKm3YRtMQqGXY5&s=TBdhkjvSuNlRD2hen15gHsPn2lwsKn3Lp_xKG_eJj1A&e=>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

…

---------------------------------------------------------------------- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is Wellcome Sanger Institute, Wellcome Genome Campus, Hinxton, CB10 1SA.

[fa8sanger]

A third solution is to do some extra filtering a posteriori, intersecting your indels with the masks and determining whether they meet the threshold or not. From what I’ve seen with thousands of indels this is a very rare occurrence though. On 10 May 2024, at 03:05, gevro ***@***.***> wrote: Another strange thing -- another sample analyzed in the same batch has the same indel artifact and it was masked: chr1 43861434 . GCTGTCAGGACTTGTATAGA G 225.417 MASKED INDEL;IDV=15;IMF=0.9375;DP=16;VDB=0.0148393;SGB=-0.689466;RPBZ=-1;MQBZ=0;MQSBZ=0;BQBZ=0;SCBZ=0;MQ0F=0;AC=1;AN=1;DP4=0,0,8,8;MQ=60;QPOS=97;RB=chr1,43861337,43861545,AAG,GTG;BBEG=43861337;BEND=43861545;DEPTH_FWD=10;DEPTH_REV=6;DEPTH_NORM_FWD=13;DEPTH_NORM_REV=14;DPLX_ASXS=107;DPLX_CLIP=0;DPLX_NM=19.8;BULK_ASXS=109;BULK_NM=0;NN=[0:153:0];SEQ=GGTGTGGAGCTGTCAGGA GT:PL:DP:DV:SP:DP4 1:255,0:16:16:0:0,0,8,8 So it isn't clear why in one sample it was correctly masked by the NOISE mask, and not in another sample. The code to run the analyses of these samples was the same. The only thing I can think of is if there is something in the indel masking code that "rescues" an indel even though it is in a region of the masks. — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cancerit_NanoSeq_issues_96-23issuecomment-2D2103717217&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=VdIDijmkJGn28nV9QYvXSgSRrRdkNsVzGG8wCIi4CXZTM3CQ6AhKm3YRtMQqGXY5&s=h7Mmfg6SZS97VZZX2hBF4Z3TZ_VhQrWX-ulXqEWiWoA&e=>, or unsubscribe [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADNUT3PQH6OMESFEJCODJBLZBQTPXAVCNFSM6AAAAABHPRGUGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBTG4YTOMRRG4&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=VdIDijmkJGn28nV9QYvXSgSRrRdkNsVzGG8wCIi4CXZTM3CQ6AhKm3YRtMQqGXY5&s=TBdhkjvSuNlRD2hen15gHsPn2lwsKn3Lp_xKG_eJj1A&e=>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

…

---------------------------------------------------------------------- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is Wellcome Sanger Institute, Wellcome Genome Campus, Hinxton, CB10 1SA.

[gevro]

Thanks, however, I'm seeing a very large number of these examples to the point that artifacts outnumber real indels. What are the key parameters or lines of code that do this? And what was the motivation to make it more intricate versus filtering out those regions directly?

[gevro]

Also, is this issue only relevant for indel filtering or also snv filtering?

[gevro]

Sorry for all the questions, but also, is there anything in the final VCF results that can allow me to determine which of these indel sites had this issue versus not? Or is this only determinable internally at the time of filtering?

[fa8sanger]

As I suggested you can intersect with the SNP & NOISE masks to evaluate the overlap On 10 May 2024, at 11:49, gevro ***@***.***> wrote: Sorry for all the questions, but also, is there anything in the final VCF results that can allow me to determine which of these indel sites had this issue versus not? Or is this only determinable internally at the time of filtering? — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cancerit_NanoSeq_issues_96-23issuecomment-2D2104392588&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=YEcu9IKu2oMngmz8czJuL9x6Ug4WAXUvhHsJjjrMs5zeySJvTcLbT4YkkAVm6tVN&s=2VYLtx3-ukQexroI6PQ9nElvP7wBK77UWlMz8XxHADE&e=>, or unsubscribe [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADNUT3OSFOQ3D4MZGN2HY5TZBSQ35AVCNFSM6AAAAABHPRGUGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUGM4TENJYHA&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=YEcu9IKu2oMngmz8czJuL9x6Ug4WAXUvhHsJjjrMs5zeySJvTcLbT4YkkAVm6tVN&s=Q5eWcTApp0VvNDkLvJZl6cUO0QVXKjDJbF94Ug9NtJ8&e=>. You are receiving this because you commented.Message ID: ***@***.***>

…

---------------------------------------------------------------------- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is Wellcome Sanger Institute, Wellcome Genome Campus, Hinxton, CB10 1SA.

[fa8sanger]

Do you mean those artifacts are cause by this rare circumstance? I wouldn’t expect so The reasons… no particular one, I may change that in the future. On 10 May 2024, at 11:40, gevro ***@***.***> wrote: Thanks, however, I'm seeing a very large number of these examples to the point that artifacts outnumber real indels. What are the key parameters or lines of code that do this? And what was the motivation to make it more intricate versus filtering out those regions directly? — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cancerit_NanoSeq_issues_96-23issuecomment-2D2104380189&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=L7yrV9gWysGAkS5dl-Nx4L-dx7eosM00rv5KwCSKrv2-ViH66GQIYMolH-pEWfdX&s=bQOcytK8ehlZARHRTboqEx2l3lt7LuI2us1pCzg-A5U&e=>, or unsubscribe [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADNUT3NWF5UCCC2QVKHGRUTZBSP3BAVCNFSM6AAAAABHPRGUGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUGM4DAMJYHE&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=L7yrV9gWysGAkS5dl-Nx4L-dx7eosM00rv5KwCSKrv2-ViH66GQIYMolH-pEWfdX&s=RMxOmzNX1UNAqZfyBvSkxVcxRkGAfDFMWHCL5OKfnes&e=>. You are receiving this because you commented.Message ID: ***@***.***>

…

---------------------------------------------------------------------- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is Wellcome Sanger Institute, Wellcome Genome Campus, Hinxton, CB10 1SA.

[fa8sanger]

It doesn’t affect snvs On 10 May 2024, at 11:44, gevro ***@***.***> wrote: Also, is this issue only relevant for indel filtering or also snv filtering? — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cancerit_NanoSeq_issues_96-23issuecomment-2D2104385027&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=Z-AYfKLuWsEMgWA5s7wm1xEFhz0Zs90wxYK6_8oyyrKx2XBtUDGRHSKpGztjGyNH&s=AjguJOQcp3cr7bXygKTRhIW-2I6BM7Mzlqo6AtJJjfA&e=>, or unsubscribe [github.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADNUT3NDLT6XU3KRJMBSISLZBSQHVAVCNFSM6AAAAABHPRGUGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUGM4DKMBSG4&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=Z-AYfKLuWsEMgWA5s7wm1xEFhz0Zs90wxYK6_8oyyrKx2XBtUDGRHSKpGztjGyNH&s=KC3NAPnc0kBJLVBFg_aSki-jl7D7LWkaV0G3-RbC-3I&e=>. You are receiving this because you commented.Message ID: ***@***.***>

…

---------------------------------------------------------------------- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is Wellcome Sanger Institute, Wellcome Genome Campus, Hinxton, CB10 1SA.

[gevro]

Do you mean those artifacts are cause by this rare circumstance? I wouldn’t expect so
Yes, I'm seeing quite a few of these artifacts. It doesn't seem that rare. In the meantime I will manually intersect the indel calls with the SNP and NOISE masks again post-analysis. I'm not sure I understand why in some samples it would be a more prevalent issue vs other samples.

[gevro]

Hi,
I think I found a possible contributor to the higher than expected indel rates. I think there might be a coordinate bug in your NOISE.sorted.GRCh38.bed.gz file.

I am seeing for example many of this indel artifact:

  CHROM     POS   ID REF ALT    QUAL FILTER
1  chr1 5287895 <NA>   G  GC 92.4151   PASS
2  chr1 5287895 <NA>   G  GC 108.415   PASS
3  chr1 5287895 <NA>   G  GC 130.416   PASS
4  chr1 5287895 <NA>   G  GC 173.416   PASS
                                                                                                                                                                                                                                                                                                                                      INFO
1       INDEL;IDV=4;IMF=1;DP=4;VDB=0.0058656;SGB=-0.556411;MQSBZ=0;BQBZ=0;MQ0F=0;AC=1;AN=1;DP4=0,0,4,0;MQ=60;QPOS=121;RB=chr1,5287774,5288396,ATG,AAT;BBEG=5287774;BEND=5288396;DEPTH_FWD=2;DEPTH_REV=2;DEPTH_NORM_FWD=15;DEPTH_NORM_REV=0;DPLX_ASXS=115;DPLX_CLIP=0;DPLX_NM=1;BULK_ASXS=101;BULK_NM=0;NN=[0:175:0];SEQ=TTGGCAGTGAGCTGCTGT
2           INDEL;IDV=5;IMF=1;DP=5;VDB=0.00187095;SGB=-0.590765;BQBZ=-2;MQ0F=0;AC=1;AN=1;DP4=0,0,5,0;MQ=60;QPOS=122;RB=chr1,5287773,5288395,TAA,CCC;BBEG=5287773;BEND=5288395;DEPTH_FWD=2;DEPTH_REV=3;DEPTH_NORM_FWD=15;DEPTH_NORM_REV=0;DPLX_ASXS=109;DPLX_CLIP=0;DPLX_NM=2.3;BULK_ASXS=101;BULK_NM=0;NN=[0:175:0];SEQ=TTGGCAGTGAGCTGCTGT
3     INDEL;IDV=7;IMF=1;DP=7;VDB=6.71664e-05;SGB=-0.636426;BQBZ=-1.1547;MQ0F=0;AC=1;AN=1;DP4=0,0,7,0;MQ=60;QPOS=122;RB=chr1,5287773,5288537,TAT,CCT;BBEG=5287773;BEND=5288537;DEPTH_FWD=4;DEPTH_REV=3;DEPTH_NORM_FWD=15;DEPTH_NORM_REV=0;DPLX_ASXS=104;DPLX_CLIP=0;DPLX_NM=3.3;BULK_ASXS=101;BULK_NM=0;NN=[0:175:0];SEQ=TTGGCAGTGAGCTGCTGT
4 INDEL;IDV=13;IMF=1;DP=13;VDB=2.26006e-08;SGB=-0.683931;BQBZ=-1.96666;MQ0F=0;AC=1;AN=1;DP4=0,0,13,0;MQ=60;QPOS=121;RB=chr1,5287774,5288395,AAG,TGG;BBEG=5287774;BEND=5288395;DEPTH_FWD=9;DEPTH_REV=4;DEPTH_NORM_FWD=15;DEPTH_NORM_REV=0;DPLX_ASXS=112;DPLX_CLIP=0;DPLX_NM=1.5;BULK_ASXS=101;BULK_NM=0;NN=[0:175:0];SEQ=TTGGCAGTGAGCTGCTGT

This artifact is apparent in gnomAD: https://gnomad.broadinstitute.org/variant/1-5287895-G-GC?dataset=gnomad_r3

Note that the position in 1-based coordinates in gnomAD is: chr1:5287895

However, in NOISE.sorted.GRCh38.bed.gz, the coordinates are:
chr1 5287895 5287896

And it is not in SNP.sorted.GRCh38.bed.gz

So there might be a coordinate bug in the code that generated the NOISE mask. Maybe also in the SNP mask for some subset of it?

It also depends how your NanoSeq pipeline interprets these masks -- I'm assuming as 0-based coordinate BED files? If so, then only the NOISE mask needs to be fixed. Are you able to share the code that generated the NOISE mask, and I can try to help fix the bug to generate a new one?

Thanks

[gevro]

Addendum: I'm not 100% sure but I think this coordinate bug might only be happening with NOISE mask sites that correspond to indels in gnomAD. And not FILTERED gnomAD substitution sites.

I wonder if maybe in your code that generated the NOISE mask for gnomAD indels, that you set the coordinate to the base after the REF position. For example for the gnomAD indel site above of:
chr1:5287895 G > GC, you set it to chr1:5287896. And then in the NOISE bed file it is set to chr1 5287895 5287896.

However, the NanoSeq pipeline calls this indel with POS = 5287895, and then your NanoSeq pipeline doesn't know which of the NOISE mask sites are indels, so it doesn't filter the call.

I'm assuming the solution would be to instead put the gnomAD indel-related NOISE mask sites using the position corresponding to the REF POS, i.e. in the above situation as chr1 5287894 5287895 in BED coordinates, which corresponds to chr1:5287895 in 1-based coordinates.

I can fix this if you send me the code that generated the GRCh38 NOISE mask.

Thanks

[fa8sanger]

I am attaching two files, one explaining how the masks were built and one with the perl code used
get_subs_above_AF_v3.pl.txt
GENERATION OF THE SNP MASK FOR BOTSEQ.txt
get_subs_above_AF_v3.GRCh38.pl.txt