Open pixelzoom opened 1 year ago
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:
'2B-': 75
and '2B-': 69
.'2B-': 100
and '2B-': null
.'2B-': 100
and '2B-': 100
.'14C': 0.000000089
and '14C': 0.000000077
.Possible solutions:
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.getAvailableDecaysAndPercents
, we could change the object to a different data storage way that would allow duplicate keys.We are not covering this for BAN 1.1 release, deferred.
In AtomIdentifier.ts, there are a number of TODOs that look like this:
It looks like these TODOs were added by @Luisav1 on 3/22/22, and the commit message indicates that it's related to https://github.com/phetsims/build-a-nucleus/issues/8. Can you please add some information here about what the problem is, where you encountered it, etc?