Presidents Summer Fellowship, Modeling Fluid Dynamics Part 2, Qiaoyu Yang
President’s Summer Fellow Qiaoyu Yang ’16, mathematics major, is testing a probabilistic particle model for studying fluid dynamics with Prof. Aleksandar Donev at the Courant Institute in New York City. In this post, he explores the differences between research in applied versus pure math.
The end of summer approaches. So does my summer research at Courant Institute. It’s been an exciting and productive time. During my time at 91²ÝÝ®ÊÓƵ, I have done several research projects, some in pure math and others in applied math. Among these experiences, I liked the one I did in my freshman summer and the one I did this summer the most. They feature different characteristics of research in pure and applied math. I think some of these differences are quite interesting and would like to share them to people interested in math and emphasize the distinctions between pure and applied math.
I did the first project in the summer of 2013 with Dave, i.e., Prof. David Perkinson, in the math department of 91²ÝÝ®ÊÓƵ. We worked on combinatorics and graph theory, a branch of discrete math. On the other hand, the research project I did this summer is building a stochastic particle model. This is a topic in scientific computation, which is a part of applied math. In the following, I will try to compare my experiences and give the readers some flavors of what research is like in pure and applied math. Of course I need to admit that these are totally based on personal experience and they can be very biased. Also, I’m still learning about math, and a lot of things highly depend on the specific subject so my conclusions can be over-generalizing. But this is not writing a research paper so I don’t want to be too rigorous in all aspects.
The first distinction is the object of study. Pure math, as its name suggests, studies mathematical objects and usually doesn’t consider problems in other subjects. There are exceptions such as mathematical physics but often the subject that interests researchers does not have real-life implication or application. On the other hand, applied math, in general, is motivated by needs of science and engineering. However, the boundaries between pure and applied math can be hard to tell. For example, research in graph theory has applications in biology, networking, decision-making theory, and so on. Also, it’s very common for results in pure math to find their application in other scientific areas after a long time. Some notable examples include number theory in cryptography and topology in general equilibrium theory in economics. The boundary is not always clear but the point is that pure math deals with math itself while applied math cares a lot about science and engineering. However, their methods are always mathematical.
The second distinction is more or less a result of the first one. Pure math is characterized by a well-developed, deep, clear and mature system. Since around mid 20th century, the Bourbaki group’s attempt to build up the whole math system in purely set theoretic language has achieved some success (even though the attempt itself is considered harmful by a large group of mathematicians such as V.I. Arnold). Since then, it’s been easy to do pure math in very clear language with all the concepts well defined. Sometimes new concepts in pure math can carry different meaning in different authors’ view. For example, once when Dave and I were talking about the definition in our paper, I asked him if we should adhere to the one used by Stanley, one of the most important people in the area we worked on. And Dave said he would like to have people accept the new version of the definition, which is more general than the old one, so for that purpose, he would like to use the new definition in the paper. The point is that, sometimes concepts can be slightly different but essentially they mean the same thing and the idea can almost always be clearly conveyed to the reader. Moreover, after some time, people would usually regularize the language and then things become universally clear. However, concepts in applied math can be confusing, especially for beginners in the area. This is not caused by the fact that people haven’t come to agreement but by the fact that a lot of these concepts arise from scientific and engineering scenarios. It’s not always possible to define such terms properly. One good example would be stiff ODE. A stiff ODE is an ordinary differential equation that cannot be numerically solved with a reasonably large timestep because of an intrinsic property. The stiff terms, which caused the stiffness of the ODE, are terms that introduce very rapid variations and thus require us to use a very small timestep for the algorithm to be numerically stable. However, it’s hard to define what we mean by “rapid variations” and “small timestep”. These are usually conditioned on the computation power that’s available to us. A lot of important concepts in applied math have a similar feature. Some examples include ill-posedness in the study of PDEs and turbulence in study of fluid dynamics. Therefore, unlike pure math, applied math can often be less accurate and clear. Usually methods and results in pure math would be at least a few decades ahead of theoretical physics, not to mention other disciplines. These make pure math very deep. Not only the theorems but sometimes even just the definition can be very hard to understand. Sometimes objects in pure math don’t have a good counterpart in real life for us to grasp idea and the whole thinking process needs to be done purely in mathematical ways. Applied math is much different. The topics are not as deep but have a much higher degree of association with science and engineering. However, as we mentioned before, applied math is not always clearly defined. This makes the study of applied math sometimes complicated. There are a lot of details that don’t fit into each other harmoniously. One needs to have experience in science and engineering to properly understand the way all the stuff works.
The third distinction is about what researchers do. I cannot say that this third distinction is justified but I can only say that it’s true from my experience. I still well remember that in the summer I worked with Dave, we read some papers and then spent a lot of time trying to come up with new ideas. The process is usually accomplished by pen-and-pencil work. We need to look up terms on the Internet but besides that most of the work is done in the mind and on paper. Sometimes we need to solicit the power of computers to generate interesting examples and verify that our ideas work on all examples but that’s not by any means the central process. However, for applied math, in addition to “thinking”, a lot of the time goes into “implementation”. As we mentioned in the first point, applied math cares about science and engineering. For example, my work this summer is to verify the robustness of a model called IRDME, which means isotropic reaction-diffusion master equation. (This name is perhaps not well justified and will be subject to change in the future, but at this point, let’s just call it IRDME.) We cannot know if the model works well only from mathematical consideration since it is not a perfect model of the phenomenon being described. By the way, perfect models do not exist since we don’t have complete understanding of the physical world. Hence, to see if this works well, we need to first write the code to implement the idea and then compare the data generated from the code with experimental results or data from other code that’s been shown to be valid and robust. This process is actually very complicated. Even though the idea appears to be innocent and not so difficult at first, the implementation can be very time-consuming. The reason is that we need to translate a very complicated model that involves many details into computer language while keeping in mind that we don’t have unlimited computing power. This is my first time to join in a formal scientific computing project and some features are new to me. It requires a lot of libraries of previously written and also many newly written functions, routines to be called in a complicated way. This makes debugging much more difficult than in a setting I’m more familiar with. Once there was a bug in the data that didn’t arise until around 1million runs of a loop that dealt with chemical reactions, and it took me a long time to find the error because the code itself was very lengthy and a bug can appear anywhere. Finally I found out the problem was caused by the random number generator we used. We needed the generator to generate a random number in (0,1], meaning, including 1 but not 0. However, the generator actually generated a random number between 0 and 1 but the way it was written allows it to generate 0 but not 1, i.e., it generated a random number from [0,1) uniformly. In modern computers, machine epsilon is usually about 10^-14 so there are roughly 10^14 possible candidates, which is about 100 trillion. Hence, it is fairly hard for the generator to generate 0 and then cause the problem. However, we ran around 1 million loops and in each loop we needed to use the generator many times so it became possible for the code to crash. Besides debugging, we also need to take care of the time and memory we use. In our case, the problem does not require massive memory and 500GB, a typical size of the Linux machines we used, is usually enough. However, the whole point of our research project is to develop a time-efficient algorithm that is also very accurate. Hence, we often need to use hard algorithms and complicated data structures to optimize the time. This makes the code hard to write and maintain. As one can see, while pure math requires mostly thinking, applied math project has a greater need for implementation.
We are still working on the particle model. It’s unlikely that we will completely finish the project in a few days. In next article I should describe, in greater detail, what I’ve been doing so far.
Tags: psf, presidents summer fellowship, mathematics, math, programming, computation, fluid dynamics, computer science