BFAST error in FindMatchesInIndexSet function

[javijevi]

Hi all,

I successfully went along the first steps of BFAST pipeline, including the indexes creation, but got the below copied error when running 'bfast match' step with the following command for a fastq test file with 9 reads:

bfast match -f reference_genome.fa -A 1 -r test.fastq -i 1 -I 2-10 1> matches.bmf 2> match.log &

Contents of match.log:
(...)
Searching index file 1/1 (index #1, bin #1) complete...
Found 4 matches.
Found matches for 4 reads.
Copying unmatched reads for secondary index search.
Splitting unmatched reads into temp files.
bfast: RunMatch.c:718: FindMatchesInIndexSet: Assertion `numReads == numWritten' failed.
Splitting unmatched reads into temp files.
bfast: RunMatch.c:718: FindMatchesInIndexSet: Assertion `numReads == numWritten' failed.

Any idea?

Thanks in advance.

[javijevi]

Splitting unmatched reads into temp files.
bfast: RunMatch.c:718: FindMatchesInIndexSet: Assertion `numReads == numWritten' failed.
Splitting unmatched reads into temp files.
bfast: RunMatch.c:718: FindMatchesInIndexSet: Assertion `numReads == numWritten' failed.

Just to tell that I made a mistake in copying twice the last two lines of the output.

[nilshomer]

Hi all,

I successfully went along the first steps of BFAST pipeline, including the indexes creation, but got the below copied error when running 'bfast match' step with the following command for a fastq test file with 9 reads:

bfast match -f reference_genome.fa -A 1 -r test.fastq -i 1 -I 2-10 1> matches.bmf 2> match.log &

Contents of match.log:
(...)
Searching index file 1/1 (index #1, bin #1) complete...
Found 4 matches.
Found matches for 4 reads.
Copying unmatched reads for secondary index search.
Splitting unmatched reads into temp files.
bfast: RunMatch.c:718: FindMatchesInIndexSet: Assertion `numReads == numWritten' failed.
Splitting unmatched reads into temp files.
bfast: RunMatch.c:718: FindMatchesInIndexSet: Assertion `numReads == numWritten' failed.

Any idea?

Thanks in advance.

Any reason why you want to use secondary indexes? I would recommend using all the indexes in the primary search (no secondary indexes).

This may be a bug (with the secondary search). Please submit your report to [email protected] so we can resolve the issue quickly.

[nilshomer]

Any reason why you want to use secondary indexes? I would recommend using all the indexes in the primary search (no secondary indexes).

This may be a bug (with the secondary search). Please submit your report to [email protected] so we can resolve the issue quickly.

I have found the bug and fixed the latest source code available via GIT. Let me know if you have any problems: )

[javijevi]

Any reason why you want to use secondary indexes? I would recommend using all the indexes in the primary search (no secondary indexes).

In BFAST book, you can find the following: 'If you wish to have a secondary set of indexes, which are used if no matches are found in the main set of indexes, use the -I option'. So, I thought that it was more efficient to not use a mismatch-allowing index, e.g., 1110111110011111, for reads which were already mapped by using an all-matchs index, that is, 11111111111111.

Obviously, I missed something important in this issue because of the complexity of the index-based search algorithm for a biologist, and I therefore will blindly follow your recommendation about not using secondary indexes.

[nilshomer]

In BFAST book, you can find the following: 'If you wish to have a secondary set of indexes, which are used if no matches are found in the main set of indexes, use the -I option'. So, I thought that it was more efficient to not use a mismatch-allowing index, e.g., 1110111110011111, for reads which were already mapped by using an all-matchs index, that is, 11111111111111.

Obviously, I missed something important in this issue because of the complexity of the index-based search algorithm for a biologist, and I therefore will blindly follow your recommendation about not using secondary indexes.

I have spent a lot of time thinking about the indexing strategy and I would follow the strategy found in section 7.1 where we use 10 "main" indexes and no secondary indexes.

I apologize for the confusion but I tried to keep options for flexibility.