loss summary issue

[Qianweisnnu]

Dear @ReverendCasy
I use the mouse genome as a reference, and the query species is another rodent. I have successfully completed the TOGA process for two species, but the proportion of one2zero in the result file reached 78%. This result indicates that the number of identified pseudogenes is quite high, which I believe is abnormal. Before using TOGA, do I need to filter the genome file, using either hardmask or soft-mask?
Thanks

[ReverendCasy]

Hi @Qianweisnnu ,
TOGA itself is insensitive to masking, although you might consider masking both genomes beforehand for whole genome alignment. For the one2zeros, I would recommend checking their loss statuses (loss_summary.tsv) and the number of orthologous projections identified (orthology_scores.tsv). If most of these genes have no orthologs, then either your query assembly is incomplete or whole genome alignment and chaining went wrong. If TOGA identifies orthologous projections but classifies them as Lost/Missing, then you most likely have issues with query assembly completeness and/or per base sequence quality. If you send me the two mentioned files, I can have a look later.

[Qianweisnnu]

Hi @ReverendCasy
Here it is, loss_summary.tsv and orthology_scores.tsv.Thank you a lot.

loss_summary.tsv

orthology_scores.tsv

[Qianweisnnu]

Hi @ReverendCasy
I have another question. When I want to identify pseudogenes from TOGA results, should I extract the L rows from the loss_summary.tsv, or just look at processed_pseudogenes.bed（processed_pseudogenes.bed）.

[ReverendCasy]

Hi @Qianweisnnu
Thank you for the attached files. From what I see, the classification step went fine (~91% of transcripts have at least one orthologous projection), so the problem stems rather from the alignment step. Two points I find suspicious here:

• ~80% of projections in the loss summary file are Lost,
• ~47% of genes in the loss summary file have the Undefined status (N), which usually happens if the respective transcripts were discarded early in the pipeline for technical reasons.

Here are a few things I suggest doing further:

• Check rejected_items.tsv for TRANSCRIPT level items with the N loss status (see this wiki section);
• Check your input annotation; consider using TOGA’s prepare-input mode;
• Check the length and score distribution for your input chains;
• If available, check the per base sequence quality for your query assembly.

If you’re using mm10 as mouse reference genome assembly, I suggest trying the annotation input supplied with TOGA2.

Regarding your second question:

When I want to identify pseudogenes from TOGA results, should I extract the L rows from the loss_summary.tsv, or just look at processed_pseudogenes.bed（processed_pseudogenes.bed）.

Processed pseudogenes are specifically sequences arising from insertion of reverse-transcribed sequence. If you’re interested in all the potential pseudogene sequences, check query_genes.tsv for lost_ and missing_ genes (see this page and especially the Tip box at the bottom).

[Qianweisnnu]

Hi @ReverendCasy
Thank you for your answer. Is it possible that the high loss ratio is due to the fact that the mouse genome used as a reference is from Ensembl, while the genome for querying is from NCBI ?I intend to try using NCBI data in the future.

[ReverendCasy]

Hi @Qianweisnnu ,
I doubt it could be the issue; as long as both the assemblies are of sufficient quality, their origin must not anyhow affect the TOGA results.

[Qianweisnnu]

Hi @ReverendCasy
Thank you for your answer. I divided the mouse genome into 22 sections based on chromosomes, then aligned the query genome with each of these 22 genome files individually to generate 22 chain files. Afterwards, I merged these 22 chain files and ran TOGA. Is this the reason for the excessive loss ratio?

[ReverendCasy]

Hi @Qianweisnnu ,
I don’t see any problems with this approach. If you suspect the problem might be in your input chain file, I strongly recommend trying our alignment pipeline, although I would rather bet on your query assembly’s quality to be the culprit.

[Qianweisnnu]

Hi @ReverendCasy ,
This is my align code. Since using lastz causes memory issues, and I am using lastz_32 here, is there a problem with this part?
lastz_32 chr1.2bit[multiple] Mau.genomic.2bit[multiple] --format=axt --chain --gfextend --gapped --step=20 --transition --inner=2000 --output=MauMmu1.axt

[Qianweisnnu]

Hi @ReverendCasy ,
I checked the lines in the rejected_items.tsv where loss_status is N, and there are a total of 200,330 lines. Among them, 183,514 lines have OUT_OF_FRAME, 16,732 lines have ALL_ORTHS_DISCARDED, and 33 lines each have NO_CHAINS, 48 lines have CHIMERIC, and 3 lines have CHAIN_LIMIT_EXCEEDED. Reference transcripts with coding sequence length not divisible by three, indicating reading frame shift or an incomplete reading frame. How should I solve this problem?

[ReverendCasy]

Hi @Qianweisnnu ,
Regarding your alignment command: I would recommend checking the default settings for LASTZ in the aforementioned pipeline since yours might not be sensitive enough.

Here:

Reference transcripts with coding sequence length not divisible by three, indicating reading frame shift or an incomplete reading frame. How should I solve this problem?

I would like to see an example of the transcript discarded for this particular reason (grep from rejected_items.tsv, then grep by the name from your input BED file) to ensure TOGA2 behaves correctly. As long as it does, your reference input annotation contains a lot of frameshifted transcripts, so I would suggest carefully checking your input. Again, if your reference species is mouse, I would recommend switching to mm10 genome and using the provided annotation.