OK, I'll pick in on this. I have the following per_tile_quality plot:

This is for the R2 from paired end data, after quality trimming with BBduk. I was (to be honest) not even aware of this per_tile issue, so my question is: should I be doing filterByTile.sh here?

Unless you have a real good reason you should not need to use
filterbytile.shwith recent data. What was the logic behind using it in this instance. We seem to be missing the complete picture here as hinted by @h.mon.The data which I am having is for a microbial genome and trying to improve the data quality as much as good. I would like to see whether the genome assembly will be better or not.
Figure I have given above is after filterbytile.sh filteration with the following command
filterbytile.sh in1=R1.fastq.gz in2=R2.fastq.gz out1=f1.fq out2=f2.fq trimq=1 qtrim=rl lowqualityonly=f ud=0.75 qd=1 ed=1 ua=.5 qa=.5 ea=.5This is the raw data per tile quality figure
There is no much changes from trimmomatic to filterbytile.sh
Trimmomatic command I used along with the
SLIDINGWINDOW:2:30 MINLEN:20 LEADING:30 TRAILING:30parameters.I think there was no need to use
filterbytile.shin this case. I suggest that if you are staying with BBMap suite then usebbduk.shto scan and trim your data to remove any extraneous sequence. Since you want to dode novoassembly you should also quality filter at Q20. But that should be all you need before going intoSPAdesor a similar assembler. If you have really deep coverage then doing normalization of reads may be needed.You are using very strict settings, for when you know there’s a serious problem (ref: Introducing FilterByTile: Remove Low-Quality Reads Without Adding Bias), however, the picture you linked does not indicate any serious tile problems.