Run FLU-avian just for Influenza type A

[biodfrl89]

Hi.
I'm running IRMA with the FLU-avian module using paired-end Illumina sequences. I like the final results of the algorithm, but I noticed, in the htop, that, during the executing of IRMA, some analysis are performed using Influenza type B profiles. I wonder if there is some option or configuration to not perform any analysis involving the Influenza type B data, in order to reduce the execution time of IRMA.

Thanks.

[sammysheep]

Technically yes, it could be configured if such a LABEL module existed, but it currently does not. LABEL does take a bit of time and uses both A and B in its classification step as you say.

We are re-examining IRMA's classification step in hopes to streamline things and improve performance.

In the near term, we will be updating plurality references such that the FLU-avian configuration should become much less necessary for avian workloads.

• Out of curiosity, what subtype was this run for?
• How did the standard settings do in comparison?

If you are still very interested in a Flu-A-only LABEL module, feel free to raise an issue in that repo.

[biodfrl89]

It would be nice to have that module in the next updates. I'll be keeping an eye on that, because in my lab they have a solid workflow involving SPAdes for the de novo assembly of Influenza virus, but the workflow is extensive, time-consuming (days for processing one sample), prone to errors, and difficult to automate. I came across with IRMA, run some tests, and had the results in a couple of hours. I was impressed. So I want to implement IRMA for a new and more efficient workflow for the lab.

I ran IRMA FLU-avian for samples of H5N1 and H7N3. And the resulting assemblies were the sames as the ones obtained with SPAdes. Obviously, with the SPAdes workflow it took about 5 days to end the analysis (for both samples), and with IRMA it took about 6 hours (for both samples). I haven't tried the FLU module, if your are referring that module as the standard settings.

Thanks for your response.

[sammysheep]

It's all the same FLU module (FLU, FLU-avian, FLU-utr, etc.), but IRMA uses an admittedly odd way to pass pre-saved configurations.

I suppose when I do breaking changes that's something I can fix. Using the standard settings uses BLAT for sorting, so it's much faster at the expense of some classification accuracy. The latter will hopefully get improved with improved references.

[sammysheep]

If you happen to try the standard "FLU" configuration for the above, let me know any runtime/consensus differences.

[biodfrl89]

"an admittedly odd way to pass pre-saved configurations" LOL absolutely. I spent some time trying to figure out how to pass custom configuration to the script and yeah, it's quite odd.

Right now I'm doing some workflow that involves IRMA to automate some process, but I'll let you know if I use the standard configuration.

Among other things, I detected something that I don't know if you are aware of. I am testing my workflow with IRMA in a sample that is really, really, really depleted in reads for segment 4 of Alphainfluenzavirus (~10 reads in the worse covered regions of S4, in a sample with more that 1M reads in the fastqs). When I launch IRMA, it seems to produce only one assembled sequence for S4, but then I do some blastn in the sequence and in turns out that the "unique" assembled sequence is in fact two joined sequences, corresponding to two matches in the same subject, with a relative big gap in the middle. I don't know if that was the intended way to report the assembled sequences, but clearly it can be misleading.

I managed to write a script that perform a local blastn using the nt_viruses database of NCBI on all assambled sequences, detect if a sequence has more than one match in the best subject, and if it does then add N's between the end and the start of the individual ordered matches. That preserves the CDS frame while adding N's according to the length of the missing subject sequence. I'm not sure if this is ok (😅), but at least it tells the user: "Ey, something of N length must be here according to BLAST, but it was not in the assembled sequence by IRMA" and that could be because there weren't enough reads to assemble that N region. It could also be a reason to try to use other IRMA module, or to perform some manual cleaning and filtering of sequences, and use another assembler, like SPAdes, on that problematic segment, just to resolve that N region (And I know I can solve it, because is a sample previously processed with SPAdes, I just don't want to do that because mixing assemblers would interfere with automation and the generation of some numeric reports).

I'm aware that all of this dependents absolutely on the final number of reads used for the assembly process of each segment, and if the sample was bad for any reason from the beginning then there is little to do, but I would be delighted to read your opinions on this matter.

[sammysheep]

Yes, there are things I would change, and likely will change, but in time.

The behavior is intended. IRMA will edit reference for deletions or unmapped regions. This is by design. However, I would be open to figuring out other behaviors for "unmapped" regions. It gets tricky because the history of what is mapped is lost over time.

IRMA can also do N-padding, but not safely for Flu (only SC2, because the algorithm as currently written, and to be re-written, is a bit too bespoke).

For flu, we usually have a curation step running after IRMA. I think my colleagues working on MIRA (which uses IRMA) also perform some curation in their GUI process.

Surveillance samples that have poor quality are filtered out or re-sequenced rather than N-padded, and this works well because flu is segmented and small and you can still get value out of the remaining segments for certain projects. For a research project, that may be less satisfactory. However, for submission to a database, uploading a segment with a long stretch of N's has limited utility for flu (my opinion, all rights reserved).