This page includes information about the structure of the labs, the checkpoints, the lab quizzes, and a bit about VPython/Glowscript.
Labs count for 20% of a student’s final course grade (15% lab participation, 5% lab quizzes). You will be meeting with your lab section(s) 11 times per semester (since there’s 12 labs but Lab 1 is done at home). Each lab period is 3 hours long (actually, 2hrs 40min now), and can usually be broken up into three portions:
- lab quiz (if there is one) – always during the first 25 minutes of the lab period
- whiteboard problems (if there are any)
- experiment and/or VPython
At the start of each lab period (after the lab quiz is over), you should do a short introduction, lasting no more than 5 minutes, which should include:
- a very brief review of the physical concepts/principles that will be used in the lab (make sure to clearly and visibly write any relevant equations on the board)
- a very quick overview of the lab itself (e.g., “today we’ll be doing an experiment that will…”, or “for this lab you’ll be writing a code that…”, etc), including any corrections to the lab materials or sections that will be skipped over
- a list of the checkpoints for the lab (how many and when do they happen)
Whiteboard (WB) problems are problems that appear as downloadable PDFs on Canvas, that students need to work on in groups and write their answers on the whiteboard available at each lab station. Not all labs have WB problems, and some labs have more than one. You should strongly encourage students to work their WB problems on paper too, to keep a permanent record of their solutions (and it gives them more space than the whiteboards when the problems are very long). When students are done with a WB problem they should call on a TA to come check their work. The GTA or UTA who checks on a group’s WB solution shouldn’t just check that the answer is correct — instead, they should ask the students some questions to make sure the students understand the concept and the procedures behind each problem. Note however that this can be time-consuming, so choose your questions (and when to ask them) wisely. Once a TA has checked the solution, the students should take a picture of their whiteboard (or notebook, or whatever they used to solve the problem) and upload it to Canvas. The WB problems are a very important part of the lab, since this is the moment when students get a chance to do some problem-solving and get immediate feedback, and very often exam problems will be very similar to the WB problems done in lab.
When students are working on the main lab exercise, whether coding or experiment, both TAs in the room should be walking around and checking on the work students are doing. You should not just sit there and wait for students to call you! Walk around the room, go table to table, look at what students are doing, ask them if they have any questions or need help. Note that just asking them “How’s it going?” tends to not be useful, as students will usually just say “we’re ok”. Instead, ask “what are you working on now?” or “are you ready for a checkpoint?” or some other more direct question. If you notice students doing something wrong (e.g., a student has their multimeter set for voltmeter but they’re supposed to be measuring currents), step in and correct them. Ask students why they’re doing X or Y, to explain their reasoning – this helps when they’re doing something wrong but haven’t realized it yet. If you see a student raising their hand to ask for help, go to them as soon as you can. Both GTA and UTA should be doing rounds regularly so every lab group is visited and checked on. If you notice that two or more groups have the same question or encounter the same difficulty, ask everyone to stop and make an announcement to the whole class to clarify or explain the situation for everyone at the same time.
Make sure that every student is working. It’s best if all students in a group work on all parts of the lab together; however, you can allow teammates can divide the work among themselves if and only if the division of work does not remain static across several weeks. For example, in one particular week, Person A is doing the coding while Persons B and C do the experiment; the following week, Person A should not be the one to do the VPython. The reasoning for this is that, for example, if there’s a coding question in an exam, the students who didn’t do any coding in lab will be at a disadvantage. And speaking of coding, you can encourage each group to do the coding on one single computer (the code can be shared among all group members at the end of the lab). This way you don’t have to help debug two or three different codes per group, but rather one single code per group.
Checkpoints are the way to keep track of students’ lab participation. Labs usually have between two and four checkpoints, where students are supposed to stop working and call on a TA to check their work. The Head TA for your class should tell you how many checkpoints there are in each lab during the Friday TA meetings.
The checkpoints are indicated in the PDF lab instructions with a box that says Checkpoint in bold orange text. When a lab group reaches a checkpoint, either a GTA or a UTA needs to come to the group, ask them questions to probe their understanding, and award them a checkpoint. The group can then move on to the next part of the lab. The TA versions of the lab instructions usually have suggestions for what questions to ask during checkpoints. It’s important to note that the process of asking questions during a checkpoint can be extremely time-consuming, so you need to be selective about how many questions to ask and when to ask them. And sometimes you’ll need to simply award the checkpoint and skip the questions.
Sometimes you’ll get several groups asking for checkpoints at the same time. There’s many groups in the lab and only two TAs per lab room, so students will most likely have to wait at one point or another (though hopefully not for too long!). Each pair of GTA and UTA should discuss what they’d prefer to do in those situations. For example, you can tell students that they can move on and then get two checkpoints at once the next time a TA comes to them. Or you can do checkpoints for two groups at the same time (for example, if they’re at the same table, or back-to-back).
Students can miss checkpoints by arriving very late to the lab (missing the first checkpoint), or leaving too early (missing the last checkpoint), or simply not doing their work. In those cases, their lab participation grade will be negatively affected, since they didn’t complete all the checkpoints. Students who are distracted or otherwise not working can get a zero on any given checkpoint even if the rest of their group completes the work (the students in the group who ARE working are awarded the checkpoint).
If a lab is very long, you may find that some students miss the last one or two checkpoints. This is ok! Students get full credit for participating, all checkpoints awarded even if they didn’t finish the lab, as long as they were making an honest effort to work throughout the entire lab period. Basically, they’re ok as long as they’re not goofing off. But don’t advertise this to your students, you don’t want to tempt them to work inefficiently!
After each lab session, the GTA must enter their students’ checkpoint grades on Canvas. A student who collected all the checkpoints for the lab gets a grade of 100; if the student had three out of four checkpoints then they get a 75, and so on.
We have Nexus 9 tablets available for TAs to use to keep track of checkpoints. The tablets are kept in a vault (which, no lie, is called ERGOTRON and totally makes it sound like some kind of ergonomic robot) in room CULC 381, which GTAs can access with their BuzzCards. In past semesters some TAs have thought of the tablets as a bit of a pain for various reasons, so you DO NOT have to use the tablets if you prefer to keep track of checkpoints in a different way (e.g., using your own laptop or tablet, pen-and-paper, etc). The exact method is left at the discretion of each GTA/UTA pair. The important thing is that GTAs must enter the checkpoint grades on Canvas after every lab, regardless of what method was used to keep track of them during the lab.
The lab quizzes happen at the start of the lab period (students have 25 minutes to work on it), usually during weeks in which there isn’t an exam.
Here’s a sample lab quiz schedule, for 2212 in Spring 2017:
Emily made one of these (listing the schedule of labs, quizzes, and exams, as well as the off-weeks when there’s no lab meetings) every time she was Head TA for one of the M&I courses. But regardless of whoever the Head TA is this semester, you should still get a full semester schedule from them. It will likely look different but it should still have all the relevant information.
GTAs are responsible for printing the lab quizzes. You can do this either in the copy room next to the Physics Front Office, or by asking Stephanie for access to the other printer. The person who has the first lab section on Monday also needs to print Formula Sheets (which will be left in the lab rooms). GTAs don’t grade lab quizzes. Lab quizzes are graded by the UTA in each lab section.
Many labs (and some homeworks, lab quizzes, and exam problems) involve coding physics scenarios using VPython (the visual module of the python programming language). If you have any programming experience, even if it’s not in python, you should have no trouble with VPython. But even if you have no programming experience, VPython is a relatively simple language to learn, and the type of programming students will be doing here is very basic and mostly focuses on the physics (e.g., calculating the trajectory of a particle under the influence of an external force, or calculating the electric and magnetic fields of a moving charged particle at some specified distance from the particle). You won’t have to worry about doing any fancy CS stuff with pointers or data structures or whatever.
The VPython website (http://vpython.org/) has lots of documentation that will help you navigate how to do this or that in VPython.
In past years, students and TAs alike would download and install a local copy of VPython in their computers. Now, we use GlowScript instead. GlowScript (http://www.glowscript.org/) is an online tool to write, edit, and run VPython codes in the browser. You can log into GlowScript using a Google account. Your codes on GlowScript can be private (meaning that only you can see them) or public (which can be shared with others by simply providing the URL). Students should make sure to set their lab codes to public so that they may share the codes with their teammates.
Since many labs include coding, it’s important for you to practice writing the code before you go teach (you can compare your own code to the sample working code provided in the TA version of each lab). A significant part of your job during those labs will be to help students debug code, which can get pretty tedious. If you practice the code beforehand, you’ll get familiarized with what the code needs to look like and what it needs to do, and this should make you more efficient in helping students with the debugging.
Before you begin your teaching duties, you should do Lab 1 (Introduction to VPython) on your own. This will help you get familiarized with the VPython syntax and code structure.