AtomIdentifier: how to handle two of the same decay?

[pixelzoom]

In AtomIdentifier.ts, there are a number of TODOs that look like this:

    28: {
      '2B-': 75,
      // '2B-': 69, // TODO: how to handle two of the same decay? https://github.com/phetsims/tasks/issues/1129
      'B-': 25
    },

It looks like these TODOs were added by @Luisav1 on 3/22/22, and the commit message indicates that it's related to phetsims/build-a-nucleus#8. Can you please add some information here about what the problem is, where you encountered it, etc?

[Luisav1]

All unstable nuclides and their decays are stored in the object DECAYS_INFO_TABLE. Both the decay type (ex. B-, 2B-, etc.) and the percentage likelihood that a nuclide will undergo that specific decay is stored in this table.

However, the issue is that for some nuclides there are two entries for the same decay, with (usually) different percentages, which results in DECAYS_INFO_TABLE having multiple properties with the same name. This is not allowed since DECAYS_INFO_TABLE is an object literal so there should be no duplicate keys.

The problematic nuclides and their duplicated decays are:

• Ca-48 (20p 28n) with '2B-': 75 and '2B-': 69.
• Zn-70 (30p 40n) with '2B-': 100 and '2B-': null.
• Mo-100 (42p 58n) with '2B-': 100 and '2B-': 100.
• Ra-223 (88p 135n) with '14C': 0.000000089 and '14C': 0.000000077.

Possible solutions:

• Previously, the possibility of representing all decays (in a third screen) was an option. However, since we're only showing basic decays (B+, B-, P, N, and A), this data is only used to see if any of its decays are one of the basic decays, which none of the duplicates are. Thus, the duplicates could simply be deleted however, this would be inaccurate should the BAN simulation represent more decay types in the future.
• Since the object is only used in getAvailableDecaysAndPercents, we could change the object to a different data storage way that would allow duplicate keys.

[zepumph]

We are not covering this for BAN 1.1 release, deferred.