usearch9 multithread fastq_filter is crashing about amptk

[nextgenusfs]

Ok, thanks this must be a linux only problem? Do you see the problem with v9.1.13? We can also use VSEARCH for this to avoid this problem, is it only in the -fastq_filter command or is it all commands? This step is probably paranoia on my part, but just trying to trim off the index 'A' linker if reads are 251 instead of 250 or 301 instead of 300.

Right now, vsearch is not a hard dependency, but I was thinking I may make it one. I don't really see a reason not to, it is easy to install and lets you bypass the 4GB RAM limit of the free 32-bit usearch. If you don't have vsearch, currently the scripts will run python versions quality filtering, etc - which are a lot slower. If vsearch is hard dependency, then can use vsearch for this and avoid this problem. Assuming it is only a problem on -fastq_filter?

[hyphaltip]

So it only happens for the fastq_filter step and it only happens on Linux - I saw it on 9.0 and 9.1.13 - so I don't think that usearch has fixed.

I agree using vsearch for as many steps as possible anyways for these steps or others. I think usearch is faster for some of the other overlap steps.

[nextgenusfs]

switched to VSEARCH for this https://github.com/nextgenusfs/ufits/releases/tag/0.7.0