When I get to the [samtools fixmate] step of my workflow, I always get a
samtools sort: couldn’t allocate memory for bam_me
… error.
My Amateur Troubleshooting Attempts
Disclaimer: I am not an expert at dealing with multi-core, multi-threaded computing clusters, so the following information may be completely useless.
I dug a little deeper and found that the [samtools fixmate] step calls both [samtools sort] and [samtools fixmate]. I already called [samtools sort] as the previous step in my workflow, so it was redundant. Even though I could simply take the [sort] step out of my workflow, I would prefer to have it taken out and called as a separate step.
More importantly, I have concerns that a single step allocating memory twice on the same thread check may cause issues. Namely:
All versions of [samtools fixmate] do this, and all versions produce the same error so I am unable to check if removing/skipping the extraneous [sort] call will fix this.
There is a new known issue with the job container configuration for some versions of the fixmate tool. This was tracked about a month ago and the correction is still pending.
I’m curious if that same step being called independently is also a problem (this would be the first report!). I would like to review closer. Would you be able to share the version you are running, and confirm the server is UseGalaxy.org.au? Find the version at the very top of the tool form.
You could also try a test: toggle into and use an earlier tool version. One back is usually enough when there are small configuration issue with the initial deployment across some of the larger instances (a new Galaxy release came out earlier this week, and learning about small things is great so we can squash the problem! ).
Other than this, I would generally suggest filtering a BAM before using this tool. Some minimum mapQ, primary alignments, proper pairs, and especially removing unmapped! Those records would usually be discarded anyway, and will help this tool to process larger primary data.
Finally, as an extra note, I can let you know that any BAM dataset with the datatype bam is coordinate sorted. This tool is intended to be run as part of a workflow that can consume any BAM and not fail for a technical reason, so the developer decided to bundle the two actions (required queryname sorting followed by fixmate). Not ideal for all use cases! But if the operation failed with one tool, it would fail with any others that called it in a bundle, which is why I think there is something else special going on and would like to review.
More details about BAM data are in this topic if curious!
We hope this helps, and please let us know if you are able to get this to run with a different version!
And .. I just reread your post! You already tried different versions. From here, I would suggest checking your BAM! It may actually be too large to process right now but there are things you can do to shrink it without important information loss!
These two do the same thing, just have the options presented differently (technical versus language).
Filter BAM datasets on a variety of attributes
BAM filter Removes reads from a BAM file based on criteria
The tool runs fine on .org and .eu because these servers are assigning a single thread to it, but .org.au tries to run it with 8 threads which causes memory usage to go beyond what’s available on the machine it’s executed on.
I can try fixing this tomorrow on the tool side, then AU needs to install that new version.
If, in the meantime AU admins read this: the solution for old tool versions is to allocate only 1 core to the tool.
The problem should be corrected now at