-
Notifications
You must be signed in to change notification settings - Fork 7
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
Recursion limit reached #31
Comments
looks like this happened during the communication between different threads. not sure what goes on there exactly. could you share with us the whole work folder of that failing step (/hps/nobackup/flicek/ensembl/compara/sbhurji/Development/fastoma_run/work/18/6d8a8694445b6226830f618af3bf2f), including the data for the roothog D0138574. Probably something like this should work: |
Hi Adrian, thank you for getting in touch. I kept the log message but I have unfortunately deleted the work directory in anticipation of the rerun. In the meanwhile I will rerun it and will let you know when I reach this issue again? |
No worries. To check the slrum job, you could see the relevant
|
Thank you that is helpful, I will check it for this run. |
Hi Sina, |
Hi Simarpreet |
Hi Sina, |
I've uploaded a fix for this issue (hopefully this time for real). you could try it by updating the repo with the |
Hey Adrian, thank you for looking into this. At the moment our servers are under scheduled maintenance I will let you know if this fixes it. Thank you. Would request to keep this issue open until then. |
Btw, if you share the fasta file of rootHOG ( inside the folder |
Hi Sina, sure thing thank you for helping with this. PFA the fasta file herewith. Just to let you know I have also rerun the pipeline at my end but it will be a while until it reaches that step, so it will be great if you could check if the issue is resolved. |
Thanks. Yes. It finished successfully in our cluster. Hope it will be smooth in your side.
|
Thank you so much for testing this on your side, will let you know how the run goes for us, finger crossed. |
Hi Sina and Adrian, sorry it has taken a while for me to get back to you. So as it stands the run was still not complete on my end. When I got the segmentation fault I tried to up the memory by updating it to the following in FastOMA.nf file: ` memory { mem_cat(getMaxFileSize(rhogsbig), nr_species as int) * task.attempt * 3 }
After which I again got the segmentation fault error but with command.log.txt The fasta file: The size of the zipped folder is more than the allowed size for git I can send that via email. |
Hello. I am having a RecursionError: maximum recursion depth exceeded error as well. I am running 0.3.4. I am only running with 15 species. I am pasting the last good line and the first error line from my .nextflow.log. I am also attaching a screenshot of my summary report. I am lost as to what I should do next to trouble shoot this issue. Thank you, from .netflow.log: Caused by: Command executed: fastoma-infer-roothogs --proteomes proteome --hogmap hogmaps --splice splice --out-rhog-folder "omamer_rhogs" -vv Command exit status: Command output: There are 4776 clusters. Command error: |
Hi @srobb1 |
Hi @Simarpreet-Kaur-Bhurji Best, |
Hi Sina, sure thing we will get in touch via email to schedule our next meeting. We can look into the above issues then? |
Hello,
While running FastOMA on 2200 species, I encountered another mafft segmentation fault but when I resumed nextflow it seemed to not complain about the segmentation fault but I got the recursion limit reached error. Please find attached the log file of the run herewith. Do you know what's going on?
recurrsion_depth_err.log
The text was updated successfully, but these errors were encountered: