Repetitive regions in mitochondrial assembly

[o-william-white]

Hello,

I am using getorganelle to assemble the mitochondrial genome of Rhagonycha fulva across multple samples. Note that the sequence data is from historical samples so we do not expect to recover full organelles given the sample quality. Retriving barcodes sequences is accepbtable for this data.

For most samples, I am able to recover mitochondrial contigs and annotations for barcode markers, notably cox1.

However, a couple of samples resulted in very short circular sequence. Attached is a log output, selected_graph and extend-gene graph for one of these samples.

This is what the short circular sequence looks like in the selected graph

However, this is what the extend-gene graph looks like. Note that I am able to annotate sequences from Rhagonycha fulva in these contigs.

Is getorganelle selecting the contigs for the selected_path based on coverage? I.e. is the assumption that organelle contigs will have higher coverage compared to nuclear contigs for example?

I think this result can be explained by the fact I am using a reference assembly of Rhagonycha fulva as a seed sequence, and within this assembly there is a large repetive region. See dot plot below.

I expect sequence reads from this repetive regions are assembling together resulting in contigs with very high coverage compared to other mitochondrial regions.

I thought it might be useful to mask repetivie sequences from the reference sequence (for example using Trf) prior to running getorganelle. Does this sound like a sensible idea?

Thanks for sharing the sofware!

Best wishes
Ollie

extended_K55.assembly_graph.fastg.extend-gene.fastg.txt
get_org.log.txt
animal_mt.K55.complete.graph1.selected_graph.gfa.txt

[Kinggerm]

Yeah, it seems to be a problem. Could you please provide the gene.fasta files you used and the *.csv file generated? Thanks!

We masked a group of repetitive sequences for our default database, mainly for speeding up, not for accuracy purposes.
The seed database has a minimal impact on accuracy, meaning the result will be the same even if you masked the repeats (refer to the case using rbcL gene as the seed database can generate identical chloroplast genome in our GetOrganelle paper).
However, the label database may influence the contig weighting and clustering in a few cases. This is what I expect in your case.

[o-william-white]

Hello,

Thanks for the quick reply. I have attached the gene.fasta and *.csv file as requested. Note I had to change the .fasta extention to ".txt" so it could be uploded.

I used the reference assembly of Rhagonycha fulva as a seed sequence and extracted label sequnces in gene.fasta using the script get_annotated_regions_from_gb.py

It looks like the sequences in gene.fasta have annotated the contigs that I wanted from looking at the *.csv file.

Interesting to know that masking repetitive sequences will help with speed.

Best wishes
Ollie

extended_K55.assembly_graph.fastg.extend-gene.csv
gene.fasta.txt

[o-william-white]

Also attached is the gb file used to generate the sequences in gene.fasta if helpful

MK692551.1.gb.txt

[Kinggerm]

Hi,
Sorry for the slow reply. This bug was triggered by the insufficient organelle graph ("broken graph") with extremely high (like 50 folds in this case) directed repetitive regions. I will try to fix it ASAP (#141).

Thanks for reporting it!

[o-william-white]

Hi,

This is great, thanks for letting me know. I am happy to test afterwards if helpful.

Best wishes
Ollie

[Kinggerm]

Hi, sorry for the delay. This issue is now fixed in 1.7.6.1.

BTW, this does not mean that this sample will be circularized; instead, it means that GetOrganelle will generate more reasonable results (three contigs in this case) even if there are extremely high repetitive regions.
There is definitely room for improvement here. Ideally, GetOrganelle should output just one scaffold with these contigs joined. However, the multiplicity estimation for contigs with extremely high coverage in a general framework is still challenging.