frencil / galaxy_of_nuclides Goto Github PK

Incorporate a build system to minify all JS libraries into one JS download, and likewise with CSS.

Previous versions of this application included a "time slider" that allowed a user to change an "elapsed time" value, on a logarithmic scale, which in turn caused isotopes to fade as half lives are surpassed.

Expand the data sets to include the percentages of an element found in nature that map to a given isotope (e.g. how protium / hydrogen-1 is 99+% of all hydrogren in nature). These data would also provide a better indicator of which isotope object to show in periodic table view.

The application is only redrawn on every page load. Furthermore, the current drawing methods would lose application state and reload all data is triggered again. A proper scale/redraw method is needed to preserve state and scale the application without reloading data.

Presently the beta decay method in the nuclide class does an oversimplified form of beta-minus decay, generating only a single electron in addition to the neutron. As decay mode data is folded in (see issue #13) the data will be specific about beta-plus and beta-minus. Full modeling of these decay modes involves particle classes that include two types of neutrinos and the positron.

These particles should be easy to model in the Particle class given how it's been re-written with the introduction of the Nucleus class and the decay method expansion should also be straightforward.

Some clean tabular data like physical characteristics (melting/boiling points, natural abundances) as well as history and etymology would be pretty cool. This would be a good complement to the prose-style element caption.

Space is tight on the isotope view so maybe this should be one more click away. The element image is big piece of real estate and would make a neat background for further information at a low opacity.

With the Particle and Orbit classes it's relatively simple to build basic diagrams of atoms but the positioning of individual subatomic particles is still a tedious effort. There are tools in the d3 API for doing this much more effectively.

An attracted mass of particles is effectively a force-directed graph of objects. Many examples at that link describe different ways of using d3's force layout. This could be abstracted to a ParticleMass or Nucleus class to handle the force definitions.

Worth considering: an "eject" method on the ParticleMass/Nucleus prototype to simulate the ejection of things like alpha particles. Also Nuclei need to split... somehow. Particles themselves also need to split and/or transmute into other particles (as seen in Beta decay).

As the UI solidifies a general help / orientation modal to explain how the site is put together and how to play with it is pretty necessary. May want to consider making this load by default for new users (with a cookie?)

The IAEA Interactive Chart of Nuclides affords the user standard scroll-to-zoom/drag-to-move capabilities. The nuclides layout should do this too, probably by way of a clip path for the stage.

With the Nucleus class now in place, able to turn a nuclide into an interactive representation of an atomic nucleus with built-in decay methods, the application is ready to ingest decay mode data.

This would likely be a new CSV file since any nuclide can have arbitrarily many decay modes, each with a likelihood percentage.

With the recent addition of the Nucleus class that simplified Orbit class is now defunct. It needs to be replaced with something to better model electron orbitals that hopefully can more closely depict the actual structure of electron orbitals in the real world (moving away from the misleading planet/sun analogy).

To reproduce:

var carbon9 = new Nucleus(matter.elements[6].nuclides[3]).appendTo(d3.select("svg"));
carbon9.alphaDecay().betaDecay();

Chaining alpha and beta decays together on a Carbon-9 nucleus should result in a Lithium-5 (three protons, two neutrons) and about half the time this is what happens. However, about half the time, what remains is a nucleus with four protons and two neutrons (technically a Beryllium-5). Inspecting the elements makes it clear that the daughter neutron from the beta decay is not present and one of the neutrons is duplicated. That is, the nucleus group in the SVG has two child proton groups with the same ID.

The fact that this happens intermittently could point to a race condition. Either way it's unclear how one proton would be generated twice in the SVG and the daughter neutron not at all, despite the Nucleus.particles object/array looking correct 100% of the time.

As a stopgap, the method Nucleus.prototype.restart() currently has a line that removes all child elements from the nucleon selector before redefining the child nodes:

nucleus.nucleons_selector.selectAll("g.nucleon").remove();

This is not a clean solution. It fails to reuse SVG elements efficiently and, especially for larger nuclides, can result in a momentary but visible instance of the entire nuclide disappearing in order to be redrawn.

The nuclide hover object is the info box that appears on mouseover for any nuclide. The half-live value shown is always in terms of seconds and this is not that useful outside of a small range of magnitudes.

The Time class does have some documented approximations for orders of magnitude, but only in unit terms (e.g. 1 x 10^n). For familiar time scales within human perception this can't be used directly, so a more sophisticated logic needs to be put together.

There are three ways that atoms decay and two of them (let's ignore gamma for now) change what the atom is. Alpha decay emits an alpha particle (Helium-4 nuclide) and Beta turns a neutron into a proton (emitting an electron in the process, but let's stick with nuclear particles for now).

This is a potential rabbit hole for going the direction of more sophisticated interactive charts of nuclides (see what this project is not), so it's important to keep this simple. Additional data required shouldn't be much more than booleans for whether a nuclide alpha and/or beta decays. The rest of the work should be in the SVG chart itself showing cool animations of spidering chains.

Pick a radionuclide and set it running. Or pick several and set them all off simultaneously. Watch the chart light up like a Christmas Tree.

In galaxy_of_nuclides/assets/js/questions/what_is_a_nuclide.js there is a sentence:

The number of in an atom determines what element it is (and therefore its chemistry).

Seems like it's missing the word "protons" (or "electrons"?) between "number of" and "in an atom"

Transition speed (specifically the scalar display.transition_speed) governs how fast transitions go and defaults to 0.8, right now. A slider or input to control this would help tune in a better default and provide more variability.