Message during salmon quant: couldn't dequeue read chunk

[Gregory P]

Hello everyone,

I'm running transcript quantification using salmon. It seems to be working fine, except that as it processes fragments it keeps writing out the following message:

 couldn't dequeue read chunk

It repeats this message a few hundred times, but there is no indication of how bad a problem it is. Any comments on the significance of this message?

I'm running the latest Mac OS X binary (Salmon-0.7.2_OSX_10.11). The command I'm using is

salmon quant -i mouse_index -l A -r data/FASTQ/mysample/*.fastq.gz -p 4 -o quant/mysample

Many thanks!

-Greg 

[Rob]

Hi Greg,

  What you're seeing is the (probably unnecessarily verbose) message coming from here (https://github.com/COMBINE-lab/salmon/blob/develop/src/FastxParser.cpp#L115).  This happens when the parser is ready to populate more records with FASTQ reads, but all of the structures reserved for holding read data are currently being processed and it is unable to immediately obtain fresh structures to fill in with new data.  Are you running on a machine with a particularly fast HDD (an SSD or a fusion drive maybe)?  Typically, this would happen when the ability to read from file is greater than the speed at which data is being processed.

  Overall, the message itself is harmless.  Actually, thanks for bringing this up, since it's probably confusing without more context is isn't necessarily something the user should see.  As long as your data finishes processing, it shouldn't be a problem at all (apart from the annoying repeated message).  Do a reasonable fraction of your reads map?  You can check the mapping rate in the quantification directory (under the aux_dir/meta_info.json file).  Long story short, it's probably just a case of our read parser communicating too much unnecessary information to the user and nothing to worry about.

Best,

Rob

[Gregory P]

Thanks Rob, that makes sense. Yes, I'm using a fusion drive which would explain that that the I/O might catch up with the parsing. I'm getting more than 80% of mapped reads, which sounds good to me.

Best,

Greg