Biodiversity insurance hypothesis in the real world

This year is being great and we have another great publication in Ecology Letters. We use long-term plant and pollinator data to show that high levels of biodiversity ensure plant pollinator matching over time despite climate change.

The story behind the paper starts 2 years ago (yes, it always take time!) when we did a paper showing that in general, plants and bees are advancing its phenology due to climate change at similar rates. The problem of this general patterns is that we don’t present data on any particular case study to show how this “general pattern” translates to a given system. My idea was doing a small follow-up using apple orchards as a case study. I ran the first analysis and saw that indeed, apple flowering and bee pollinators are advancing at similar rates. Cool, We can now provide a case study that validates the pattern observed! But then I went further and tried to see what happens when the main apple pollinators are analyzed one by one. Here the things got interesting because some bee species DO show a phenological mismatch with apple, but the total synchrony is stable at the community level because the effects of individual species cancel out. When I showed the results to Rachael, she immediately related them to the biodiversity insurance hypothesis, and we start working on validating this idea. That meant looking for more data, including a simulation, and a lot of fun reading the biodiversity ecosystem function literature. Is amazing how much of what we know relating biodiversity and ecosystem functioning is based on experiments in grasslands, so applying those concepts to real world trophic interactions was intellectually very stimulating. I like a lot the final paper and I am looking forward to work more on this topic, hopefully with less complex data.

Advertisements

Software carpentry

I would never call myself a programmer, but as an ecologists I manage moderately big and complicated datasets, and that require to interact with my computer to get the most of them. I self-taught most of the things I need to do and more or less I succeeded on managing my data (MySQL), write simple functions to analyze it (R) or use other people functions (written in Matlab or java for which I have no knowledge at all). That’s nothing fancy. I don’t create software or develop complex simulations. But I still need to communicate with my Mac. Knowing some basic programming is for me the difference between painful weeks of pain and tears vs. a couple of hours performing an easy task. That’s why I sign up for a software carpentry boot camp.

What I learnt?

– The Shell: I rarely interact with the shell, but I had to do it in three occasions in the past. It was always a guesswork. What I needed to do is simply copy and paste some code I find in the internet to run a script written by other scientist tweaked for my data. The tweaking part was usually ok as the specific task I performed came with some help from the authors, but opening the shell and figure out where to start calling the program, or how the path structure works, and all this minor stuff was a shot in the dark. Now i learned some of this basics (pwd ls cd mkdir cp mv cat sort | ) and while I will probably not use them much, next time I need to open the terminal (to run pandoc maybe?) I will know how to start. A cool thing is that you can easily run R scripts*:

Rscript file.R input.txt

or shell scrips:

bash file.sh

* the R script can load the input using:

### Read in command line arguments
args <- commandArgs(trailingOnly = TRUE)
### Read in data from file set in the command line
data <- read.table(args[1],sep=",")

– Regular expressions: I also used regular expressions a couple of times before, but is not in my everyday toolbox. Seeing some examples on how they can be used was a good reminder that I am still doing some tasks in a suboptimal way. (go to www.regexpal.com to play with them) I liked the:

alias grep="grep --color=auto"

to put some color in my terminal by default.

– Git: I am using Git (well, trying to, at least) since a year ago or so. Git is not a hipster caprice, but a solid and tested system to keep track of what you do. However, it can be a bit complicated at the beginning. I was using a GUI so far, but in SWC they show me how to set up a folder and do the usual tasks from the shell. I have to say that while I like the GUI for seeing the history, is way easier to setup a new project from the command line (git init). I also understand now better the philosophy of Git, and why staging (git add) is useful to separate files in different commits (git commit), for example. I also learnt how the gitignore file works. Just list in a txt the files that shouldn’t be tracked with regexp:

*.pdf
data_*.csv

– Unit tests: My friend @vgaltes (a real software dev.) is always pushing me to adopt unit testing, but is very obscure for me on how to do that in ecology, where my code is most times is ephemeral and quick. I usually test moderately complicated functions with fake datasets constructed on the fly to see if they behave as expected. This checks that it is currently doing what you think it is but not tells you if it will always behave this way in other situations. Ethan White advice was to scale up this approach, so that I can save the fake data and run it every time I change the code to see if it still works. Those are regression tests (or vector tests) according to Titus Brown (Read his post, it makes you think). A second step I am not actually ding is Stupidity Driven Testing, (basically test for known bugs). I need to see how I adopt that but having bugs in your code is easier than it looks like, so the more safety controls you have the better. Paraphrasing Titus:

“If you’re confident your code works, you’re probably wrong. And that should worry you.” 

More important is probably learning from seeing other people coding, one of my main problems is that i don’t work closely with more experienced users that often, so i can not learn from imitation. For example, I sucks at respecting name conventions, commenting enough and simplifying complex lines in several simpler lines, but I’ll try to get better at that. Overall I feel as if I started using more complex software directly by running (sometimes in a clumsy way) and this course teach me how to walk properly. Thanks @ethanwhite and @bendmorris!

F1000 Research waves fees for ecologists

Quick post to say that if you are en ecologist you can try now F1000Research for free until the end of the year (just enter the code ECOL16 during submission). Other than the beauty of open access, open peer-review (yes, where reviewers get credit too for doing a good job), and fast publication, I like the freedom of formats offered. They are introducing a new format, “observation papers”, for sharing observations that will not be enough for a full paper, but you don’t want them to be lost forever. Tons of small datasets are wasted because there is no enough data to make a full story. I am thinking specially in master thesis, or studies with low replication. Achieving those in a common place can be a good practice. I see two reasons for doing that at F1000Research. It has a good search tool and they only publish papers if data is released, hence, this data can be used on meta-analysis, for example. The drawback is that it can be expensive for master students, but you can try for free now.

#ESA2103

This will be my second year at ESA. It is also a great chance to see the US friends I made as a PostDoc here, but also to interact with lots of new people.

I would like to do a decent preview of the talks I am looking forward to see, but last week was hectic and I only have the time to post my tentative schedule in EsaSchedule (PDF).

And of course, you should come to my talk (Thursday 02:50 PM – 03:10 PM room: L100B). I have beautiful slides, and I am talking about completely new research. If you are interested in bees, pollination, response/effect traits framework, species loss simulations or Biodiversity ecosystem function, you will like it. And please don’t hesitate to stop to say hello after the talk (or have a beer, or run by the river,…) if you feel like it.