text: user292: In my snakemake workflow, I use deeptools bamCoverage (in a make_bigwig rule), then computeMatrix and plotProfile (in different plot_*_profile rules) to create coverage profiles for various kinds of small RNAs. It sometimes happens that there are very few reads in a particular category of small RNAs. This results in bamCoverage exiting with an error (when I use the --skipNAs option, in order to make coverage profiles not take into account empty regions):
  Error: The generated bedGraphFile was empty. Please adjust
  your deepTools settings and check your input files.
  
  The fact that bamCoverage fails make things a little annoying for me, because the later the failure, the easier to handle things in my workflow: I will need to catch the error and generate a dummy output file in the make_bigwig rule, and then handle the special dummy file in the plot_*_profile rules.
  I would be fine having an empty coverage file: the absence of reads (either in the bam file, or matching selection criteria in bamCoverage) is not due to an error.
  Is this just not possible, by the format definition?
  Did I miss an option to have bamCoverage accept making empty files?
  Would this make computeMatrix fail?
  
  user77: I'll fix the bamCoverage issue in the 2.6.0 release (it may already be fixed since I rewrite how bigWig files are made for that release). You can follow my status on the issue page. In principle you should be able to do this, it's just a deepTools limitation.
  This should work fine with computeMatrix, though keep in mind that you're just going to get a big block of NA values.
  Update: This error ends up coming from pyBigWig. I've just found that bedGraphToBigWig also can't make a bigWig file with now entries, so I suspect this is sort of undefined behavior. Regardless, I'll alter pyBigWig to produce a file that it can open and use in a meaningful manner.
  
original_text: 292: <p>In my snakemake workflow, I use deeptools <code>bamCoverage</code> (in a <code>make_bigwig</code> rule), then <code>computeMatrix</code> and <code>plotProfile</code> (in different <code>plot_*_profile</code> rules) to create coverage profiles for various kinds of small RNAs. It sometimes happens that there are very few reads in a particular category of small RNAs. This results in <code>bamCoverage</code> exiting with an error (when I use the <code>--skipNAs</code> option, in order to make coverage profiles not take into account empty regions):</p>
  
  <pre><code>Error: The generated bedGraphFile was empty. Please adjust
  your deepTools settings and check your input files.
  </code></pre>
  
  <p>The fact that <code>bamCoverage</code> fails make things a little annoying for me, because the later the failure, the easier to handle things in my workflow: I will need to catch the error and generate a dummy output file in the <code>make_bigwig</code> rule, and then handle the special dummy file in the <code>plot_*_profile</code> rules.</p>
  
  <p>I would be fine having an empty coverage file: the absence of reads (either in the bam file, or matching selection criteria in <code>bamCoverage</code>) is not due to an error.</p>
  
  <p><strong>Is this just not possible, by the format definition?</strong></p>
  
  <p><strong>Did I miss an option to have <code>bamCoverage</code> accept making empty files?</strong></p>
  
  <p><strong>Would this make <code>computeMatrix</code> fail?</strong></p>
   77: <p>I'll fix the <code>bamCoverage</code> issue in the 2.6.0 release (it may already be fixed since I rewrite how bigWig files are made for that release). You can follow my status <a href="https://github.com/fidelram/deepTools/issues/598" rel="nofollow noreferrer">on the issue page</a>. In principle you should be able to do this, it's just a deepTools limitation.</p>
  
  <p>This should work fine with <code>computeMatrix</code>, though keep in mind that you're just going to get a big block of NA values.</p>
  
  <p><strong>Update</strong>: This error ends up coming from pyBigWig. I've just found that <code>bedGraphToBigWig</code> also can't make a bigWig file with now entries, so I suspect this is sort of undefined behavior. Regardless, I'll alter pyBigWig to produce a file that it can open and use in a meaningful manner.</p>
  