oushujun
Warning: LOC list - is empty / NO LTRs, SINES or LINES
Hi I am wondering if there is any error here. I have done TE predictions for like 8 genomes (around 20MB) in the same family and normally find a high number of TEs and find that this specific species does not have as good results as the rest.
/shared/EDTA/EDTA.pl --genome genome.fasta --overwrite 1 --sensitive 1
--anno 1 --threads 6 --evaluate 1 --force 1
#########################################################
##### Extensive de-novo TE Annotator (EDTA) v2.2.0 #####
##### Shujun Ou ([email protected]) #####
#########################################################
Parameters: --genome genome.fasta --overwrite 1 --sensitive 1 --anno 1 --threads 6 --evaluate 1 --force 1
Wed 5 Mar 15:14:07 GMT 2025 Dependency checking:
All passed!
Wed 5 Mar 15:14:08 GMT 2025 Obtain raw TE libraries using various structure-based programs:
Wed 5 Mar 15:14:08 GMT 2025 EDTA_raw: Check dependencies, prepare working directories.
Wed 5 Mar 15:14:08 GMT 2025 Start to find LTR candidates.
Wed 5 Mar 15:14:08 GMT 2025 Identify LTR retrotransposon candidates from scratch.
awk: fatal: cannot open file `genome.fasta.mod.pass.list' for reading: No such file or directory
Warning: LOC list - is empty.
Error: Error while loading sequence
Filter sequence based on TEsorter classifications. Unclassified sequences will also be output to the clean file.
Usage: perl cleanup_misclas.pl sequence.fa.rexdb.cls.tsv
Author: Shujun Ou ([email protected]) 10/11/2019
mv: cannot stat 'genome.fasta.mod.LTR.intact.fa.ori.dusted.cln.cln': No such file or directory
mv: cannot stat 'genome.fasta.mod.LTR.intact.fa.ori.dusted.cln.cln.list': No such file or directory
cp: cannot stat 'genome.fasta.mod.LTR.intact.raw.fa.anno.list': No such file or directory
ERROR: No such file or directory at /shared/EDTA/util/output_by_list.pl line 39.
perl filter_gff3.pl file.gff3 file.list > new.gff3
Wed 5 Mar 15:14:20 GMT 2025 Warning: The LTR result file has 0 bp!
Wed 5 Mar 15:14:20 GMT 2025 Start to find SINE candidates.
.... Similar results follow from this.
Thanks, Keith
I'm getting nearly the same error using version v2.2.2 (quay.io-biocontainers-edta-2.2.2--hdfd78af_1 image via apptainer).
My error includes a cds input and has Error: cd-hit-est is not found in the CDHIT path ! even though the dependency check states All passed!. @keith-harrison are you using a containerized version of EDTA, by chance?
@oushujun Hi, I have also installed version v2.2.2 and am using a singularity container (with docker://quay.io/biocontainers/edta:2.2.2--hdfd78af_1). I have the same error as well:
Error: cd-hit-est is not found in the CDHIT path !
No I use the conda/mamba version which works well for me (redownloaded last week to get the new version finally 👍 ). Also the error I am having has nothing to do with the error you are having since they occur independently, mine is just down to no LTRs being found in some of my genomes :) try to make a new github issue just so its clear for the author of the tool.
To answer to Keith's original question, if the genome is this small (20Mb), you may want to consider the possibility that it's missing some types of TEs. If you believe the program runs correctly, you may use --force 1 to bypass the missing types.
For other apptainer questions - I am very unfamilar with singularity/apptainer, sorry. I would love to know the solution if you find out, or ways to improve EDTA or its conda recipe to solve this issue.
Thanks! Shujun
The cd-hit-est error is cause by LTR_retriever#L282. The which command is not available in the container, at least for singularity. As a stopgap, I'm binding the host's which executable inside the container by adding -B /usr/bin/which to the singularity command:
export PYTHONNOUSERSITE=1
singularity exec -B /usr/bin/which {path}/EDTA.sif EDTA.pl --genome genome.fa [other parameters]
The run hasn't completed yet; however, it has finished finding LTR candidates without any issues.
Adding which (available in the conda-forge repo) to the dependencies should fix it
Thank you @maa146 for this fix! Binding which executable inside the container helped.