Simulating Newton’s Law of Universal Law of Gravity

Interactive simulations (like those created by the University of Colorado – PhET) can be really nice for impressing students, and giving them a way to explore the dynamics of a simulation. If incorporated into a lesson well, they can add to the active learning process. The question that I always struggle with though is “are the students learning how the simulation works, or are they learning how nature works?”

I have a nagging feeling that the students would possibly get more out of being able to see the simulation source code, specifically the rules of behavior of the simulation, and then through “tweaking” the code, see how those rules govern behavior. I would like to develop curriculum that would allow my students more opportunities to explore the code “behind” the simulations. This presents a few challenges that have been identified by other great physics educators, and if you are thinking about doing the same thing – I would suggest reviewing their insights. I include a quote from Ruth Chabay’s brief, but very interesting article on this topic:

To integrate computation, especially programming, into an introductory course, it is necessary to minimize the amount of non-physics related material that must be taught. To do so it is necessary to teach a minimal subset of programming constructs; employ an environment and language that are easy to learn and use; ensure that program constructs match key physics constructs; provide a structured set of scaffolded activities that introduce students to programming in the con- text of solving physics problems

Which Code?

A popular programming language in the Physics Modeling community is VPython. I have chosen to use a different language to use called Processing. There are reasons I chose this language, but I am sure there are reasons one would choose VPython (or other languages). At this point, I have not had the opportunity to work with VPython, so this post will not attempt to compare Processing to other languages. Perhaps I will do so in the future…

Here are some general reasons why I like Processing:

1. It’s free and open source.
2. Because its built on a visual programming interface, its really easy for the students to create visual content on the screen, and it is very easy to create visual animations due to the embedded “draw” loop.
3. The official website has great examples and tutorials. It is full of great code samples and quick tutorials. You can loose yourself for hours (or days!) just having fun exploring the examples and tutorials.
4. The IDE is simple and very similar to the Arduino IDE, so if you plan on doing any Arduino programming, the similarity is nice for the students.
5. There is a nice vector library for doing vector operations (.add, .mult, .norm, .dot, etc.)
6. Its object oriented so that you can have the added benefit of teaching important programming concepts – though this might be why some people might not like it.

The Simulation

The simulation that the students were introduced to was a simulation that modeled Newton’s Law of Universal Gravitation. The students were given some instructions on the basic structure of the program, and I made sure that there was some guiding comments embedded in the code. This program was inspired/adapted from a similar program created by Daniel Shiffman who has also written an amazing book on simulating nature through code called Nature of Code.

The program defines two classes. First, there is the parent class called Particle. This class defines some basic attributes like location, velocity and acceleration as well as mass. It also has some basic functions that allow it to move and allow it to respond to a force. The second class is the child class called Planet. It can do everything that a Particle can (because it inherits from the Particle class), but it can also exert an attractive force on other Planets.  Here is the code below:

/* A parent class for all moving particles
class Particle {
  PVector location;
  PVector velocity;
  PVector acceleration;
  float mass;

  Particle(float x, float y, float m) {
    mass = m;
    location = new PVector(x, y);
    velocity = new PVector(0, 0);
    acceleration = new PVector(0, 0);
  }
  
  void applyForce(PVector force) {
    // Newton’s second law at its simplest.
    PVector f = PVector.div(force,mass);
    acceleration.add(f);
  }

  void move() {
    velocity.add(acceleration);
    location.add(velocity);
    acceleration.mult(0);
  }
}

/** 
 This class defines an object that behaves like a planet.
 Planet objects extend Mover objects, so they can move. They
 also can attract other planet objects.
 **/
   
class Planet extends Particle {

  float size;
  float G = 1;

  // To create a planet, you need to supply coordinates, mass, and size
  Planet(float x, float y, float m, float s) {
    super(x, y, m);
    size = s;
  }

  // This function allows a planet to exert an attractive force on another planet.
  PVector attract(Planet p) {

    // We first have to figure out the direction of the force
    // This creates a unit vector for the direction
    PVector force = PVector.sub(this.location, p.location);
    float distance = force.mag();
    distance = constrain(distance,size + p.size,500);
    force.normalize();

    // This is where we use Newton's Law of Universal Gravitation!
    // The stength of the attraction force is proportional to the
    // product of the mass of this planet and the mass of the other planet
    // as well as the value of G. It is also inverseley proportional to
    // the distance squared.
    float strength = (G * mass * p.mass) / (distance * distance);
    
    // To get the final force vector, we need to 
    // multiply the unit vector by the scalar strength
    force.mult(strength);

    // Return the force so that it can be applied!
    return force;
  }
  
  // Just displays the planet as a circle (ellipse)
  void display() {
    stroke(255);
    fill(255, 100);
    ellipse(location.x, location.y, size/2, size/2);
  }
  
}


/** 
  This program simulates the gravitational interaction between planet objects
  **/
  
Planet planet1;
Planet planet2;

void setup() {
  background(0);
  size(800,800);
  // Inputs for each planet:
  // (x, y, mass, radius)
  planet1 = new Planet(width/2,height/4,6000,60);
  planet2 = new Planet(width/2,height/1.25,6000,60);
  
  // This is where you can change the initial velocities of the planets.
  planet1.velocity.x = 0;
  planet1.velocity.y = 0;
  planet2.velocity.x = 0;
  planet2.velocity.y = 0;
}

void draw() {
  background(0);
  
  // f1 is a force vector that is created by calling the planet's attract function
  PVector f1 = planet1.attract(planet2); 
  // Now apply that force on the other planet.
  planet2.applyForce(f1);
  // Now deal with the opposite force pair
  PVector f2 = PVector.mult(f1, -1);
  planet1.applyForce(f2);
  
  // Allow the planets to now move.
  planet1.move();
  planet2.move();
  
  // Display the planets
  planet1.display();
  planet2.display();
}

Experimenting With The Code

The students could change the initial values of the planets, such as the starting positions, the masses and radii by changing the input values of these two lines of code:

planet1 = new Planet(width/2,height/4,6000,60);
planet2 = new Planet(width/2,height/1.25,6000,60);

The planets initial velocities could also be modified by changing the values assigned in these four lines of code:

planet1.velocity.x = 0;
planet1.velocity.y = 0;
planet2.velocity.x = 0;
planet2.velocity.y = 0;

The code that actually guides the strength of the gravitational attraction between the two planets is actually very simple. This is the magnitude of the force as defined by Newton’s Law of Universal Gravity in code:

float strength = (G * mass * p.mass) / (distance * distance);

There is some slightly complicated code that controls the direction of the force and how that force is then applied to the planet object’s state of motion, but I didn’t have the time to explain this, which was a bit disappointing (see below).

For The Future

I am currently really interested in incorporating programming into the academy program, but have found myself a bit intimidated by the challenges identified by Ruth Chabay. The most significant challenge is time:

In an already full introductory physics curriculum, there is little or no time to teach major programming skills. Students who are new to programming are also new to the process of debugging; teaching debugging strategies requires even more time…Working on programming activities only once a week in a lab or recitation section may not be adequate to keep knowledge of syntax and program structure fresh in the students’ minds.

I plan on taking some time this summer to see how I could integrate computer programming more significantly into the curriculum without causing the learning of Physics to suffer – that would of course defeat the purpose!