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:
Sunday, March 29, 2015
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.
Subscribe to:
Posts (Atom)