No improvement while scaffolding using onehic.py

[alex-merge]

Hi,
I’m currently benchmarking Hi-C scaffolders and running into issues with AutoHic.
I used Juicer and 3D-DNA (v180922) to generate the merged_dedup.txt and assembly files, respectively. When running AutoHic using the onehic.py script with your Singularity image, I’m getting either smaller-than-expected FASTA files or, when comparing to the reference with QUAST, no improvement compared to the 3D-DNA output.
Could you help me troubleshoot this?

Here are the commands that I used in my scripts:
3D-DNA (v180922)

run-asm-pipeline.sh \
	-m haploid \
	../references/AG.DToL.fa \
	../aligned/merged_nodups.txt

AutoHic

apptainer exec AutoHic.sif /home/autohic/miniconda3/bin/conda run -n autohic \
	python3.9 ${Autohic_dir}/onehic.py \
	-hic "3DDNA/${ID}.final.hic" \
	-asy "3DDNA/${ID}.FINAL.assembly" \
	-autohic ${Autohic_dir} \
	-p "${Autohic_dir}/error_model.pth" \
	-out AutoHic

Here are the logs :
AG.DToL.3DDNA.log
AG.DToL.AutoHiC.log

Let me know if you need more details!

[Jwindler]

This is normal.

1. Your results are so good that there are no errors to adjust;
2. Your results contain errors that AutoHiC cannot currently adjust;
3. If the errors are very obvious or related to their size, you can try adjusting the --min-len and --max-len parameters.

[alex-merge]

Thank you for your response !
I understood that AutoHiC detects chromosome boundaries and thus produces chromosome-level scaffolds. Even if there are no assembly errors (which is very likely with these assemblies), I thought I would get scaffolds. Yet, this is not the case in my tests.
What am I missing ?

[astudentfromsustech]

Dear author, I also have the similar problem.
I wish it can correct the obvious inversion in each group (scaffolding using HapHiC), but the autohic can't detect it. Can you tell me how to solve it or do you have any idea?

[Jwindler]

In my view, this does not appear to be an obvious assembly error involving an inversion—a type that AutoHiC would typically be able to recognize and correct. Based on my experience, this issue may have arisen during the alignment process due to the presence of repetitive sequences; I suggest you further examine the sequence within this specific region. @astudentfromsustech

[astudentfromsustech]

In my view, this does not appear to be an obvious assembly error involving an inversion—a type that AutoHiC would typically be able to recognize and correct. Based on my experience, this issue may have arisen during the alignment process due to the presence of repetitive sequences; I suggest you further examine the sequence within this specific region. @astudentfromsustech

Thank you for you quick reply. I made a mistake, it's not inversion but the mistake (for example, the contig on the left-bottom should be put together with the one up-top)

[Jwindler]

The contig in group 1 is likely present because if the chromosome ends are repetitive sequences, it could be an alignment-induced interaction, and it would conform to the distance decay rule. The small contig in group 2 might be problematic because it exists alone and doesn't conform to distance decay, but I cannot determine its true location from the heatmap. For this complex situation, you can adjust the test in Juicebox. @astudentfromsustech