Skip to main content

SageMath, Where Objects Rock and Scripts Don't

I moved the Sage simulation of the can crusher to an object oriented implementation today.  A few days ago,I was worried this might have been a bit of overkill and just a subconcious desire on my part to place the project in a code format I'm used to seeing things in.  I hit an example yesterday that convinced me otherwiser, and only a few short, OK,  and somewhat grueling, hours later, I had a much easier to use OO simulator.

Prior to yesterday, my usage mode of the can crusher code was as follows:
1.  Evaluate the cell that contained the initializaiton code.  There were some declarations of global varaibles and a little bit of code that atually ran on evaluation to place values in these variables.
2.  Evaluate the cells that contained the current calculating function and the can moving function separately.
3.  Evaluate the cell that contained the simulation code.

This, as far as I knew had to be done every time I wanted to change any values and run a simulation.  I was constantly worried that I might not evaluate the cells in the correct order or that a rogue global variable might escape initialization.

The clincher came when I wondered if there was a difference between the simulated current through the driving coil when the can was allowed to crush and when it was not.  In order to do this, I had to execute the above procedure, then, copy the results of the global current array into a placeholder array, then modify the simulation code, then run the above procedure again, and finally graph the new global current array and the placeholder array on the same plot to get the following result


Contemplating the stress of wondering what I had called my placeholder variables and whether or not I'd run through the initialization procedure correctly every time led to this morning's object oriented re-write.  What I wound up with was a simulator object that encapsulates all the initialization procedures and its own set of member variables that correspond to the previous set of globally available variables  Now, to create a comparison like the one shown above, I can just create two simulations, passing both of them the same limit for the number of simulation steps to run, but tell one of them to turn the can moving portion of the code off, like so, (my simulator class is named Crusher):

nm_crushtest = Crusher()
nm_crushtest.set_movecan(False)
nm_crushtest.simulate(372)

crushtest = Crusher()
crushtest.simulate(372)

After the simulations have run, the graph is easy to generate:

nomove = list_plot(nm_crushtest.coilOutTime[0:372, 0:2], color='red')
move = list_plot(crushtest.coilOutTime[0:372, 0:2], color='blue')
show(nomove + move)


The Grueling Bit
If you're coming from a C++ background, the only part that will drive you nuts is having to put 'self.' in front of every member variable every time it is used in the class definition.  I still think I must have been doing this wrong and hope that I kind Python expert will correct my gruesomely bad coding style soon.

References:
1.  The Python object oriented documentation
https://docs.python.org/2/tutorial/classes.html

2.  Upcoming useful docs: How to handle large +Sage Mathematical Software System programs
http://www.sagemath.org/doc/tutorial/programming.html

3.  The can crusher simulator in it's many revision controlled incarnations
https://github.com/hcarter333/cancrusher

Comments

Popular posts from this blog

More Cowbell! Record Production using Google Forms and Charts

First, the what : This article shows how to embed a new Google Form into any web page. To demonstrate ths, a chart and form that allow blog readers to control the recording levels of each instrument in Blue Oyster Cult's "(Don't Fear) The Reaper" is used. HTML code from the Google version of the form included on this page is shown and the parts that need to be modified are highlighted. Next, the why : Google recently released an e-mail form feature that allows users of Google Documents to create an e-mail a form that automatically places each user's input into an associated spreadsheet. As it turns out, with a little bit of work, the forms that are created by Google Docs can be embedded into any web page. Now, The Goods: Click on the instrument you want turned up, click the submit button and then refresh the page. Through the magic of Google Forms as soon as you click on submit and refresh this web page, the data chart will update immediately. Turn up the:

Cool Math Tricks: Deriving the Divergence, (Del or Nabla) into New (Cylindrical) Coordinate Systems

Now available as a Kindle ebook for 99 cents ! Get a spiffy ebook, and fund more physics The following is a pretty lengthy procedure, but converting the divergence, (nabla, del) operator between coordinate systems comes up pretty often. While there are tables for converting between common coordinate systems , there seem to be fewer explanations of the procedure for deriving the conversion, so here goes! What do we actually want? To convert the Cartesian nabla to the nabla for another coordinate system, say… cylindrical coordinates. What we’ll need: 1. The Cartesian Nabla: 2. A set of equations relating the Cartesian coordinates to cylindrical coordinates: 3. A set of equations relating the Cartesian basis vectors to the basis vectors of the new coordinate system: How to do it: Use the chain rule for differentiation to convert the derivatives with respect to the Cartesian variables to derivatives with respect to the cylindrical variables. The chain

The Valentine's Day Magnetic Monopole

There's an assymetry to the form of the two Maxwell's equations shown in picture 1.  While the divergence of the electric field is proportional to the electric charge density at a given point, the divergence of the magnetic field is equal to zero.  This is typically explained in the following way.  While we know that electrons, the fundamental electric charge carriers exist, evidence seems to indicate that magnetic monopoles, the particles that would carry magnetic 'charge', either don't exist, or, the energies required to create them are so high that they are exceedingly rare.  That doesn't stop us from looking for them though! Keeping with the theme of Fairbank[1] and his academic progeny over the semester break, today's post is about the discovery of a magnetic monopole candidate event by one of the Fairbank's graduate students, Blas Cabrera[2].  Cabrera was utilizing a loop type of magnetic monopole detector.  Its operation is in concept very sim