[ASK]

[Ajeet1699]

I am getting error at IDR step.

idr -s mm10_all_peaks_calculated.narrowPeak GEM_IDR_input.narrowPeak -o GEM_IDR_output.tsv --input-file-type narrowPeak --rank signal.value --use-nonoverlapping-peaks

Traceback (most recent call last): File "/home/u249048/.conda/envs/chip_myenv/bin/idr", line 10, in idr.idr.main() File "/home/u249048/.conda/envs/chip_myenv/lib/python3.7/site-packages/idr/idr.py", line 900, in main useBackwardsCompatibleOutput=args.use_old_output_format) File "/home/u249048/.conda/envs/chip_myenv/lib/python3.7/site-packages/idr/idr.py", line 487, in write_results_to_file merged_peak, IDR, localIDR, output_file_type, signal_type) File "/home/u249048/.conda/envs/chip_myenv/lib/python3.7/site-packages/idr/idr.py", line 348, in build_idr_output_line_with_bed6 rv.append( "%i" % min(x.start for x in m_pk.pks[key])) ValueError: min() arg is an empty sequence

Is I am doing anything wrong?

[JSuryatenggara]

Hi Ajeet. That error seems to be caused by an empty peak set, which in your case it looks to be GEM's (GEM failed to call any peak in your dataset). To confirm whether this is indeed the case, you can check the file "GEM" in folder 21_peaks_merging/ to see if it is empty. This error may be closely related to the poor alignment rate (in your previous post), so fixing that problem may solve this one. Or it could be caused something else (e.g., the dataset somehow very unsuitable for GEM to process), in which what you can do, for now, is to try relax the significance level for q-value (e.g., set --q down to 1 from the default 2).

Meanwhile, we will make it so the pipeline won't crash under such "zero peak set size" situation. Thanks for reporting this issue.

[Ajeet1699]

Hi. In GEM file, I have found 4546 entries. Venn.txt have this results: MACS2 GEM HOMER Genrich Total Name X 1 Genrich X 5071 HOMER X X 10 HOMER|Genrich X 114 GEM X X 422 GEM|HOMER X X X 7 GEM|HOMER|Genrich X 81 MACS2 X X 5 MACS2|Genrich X X 479 MACS2|HOMER X X X 23 MACS2|HOMER|Genrich X X 111 MACS2|GEM X X X 20 MACS2|GEM|Genrich X X X 1890 MACS2|GEM|HOMER X X X X 1876 MACS2|GEM|HOMER|Genrich

[JSuryatenggara]

Hi Ajeet, thank you for the reply. I tried to replicate your issue with some of my datasets but couldn't. In my case everything runs smoothly until the end. Can you try manually rerunning 21_peaks_merging_script.sh, and then followed by 22_peaks_processing_script.sh, to see if the same issue persists? Thanks.

[Ajeet1699]

Hi. I tried to run again as you asked, but same error is showing again. Thanks

[JSuryatenggara]

Hi, sorry for the delayed response. In that case, I will need to see your mm10_all_peaks_calculated.narrowPeak and GEM_IDR_input.narrowPeak files to figure out your problem. Can you upload them somewhere I can download from? Thanks.

If you can share the data through a shared dropbox / onedrive / google-drive folder, that might be the easiest way.

[Ajeet1699]

Hi. Please find both file in attached zip file. error_test.zip

[JSuryatenggara]

Hi Ajeet. I found the problem. It was not caused particularly by idr call on GEM peakset.

PROBLEM: The anaconda3 idr module is known to have this persistent bug (which still hasn't been fixed by the time I finished building ChIP-AP) where it returns exactly the same error you are having right now when the --use-nonoverlapping-peaks option is activated. This is caused by a buggy line inside idr.py script. chipap_installer.py should've taken care of that buggy script during installation by replacing it with the fixed version of the idr.py script (included inside the folder chipap_installation/). So it looks like there was some problem during your installation causing the fix to not be applied.

SOLUTION: You will need to replace your idr.py script manually. According to your error messages, it is this one: /home/u249048/.conda/envs/chip_myenv/lib/python3.7/site-packages/idr/idr.py. Replace that file with the idr.py inside the folder chipap_installation/. That should fix your problem.

Kindly let me know if that solves your problem, and if you have any other question.

[JSuryatenggara]

Since there is no further question, closing this thread assuming the problem has been resolved.