gatk position indel

[pingu]

Hello,
I am implementing my pipeline for Roche 454 Junior and I have used GATK for called of variants.
I have compared my variants with Roche's variants and for BRCA1 my variants corresponded, but the position of indel for BRCA2 are wrong, the vcf file reported that them position is a few bp before (instead the positions of snp are right)
I have searched on genome browser and I have seen that the position of Roche were right.

For example, this are the coordinates that I have in my files.
Roche GATK VARIANT
32893207 32893197 T/-
32900342 32900337 A/-
32900370 32900363 T/-
32900376 32900371 C/-
32900933 32900933 T/A
32907208 32907202 A/-
32907428 32907420 A/-
32907546 32907535 TTT/-

Could help me?

[Len Trigg]

The positions of the indels are not "wrong", just different. For example, the first case, the reference genomic sequence from 13:32893197-32893208 is:
ATTTTTTTTTTA

The Roche version of the resulting variant is:
ATTTTTTTTT-A

The GATK version of the variant is:
A-TTTTTTTTTA

BOTH of these give the same corresponding post-indel genomic sequence of:
ATTTTTTTTTA

Neither is more right or wrong than the other. What you have encountered is just a representational issue, that there are often multiple equivalent ways of representing the same haplotype. You can postprocess with tools such as bcftools norm or vt which removes some of these issues by normalizing calls according to convention (e.g. left-aligning simple indels), or perform comparison with more sophisticated tools such as RTG vcfeval (which actually compares whether the resulting haplotypes are the same, regardless of the representation, and deals with much more complicated scenarios than normalization alone can address).

[pingu]

Thank you very much for your help.
But if I take the reference sequence from chr13:32900363-32900371 : CTTTTTTTA
I do not understand how is it possible that my vcf reports that in the 32900363 I have a deletion.
Thank you in advance

[Len Trigg]

Check the tool that you are using to output your brief format above -- I suspect that it is not taking into account the padding base that is added to pure insertions/deletions (in order to prevent an empty value in either the REF or ALT field -- see the VCF specification for more information). This causes a corresponding alteration of the reported variant position by 1. I would think that the GATK/Roche variants there are alternative representations of a deletion of a T, not a C.

[pingu]

Thank you very much for your precious help. You are right, the deletion is T.
I have tried "bcftools norm" to normalize calls of my GATK vcf ( in particular I have used this command: ./bcftools norm -f hg19_complete.fa output.vcf.gz -O z >out.vcf.gz) and it reported:
total/modified/skipped: 51/0/0
So if I have understood right my file vcf was not modified.
Could you help me to understand why does not bcftools modify my vcf?
thank you very much in advance