Name and Contact Information: Daniel Rothenberg Website: http://www.danielrothenberg.com Location, timezone, languages: Ithaca, New York (anticipate San Francisco, CA this summer) Eastern timezone Languages: English, some French Level of experience in scientific or numeric computation: I work with climate models (mostly the CCSM3.5) pretty regularly, and have no problem hacking around in Fortran. For instance, last summer I interned under Dave Randall at the Center for Multiscale Modeling of Atmospheric Processes at Colorado State University, and performed a test case (the Jablonowski/Williamson baroclinic instability case) on an anelastic dynamical core. Essentially, I was handed Fortran-90 code and a makefile (which didn't work), and was told to port the model to compile and run on a computer at NERSC (Franklin) and Oak Ridge (Jaguar - the XT-5 partition with 12 cores/node). Didn't take very long; I got everything working, hacked away at the code to re-implement the test case (there were outstanding issues with setting up the initial conditions), and started running the model. The second goal of the project was to visualize output from the model. This was an issue because it ran on an icosahedral/geodesic grid, so there were few visualization tools which displayed it correctly. I implemented a tool in Python/MayaVI2 to read in the raw Fortran binary files dumped from memory by the model (https://bitbucket.org/counters/geodesic-plotter) and displayed them on a grid. I later used a plugin with Visit to animate the model data. I also implemented some other features in the model and did further work. I implemented Parallel NetCDF I/O for the diagnostic, cell-centered variables (model used a Z-grid, so writing the vorticity and divergence data (which is computed on cell edges/corners) proved a bit too difficult for my limited amount of time), and did a bit of numerical analysis to see how the model scaled with resolution and adding processors. The bulk of my project, though, focused on debugging the model - I found a numerical error which totally polluted the simulation at the lowest model layer. At first, I thought it was an issue with how the program was parallelized, but after running some simplified low-resolution cases in serial and 2, 4, and 8 processors, I ruled this out. I later investigated the initial conditions, but those seemed fine as well. The heart of the dycore was a 3D multigrid solver, which is still admittedly above my mathematical head (not by much, though), but one of my mentors, Ross Heikes, investigated it and ruled it out also. The bug was never found (again, limited time summer project), but Ross said that in subsequent iterations of the dycore it doesn't appear... may have been a weird glitch with computing the weights for each cell when fixing the icosahedral grid for better isotropy. Longwinded science/math rant aside, I've got a good background in numerical/scientific computation. I use NumPy/SciPy/matplotlib/PyNGL pretty extensively for my routine data analysis, which usually involves shell scripting, processing large NetCDF files (CCSM3.5 output), and then performing statistical analyses and finally data visualization. I don't have a "favorite" Fortran compiler - I usually default to what the code I inherited was originally written with. In the occasions where I've written my own code from scratch (such as in my Meteorological Software course or when I'm writing Fortran routines to speed up my NetCDF processing), I use gfortran because it's shipped with Ubuntu (my home OS for programming). I've also used Matlab for coursework, such as my Numerical Analysis/Differential Equations course. Through that, I've implemented plenty of ODE/PDE solvers, polynomial/chebyshev etc. interpolation routines, and other fun projects. I prefer SciPy, though. At Cornell, I took a graduate level course called Computational Methods of Non-Linear Systems (http://pages.physics.cornell.edu/~myers/teaching/ComputationalMethods/) which used SciPy as the foundation for solving all sorts of problems, from simulating percolation to the double pendulum, and performing analyses like Poincare sections. I can't say I'm terribly familiar with some of the mathematical analysis you mention in this question, but I do have a strong background in maths - above and beyond the routine meteorological coursework, with Real Analysis, Numerical Analysis, and higher-level Diff Eq's classes. I learn fast, and it won't be a problem picking up some new mathematical skills. Level of experience with open-source software Pretty extensive user. I've only ever skimmed "The Cathedral and the Bazaar" when it pops up on /r/programming, but I use a lot of open-source tools. I primarily work in Ubuntu, and use open-source compilers whenever possible. I use Eclipse for a lot of my hardcore work. For instance, I'm currently working on a project (http://storm-report.appspot.com/new/test) which reads NWS #wxreport tweets and plots them on a map; the project is built in GAE (Python) and GWT, and having Eclipse and Aptana is absolutely invaluable for easily moving between Java/Python and having direct access to the API's that the project is built on. When I do rot-gut data analysis and scripting, though, I prefer working in Emacs in a console. Just simpler, cleaner, and faster that way. I've never contributed to open-source projects, unfortunately. Never too late to start, I suppose :) Level of experience with Python and other open-source langauges I'm an extensive Python user; I've been working with it since my AP Computer Science teacher in high school asked me to re-implement a project in it (we were studying recursion and had to solve the N-Queens problem. I thought it would be cool to implement a genetic algorithm to "find" the solution to the problem in Java, so I did. My teacher told me to re-write the code in Python just for laughs, and I've been stuck with the language ever since). In that same class, we used Java and Scheme, although I don't use either language very often anymore (Java some, for working with GWT). I'm a huge advocate for Python in the atmospheric sciences, and even participate in Johhny Lin's PyAOS project (http://pyaos.johnny-lin.com/). Level of education and experience in scientific research I think my CV will speak for itself, but I've got a solid background for a young, recent college grad. To summarize, I've done several summer internships, and worked with a professor at Cornell on a project which ultimately turned into an Honors Thesis. I'm carrying over that thesis work and turning it into a journal article (my deadline with my professor for the draft journal article is actually on Friday!). I've also co-authored two papers (which I mainly performed data analysis, background research, and visualization), and presented a poster at the 2011 AMS meeting. Level of experience in climate science I have a BS in Atmospheric Science from Cornell, and have committed to pursuing a PhD in Atmospheric Science at MIT this coming fall. I work regularly with the CCSM3.5, and my research has spanned atmospheric dynamics to numerical modeling to biogeochemistry. I'm a vociferous consumer of the climate "debate" online, and regularly read blogs like RealClimate and ClimateProgress (as well as "skeptic" blogs like WattsUpWithThat, if only to test my ability to de-bunk a lot of the stuff that's out there). Through my grad school visits I've had the opportunity discuss climate science and policy with the likes of Richard Somerville at Scripps, and debated the merits of the cubed-sphere grid versus the icosahedral grid with SJ Lin at GFDL. Tomorrow, I'm eating lunch with Gavin Schmidt (my mentor is hosting him for a talk in the afternoon). Climate science is my passion, and my career goals center heavily around it. Why are you intending to participate in GSoC/Why have you chosen CCF This summer is my "gap" summer between undergrad and my PhD program, but I don't want to be lazy and sit around all day. I want to contribute actively to the climate science arena, and the Climate Code Foundation seems to be the best way to do this. A huge pet peeve of mine is the stagnancy of technology in the atmospheric sciences. We use outdated, deprecated technologies to build our "high-performance" models, and simply put, this paradigm is not sustainable. I've worked with the ultra-high resolution Global Cloud Resolving Models which we'll soon be using to perform climate projections at 1km global resolution via my work at CMMAP, and although we have the computational capacity to perform this work, we do NOT have the code to do it in a reasonable efficient manner. We're stuck with 40-year-old code bases using legacy C and Fortran-77 code. We're also stuck with some of the original developers of this code, which is why things aren't evolving any faster than they are. A major career goal of mine is to advocate for the adoption of better technology and computational techniques in the atmospheric sciences. In particular, I'm interested in , at some point, building a totally modular, highly-engineered numerical weather prediction or global circulation model for researchers. The goal would be to build a tool whose code can easily be replaced. For instance, say a grad-student wants to pop a new advection routine into the ocean component of the model. Nowadays, that might require that student building a simplified numerical routine to simulate the advection, then hacking their code into oblivion to get it to work with the model. Models like the CESM have modular components to them, but we should take that abstraction one level further. Need an advection routine? Well, define an interface in the model which tells what goes into the advection routine and what comes out, and then you can pop any routine you want extremely quickly. Similar things could be done for microphysics or chemistry schemes in atmosphere models. Suffice it to say that there are few people willing to take a gamble and invest in such a project. I know for a fact it will have to wait until after my PhD is completed, and I've earned a reputation in the field. But it'll likely never happen at NCAR, GFDL, or the other major modelling centers, so I'll probably have to take it to the private sector at some point - perhaps Nathan Myhrvold and Intellectual Ventures might be interested in the challenge of building a modern GCM from the ground-up... Nevertheless, I think working with CCF on a climate related project somewhat orthogonal to my normal research would be a fabulous opportunity to improve my software engineering and programming skills, as well as continue to develop my faculties with numerical methods and high-performance computing. I'm an advocate for transparent, clear code, and let's be honest - "clear code" is in the name of one of the CCF's major projects! Your organization and potential projects are literally a perfect fit for me, if there ever was one.