Macro view

[ariel-phet]

After discussion it was decided that we should have a macro view included in the sim, details are in the the design doc.

This work will be done after @schmitzware performs the port of the current sim, and likely by another developer. Opening this issue to document the enhancement.

[pixelzoom]

This feature is described as the "atom scene" in this section of the design document: https://docs.google.com/document/d/1MUdOXlibhm6e_B2wUTAkvoYqN49ayHGG-tcCNGDeqaw/edit#heading=h.wfmgt7c78o7o

Here's a screenshot, but consult the design document for most recent:

[pixelzoom]

3/10/2016 status meeting: @jessegreenberg will be adding this feature. Talk to me before proceeding.

[pixelzoom]

Some thoughts on implementation....

Model:

It has been previously suggested to have a totally different model for the 'Atom' scene. I think that's undesirable and unnecessary. Better to use the same model in both scenes. So I would look at generalizing RSBaseModel and RutherfordAtomModel to handle multiple nuclei, with the 'Atom' scene being the general case (N nuclei) and the 'Nucleus' scene being the case where N=1.

View:

rutherford-scattering-strings_en.json: Add 'Nucleus' string. There's already an 'Atom' string, used to label a control panel. Decide whether a second 'Atom' string is necessary.

RSBaseView, change vars to protected fields for layout:

// @protected for layout by subtype
this.targetMaterialNode = ...

// @protected for layout by subtype
this.spaceNode = ....  

RutherfordAtomScreenView, add scene control:

