-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error using read_type = hifi and fastq.gz file #123
Comments
While I was typing up this bug report the fasta version finished.
Very happy with these stats! I still need to make sure everything looks OK since I have imperfect inputs (not a mono culture) but I'm optimistic currently. Cheers |
This is a known bug, see #119 , you can transform the fastq file to fasta file to avoid this error. I will fix it in next release. |
Thanks for taking the time to respond. I look forward to your next release. |
Can I use a fasta.gz or does it need to be uncompressed fasta? |
fasta.gz should work fine. can always test it and then gunzip if it fails. |
Confirmed that gzipped fasta does work fine |
Describe the bug
nd.asm.fasta
file is empty, with the IndexError produced shown below.Error message
The pid log did not provide any error message, but I got this on stderr because the files are empty:
Config file
Input fofn
Operating system
GCC
Python
NextDenovo
To Reproduce (Optional)
Use a input
fastq.gz
hifi file and you will receive the same IndexError.I think a check that the split fastas in the
01.split_seed.sh.work/split_seed0
folder are valid, and another check at the 02.cns_align.sh.work folder that the output files each have something in them after alignment (unless 0 size files might be expected in some cases) would help resolve this type of issue in the future.Additional context (Optional)
output folder structure & sizes
You note that the
cns_align
subdirs in02.cns_align.sh.work
have largenextDenovo.sh.e
files, and each is giving a warning about alignment length of 0.I traced the error back to the
01.split_seed.sh
command. The split_cns.py expects a fasta file so when a fastq file is provided, the output is a mess of invalid files. I can resolve the error by converting my fastq to fasta.I'm not sure if adding fastq support into split_cns.py makes sense or if disallowing fastq as input to the hifi workflow makes sense.
Thanks for this software and I'm excited to compare the outputs to my other assemblies (based on what my colleagues have told me this should compare favorably).
The text was updated successfully, but these errors were encountered: