Spring Block
Apr. 22nd, 2017
Today we worked in VirtualBox to create our own computers and used Linux as our operating system. We started off by changing a lot of different parts of the computer, like the hard drive, operating system, and memory. It was especially interesting to work with this after learning about parallel computing and how changing different aspects of it can affect the speed, rate, and time it takes to get tasks done. We ran a couple of different programs, changing certain aspects to them in the code and seeing how the programs changed in turn. We also all hooked our computers up together and ran it on different computers with the ones nearby us. We additionally created graphs with the information we had gathered through running the programs and analyzed them.
Apr. 8th, 2017
We started by reviewing the basics of what we had gone over in the notebook last week. Then, we went on to the next activity. We searched for careers that use high performance computing to learn about how what we’re learning in class could be applied in real life. I looked for ways that doctors could use high performance computing. Many articles came up about how computers could replace doctors in the future, but there was one specific one about “Dr. Watson,” a supercomputer that could store way more information than a human doctor could. It did the job faster, more effectively, and knows more than a human doctor would. It was fascinating, but also interesting that the job of doctors could be “replaced” with a computer that was more effective. We then discussed and learned about different careers that used supercomputing. After that, we answered questions in our notebook about the world’s fastest supercomputers, looking at the TOP500 site. We reviewed the questions as a class and discussed supercomputers and their corporations.
After the break, we looked at Little Fe and talked about how it used what we had learned in class earlier. We talked about Blue Waters, saw how it was built, and talked about why it wasn’t included in the TOP500 list and why they opted out. We then saw how Blue Waters could be accessed, with a high security system ahead of it. To use Blue Waters, you have to reserve time, using a scheduler program. We also talked about kilo-, mega-, giga-, tera-, and peta- and what they meant. We shopped for the parts to make our own supercomputers. Little Fe at Shodor cost around $3000, so that was around the range we were going for. I decided to go all out and get something of a little higher price. My grand total came out to $20,489, half of it coming from my cooling fan. Once we finished that, we were done with our parallel computing notebooks. We learned about BCCD and started to work on actual parallel computer programming, instead of just talking about it in theory. Using Terminal, we discovered important things that helped to configure our system and what different commands meant and did. I learned a lot about parallel computing and I’m excited to work with it in the future.
Apr. 1st, 2017
Today, we started by making a copy of the Parallel Computing Notebook, which we accessed through our apprentice docs. After we all made copies that were accessible through our website, we talked about parallel computing, serial computing, what they both were, and examples of the two. We used an already made model to visualize flipping coins in parallel and serial, changing the work size (total amount of coins we wish to flip), maximum amount of time steps, number of parallel workers, and the maximum worker memory (how many coins the workers can remember that they flipped). Our notebooks have a series of questions that relate to the model, depending on changing the different variables and comparing the serial worker to the parallel workers. We discussed the three ways that parallel computing was better than serial. It got the task done sooner, more of the task done, and did it better than the serial worker. We talked about communication versus computation, and how that can change the best type of worker(s) to use.
We then went to Shodor's Interactivate forest fire model for the next part of our notebook, something similar to what we built in the group projects last week. In this model, we used humans as computers. The goal was for nobody to be an idle computer, everybody working and nobody just sitting and watching someone else. We started by assigning ourselves numbers. To simulate message passing that computers do, we passed around Post-It notes to communicate. We each went through the model 5 times with our individual probabilities. We then averaged the percentages and iterations it took for the model to burn out and Aaron graphed all of them. After we finished analyzing the graph, we answered a series of questions about the experiment. Then, we worked on an activity called Domain Decomposition. We tried different ways of changing the workload to see how it affected the number of dependencies. The most number of dependencies happened when the colors were most spread out, not touching each other, at 112 dependencies. The least number of dependencies happened when one color covered the whole model, at 0 dependencies. We talked about dependencies and workload sizes and which models were interesting. We then worked on a parallel "recipe", containing materials, instructions, and dependencies. We used a store example to talk about things that could go wrong, dependencies, and communication. We chose Interactivate models to explain the model and write about parallel tasks and data. We then discussed some of the Interactivate models.
Mar. 18th, 2017
Today, Leanne and I wrote our script, linked our final forest fire model to our websites, and presented. I thought our presentation went well. We accomplished everything that we set out to do in our HLD and I'm really glad that the clicking aspect worked successfully. If we had to add any other aspects to our model, I would add the ability for trees that were burnt to eventually regrow, having some density in the forest. Another aspect that we could add is a percent chance that trees light on fire. Right now, all healthy trees that are adjacent to a burning tree will end up lighting on fire, and it would be interesting to see trees that just didn't light on fire, or took longer to turn to a burnt tree. The part overall that we had the most difficulty with was the clicking into the agent model in order to light a healthy tree on fire, which was difficult and required a lot of help from the interns in order to complete it successfully. It would be really cool to learn how to do everything that the interns did and helped us with and be able to do that from scratch. They explained it well, but I'm not sure if I would be able to remember what we went through in order to apply it to a new model. It was also difficult for us to create the burnt trees and have them fully work, although we did that successfully all by ourselves. I had a lot of fun and am excited for what we'll be doing in April and the next group project!
Mar. 11th, 2017
Today, Leanne and I continued working on our Forest Fire project. We now have the whole model successfully working. The agent model and the graph both work correctly. The user can also click on a healthy tree in order to turn the healthy tree into a burning tree. Next week is the week that we present. Before we present we want to write our script, finish up and link our project to both of our websites, and make sure everything is working. We got a lot of help from the interns with clicking into the model and other things.
Mar. 4th, 2017
Today we started our new group projects. The goal of the project is to change the disease model that was created from a previous predator prey model into a forest fire model. We learned about how these three models aren't really that different when you get into the details of them. Leanne and I are working together. As a class, we all got an HLD document for this model. We had to list out our agents for the model and the behaviors that the model would do. After we finished that, we had to present it to Aaron, the manager, and get it approved before we started working on the model. Our goal for this model was to have healthy trees, burning trees, and burnt trees. The user would click on a healthy tree in order to select it and set it alight. Once a healthy tree was set on fire, it would become a burning tree. Burning trees have a percent chance of turning the healthy trees adjacent to them into burning trees as well. After a certain amount of time steps, the burning trees would turn into burnt trees, no longer able to spread fire or catch on fire.
After Leanne and I got our Desired Behavior/Components section approved, we started working on editing the disease model, in order to turn it into a forest fire model. We kept healthy as healthy, changing the "people" to "trees"; but changed the "sick people" to "burning trees." Then, we changed the html so that the description for our project matched the project idea we had in mind. After that, we went through, looking for all the places where "healthy" was written, so we could additionally add "burnt", so that our new shape would be successfully created. We haven't worked in changing burning trees to burnt trees yet, but have most of the code to do that. After we created a working model, with healthy trees and one randomly placed burning tree filling the grid and all the healthy successfully turning into burning, we wanted to implement the user being able to burn trees by clicking on a healthy tree inside of our agent model. Leanne and I didn't know how to do this, so we got help from the interns, Anagha and Albert. They put clicking into our program, the console log knowing that the healthy tree was supposed to turn red, but we still have more work to do in order for our program to fully work. I also had my monthly meeting with Kristen today and had my stipend meeting with Aaron this previous Wednesday.
Feb. 18th, 2017
We looked at the Console tab in the web inspector again and learned about new things that it can do. We worked with different functions within the Console and learned about and installed a linter, which checks the syntax in code. We looked at how the Console told us where and what our errors were, for most things, and how it could output different random values we could use. We then stopped the food from regrowing, using ESLinter to check our work through the way. We learned about functions being used in JavaScript and how they were defined. In addition to stopping the food from regrowing, we also stopped reproduction and stopped our agents from eating from within the step function. Instead of commenting out variables this time, we commented out functions. We also learned about the correct order to place things in in JavaScript. We also covered calling and defining functions and variables. We also learned about keywords and how they cannot be used for the names of variables or functions. We changed "eating" to "infecting" and edited the functions and then moved them so that they were in alphabetical order. We worked with arrays again and reviewed them. We looked at how to add functionality to the model once we knew what it was supposed to do. Now, the model has sick people and healthy people. When a sick person is next to a healthy one, the healthy person turns into a sick person. The number of people always stays the same, however the number of sick grows and healthy reduces, the model eventually getting to 40 sick people and 0 healthy people. We finished and successfully created a disease model out of a predator prey model!
Feb. 11th, 2017
We reviewed what we went over last time and how the web inspector works. We went to the Console tab in the web inspector and tried different calculations using arithmetic symbols that we already knew of. We learned how JavaScript can even do algebra. Every time the web inspector had a different value entered into it, it changed the "$(number)" sign written in light gray next to the answer. We also learned about how, just as we can parse words, we can also parse code. We also worked with variables in the web console. We learned how to give different values to variables, how to set the value of one variable as the value of another variable, and what defines a variable and what doesn't. We learned about how, unlike in math we learn in school, the equal signs in JavaScript aren't bidirectional. We also learned about using "typeof" and using "==" and "!=" to test if the values were or weren't equal. We also learned about when certain strings or numbers were greater than or less than others. We also learned about adding strings together, known as concatenation, and how we couldn't subtract, divide, or multiply strings. After we finished working on the web console, we went back to the predator prey model that we were changing to a disease model. We edited the description in the HTML so it was describing a healthy/sick model instead of a predator/prey model. We decided to take away reproduction, food, and aging to simplify our model, as those things weren't necessary. We went through the model and commented out all the parts that contained food, removing the food from our graph and stopping it from regrowing in our agent model.
Feb. 4th, 2017
We started off today by listing all the programming concepts we had learned about and taken notes on, what they meant, and how they could be applied in programming. After we went over the list as a class, we talked about Expectation, Observation, and Reflection, a recurring topic in today's discussion. As a class, we listed out the materials that we use for programming and examples of those materials. We learned about different topics, such as obfuscation being used to avoid plagiarism. We worked on programming today, using Atom as our text editor. We went over the predator/prey model that Aaron had already programmed, going through the code and talking about what the different lines meant. Our end goal was to turn the predator/prey model into a disease model, and eventually turn that into a forest fire model. Using Atom, we found all the places where "predator" and "prey" were written, and we've changed some of the "predator" parts to "infected". We also learned about how making backups was a very important thing to do, so that you would have a working copy if you couldn't identify where you made a mistake. We also reviewed why we should save often, to avoid making mistakes that would take more work to reverse than it took to create them. We also learned about using the inspect element function to read code, and saw how Google obfuscated their code so that people wouldn't be able to plagiarise and understand the code.