Does the LOH calling utilize the information of match normal WES data?

[ddzhang3]

Thanks for your excellent work on the HLA typing and LOH identification. Here I confused about the LOH calling strategy. The script/cal.hla.copy.pl utils seem to accept HLA types from the previous step (which should be called on matched germline/normal sample in my opinion), So how do I provide the tumor information to the script/cal.hla.copy.pl?

Or reversely, the script/cal.hla.copy.pl does accept the HLA type from tumor sample, then the information of normal sample isn't taken into consideration?

I'm confused about this, even after a careful inspection on the manuscript and readme in GitHub.

[wshuai294]

Hi,
script/cal.hla.copy.pl considers the tumor sample independently with the assumption that tumor sample is a mixture of tumor and normal cells.

You could run script/cal.hla.copy.pl on tumor sample and normal sample separately. If the allelic imbalance is more significant in tumor than in normal sample, it would be a much more confident signal of LOH.

[ddzhang3]

Thanks for your useful reply, it does make sense.
However, the alignment rate for bowtie was really low, following HLA reads extraction by ExtractHLAread.sh -s 451 -b ../outputs/451N/normal_DNA/bam/451N_rmdup.bam \ -r hg19 -o ../outputs/451N/normal_DNA/bam/:

247017 reads; of these:
247017 (100.00%) were paired; of these:
218589 (88.49%) aligned concordantly 0 times
3609 (1.46%) aligned concordantly exactly 1 time
24819 (10.05%) aligned concordantly >1 times
----
218589 pairs aligned concordantly 0 times; of these:
73 (0.03%) aligned discordantly 1 time
----
218516 pairs aligned 0 times concordantly or discordantly; of these:
437032 mates make up the pairs; of these:
434854 (99.50%) aligned 0 times
86 (0.02%) aligned exactly 1 time
2092 (0.48%) aligned >1 times
11.98% overall alignment rate

and the 451.local_assem.log shows some error:

/bin/bash：line 1: 1133711 aborted /home/zhangdandan/apps/SpecHLA/script/../bin/fermikit/fermi.kit/fermi2 assemble -l 40 -m 53 -t 12 ../outputs/451T/tumor_DNA/bam//451/prefix2.flt.fmd 2> ../outputs/451T/tumor_DNA/bam//451/prefix2.pre.gz.log

the ratio of N looks strikely high:

The ratio of N (masked) is 0.66 for the allele ../outputs/451N/normal_DNA/bam//451/hla.allele.1.HLA_A.fasta
The ratio of N (masked) is 0.66 for the allele ../outputs/451N/normal_DNA/bam//451/hla.allele.2.HLA_A.fasta
The ratio of N (masked) is 0.93 for the allele ../outputs/451N/normal_DNA/bam//451/hla.allele.1.HLA_B.fasta
The ratio of N (masked) is 0.93 for the allele ../outputs/451N/normal_DNA/bam//451/hla.allele.2.HLA_B.fasta
The ratio of N (masked) is 0.94 for the allele ../outputs/451N/normal_DNA/bam//451/hla.allele.1.HLA_C.fasta
The ratio of N (masked) is 0.94 for the allele ../outputs/451N/normal_DNA/bam//451/hla.allele.2.HLA_C.fasta

All the exceptions seem to relate to the low aligment rate, could you give some advice?

[wshuai294]

Hi,
You could try to use a higher value of -m or a lower value of -k. Also, in our test, the alignment tool Novoalign works better than bowtie2. The assembly bug is due to the low number of reads. Maybe the number of HLA-reads in your sample is low. Pls have a check.

[ddzhang3]

Thanks for your suggestion, that does really work (modify -m/-k). I will try to inspect how this modification rescue reads even though the bowtie2 alignment give such few reads mapped.