Summary of miscodes

Updated Tuesday, 29 May 2018, Wednesday, 9 January 2019, 24 June 2019, 14 October 2019, 23 June 2020, 15 September 2020, 28 December 2020, 29 November 2023, 13 May 2024

During the lifetime of the STRmix™ project we have detected fifteen coding faults that act on the reported LR.  Please see below for a summary. Where necessary, more detailed explanations and the results of investigation for miscodes are provided as separate documents.

1. Present in versions up to (but not including) V1.08. It affected the LR in an exceptionally minor way and produced neither false inclusions nor exclusions. It was detected by a third party laboratory repeating calculations by hand. It did not result in the need to reissue any statements. Statement-on-minor-miscoding-in-BN-formulae-STRmix-V1-08-with-additional-comments.pdf [PDF, 275 KB]

2. Present in STRmix™ versions up to (but not including) version 2.0.6. This was discovered after a case was brought to Forensic Science South Australia’s attention in December 2014 by Queensland Health. This miscode was reported, with errors in the reporting, in the press.^[1](external link) The miscode affects the numerical value of the LR in rare instances and does not change an inclusion into an exclusion. All potentially affected cases in Australia and New Zealand were examined and very few instances of a different LR occurred outside Queensland. There are no known false inclusions as a result of the miscode. To get an effect from this miscode a specific set of circumstances is needed which we believed quite unlikely to occur and which had not been specifically tested in developmental validation prior to this date. Statement-relating-to-STRmix-miscodes-180316.pdf [PDF, 216 KB]

3. Involved rare cases with multiple dropped alleles across all contributors within the one locus. This was found to be due to a change in STRmix™ that was introduced in the V2.3 series and has been present in all versions subsequent to this up to V2.3.09 and V2.4.04 (inclusive). The effect on likelihood ratios (LRs) is in a conservative direction and very minor. Variation-in-STRmix-regarding-expected-heights-of-dropped-out-peaks-040716-ws.docx.pdf [PDF, 589 KB]

4. Present in V1.0 to V2.4.05 for drop-in modelling and V2.4 to V2.4.05 for forward stutter modelling. This affects only the database search LR (assuming the presence of forward stutter peaks and/or multiple drop-in alleles, and modelling of these artifacts was enabled) and to the Highest Posterior Density (HPD) calculations. There was no detectable effect on the LR in a number of trials. STRmix-v2-4-06-Description-of-changes-ws.docx.pdf [PDF, 846 KB]

5. Present in all versions preceding V2.4.08 – three miscodes described below. Description-of-the-LR-changes-in-STRmix-v2-4-08-ws.pdf [PDF, 600 KB]

5.1. A change has been made to LR calculation (unrelated point estimate, stratified, unified and HPD) for mixed DNA profiles when there are multiple contributors considered under Hp who are unknown under Hd. The contributors must have dropped alleles (either the same or different) at the same locus. Changes were usually less than a factor of 10.

5.2. A change has been made to the way drop-in alleles are assigned within the determination of the genotype array within pre burn-in. This will affect all LR calculations including within the database search (standard and familial LRs), unrelated and related scenarios. Changes in the LR were usually less than one order of magnitude.

5.3. A minor anomaly in the familial search LR was identified. The issue affected mixed and single source profiles with dropout where on some occasions an incorrect allele frequency was assigned to the alleles. The comparison of LRs between versions indicates that this was mostly within one order of magnitude.

6. A change was made to the way the seed was calculated affecting all versions preceding V2.3.07. In previous versions the seed was randomised on startup by multiplying the day by hour by minute by second. Between 0000hrs and 0100hrs the seed did not reset and the same seed was used for all calculations. This only affected multiple interpretations that were started within this hour. The seed is used within the random number generator within STRmix™.

7. Present in STRmix™ versions 2.0 through 2.6 inclusive. If the STRmix™ input file has duplicated homozygous alleles, (i.e any locus where a single peak has been detected has the resulting peak data duplicated) this can affect drop-in modelling and the LR calculation within STRmix™ under a very specific set of circumstances. If the height of a duplicated peak is below the STRmix™ drop-in cap, then the peak may be considered as drop-in during deconvolution. When this occurs STRmix™ must consider both instances of the peak in the input file as drop-in. This results in an additional drop-in penalty being applied and will impact the genotype weights assigned by STRmix™. Furthermore, if genotype sets including drop-in are accepted during deconvolution, additional term/s for the allele frequency of the drop-in peak will be included in the LR calculation. Use-of-duplicate-homozygous-alleles-in-STRmix2.pdf [PDF, 829 KB]

