File *nmtf.LTRlib.fa not made #81
Comments
|
Hi Lauren, It's likely that the program did not identify any non-TGCA LTR elements in the genome. Please check if there are any entries in the Best, |
|
Hi Shujun, Thanks for the prompt response! I look a look at that file, but it looks like there are entries: Are there cases where it is expected to have entries in the file, but they don't end up in the *nmtf.LTRlib.fa file? Thanks for your help! |
|
Hi Lauren, Can you paste the program screen output here? And if rerunning the program is not too slow, please rerun it with the Best, |
|
Hi Shujun, For sure -- here's the full log: I'll also launch another run with the Thanks, |
|
With a glance the log file seems good to me. I will take a closer look at each step. The number of intact LTR elements seems a little bit low for me. Did you use the hard-masked genome or the soft/un-masked one for LTRharvest and LTR_FINDER? |
|
It could be maybe partially because it's not a super contiguous assembly?? The N50 is ~150kb, and I split the file into partitions so it ran faster. |
|
Splitting the genome is suboptimal because the filtering step needs a bigger sample size to be effective. You may use more threads to run it and the parallelism is quite efficient. |
|
So I did it because I'm running other tools as well (LTR finder, RepeatModeler), and the genome I'm working with is quite large (~6GB). Do you think that the parallelism would scale to a genome of that size?? |
|
Yes, it scales well. Check out the wheat issue for benchmarks. You may also
try EDTA which integrates many good tools
…On Sun, Aug 30, 2020 at 1:07 PM Lauren Coombe ***@***.***> wrote:
So I did it because I'm running other tools as well (LTR finder,
RepeatModeler), and the genome I'm working with is quite large (~6GB). Do
you think that the parallelism would scale to a genome of that size??
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#81 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNX4NHGU7HSMPLS35XT7GDSDKBL7ANCNFSM4QONGE7Q>
.
|
|
Ok cool - I'll give it a try without partitioning (it was too slow previously but I see there have been significant improvements since I last tried!). |
|
A recent update should have made TIR-Learner much faster. Please try it out
if you get a chance. thanks!
Shujun
…On Sun, Aug 30, 2020 at 2:34 PM Lauren Coombe ***@***.***> wrote:
Ok cool - I'll give it a try without partitioning (it was too slow
previously but I see there have been significant improvements since I last
tried!).
And thanks for the suggestion about EDTA -- I think another member of our
group tried it but found that one of the components (I think TIR-learner)
was quite slow, so that's why I haven't tried it myself yet.
Thanks for your suggestions!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#81 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNX4NFH4BWJJOZHGH3BVMDSDLAXFANCNFSM4QONGE7Q>
.
|
Hello,
I'm running LTR retriever v2.9.0 (installed via conda), and based on the logs I'm expecting to see these output files in my working directory:
However, I'm only seeing two of those files:
Specified parameters:
Any idea why that fasta file isn't being generated? Or am I looking in the wrong place?
Thanks so much!
Lauren
The text was updated successfully, but these errors were encountered: