Closed myxotheles closed 1 year ago
Tried again with more memory, still not resolving. I checked my input bam with samtools quickcheck looks ok. This is probably a bug in nanomonsv or in the nextflow pipeline not passing data properly. Please can you look at this as this makes the workflow unworkable.
Hi @myxotheles, I can see here that your normal file is generated with non-ONT datasets. I am not sure if nanomonsv supports them since it is specifically designed for ONT data. From our part, the workflow seems to be passing the inputs to the software correctly, so your guess that the crash lies with the software is correct.
I noticed that you opened an issue on the nanomonsv
github page. I would suggest to wait for the reply from the nanomonsv developer before attempting to run the workflow again.
Dear @RenzoTale88 , thanks for your reply. We only have the control sequenced with Illumina. We could re-sequence it with nanopore though. However unfortunately, in practice you often don't have normal tissue for control, particularly with archived samples. If that is the case, is it possible to run the workflow in 'tumour only' mode?
Unfortunately no, the workflow currently requires a tumor/normal pair to work properly. Mind that, although nanomonsv does call SVs using only the tumor samples, this mode has not been tested.
What happened?
Hi, I have run this workflow via command line on our HPC. We do not have docker/singularity but we have apptainer. Since apptainer and singularity are similar, I have tried to see if it works when specifying singularity. It seemed to run just fine but then crashed suddenly. I am not sure this error has got to do with apptainer, it looks more like a bug in python code
Operating System
CentOS Linux 7 (Core)
Workflow Execution
EPI2ME Labs command line
Workflow Execution - EPI2ME Labs Versions
No response
Workflow Execution - CLI Execution Profile
Singularity (Apptainer)
Workflow Version
v0.2.0-g5bcd48d
Relevant log output