8. Present in STRmix™ versions 2.6.0 and 2.6.1. When assigning an LR, if a POI sits in a dropout position their alleles are written into a modified genotype array with corresponding weights. In v2.6.0 and v2.6.1, these weights were not being normalised before an LR is assigned. Details of the effect of this change can be found at: Change-to-normalisation-of-weights-before-an-LR-is-assigned-in-STRmix.pdf [PDF, 1.2 MB]

9. Present in STRmix™ versions 2.6.0, 2.6.1 and 2.6.2. An intermittent issue due to unsynchronised number parsing was identified in 2.6 versions whereby settings could change unexpectedly under some conditions (affected by multi-threading, the speed of the threads on the computer and various other factors including solid state drive vs spinning disk). In some cases the population fields were getting incorrectly parsed and throwing up an inconsistency error, and in the worst case result the theta changed in the default population. The value used in the calculation was printed to the report and therefore available on review.

10. Present in only STRmix™ V2.3.07.  Within V2.3.07, template values were ordered per contributor in order to help improve precision.  Per contributor degradation values were not ordered at that time.  The effect was that for some profiles with similar template but different degradation values, multiple genotype combinations were accepted with near equal mixture proportions for loci that should otherwise have been resolvable (or nearly so).  Details of the effect can be found here [PDF, 625 KB].

11.  Present in STRmix™ V2.0 and all versions from V2.4 through to V2.7.0. There are limitations on the length of a number that computer software programs can store.  A rare issue can occur in these versions where this number can be exceeded. This was corrected in STRmix™ V2.3 series, but reverted inadvertently in subsequent versions as part of coding efficiency improvements.  This issue occurs when:

• The total number of iterations per chain exceeds 2,147,483,647 (~2.15 billion / ~2.15x10⁹)

and/or

• The total number of iterations for a given genotype combination exceeds this number when summed across all chains.

These are rare events and the vast majority of these incidents will result in an error message and a failed deconvolution. For the small sub-set of instances where a deconvolution runs to completion this can result in incorrect weights being applied to genotype combinations and ultimately lead to an incorrect LR. However, a review of the diagnostics should highlight to an analyst that a problem had occurred. The review of each deconvolution and the associated diagnostics has always been part of the process for utilising STRmix™. The LR calculated from one of these affected deconvolutions would typically be lower than that calculated from an unaffected run. As a consequence, it is possible an exclusionary LR (LR<1) could have been generated for a true donor.

12.  Present in STRmix™ V2.6.0 to V2.6.3, V2.7.0 and V2.8.0.  This issue only affects the Variable Number of Contributors (varNOC) function.  When varNOC was first implemented in STRmix™ V2.6.0, the size of the hyper-rectangle was set as a fraction (M%) of the total iterations. The algorithm used to set the size of the hyper-rectangle mis-tallied the number of iterations within this volume resulting in the volume and hence M being only approximate. It therefore contains only approximately M% of the total iterations. The effect on the varNOC LR is marginal and is less than the effect of run to run variation. Details of the effect can be found here [PDF, 2.1 MB]

13. Present in STRmix™ v2.10 only, this issue only affects the LR results when using artefact probabilities and an ‘all in one’ deconvolution plus LR. The use of a kit file with artefact probabilities enabled, in conjunction with an evidence input that contains artefact probabilities (exported from FaSTR™ DNA), can result in a point estimate LR that differs when the LR is generated from an ‘all in one’ deconvolution plus LR rather than an LR from Previous on the same deconvolution. This is limited to interpretations where dropout is present in the accepted genotypes. This issue can be mitigated by only using the LR from Previous or Database Search functions (which correctly utilise the artefact probabilities) when using artefact probabilities.

[1] http://www.couriermail.com.au/news/queensland/queensland-authorities-confirm-miscode-affects-dna-evidence-in-criminal-cases/news-story/833c580d3f1c59039efd1a2ef55af92b (external link)(external link)