Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AtomIdentifier: how to handle two of the same decay? #42

Open
pixelzoom opened this issue Sep 14, 2023 · 2 comments
Open

AtomIdentifier: how to handle two of the same decay? #42

pixelzoom opened this issue Sep 14, 2023 · 2 comments

Comments

@pixelzoom
Copy link
Contributor

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?

pixelzoom added a commit that referenced this issue Sep 14, 2023
@Luisav1
Copy link
Collaborator

Luisav1 commented Oct 3, 2023

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
Copy link
Member

zepumph commented Oct 17, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants