analyze the CNV of cancer cell lines with whole exome sequence

[LongpanUPC]

Hello, thank you for developing and continuing to maintain this amazing tool! In fact, I met some problem about the CNV on cancer cell lines and I am not sure if my idea is feasible or not. In the lab, we have more than 60 mesothelioma cell lines with WES and we want to know the allelic-specific copy-number profiles of these cancer cells. The following is my idea:

1. using the function ascat.prepareTargetedSeq to get the cleaned loci and allele file from a batch of normal samples (samples are from tissues);
2. determine one male normal sample as a control (randomly), later all the male mesothelioma cell lines will compare with the same normal sample using the cleaned loci and allele file. For the female samples, do the same way.

Do you think it's logical or feasible? If possible, I checked the source script of ascat.prepareTargetedSeq, there is a step called "remove SNPs close to each other with similar genotypes" that I don't understand very well. I am not sure if it's specific to target sequencing which need to remove SNPs close to each other with similar genotypes in order to get cleaned loci and allele files. In my naive idea, it's not necessary to do this step in the WES data in order to get cleaned files. Can you give some comments for this step? Besides, do you think how many normal samples are required to get relative good results

Finally, could you give me some additional suggestions to deal with the allelic-specific CNVs on cancer cell lines with whole exome sequence.

thank you very much!! Long

[tlesluyes]

Hi @LongpanUPC,

Are the normal samples you mention coming from the same patients as the 60 cell lines (so you do have tumour/normal pairs) or are those random normal samples? It sounds like you have unmatched cell lines, which ASCAT will not be able to analyse. As you mention, you may use ascat.prepareTargetedSeq on normals to get clean loci but we still do require tumour/normal pairs for processing sequencing data. This allows getting clean SNP-based logR tracks and relying on normal BAF to see how heterozygous SNPs behave in tumour samples (so ASCAT calls allele-specific CNAs). Also, our function to predict genotypes in unmatched tumours works well with SNP arrays but needs to be benchmarked for sequencing data (for every cohort as sequencing depth & coverage are always different) and does not work for cell lines as it leverages the signal from admixed normal cells. We might release a future update later this year that allows extracting logR and BAF from unmatched sequenced tumours, but our genotype prediction isn't suited for cell lines so ASCAT is unlikely to be the ideal tool for your data.

Instead, you might be interested in running our ASCAT.sc tool. It'll leverage off-target reads to derive total (non allele-specific) and binned (not SNP-based) copy-numbers.

Cheers,

Tom.

[LongpanUPC]

thank you for your reply! Actually, the normal samples are not from the same patient. However, Since I already get the cleaned loci file, I am not sure if I can specify one normal sample as paired normal file as input (like deceived ASCAT that made it think they belonged tumour/normal pairs).

As for ASCAT.sc, it not useful for me. In Fact, we want to get allele-specific copy-numbers and use this output to run CNV signatures (https://doi.org/10.1038/s41586-022-04738-6)

[tlesluyes]

Hi @LongpanUPC,

You can't 'hack' the system by providing a random normal sample I'm afraid. This is because, as mentioned in my previous post, ASCAT uses heterozygous SNPs (in the normal) and checks how they behave in the tumour. Since genotypes will not be consistent across patients, this will cause major issues in the interpretation. Not sure logR using unmatched tumour/normal would be clean either.

You can still get CNA signatures (please use CNA, CNV refers to germline copy-number variations) using ASCAT.sc, it would 'just' be a different set of signatures: https://doi.org/10.1038/s41586-022-04789-9

Cheers,

Tom.

[LongpanUPC]

thank you very much @tlesluyes , I will check this paper you mentioned and maybe it's another way to deal with the problem. best, long