Showing posts with label CSAG. Show all posts
Showing posts with label CSAG. Show all posts

Tuesday, November 13, 2012

Pythons, pandas and ferrets: The zoo of tools for atmospheric scientists

Sitting in a postgraduate group meeting a few weeks ago, the modelling students were discussing the various tools available used. One social scientist commented that to an outsider the conversation sounded highly amusing, and to those not familiar with the tools, I suppose discussing ferrets, pythons, Fortran, C and R sounds like a cross between a zoo and alphabet soup.

Why all these different tools? Legacy....

Fortran is the backbone of all climate models, used mainly for its numerical core that some argue is still faster then C etc. (they just don't want to port the system to a newer language). One programmer described reading Fortran is like scratching your own eyes out...pretty graphic!

Then comes C, the quintessential language of the engineer.

Ferret is a scripting language for environmental applications.

Python is an interpreted language that is has evolved over time, it used to be incredibly slow to manipulate data, but the modifications have sped up calculations and new modules have made python a welcome addition to the scientific zoo. SciPy, NumPy, pandas make it possible to do R comparable (actually fixed issues in R) calculations. Matrix manipulations have never been better.

Friday, September 17, 2010

Tornado!


I arrived in the office the other day to this contraption sitting on the conference table. Apparently our IT guy built a tornado simulation. Very cool.

Tuesday, July 27, 2010

The Seeds of Time

"If you can look into the seeds of time, and say which grain will grow and which will not, speak then unto me." - William Shakespeare, Macbeth Act 1 Scene 3

What farmers want and what forecasters provide are two vastly different sets of information. I'm becoming increasing more frustrated with researchers who say 'but its not possible'. Well then why did you give the farmer the chance to ask for it in the first place, you're creating false expectations of the capabilities of science.

With this in mind, what can we the forecasters offer? Tailored forecasts for one. Industry specific? Individual time frames? Spatial resolution? These products seem to be lacking in South Africa and to some respect the rest of Africa.

Pop quiz: Would you trust the mean of the data below to tell what is going to happen in the next 3 months?

The trouble with (weather) forecasting is that it's right too often for us to ignore it and wrong too often for us to rely on it. - Patrick Young

We as a scientific community are improving our climate models to accurately reflect the climate conditions but they are not so accurate that we can rely on them completely. Would you place a bet based on your forecast?

There must be a way to create a robust solution that can cater for the inconsistencies in model skill. What is it? I'm not sure, that is part of the reason I came to IIASA, to discover, to explore. Its turning into a long path to an even more distant discovery but when have I ever chosen the easy path in the past.

Monday, May 10, 2010

Visiting SAWS

Simon Mason from IRI is visiting South Africa for a project with the South Africa Weather Bureau (SAWS). I had the opportunity to go to Pretoria to ask a few questions to the expert himself. Below I have listed a few things I learnt on my trip:

There are 3 attributes that one must consider in verification of forecasts:
• Resolution: Conditioning on the forecast. If you forecast something, does it happen? A forecast is useful if you have some resolution. Difficult to measure (need lots of data). Good for regions not grid boxes.
• Discrimination: Conditioning on outcomes. If it rains, did we forecast it. Needs less data. Can get map
• Reliability: Measures confidence and bias. Not useful on its own. Need to use (Resolution ∪ Discrimination) ∩ Reliability

Defining a region of study:
It is worth starting at 20 degrees latitude and longitude on each side of area interested and then narrow down by looking at diagnostic maps from GCM to downscaled. Easy to do with CCA. If looking at geo-potential height as an indicator, then the region may need to be bigger to include larger scale synoptic conditions.

Some extra literature for my spare time:
[1] R. Hagedorn and L. A. Smith. Communicating the value of probabilistic forecasts with weather roulette. Meteorological Applications, 2008.
[2] S. J. Mason. Recommended procedures for the verification of operational seasonal climate forecasts. 2010.
[3] A. H. Murphy and D. S. Wilks. A case study of the use of statistical models in forecast veri- fication: Precipitation probability forecasts. Weather and Forecasting, 13:795–810, September 1998.
[4] M. S. Roulston and L. A. Smith. Evaluating probabilistic forecasts using information theory. Monthly Weather Review, 130:1653–1660, June 2002.
[5] M. K. Tippett and A. G. Barnston. Skill of multimodel enso probability forecasts. Monthly Weather Review, 136:3933–3946, 2008.

Friday, September 11, 2009

SASAS Conference


South African Society for Atmospheric Scientists (SASAS) host an annual conference to bring together the Atmospheric Scientists and interested parties (agriculture, atmospheric chemists, hydrologists, oceanographers) a chance to meet and present their current research.

This year Climate Systems Analysis Group (CSAG) were tasked with running the conference. SASAS was held at Waterval in Tulbagh, a team building and conference venue just outside the picturesque wine producing town. There was snow on the mountains and fog in the mornings..nice and chilly.

The theme this year was BEYOND THE BOX. Trying to slowly shuffle atmospheric scientists from the traditional methods to the innovative. The conference structure changed to include 2 new sections; Grill the Climatologist and Beyond the Box.

Grill the Climatologist consisted of thought provoking questions put before a panel of three scientists. The questions were anonymously submitted to the chairman of the session. They included geoengineering, why we bother running more simulations when we can't cope with what we have already and carbon trading.

Beyond the Box was split into 2 sections, a short introduction by four scientists on what they think is the future of atmospheric science. These presentations highlighted the current failures and their visions of hope. The second section expanded on these ideas and included a few extra presentations on innovative approaches to climate science.

A few take home messages from this conference are that carbon trading is a disastrous idea, geoengineering is not a solution and that we need to stop looking to new and better models and tell a story with the data we already have.

Monday, June 1, 2009

How to Think Like a Computer Scientist

I have been looking through the various online resources available for Python and found Green Tea Press which includes How to Think Like a Computer Scientist: Learning with Python and Python for Software Design. I find the book informative for people who can already program but need to understand the idiosyncrasies of a new language.

Friday, April 17, 2009

Ballroom is hotting up

For those who watch the UCT Ballroom calendar Medal Tests are just around the corner. Extra lessons start on Sunday and we are set to have a truly awesome time this year. We're going Greek! The committee are also gearing up for Intervarsity and all it entails (the bane of my existence at the moment).

My thesis is slowly progressing with a multitude of stops and starts as problems arise. I am currently investigating the SMILE library for Bayesian Inference. I am not completely sold on the library and the API yet and am wondering if I should have stuck it out with PNL. I seem to have more problems than solutions currently. The nightmare continues.

Thursday, April 16, 2009

Python for Nonprogrammers

The EGS Honours class at UCT has requested a course on programming and the research they are attached to (CSAG) has decided Python is the best introductory language for them. I have never taught Python to people who have never programmed before and especially ones who have already done an entire degree. How quickly can you move through the basic programming concepts? Do you assign it as homework before your first lecture? Any suggestions?

I have read through a Byte of Python but I am not convinced it covers the topics in enough depth. I as a programmer can breeze through the whole book without a qualm but I do not remember a time when I didn't know what a variable is or what an IO stream is.

We will see how well things go next week. I might be designing the lecture material yet again. Sigh. If nothing else, it is a challenge to see how well I can still teach the basics.

Thursday, February 5, 2009

Battle of the Supervisors


To all those with two supervisors, I am beginning to understand the potential headaches. I have been adopted by the new lecturer in CSAG, Babatunde Abiodun, a veritable workhorse who really really works his students. This contrasts with my actual supervisor Bruce Hewitson, who lets students design their own work program. While I like deadlines, it is going to interesting to balance the two.

My first conflict of interest is my chapter 1 structure. I have been diligently working away at a outline designed last week only to have it changed this morning into a more philosophical introduction into the topic.

If I can balance the two styles I think I will end up with a very comprehensive thesis. Here is to hoping.

Tuesday, January 27, 2009

Thesis advice

I had a meeting the other night with one of the new lecturers in EGS. He comes to UCT from the USA and seems to work days, nights and weekends. Our meeting started at 9pm (night owl that I am). I went over my last couple of months and where I see myself heading this year. I was offered some interesting advice.

Plan your thesis so that it fits into two or three papers plan what you want to present in the papers and then your research has a focus, a streamlined idea. Plan the figures you would want in a paper, no more than ten that summarise of highlight something you wish to discuss. Anything more you probably would just add to your thesis and never explain properly in the flow of text.

Think about the type of journal you are aiming for, is it a review of the literature available? Most journals want to print new work so if you want to discuss old work you have to include suggestions of new areas open to this type of technology or how the literature has lead to the experiments you're working on.

Do not go into a doctorate working for three papers and not a thesis. A thesis is a valuable tool to present a body of work as it developed. UCT has a newish option open for doctorate students, doctorate by papers. Your thesis is them a collection of three papers published and an introduction and conclusion to link them all together. The nice option is that if the papers are already published, the examiners cannot fail you, your work is already peer reviewed for every paper and they are more making constructive comments.

Plan your timetable to produce at least two papers by the middle of your second year, and a third by the end of the second year. This way you have time to write up your thesis and get published before you head off to post-doc and don't have time anymore.

Just some food for thought, use, don't use.