MatSci was, from the second week of classes, my favorite course of this semester. I was a little nervous about going into projects right away with no background first, but MatSci ended up being the best project-based class I've ever taken, and I definitely think projects were the right way to frame this course.
Thursday, May 21, 2015
Wednesday, May 20, 2015
Arduinos, Valves, and Raining Patterns: Thoughts on Principles of Engineering
Principles of Engineering (PoE) is very much a do-learn course. It's really a class about integration, starting with three labs using Arduino Unos and then spending the rest of the semester on a team project that must include significant mechanical, electrical, and software systems. I was nervous about PoE going in because I was a mechE who hadn't done much mechanical design, so I wasn't sure what role I would take on the project team. I ended up having a lot more fun than I expected, and PoE contributed more than any other class this semester to my growth as a mechanical engineering. I wouldn't have expected to say this going in, but I think PoE is an important class to have in the curriculum, and I'm really glad it's a graduation requirement.
Monday, April 13, 2015
I'm going to be a senior?
My life is still mostly class projects (even more so now that MechSolids projects are about to start), though the weather is finally warming up, so I've also been spending time at Babson's baseball games. There are only three weeks of classes left, and registration was at the end of last week. It's a little weird to think that I'm already registering for senior year. Here's what I'll be up to this summer and next fall:
Sunday, March 29, 2015
The Most Project-y Time of the Year
We're more than halfway through the semester, and I'm doing projects in three of my four classes. Here's a little bit about what I'm working on at the moment:
Tuesday, March 10, 2015
It's a Small World After All
About a month ago, my friends Amelie and Eleanor and I participated in the Mathematics Competition in Modeling (MCM). The contest is 96 hours long, and the final deliverables are a report and some short, non-technical piece of writing specific to the problem topic.
There were four problem options, and we went with Problem A:
The world medical association has announced that their new medication could stop Ebola and cure patients whose disease is not advanced. Build a realistic, sensible, and useful model that considers not only the spread of the disease, the quantity of the medicine needed, possible feasible delivery systems, locations of delivery, speed of manufacturing of the vaccine or drug, but also any other critical factors your team considers necessary as part of the model to optimize the eradication of Ebola, or at least its current strain. In addition to your modeling approach for the contest, prepare a 1-2 page non-technical letter for the world medical association to use in their announcement.
We ended up building two models to look at the problem on different scales. One model was of a district (and would be easily extendable to a country), and that model was focused on supply of the drug and distribution of medical workers. Instead of looking at individual people, we looked at percentages of the population moving among risk levels and susceptibility levels over time.
The other model was at a town level, and we focused on the connections among people and how a triage-like system of distributing the drug influenced disease spread and resistance within a community. For this model, I got to play around with graph theory! After reading some papers about networks and modeling spread of disease or information, we chose to go with a type of network structure called a small world model. In our implementation, each person in the community was represented by a vertex, and close relationships (the kind that would lead to a lot of contact even if someone were ill) were represented by edges. We gave each edge a weight between 0 and 1 to indicate how strong a connection it was. The small world part comes in from how we determined where to put edges. Each vertex had edges to a few vertices near it in a very regular pattern, and then we added in a set number of randomly determined edges. For example, say we had a community of 70 people, and we organized the 70 vertices in a circle. Then one possible setup like ours would have each vertex connected to two vertices immediately to its right and two vertices immediately to its left, and there would be a few random edges crossing through the center of the circle.
I spent most of my time working on the small world model and thinking about how to integrate the two models. I hadn't expected to get to do graph theory, so this was exciting! My research group published some spread papers a year or two before I joined, and I've seen a lot of presentations at math conferences over the years about spread and containment in various networks, but I'd never actually done any work in the area. Knowing what kinds of networks were possibilities and where to look for more information was really useful for the competition, and I feel more comfortable working with networks in general now.
We came to some cool conclusions from the graphs we got out of the models, and we were even able to use some of our user-centered design experience in interpreting the results. From a mathematical point of view, there's more information that I would have liked to know about our graphs, but at the time I wasn't entirely sure if that information would be relevant. We were pretty happy with our work, and Amelie and I are planning on competing again next year!
There were four problem options, and we went with Problem A:
The world medical association has announced that their new medication could stop Ebola and cure patients whose disease is not advanced. Build a realistic, sensible, and useful model that considers not only the spread of the disease, the quantity of the medicine needed, possible feasible delivery systems, locations of delivery, speed of manufacturing of the vaccine or drug, but also any other critical factors your team considers necessary as part of the model to optimize the eradication of Ebola, or at least its current strain. In addition to your modeling approach for the contest, prepare a 1-2 page non-technical letter for the world medical association to use in their announcement.
We ended up building two models to look at the problem on different scales. One model was of a district (and would be easily extendable to a country), and that model was focused on supply of the drug and distribution of medical workers. Instead of looking at individual people, we looked at percentages of the population moving among risk levels and susceptibility levels over time.
The other model was at a town level, and we focused on the connections among people and how a triage-like system of distributing the drug influenced disease spread and resistance within a community. For this model, I got to play around with graph theory! After reading some papers about networks and modeling spread of disease or information, we chose to go with a type of network structure called a small world model. In our implementation, each person in the community was represented by a vertex, and close relationships (the kind that would lead to a lot of contact even if someone were ill) were represented by edges. We gave each edge a weight between 0 and 1 to indicate how strong a connection it was. The small world part comes in from how we determined where to put edges. Each vertex had edges to a few vertices near it in a very regular pattern, and then we added in a set number of randomly determined edges. For example, say we had a community of 70 people, and we organized the 70 vertices in a circle. Then one possible setup like ours would have each vertex connected to two vertices immediately to its right and two vertices immediately to its left, and there would be a few random edges crossing through the center of the circle.
I spent most of my time working on the small world model and thinking about how to integrate the two models. I hadn't expected to get to do graph theory, so this was exciting! My research group published some spread papers a year or two before I joined, and I've seen a lot of presentations at math conferences over the years about spread and containment in various networks, but I'd never actually done any work in the area. Knowing what kinds of networks were possibilities and where to look for more information was really useful for the competition, and I feel more comfortable working with networks in general now.
We came to some cool conclusions from the graphs we got out of the models, and we were even able to use some of our user-centered design experience in interpreting the results. From a mathematical point of view, there's more information that I would have liked to know about our graphs, but at the time I wasn't entirely sure if that information would be relevant. We were pretty happy with our work, and Amelie and I are planning on competing again next year!
Wednesday, March 4, 2015
I Am a MechE
In this month's issue of Frankly Speaking, Olin's newspaper, Meg Lidrbauch wrote about trying to do too much and the culture around that at Olin. It's a good piece, and I agree with its main point, but I'm going to go off of something that's a bit of a side argument in the article.
Meg talks about realizing that she's not a mechanical engineer, and in doing so she describes the typical Olin mechE as someone who does design in Solidworks, puts a lot of time into one of the large vehicle project teams, and can be found in the machine shop.
But this is far too broad a brush, even at Olin. Amelie, Erzsi, Ariel, and Antoinette are all mechanical engineering majors, and I've had major requirement classes with all of them. Amelie can CAD and machine but would much rather spend her time on sensor research. Erzsi builds and loves being in the machine shop, but she does not CAD. Ariel is interested in sustainability and helps lead the Human Powered Vehicles team, so she fits the description but has her own slant. Antoinette prefers conceptual design to hardcore mechanical design or CADing and is really interested in K-12 education. Actually, one of the people who conforms most to that image of the Olin mechE is much more of an electrical engineer; each month he chooses an integrated circuit of the month and writes a little bit about it in a newsletter that he distributes through the dining hall.
Of course there are mechEs here like the one described. The other two people on my MechAero team pretty much fit the stereotype. For that matter, so do at least two-thirds of the rest of the class. The image accurately describes a lot of people. That's how it originated! But this is not the only way to be a mechE. I identify less as a mechanical engineer at Olin than I do anywhere else because of the prevalence of this idea of what it means to be a mechE at Olin. Outside the Bubble, calling myself a mechanical engineer provides others with reasonably accurate information about my knowledge base, but that's not the case at Olin.
Meg talks about realizing that she's not a mechanical engineer, and in doing so she describes the typical Olin mechE as someone who does design in Solidworks, puts a lot of time into one of the large vehicle project teams, and can be found in the machine shop.
But this is far too broad a brush, even at Olin. Amelie, Erzsi, Ariel, and Antoinette are all mechanical engineering majors, and I've had major requirement classes with all of them. Amelie can CAD and machine but would much rather spend her time on sensor research. Erzsi builds and loves being in the machine shop, but she does not CAD. Ariel is interested in sustainability and helps lead the Human Powered Vehicles team, so she fits the description but has her own slant. Antoinette prefers conceptual design to hardcore mechanical design or CADing and is really interested in K-12 education. Actually, one of the people who conforms most to that image of the Olin mechE is much more of an electrical engineer; each month he chooses an integrated circuit of the month and writes a little bit about it in a newsletter that he distributes through the dining hall.
Of course there are mechEs here like the one described. The other two people on my MechAero team pretty much fit the stereotype. For that matter, so do at least two-thirds of the rest of the class. The image accurately describes a lot of people. That's how it originated! But this is not the only way to be a mechE. I identify less as a mechanical engineer at Olin than I do anywhere else because of the prevalence of this idea of what it means to be a mechE at Olin. Outside the Bubble, calling myself a mechanical engineer provides others with reasonably accurate information about my knowledge base, but that's not the case at Olin.
Tuesday, February 17, 2015
#LoveOlin
I didn't fall in love with Olin, not really. Not like so many other Oliners do.
I was impressed when I first visited in summer 2010. I came to Olin right after leaving Mathcamp, and what I heard about Olin culture reminded me of Mathcamp culture. I liked the idea of knowing everyone and especially of knowing the professors. My Olin visit also changed what I looked for at other schools. I started asking about how easy it was for students to be trained on the machines, looking at how present design was in the curriculum and how early, and finding the statistics on how many graduates went into industry. But I wasn't in love, not yet. It was far too early to fall in love, far too dangerous to fall in love a year before I started applying to schools.
I called Olin my top choice for all of junior year and most of senior fall. It was close to Rice and Georgia Tech, and a lot of times I just grouped the three together as my top choices, but if asked to name one, I would say Olin. In January 2012 I was invited to Candidates' Weekend, and in February, I became a candidate.
I liked Candidates' Weekend, but so many people talk about leaving CW knowing for sure they wanted to go to Olin. I didn't know that for sure. I liked the other candidates and had some good conversations with Oliners, but the design challenge had made me pretty uncomfortable, and I still wasn't sure about parts of the curriculum. I wasn't sure about the curriculum constantly changing. While I liked campus, I didn't like the location, and the small size came with a lot of disadvantages.
Obviously, I ended up choosing Olin, but I wasn't in love when I chose. I was sure, but not in love.
I still don't think I'd say I'm in love, not in any continuous way. I have had plenty of moments over the past two and a half years of being in love, and a lot of them are unsurprising: good team experiences, great conversations with professors, opportunities I wouldn't get at other places due to school size or my major. But not all of these moments are so predictable, and some of them remind me that whether or not I'm in love with Olin, I do love it.
Last Friday wasn't exactly the kind of day to make me love Olin. It hasn't been the easiest or happiest semester in general. I was leaving at 1pm to go to the airport and fly home for the long weekend, but I had an assignment due at 5pm that wasn't done. I had gotten too little sleep, hadn't finished packing, and was frustrated with the assignment and myself, but I still felt like I needed to go to Linearity class and NINJA.
And then I stood in the middle of the Dining Hall Mezzanine after answering a couple of questions at a whiteboard, looked around at the eighty or so Linearity I students working on problem sets and quizzes, and thought, "This is why I'm here."
Some days that's all it takes.
I was impressed when I first visited in summer 2010. I came to Olin right after leaving Mathcamp, and what I heard about Olin culture reminded me of Mathcamp culture. I liked the idea of knowing everyone and especially of knowing the professors. My Olin visit also changed what I looked for at other schools. I started asking about how easy it was for students to be trained on the machines, looking at how present design was in the curriculum and how early, and finding the statistics on how many graduates went into industry. But I wasn't in love, not yet. It was far too early to fall in love, far too dangerous to fall in love a year before I started applying to schools.
I called Olin my top choice for all of junior year and most of senior fall. It was close to Rice and Georgia Tech, and a lot of times I just grouped the three together as my top choices, but if asked to name one, I would say Olin. In January 2012 I was invited to Candidates' Weekend, and in February, I became a candidate.
I liked Candidates' Weekend, but so many people talk about leaving CW knowing for sure they wanted to go to Olin. I didn't know that for sure. I liked the other candidates and had some good conversations with Oliners, but the design challenge had made me pretty uncomfortable, and I still wasn't sure about parts of the curriculum. I wasn't sure about the curriculum constantly changing. While I liked campus, I didn't like the location, and the small size came with a lot of disadvantages.
Obviously, I ended up choosing Olin, but I wasn't in love when I chose. I was sure, but not in love.
I still don't think I'd say I'm in love, not in any continuous way. I have had plenty of moments over the past two and a half years of being in love, and a lot of them are unsurprising: good team experiences, great conversations with professors, opportunities I wouldn't get at other places due to school size or my major. But not all of these moments are so predictable, and some of them remind me that whether or not I'm in love with Olin, I do love it.
Last Friday wasn't exactly the kind of day to make me love Olin. It hasn't been the easiest or happiest semester in general. I was leaving at 1pm to go to the airport and fly home for the long weekend, but I had an assignment due at 5pm that wasn't done. I had gotten too little sleep, hadn't finished packing, and was frustrated with the assignment and myself, but I still felt like I needed to go to Linearity class and NINJA.
And then I stood in the middle of the Dining Hall Mezzanine after answering a couple of questions at a whiteboard, looked around at the eighty or so Linearity I students working on problem sets and quizzes, and thought, "This is why I'm here."
Some days that's all it takes.
Subscribe to:
Posts (Atom)