MSajek
commented
1 year ago I had exactly the same issue. It looks like it can be caused by very long reads. Filtering fastq files in preprocessing step can help here (e.g. filter to long reads during adapter trimming step). If not you can try to identify which line in input sam file cause an error. I analyzed small files and I was able to it manually, but for larger input files script can be required. First, you should check the last line in your_file_PARalyzer_Utilized.sam
tail -n 1 your_file_PARalyzer_Utilized.sam
That's last line utilized by PARalyzer that did not produced error. Then, check number of this line in your original input.sam. Let's assume that read name in this line is read_10000.
grep -n 'read_10000' input.sam
Let's assume that line number is 10000, then you produce your tmp.sam by increasing this number by e.g. 1000
head -n 11000 inmut.sam > tmp.sam
Run PARalyzer with tmp.sam and check if it is producing error.
If not, increase more (e.g. next 1000).
If yes, you know that line causing error is between 10001 and 11000 and you can start next iteration e.g. using half value (10500) to see if wrong line is between 10001 and 10500 or 10501 and 11000. In this way with relatively low number of iterations you should be able to identify line which cause an error and delete it by e.g.
grep -v 'read_name_in_wrong_line' input.sam > input_corrected.sam
santataRU
when I run the paralyzer, not the parpipe, I met some problems, here is the specific information:
does anyone know how to solve it?