Addition of alleles to schema

[arshdeep1k]

Hi, I am looking to get some clarification on allele calling method.

At the completion of alleleCall module, it produces a log message with information such as:

Assigned identifiers to 174 new alleles for 162 loci.
Getting original sequence identifiers for new alleles...
Getting data for new representative alleles...
Adding the BLASTp self-score for the new representatives to ..schema/short/self_scores
Creating FASTA files with the new alleles...
Adding new alleles to schema...
Added 174 new alleles to the schema.
Added 1 new representative alleles to the schema.

I would like to know how a schema will be updated/effected if:

• an analysis dataset is discovered to have contaminated species
• low quality genomes
• running AlleleCall on subset of the whole dataset initially used
• re-run AlleleCall of duplicate dataset.

How is the schema altered in each of these scenarios, and whether there are internal quality checks in place before a new allele is added to the schema. Is it better to create a copy of the schema to use for test runs?

If you could provide some advice/suggestions on what should be the best practice, that will be great.
Thank you.

[ramirma]

Dear @arshdeep1k ,

Thank you for your interest in chewBBACA. I will try to clarify what happens to the schema in each of the points you raise.

As an introduction let me state that chewBBACA does not have any specific "quality checks in place before a new allele is added to the schema". This means "garbage in -> garbage out". Having said this, chewBBACA will still apply its normal criteria to identify loci and alleles, which means that nothing extremely divergent will find its way into the schema, This behavior will be made clearer in the points below. As a reminder, if you run with the --no-inferred flag, no new alleles will be added to the schema, which is the safest option should you have any suspicion about the genomes under analysis, or if you simply want to try out a schema in a different but closely related species.

1. an analysis dataset is discovered to have contaminated species
   If a strain is contaminated with another species or is not of the target species, chewBBACA will, nonetheless, try to perform allele call. If this is a closely related species, a variable number of loci may have alleles which are sufficiently similar to be called and added to the schema. If the species is too distantly related, no loci should be called and no new alleles identified. Again, the best option for this case is to run with the --no-inferred flag.

2. low quality genomes
   Same as in point 1. In this case the issue will be nonexistent mutations and premature stop codons given the low quality of the sequence. Usually this is easy to identify because one of the genomes will have too many new alleles and fewer loci for which alleles were called than is usually the case.

3. running AlleleCall on subset of the whole dataset initially used
   This is similar to point 4. Whenever you run the AlleleCall process, chewBBACA uses the existing schema to perform allele call. If the schema was altered in the first run, a second run, even on the same strains, may find and call additional alleles. This is because whenever a new representative is found it may allow identifying novel divergent alleles. In very mature schemas, when thousands of strains have already contributed alleles to the schema, this is unlikely. Whereas in newer schemas that are being created this is a common observation. So the answer really depends on the "maturity" of the schema. In a "mature" schema the results should be completely reproducible, in a "newer" schema, a few novel allele calls may occur. Having said this, no change of alleles will ever occur. What may happen is that loci for which an allele was not called on the previous run, will now be called.

4. re-run AlleleCall of duplicate dataset.
   I think we have already covered this in point 3. Having a subset or the full set of isolates is the same. I would just like to reinforce that chewBBACA is completely reproducible for the allele calls, if the same schema (with the same representatives) is used. And even if a schema is allowed to "evolve", no change of alleles will ever occur. What may happen is that loci for which an allele was not called on a previous run, will now be called because the schema now allows the identification of more divergent alleles.

I hope to have clarified the issues you raised.

Mario

[arshdeep1k]

Dear @ramirma,

Thank you for addressing my queries in detail and providing clarifications. It was really helpful.

Given that any subsequent analyses can produce additional allele calls for genomes in my dataset if any new representative alleles were added to the schema in previous analyses; In the scenario of running cgMLST analysis routinely for public health surveillance purposes, is it recommended to re-run allele calls on the whole dataset everytime new genomes are added to our dataset?

I am aware there is an option to run alleleCall only on the new genomes and then run the Join Profiles function, but then that means alleleCalls for previously analysed genomes will not be screened against the new alleles added to the schema. Please clarify if I am understanding this correctly?

Thanks again,

Arsh

[ramirma]

Dear @arshdeep1k ,

The question you ask does not have a straightforward answer. Let me break this down.

1. Goal is reproducibility and stability. Run with the --no-inferred flag. This will make sure that the schema is not altered each time you run a batch of strains. Of course the correspondence between any novel alleles will have to be confirmed afterwards separately. This approach will make sure that the schema is "fixed" and every call will be completely reproducible. The disadvantage is that you are not making the most of the genomic information since divergent alleles may not be called and new alleles cannot be compared directly and will have to be analyzed separately if you want to include them in the analysis.

2. Goal is maximum information. Since novel alleles will be added to the schema with time this will make it possible for chewBBACA to recognize more divergent alleles. So the ideal situation would be to once you have a dataset of interest, to run chewBBACA again with the most complete allele collection. As I pointed out above, in a "mature" schema" the differences should be minimal, but may provide a little additional information. The Join Profiles function is not a substitute for this, since the allele calls will still have the timeline bias we discussed. This function is simply meant to facilitate joining the profiles into a single file for downstream analysis. So indeed you were understanding correctly.

So really the path you choose is dependent on your goals, number of isolates you receive and workflow.

I hope to have clarified the issues you raised.

Mario

[arshdeep1k]

Dear @ramirma ,

Thank you for the detailed explanations, this goal oriented approach is insightful in helping me make a decision for the analysis.

Arsh