skoren
commented
1 year ago I think your data is lower quality (or at least in terms of matching between reads). This could be due to the PCR amplification beforehand. There's essentially no overlaps and nothing to reconstruct at typical HiFi error rates. That is why you had so many consensus jobs, there were lots of very short nodes composed of just a few (or 1) reads.
I'd suggest turning on trimming and increasing the error rate (correctedErrorRate=0.025 -untrimmed). You could try several error rates, the default if 0.01, so I'd try the above plus maybe 0.015, 0.03, and 0.05.
deoliveira86
Dear all,
I have recently acquired many HiFi libraries through a ultra-low insert library including PCR protocol from a single metazoan specimen. I followed the recommended pre-processing steps and performed everything in house from the native
reads.bamfile:"rq":">=0.99"and"rq":">=0.999", respectively). For convenience, the HiFi reads with QV>=30 I will call ultra-HiFi (uHiFi) from this point onwards.Before running the assembly, I did some sanity checks with the data, namely:
Canu v2.2using Sequel recommended parameters, and was polished, purged, and any contaminants removed with blobtools) with minimap2. The mapping rate was >94%, confirming that the HiFi data correspond to the organism which I am interested and there are likely no contamination in the data.To summarise some basic info about the genome:
With this previous information I ran
Canu v2.2with the following command line:canu -p uhifi-100x -d uhifi-100x genomeSize=1.265g maxInputCoverage=100 uHiFi_libraries.*gzEverything ran normally (and the histogram plots agree with the GenomeScope prediction - see below) until the computation of the cns jobs.
Thousands and thousands of cns instances were submitted to the cluster and I could see that after bogard assembler run, no reconstructed contig was generated. See log below from the canu.report file:
From the report above, it is pretty clear that almost every all the HiFi reads could not be assembled, which is making me pretty worried about the quality of the data and making me extremely confused. From the Unittiging/overlap categories (below), I can see that Canu could identify more reads for the genome reconstruction, and despite the level of unique reads is quite low (2.50%), the low-coverage and other category reads could be used for assembling.
Because I am using uHiFi reads the error rates should not be high and the Error rate log (if I understood it correctly), tells me that the error rate is not an issue.
The Best edge filtering log tells me that only a small percentage of reads have at least one edge (0.06%), indicating that virtually all my HiFi reads have no useful overlap. This is scary and I wonder why?
Finally, since almost no overlap was identified Canu produced any output and for some reason launched thousands of cns jobs which I killed after more than 50,237 *out files were written in the unitigging/5-consensus/ folder. Furthermore, I could see that in the uhifi-full.ctgStore/ folder there is a total of 87,022 partitions. Why cns jobs would be submitted without any reconstructed contigs?
I investigated the unitigger.err log file, but I couldn't properly interpret the results. I will attach here, that could may be useful.
Does anyone have an idea what is happening? My guess would be that playing around with bogart parameters (e.g., overlapping generation limits and overlap processing limits) can actually help me to produce an assembly (well, it cannot get any worse, since I had no output). Additionally, I am running now many instances of hifiasm to see how the software will perform with the data. I imagine if the hifiasm results (if any) are also not great, something must be wrong with the data.
Furthermore, does anyone have any idea what could go wrong with the library preparation? Since the quality of the libraries is good (in terms of QV) and my N50 HiFi read length is not bad (~10Kb), the source of the issue must come from the ultra-low library prep (I guess??). The extremely high repeat content of the genome I am working can also cause assembly issues, but, one more time, researchers can go through telomeric sequences using HiFi and that does not impede them to have at least assembled sequences.
I appreciate the help, Best, André