Solutions to
Barracuda
Problems
error while loading shared libraries: libcudart.so.6.0: cannot open shared object file: No such file or directory
Barracuda needs the CUDA run time libraries.
Work around
Add the location of the missing run time libraries to your
LD_LIBRARY_PATH.
E.g. in tcsh something like:
setenv LD_LIBRARY_PATH "$LD_LIBRARY_PATH":/usr/local/cuda/lib64/
[aln_core] CUDA ERROR(s) reported during first kernel run! Last CUDA error message: the launch timed out and was terminated
Did you connect your console to the GPU you are using with Barracuda
and run windows on the console?
The barracuda's kernels take a long time to complete.
Often far longer than the X-11 windowing system is expecting.
It may be that the windowing system has timed out
and aborted one of barracuda's kernels.
Work around
You will probably need to dedicate the GPU you are using to accelerate
BarraCUDA to just running as a GPGPU device.
Can you plug your console into another video port on your computer?
Can you avoid running X-11 on your console?
Can you (greatly) increase the timeout?
[aln_core] CUDA ERROR(s) reported during width/bid preparation! Last CUDA error message: an illegal memory access was encountered
Did you try and use 0.6 index with Barracuda version 0.7.0 or later?
Work around
Rebuild your index files.
See BWA work around.
CUDA ERROR(s) reported during split kernel run! Last CUDA error message: an illegal memory access was encountered
This error may be reported by query sequences which exceed 100 bp.
However, e.g. on other hardware,
the error may not be reported or may be trapped at a different point
in the code giving a slightly different error message.
Work around
Remove or truncate sequences longer than 100 ACGT base characters
from the DNA query input file.
For example, you might replace a long query sequence
with one or more of its subsequences each of ≤100 bp.
Error now trapped and properly reported.
(The fix is included in barracuda 0.7.107c).
The aln option works best with short sequences.
There is a configurable internal
limit MAX_SEQUENCE_LENGTH of 100bp.
If you edit #define MAX_SEQUENCE_LENGTH you will
need to run make again.
(First
clear the linux/ and linux/objs/ directories.)
If you make large changes to MAX_SEQUENCE_LENGTH
you need to double check the GPU does not run out of memory.
[barracuda_read_seq] Sequence nnnBP truncated to 150
This is a warning introduced in version 0.7.107d.
With barracuda 0.7.107c and earlier, reads that were too long would cause
barracuda to stop.
This warning means over long sequences are truncated to the limit
but barracuda aln continues.
In BarraCUDA 0.7.105 to 0.7.107c the limit was 100 base pairs.
Work around
Alignment using just the first 150BP is often sufficient.
If not, see the description of limit MAX_SEQUENCE_LENGTH
above.
Noisy reads more than 127bp fail to match
Applies to version 0.7.107d (fixed in 0.7.107e).
Sometimes mismatches at the end of the read will cause the read to be
rejected and so no match for the read is reported.
Work around
Problem cannot arise with reads less than 127 base pairs.
Fixed in 0.7.107e.
[bns_restore_core] fail to open file 'indexes/ucsc.hg19.nt.ann'. Abort!
Did you give a DNA sequence fasta file on the command line where you
should have given a .sai file
(e.g. a SAI file produced by barracuda aln).
BarraCUDA's command line pretty much follows that of BWA.
Usage: barracuda sampe [options] <prefix> <in1.sai> <in2.sai> <in1.fq> <in2.fq>
Work around
Double check command line.
sampe_core no Running with threads
When you run barracuda sampe you do not get a status
message like:
[sampe_core] Running with 8 threads
Similarly does barracuda ignore the -t command line option?
This may be caused by building barracuda without
HAVE_PTHREAD.
Which may in turn
be because your system does not support posix threads or
perhaps
you got a message like:
/bin/sh: ldconfig: command not found
when you compiled BarraCUDA?
Work around
If caused by missing ldconfig, then add ldconfig to your path
and rebuild barracuda.
E.g.
setenv PATH "$PATH":/sbin
make
Before using make you will need to remove the existing version
and its object files
(see subdirectory linux/release/).
Check -DHAVE_PTHREAD was used when compiling each file.
Check sampe does indeed produce a "Running with n threads"
message.
Note barracuda
can still override -t on your command line
as it limits the number of host threads
to the number of CPUs the host computer has.
Barracuda sampe running with 8 threads
On a multi core server by default barracuda sampe
will run with up to eight host threads.
Work around
If your server has more than 8 CPUs you can use the -t
argument to tell barracuda to use more than 8 host threads.
[aln_core] Error binding "bwt_src" to bwt_cuda constant.
invalid device symbol
Are you trying to use Barracuda on a pre 3.5 GPU?
By default Barracuda is compiled with instructions from compute level
3.5.
These instructions will not run on GPUs with compute level lower than 3.5.
GPUs older than 2.0 are not supported.
See also next error.
Work arounds
For GPUs between 2.0 and 3.5 recompile with the appropriate -arch
I.e. set environment variable Arch to sm_20
remove previous image and object files
and re-run make.
Use more recent GPU.
[aln_core] Not enough memory to perform alignment (min: 675 MB).
Barracuda aln needs 675 megabytes (ideally more)
plus the space taken by the reference genome on the GPU card.
This error message means that
barracuda is saying after loading the compressed reference genome on to the GPU
it does not have that much left free RAM on the GPU.
Work arounds
Most modern GPUs should have enough on board memory.
There are a number of nVidia tools,
e.g. deviceQuery,
which show GPU characteristics such as total amount of global memory.
nvidia-smi may show actual current usage.
Is anyone else using the GPU?
Barracuda sampe hangs
Sometimes barracuda sampe may get as far as
[sampe_core] Converting SA /tmp/ERR242845_1.200k.sai /tmp/ERR242845_2.200k.sai to linear sequence coordinates, please wait...
[sampe_core] .
and appears to stop.
Typically everything is fine, sampe is simply doing a lot of work and
it will eventually move on.
It may be that sampe needs more RAM than your machine has, in which
case it may be taking a very long time as your operating system tries
to find more memory for sampe to run. This is often futile and the
only realistic situation is to find a computer with more RAM.
It appears occasionally sampe really gets stuck in a loop.
Work arounds
First check that sampe is really not going to complete.
Even on modest size problems, this step may easily take several minutes.
Check that there is enough memory.
Even for less than a million reads and the full human reference
genome, you may need more than 6 Gigabytes.
Let me know if you hit this problem.
example
Epigenetics and GeForce GTX 1080
[aln_core] CUDA ERROR(s) reported during first kernel run! Last CUDA error message: out of memory
[aln_core] Abort!
Under certain unusual circumstances the calculation of
buffer size assumes there is more space left on the GPU
than there really is
so setting buffer to be too big.
This causes the GPU to run out of memory
leading to the above error message.
Work around
Fixed by release 0.7.107h
Very old GPUs
[aln_core] CUDA ERROR(s) reported during first kernel run! Last CUDA error message: out of memory
[aln_core] Abort!
Did you compile Barracuda with SM_VERSIONS = sm_13 or less?
No work around
Barracuda is not supported on compute level 1.3 or earlier GPUs.
(Hint try reducing buffer to 21 and blocksize to 64.
But note a pre compute level 2.0 GPU is bound to be slow.)
No matches found in tiny reference genome
Up to 0.7.107 BarraCUDA stopped immediately on genomes
whose BWT table was less than 1048576 bytes
without reporting an error.
Work around
Fix incorporated into version 0.7.107a
barracuda_0.7.107a.tar.gz
cuda.cuh:323: unsigned int __global_bwt(unsigned int *, int, int, int *, uint4 *, uint4 *, uint4 *, uint4 *): block: [46,0,0], thread: [47,0,0] Assertion `!(base<0 || base >= 775451201)` failed.
[aln_core] CUDA ERROR(s) reported during width/bid preparation! Last CUDA error message: device-side assert triggered
[aln_core] Abort!
Caused by debug code being too sensitive to size of reference genome.
Work around
The problem was fixed in barracuda_0.7.107.
Please use the newer version of
Barracuda.
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by linux/release/barracuda)
Probably due to different versions of the GNU C library on the Linux
host computer you are using now
compared to the one you used to compile and link the barracuda program.
Work around
Perhaps the easiest is to compile again, e.g. using:
make clean
make
on your new computer.
It may be there is already a compatible version of file libc.so.6
on your computer and appropriate use of path and or environment variables
will enable the operating system to find and use it when you start barracuda.
0.6.2 beta [infer_isize] inferred maximum insert size: Segmentation fault
Work around
The problem appears to have been fixed in barracuda_0.7.105a
Please use the newer version of
Barracuda.
Alternatively disable multiple host threads when running sampe
using sampe -t 1
Undefined reference to `bwt_2occ4' `bwtl_2occ4' `bwt_2occ'
BarraCUDA 0.7.107e make fails on Ubuntu 16.04.1
with
gcc version 5.4.0.
It appears the new version of the GCC compiler has a stricter
definition of C++ and is rejecting
source code which earlier versions of gcc compiled without problem.
Work around
Fixed in barracuda release 0.7.107f
Small indexes and large number of mismatches aln -n
There seems to be a problem when the number of difference between
the read sequence and the index is very large
on very small indexes
(e.g. the index contains less than 1000 bases).
In regular NGS cases aln -n is fine
but in such special cases there is a problem when the integer given with
-n greatly exceeds 2,
in that far fewer matches are reported than would be expected.
The problem also occurs in BWA (version 0.7.12-r1039).
Work around
Cause and cure are unknown.
Variation in results between different runs on the same data
Where there are many potential matches,
the exact details of those reported by BarraCUDA
may be different from those reported by BWA.
Cause
-
BarraCUDA uses depth first search rather than
breadth first search as used in BWA.
This may cause slight differences,
particularly
if you have very short reads
with many multiple hits.
-
There is an element of randomness
due to potential different synchronisation inherent in multi-threading.
Where there are multiple possible mappings, due to parallel
operation it is possible for a second run to find them in different
orders. This can lead to different but possibly equally good mapping
being printed out in the the second run.
Thus although there may appear to be many differences in the
output file, many of these differences are not so interesting
when you look at them in detail.
Help with aligning bisulfite sequencing methylation data with barracuda
See seqbarracuda-meth
documentation
by Albert Vilella.
[aln_local_core] Potential bug: (206,223) > 170
Long story short, it's not a bug.
Work around
Simply ignore this and similar informational messages.
W.B.Langdon
Back
29 October 2014
(last update 26 September 2017)