var atomString = require( 'string!RUTHERFORD_SCATTERING/atom’ );
var nucleuString = require( 'string!RUTHERFORD_SCATTERING/nucleus’ );

var sceneProperty = new Property( ‘nucleus’ ); // which scene to display, 'nucleus’|’atom'

var sceneRadioButtonGroup = new RadioButtonGroup( sceneProperty, [
  { value: ‘nucleus’, node: new Text( nucleusString, … ) },
  { value: ‘atom’, node: new Text( atomString, … ) },
], {
  orientation: ‘vertical’,
  spacing: 20,
  left: this.targetMaterialNode.left,
  top: this.spaceNode.top,
  maxWidth: …
} );

sceneProperty.link( function( scene ) {
   ... make the proper 'space' visible
} );

Change RutherfordAtomScreenView.createSpaceNode to something like this, "space" nodes for the 2 different scenes, with a Node wrapper:

var createSpaceNode = function( model, showAlphaTraceProperty, modelViewTransform, canvasBounds ) {
    return new Node( {
      children: [
        new NucleusSpaceNode( model, showAlphaTraceProperty, modelViewTransform, {
      canvasBounds: canvasBounds
          } ),
       new AtomSpaceNode( model, showAlphaTraceProperty, modelViewTransform, {
      canvasBounds: canvasBounds
          } ),
  };

... where NucleusSpaceNode was formerly RutherfordAtomSpaceNode, and AtomSpaceNode is a new Node that implements the new view.

[jessegreenberg]

Whether or not we generalize RSBaseModel and RutherfordScatteringModel to handle multiple atoms, I am not sure how to apply the trajectory model to this scene. See https://github.com/phetsims/rutherford-scattering/blob/master/doc/trajectories.pdf.

It looks like that algorithm uses a particle in a box approximation and makes assumptions about the atoms being in the center of the box. So we will need to

a) Change the trajectory algorithm to handle an atom at any position. This could mean recalculating some constants and initial conditions, but I am not sure what kind of approximations and assumptions are being used in the above pdf.

b) A new model where each atom has its own coordinate frame and is at the center of its own box for the trajectory computations.

c) A new model for this scene which is not physical, and merely creates the behavior desired in the design document.

[ariel-phet]

@jessegreenberg would it be crazy to just treat each atom as its own "box" so that you basically have 5 boxes, and each time a particle crosses into a box, you only worry about the nucleus being in the center of that box? It seems then there just needs to be some scale factor, the deflections and such would always be at the same angles?

[schmitzware]

Interesting idea, Ariel. Jesse could just pass off a particle (w/ it's current vector) to an individual display (aka 'box) and let that sim step the models of it's own particles. This is actually how some large multi-machine, large format displays (i.e. multiple monitors) work.

One question for you physicists - in the model, is the effect of each nucleuses small enough that it really doesn't effect particles in other boxes?

[ariel-phet]

@schmitzware yes the nucleus is definitely small enough. The average nucleus is around 10^-15 m in diameter, the average atomic radius is 10^-10 m. So a factor of 100,000 times smaller than the actual atom. (the analogy often used is that if you place a baseball at second base in an MLB baseball stadium, the size differential between the ball and the stadium is about the same as the nucleus and the atom). In fact this is what Rutherford saw...most particles just passed straight through but a very occasional one would bounce almost straight back..the atoms were almost entirely empty space except for points that appeared to be very small dense spheres.

[jessegreenberg]

Yes, I really like the idea of treating each atom as its own box! I think that will be a good way to generalize the model to N atoms too. It will be more involved than just a scaling factor, because now we need to handle the cases where particles can enter a box from any direction. Even if we do not handle multiple deflections, the trajectory is dependent on the initial conditions of the particle, and starting from a position different from the bottom of the box will mess up the algorithm.

So I am thinking there are two cases:

• The particle moves up through the space, un-deflected, and reaches the edge of a new atom's bounding box. In this case, the particle then enters the new atom's bounding box and travels through it until it reaches the next bounding box or gets close enough to an atom to cause a deflection.
• The particle is deflected by an atom. In this case, the deflection trajectory will carry it through the entire global space until it reaches the edge of the space window. This way, the trajectory algorithm can be carried out through the lifetime of the particle.

For both of these cases, the particle is tracked in the coordinates of the entire window space, but the trajectory algorithm calculates changes to position in the coordinates of the atom's bounding box. Again, this is to make sure the trajectory algorithm can continue for a deflection even when the particle has left the bounding box.

This does not handle multiple deflections, but I think it will be sufficient to handle everything for the Atom scene with any number of atoms.

[jessegreenberg]

Additional design decisions, discussed with @amyh-phet:

• The beam is intentionally wider for the Atom scene.
• The user should be able to turn of trajectories of particles in the 'Atom' Scene
• Trajectories in the 'Atom' scene can disappear as soon as the particle reaches the bounds of the model.
• Electron energy level circles scaled by the Bohr radii do not need to change with the number of protons.

[jessegreenberg]

Commit above is an initial commit which implements model changes. It is working well and the Atom scene behaves correctly. Up next:

• [x] Atom subtypes (specifically moveParticle) function should be refactored into Atom.js.
• [x] Check for additional places to refactor new code
• [x] Implement new view representations for the atoms and particles of the 'Atom' scene.
• [x] Additional changes to the view for atom scene (legend, scale description, beam width, etc...)

[jessegreenberg]

It also appears that the top right and bottom center atoms are not causing any scattering. Will look into that as well.

[jessegreenberg]

Commit above draws the radii scaled by Bohr Energies.

[jessegreenberg]

Commit above implements the new 'particle' representation with magenta circles and traces.

[jessegreenberg]

The model for the atom scene is incorrect and needs to be fixed. At the moment, the bounding box for the trajectory approximation is the bounds containing all Bohr Radii for the atom. This is too large for the model since a particle only scatters when much closer to the nucleus. The bounding box needs to be only slightly larger than the nucleus.

So the model should change to something like this:

• Atom scene contains N atoms, with bounds that are slightly larger than the bounds of the nucleus node.
• Node containing the rest of the space, in which a particle will travel straight through without any scattering.
• Particles will travel through space until they reach a bounding box around an atom's nucleus. Particles will enter the box through the bottom and the same trajectory algorithm can be applied. Like in https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-219877790, once the particle is scattered, the atom that caused the scatter will handle the trajectory for the remainder of the particle's lifetime.

This will not handle a particles that get scattered twice.

[jessegreenberg]

Above commit does this and fixes https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-221030123

[jessegreenberg]

Particles are removed from the scene before the trajectory algorithm fails. The algorithm never fails for the 'Nucleus' scene, but frequently fails for the 'Atom' scene. We should find out why.

I don't think it is because the particles are too close to the center of a nucleus, sometimes particles are removed from the space when they are far to the left or right of the center of the nucleus.

[jessegreenberg]

After about five minutes of running the 'Atom' scene, 16 particles were removed from the space, and all were due to this catch

      // check intermediate values to handle potential algorithm failures
      var i4 = ( ( b * Math.sin( phiNew ) ) + ( ( D / 2 ) * ( Math.cos( phiNew ) - 1 ) ) );
      if ( i4 < 0 ) {
        this.removeParticle( alphaParticle );
        return;
      }

There are 8 places where the algorithm looks for a failure like this and this is the only one that is happening with noticeable frequency.

[jessegreenberg]

It looks like the atoms are also 'bouncing' when they hit the boundary of the atom's box. This is only noticeable when the particles have low energy and there are lots of protons in the nucleus.

[jessegreenberg]

This might be due to incorrect initial conditions in the trajectory algorithm. The initial conditions are at the entry point of the particle in the space, while they should be the entry point of the particle in the particular atom's bounds.

[jessegreenberg]

Commit above fixes the issue https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-226244307 was correct. This seems to improve the behavior of particle trajectories for the atom screen, maybe https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-226026502 will be fixed for free?

[jessegreenberg]

Not fixed, but improved. 3 particles were removed from the space in 5 minutes, down from 16 particles in five minutes in https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-226028415.

[jessegreenberg]

Increasing the size of the atomic bounds seems to make the algorithm less fragile too, after the commit above, 0 particles were removed from the space in 8 minutes. I am considering that sufficient and will wait to investigate unless it is observed in dev testing or review.

The legend panel is the last thing to do!

[jessegreenberg]

I believe that everything is complete for the 'Atom' scene. A task has been opened for dev testing. @amyh-phet would you please also review the dev version to verify that the new 'Atom' scene features are to spec?

Dev version: http://www.colorado.edu/physics/phet/dev/html/rutherford-scattering/1.0.0-dev.3/rutherford-scattering_en.html

Pinging @ariel-phet in case he would like to take a look as well.

[ariel-phet]

Visually everything looks great. Seems like we need to investigate multiple scattering (or avoiding it).

Remember the learning goal is certainly "the atom is mostly empty space" so hollywooding this would be fine if we just made sure multiple scattering does not occur, but feel free to investigate.

[jessegreenberg]

The trajectory algorithm makes the following assumptions:

     * (1) The atom is located at (0,0).
     * This is not the case in our model. So coordindates are adjusted 
     * as described in the comments.
     * (2) +y is up.
     * Our model has +y down. So we'll be adjusting the sign on y 
     * coordinates, as described in the comments.
     * (3) alpha particles are moving from bottom to top
     * (4) x values are positive.
     * The algoritm fails for negative values of x. This is not
     * mentioned in the specification document. So we have to convert
     * to positive values of x, then convert back.
     * (5) Using "phi=arctan(-x,y)" as described in the spec causes
     * particles to jump discontinuously when they go above the y axis.
     * This is fixed by using Math.atan2 instead.
     * (6) Depending on the parameters supplied, the algorithm will tend
     * to fail as the alpha particle's horizontal position (x) gets closer
     * to zero. So the Gun model is calibrated to fire alpha particles 
     * with some min initial x value.

We really just have to get around assumption 3. To implement multiple nuclei we are already adjusting the new position of the particle relative to the frame of the nucleus, see https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-219877790. Perhaps we can do a similar correction for the particle moving into the bounding box from a different orientation. Or maybe we can investigate a new solution with additional relative transformations.

[jessegreenberg]

I will take a look at https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-226551995. If it seems to be something that will take a lot of time, it is likely we can 'hollywood' the particles to enter the space at a position which will not create multiple deflections as mentioned in https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-226543631. The trajectories in general would be a lot less dynamic in this case.

[jessegreenberg]

Multiple deflections seem very possible with the current trajectory algorithm since we can use the symmetry of the bounding box and assume that the nucleus as in the center. If the particle enters the box from the top, we can rotate its position 180 degrees relative to the position of the nucleus. The algorithm calculates a change in the position from the particle. That delta vector can then be rotated back 180 degrees and added to the position of the incoming particle. If comming in from the side, the delta would just be rotated +/- 90 degrees depending on if it is from the right/left.

[jessegreenberg]

Yes, https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-226576125 should work really well, and at this point supports particles coming in from the top of the bounding box.

[jessegreenberg]

The next big step is to handle particles coming in with non zero x velocity.

[jessegreenberg]

https://github.com/phetsims/rutherford-scattering/issues/20#issuecomment-226576125 was not sufficient for handling particles entering the bounding box with an orientation that isn't orthogonal to the bottom edge of the box. Instead, we need to rotate the coordinate frame of the bounding box to capture initial conditions correctly. When the particle enters the rotated box, the atom can begin the trajectory algorithm, and the particle can pass from one atom to another. Image below illustrates this and shows an example.

When a particle enters the circle containing the bounds, a new set of rotated bounds are prepared so that the bottom edge of the box is perpendicular to the direction of the particle travel. This way the trajectory algorithm is the same and can assume the particle is moving from bottom to top in the coordinate frame of the rotated box.

[jessegreenberg]

More general approach of rotating coordinate frame of bounding box works for particles entering from the top as well:

Next I will need to investigate a couple new bugs introduced with the new approach. Particles can occasionally get stuck inside the bounding box. The trace following the particle seems to grow much longer as well.

[jessegreenberg]

Multiple deflections supported in commit above.

[jessegreenberg]

Macro view complete! Closing.