Lunch with Dr. Raul Andino

CIDD grads and post-docs!

Join Dr. Raul Andino for lunch immediately following his CIDD seminar this week. Please RSVP no later than Wednesday at 5pm with your food preferences below so that we can plan accordingly. See you there!

When: Thursday, October 1st, 2015 12 – 1 pm

Where: W-203 Millennium Science Complex

Posted in News | Leave a comment

A quick overview of GIS with R

Spatial data are pervasive in ecology, especially for wild systems. In the past, ecological analyses that hinged on space were usually performed in ArcGIS. A LOT of species distribution modeling and habitat modeling utilized Arc functionality, thanks in great part to Hawth’s tools and other toolkits expressly aimed at ecological questions.

As it turns out, though, Arc is both expensive (at least relative to my grad student income), and limited in statistical capacity. Each generation of ecological models incorporates more mechanism, more heterogeneity, and hence more complexity. Dealing with those complexities in Arc is, frankly, painful. Besides, we’re all using R anyway… why can’t we just deal with spatially referenced data there?

As far as I can tell, ecologists rely on Arc for three basic tasks:

  • Specifying / aligning geographic metadata, and reprojecting layers
  • “Drilling down” to integrate data from multiple layers
  • Spatial data visualization.

In this post, I’ll go through ways to accomplish each of these tasks in R. I’ll start with a little GIS background, introduce GIS in R, and then delve into each of these topics specifically. I’m a relatively novice to GIS (although not to R), so please post feedback and extensions (and criticisms, if you must)!

Introduction: What’s a GIS?

A GIS is much like any other relational data structure, except that its index variable references a point in space (and sometimes also time). People talk about GISs as being comprised of stacks of “layers”. These are essentially the same as a set of two-dimensional spreadsheets, linked by a common field that contains spatial (or spatiotemporal) information. 

Metadata is really, REALLY important for GIS, because “spatial locations” can be specified in many different ways. In order to properly align different layers, the user has to know the projection (remember those map projections we learned about in middle school geography?) and coordinate reference system (CRS) associated with each layer, and be sure that they match across all layers. If the projection and CRS do not match from layer to layer, some layers will need to be reprojected.

  • Projections describe the way in which the (spherical) world gets projected onto a (planar) map. Projections from spheres to planes always contain distortions, but you can choose the projection to minimize distortion for attributes of the map that you care about (e.g., area, orientation, shape, etc.).
  • Coordinate reference systems (CRSs) are different ways of writing down spatial locations. The best-known is probably Longitude/Latitude; in ecology Universal Transverse Mecrator (UTM) coordinates also get used a lot. Coordinate reference systems are cataloged in the EPSG registry, where every CRS is assigned a unique identifier.

GIS information is stored in two broad file classes: vectors (continuous in space; categorical in variable value) and rasters (categorical in space, continuous in variable value). The contents of vector files can be further compartmentalized into points, lines, and polygons. Since the preponderance of my own experience is with vectorized data, I’ll focus primarily on vectors here.

There several kinds of GIS storage objects. The two I know best are shapefiles and KML files.

  • Shapefiles are the brainchild of ESRI, ArcGIS’s parent company. They are actually batches of files that include different pieces of information pertaining to a given layer. Each piece has its own extension. These include .shp, .dbf, .proj, and others. To get all the projection, coordinate references, and attached data, whatever programming you’re using needs to access ALL these files in tandem, not just the .shp file.
  • KML files were developed for use with google Earth. They are a geographic extension of XML, which is a broadly used datastructure that organizes information on the web. I won’t go into KML files in depth, but you can access them using the getKMLcoordinates() function in the maptools package.

Spatial data in  R


R currently has a bazillion spatial packages — for a nice summary of all the functionality that’s already out there, check out CRAN’s Spatial Task View. Looks to me like the work-horse packages that underlie most of the gadgets-and-gizmos spat-temp utility are:

  • rgdal —— brings GDAL/OGR functionality to R
  • spatial —- defines key spatial object classes
  • sp ——— transformation and drilling functionality
  • maptools – gets a lot of use, especially readShapePoly (but see my comments on that below)
  • rgeos —- interface engine connecting R with GEOS, a C API with lots of nice topological functionality


Probably the most broadly-used class used spatial information in R is through the SpatialPointsDataFrame (“SPDF”) class implemented in sp. SPDFs are S4 objects (with a few S3 functionalities). They are very similar to the vanilla dataframes that we all know and love, except that they have a bunch of leading slots for projection and coordinate reference system information.

Specifying geographic metadata, and reprojecting layers

If you’re reading ESRI (e.g., ArcGIS) shapefiles into R, use the readOGR function in the rgdal package. Maptools can also read shapefiles with its readShapePoly (and similar) functions, but those functions don’t being projection information along, they just read the .shp file. Here’s an example of how to read in a shapefile with readOGR.

MyShp <- readOGR(dsn = "<Path to files>",  # Path to all derivates
                 layer = "<Layer name>")   # Name until ".shp"

We can check the projection of MyShp by using the proj4string() function in sp:


To convert a standard data frame (like you’d read in with read.csv) to a SPDF, all you have to do is specify what fields contain coordinates (using the coordinates function in sp). Note that ORDER MATTERS to coordinates(). You must specify the data as Longitude + Latitude (not Lat + Long).

MyData <- read.csv("<Path to files>", header = T)
# if coordinates are in MyData$Longitude and MyData$Latitude:
coordinates(MyData) <- ~Longitude + Latitude

By using the coordinates() function, the MyData object will be updated to an SPDF. It will retain all its original information, which will now be in its Data slot (accessed through calling MyData@data).  To specify the projection of MyData, use the proj4string() and CRS() functions from sp.  I’ve stuck strings specifying EPSGs for lat-long and google projections into named objects that I then pass along to CRS().

# EPSGs for some commonly-used projections
googleproj <- "+init=epsg:3857"
latlong <- "+init=epsg:4326"

proj4string(MyData) <- CRS(latlong)

SPDFs can be easily reprojected to a different CRS using the spTransform function in sp. Here’s how we’d reproject MyData to be on the google coordinate system: <- spTransform(MyData, CRS(googleproj)) 

“Drilling down” to integrate data from multiple layers

The over() (or %over% if you’re into binary) function in sp aligns two layers and extracts the values from one layer that occur at the spatial locations referenced in the other. For example, if I had a set of points living in a SpatialPointsDataFrame and a set of polygons in a SpatialPolygonsDataFrame, I could use %over% to get the polygon-level values corresponding to each point.

MyShpPoints <- readOGR(dsn = "<Path to points>",
                          layer = "<Pt layer name>)
MyShpPolys <- readOGR(dsn = "<Path to polys>",
                         layer = "<Poly layer name>)

# get values form the "Name" field in MyShpPolys
# corresponding to the location of each point in MyShpPoints
PtPolyNames <- (MyShpPoints %over% MyShpPolys)$Name

We can get the area of polygon overlap for two polygons (like you might need for calculating homerange overlap for two animals, for example) by using the gIntersection() function in the rgeos package. For two polygons in the same SPDF, this might look like this:

MyShpPolys <- readOGR(dsn = "<Path to polys>",
                         layer = "<Poly layer name >)
# Extract geometries of the two focal polygons
Poly1 <- MyShpPolys$Polygons[[1]] # gets 1st polygon from MyShpPolys
Poly2 <- MyShpPolys$Polygons[[2]] # gets 2nd polygon from MyShpPolys
Poly1Poly2Overlap <- gIntersection(Poly1, Poly2, byid = F)

Spatial data visualization

I recommend using map tiles to underlay maps in R.  MapTiles are 256×256 pixel images that sit under Javascript map interaction platforms (think: google maps or nytimes-like graphics). The RgoogleMaps package facilitates importing these files into R for graphical use with its GetMap() function.  To bring a map tile into R in, first go to google maps in a web browser and navigate to where you want to be. Right-click on your desired location, and select “What’s here?” in the dropdown menu. A pop-up window will open, displaying the decimal-degree lat/long for the location. This will be the center of the map tile you import.  PlotOnStaticMap() displays the tile in an R graphical device.


# these coordinates point to a field site near Hells Canyon, WA.
centerIn <- c(46.264, -117.320)

# specify magnification (I do this with guess-and-check)
googleZoom <- 11

# specify map type (terrain, roadmap, satellite, etc.)
googleMaptype <- "terrain" <- GetMap(center = centerIn,
                       zoom = googleZoom, 
                       maptype = googleMaptype)

# to view the map:

Static maps

In order to overlap your own spatial data onto this map, first reproject the data so that it matches the tile with RgoogleMaps’ LatLon2XY.centered() function. Then, add the reprojected data to the maptile with standard plotting functions like points():

# Check that MyShpPts is in Lat/Lon and reproject if necessary

MyShpPtsGoogle <- LatLon2XY.centered(, # tile name
                                           zoom = googleZoom)

       pch = 16, cex = 0.8)

Dynamic / Interactive maps

RStudio recently released an R extension of leaflets, the javascript library used to make webmaps like those used by the New York Times and Leaflets provides researchers a means of directly interacting with their map (perhaps the best feature of Arc).  I won’t parse RStudio’s excellent documentation of their leaflets utilities here, but I highly recommend checking it out.

Some useful links and packages

There are lots of starter sheets for people working at the R/GIS interface. Here are a few I found particularly useful.

Quick basics from Lancaster

NCEAS: Coordinate Reference Systems

A few other packages that may be useful to ecologists:

adehabitatHR (for homerange estimation)

adehabitatLT (for animal movement analysis)

geosphere (for buffering and hard spherical geometry problems)

Posted in News | Leave a comment

CGSA Night at the Spikes

Come enjoy some local baseball with us Thursday at 7 PM.  We’ll meet just inside the stadium entrance.  Feel free to bring friends, family, and/or significant others.

Tickets are available for free through the HUB – see here.

Posted in News | Leave a comment

Why aren’t there more women in ecological computing?

In case you somehow missed this, we’re living in an information era. For most scientists, this means that an ever-growing component of our jobs is to access and synthesize information. The old naturalist skills that drove ecology in the past are being replaced, in many cases whole-sale, with information technology acumen.

Despite the importance of IT in modern ecological research, computational skills in the ecological community remain pretty gender-imbalanced. As a computationally savvy(ish) female scientist, this worries me. My personal experience is that computational skills take work to acquire, and in the end they are based more on effort than talent or intuition. Ecologists, and particularly ecological women, need to develop and communicate these skills if we want to hold on to our federal support. At the moment, we’re operating under digital silence. In this post, I’ll

  • Look at the numbers on female participation in ecological computing
  • Think about what these numbers mean
  • Suggest some steps to improve ecologists’ computational skills
  • The intent of this post is NOT to criticize the computational community, and particularly the R project, whose community is very actively trying to improve female participation. It is also not intended as a criticism of Penn State, whose biology program has given me a huge amount of flexibility to pursue my graduate work. Instead, I hope that this post will inspire smart women to recognize one another, and enter and participate in the computational domain in a more visible way.

    A few numbers on women in ecological computing

    1. Female participation in R / Open Source

    The vast majority of academic ecologists now use the statistical computing environment R ( R is an open source/open access project, driven by a board of directors. R packages are contributed from the broader scientific community, and adopted for hosting at the Comprehensive R Archive Network (“CRAN”). While the gender representation of PhD recipients in the scientific fields that interact most heavily with R is increasingly better balanced (~46% of PhDs awarded to women in statistics in the last decade; ~ 50% of science PhDs awarded to women), female contribution to R remains low.

    I checked the packages listed on the CRAN environmetrics task view. Of the 107 packages listed, five were maintained by authors with clearly female names, whereas 94 had maintainers with clearly male monickers (maintainers of the remaining 8 packages had names that could not be readily classified using the gender package in R). In short,

      5% of the ecology/environment packages hosted on CRAN are maintained by people with clearly female names.

    There are currently 24 men and no women on the R Core Development Team (which is an elected body). Of the 58 other folks that the R project recognizes as major contributors to R, only one has a clearly female first name.

    The dearth of women in computational ecology reflects the general absence of female participation in scientific computing. Although it’s notoriously difficult to measure, female Linux usership likely remains at less than 5%. StackOverflow, R-help and other web forums for computing assistance see very little female participation, even among individuals posing questions. Women in ecology are confronted with the same challenging computational community that women encounter across the computational board. While there are some signs of progress (for example, r-help doesn’t seem to be getting meaner), a lot of work remains.

    2. Female participation and recognition on github

    Additionally, female participation on the code management site github remains incredibly low.

      Less than 3% of code repositories with 5 or more stars map to owners with clearly female names (see Alyssa Frazee’s analysis here).

    The low rates hold across a whole bunch of programming languages. And don’t be fooled: R looks better than most because the gender classified Frazee used classes “Hadley” as female.

    3. Female participation in the ecological literature

    The trend toward female underparticipation holds in the ecological literature as well. 28% of the authors on 500 randomly chosen publications in Ecology Letters have clearly female first names (as opposed to 71% with clearly male names). This drops to 25-26% in the journals Ecological Modelling, and Journal of Theoretical Biology (however, name misclassification rates here are high: 18.8% of names not classified in Ecology Letters; 42.0% in Ecological Modelling, 39.5% in JTB).

    What to make of this?

    First, these numbers are in no way perfect. The participation rates presented here hinge on first name as a true signal of an individual’s gender. Gender associations with a given name are probabilistic, and certainly there may be some error in gender classification of each name. Generally, women in science are aware of gendered stereotypes, and may use gender-ambiguous monickers, or forego names for initials. Lastly, the distribution of number of packages per maintainer is somewhat overdispersed, and maintainers with more then four packages on the environmetrics list all have male names.

    Even with these caveats, I think these data convey a real, emerging problem for the ecological community. Even though many women participate in graduate-level ecology, relatively few participate in the computational realm. Increasingly, that’s the area where the money is. We need to make some changes, or women are likely to be left out.

    These numbers don’t tell the whole story, though. There are some women who are doing amazing things in the computational domain, whose work is often overlooked. Karline Soetaert, for example, is the author of the deSolve package in R, a workhorse package that gets used all over the place. The University of Washington is home to several prominent female R developers, including Daniela Witten and Hana Sevcikova. We may see a generational shift (someday) to a more gender-inclusive computing environment…

    … but that day hasn’t arrived just yet. I think these steps would help get ecological women (and all entry-level users) assimilated into the broader computational community.

    1. A clear statement of computational expectations for ecologists.

    In my experience, grad students really like checking things off lists. If they’re given a list of required competencies, they’ll achieve them. The problem with computation is that people don’t know what skills they should be working to attain. Here’s one example of such a list for ecology grad students:

    – basic knowledge of file directory structure on your own operating system
    – ability to launch a terminal and navigate in it
    – basic knowledge of SQL (set up a database; run a query)
    – ability to fit basic statistical models (ANOVA, linear models)
    – ability to simulate simple datasets
    – basic plotting in R (with overachievers picking up gnuplot or javascript)

    In my mind, these are NOT statistical competencies. There is a TON of material that has to get covered in statistical courses for ecologists. Computational skill belongs elsewhere in the ecological curriculum (if for no other reason than that, just like ecologists, many statisticians lack the training to effectively outfit students with these skills).

    2. Local contact and community

    User groups and forums, computing “corners” where people can work together, and formal code mentoring are all enormously helpful in getting smart new users up to speed computationally. These forums exist at many institutions, but my impression is that they tend to be chronically underutilized. Graduate programs should encourage participation in these forums. A competency list might foster participating.

    3. Inclusion of computing in the general ecology curriculum.

    I wish more graduate programs would incorporate a one-credit, one-hour-a-week-for-one-semester course for all ecology graduate students that taugh basic computing, got students started with R (and maybe also Python, javascript, etc.), and set them up computationally to conduct their own research.

    This post builds on a talk for the Montana State University Department of Statistics, given in April of 2015.

    Posted in News | Leave a comment

    Lunch with Dr. Ian Lipkin

    Please join us for lunch with Dr. Ian Lipkin (Columbia) immediately following his CIDD seminar. RSVP using the poll below- hope to see you there!

    When: Thursday, May 7th, 2015 12:00pm – 1:00pm

    Where: W-201 Millennium Science Complex

    Posted in News | Leave a comment

    Lunch with Dr. Paul Turner

    Join us for lunch with Dr. Paul Turner (Yale University) immediately following his CIDD seminar. RSVP using the poll below so that we can order enough food!

    When: Thursday, April 23rd, 2015 12:00-1:00pm

    Where: W-201 Millennium Science Complex

    Posted in Speaker Lunches | Leave a comment

    A few steps toward cleaner, better-organized code

    This post follows from a discussion with my Bozeman lab on code management (see my very ugly slides with more details, especially on using git and github through Rstudio, here).

    Developing good coding habits takes a little time and thought, but the pay-off potential is high for (at least) these three reasons.

    • Well-maintained code is usually more reproducible than poorly-maintained code.
    • Clean code is often easier to run on a cluster than poorly-maintained code (for example, it’s easier to ship clean simulations and analyses away to a “big” computer, and save computing time on your local machine).
    • It’s likely that code, as well as data, will soon be a required component of publication, and we might as well be ready.

    Since biologists and ecologists receive limited code management training, many grad students are unaware of established code and project management tools, and wind up reinventing the wheel. In this post, I go through a few simple steps to improve code management and keep analyses organized. Most of my examples pertain to R, since that’s my language of choice, but these same principles can be applied to most languages. Here’s my list, with more details on each element (and strategies for implementing them) below.

    1. Find a style guide you like, and use it
    2. Use a consistent filing system for all projects
    3. Functionalize and annotate analyses
    4. Use an integrated development environment like RStudio
    5. Use version control software like git, SVN, or Hg and incorporate github or bitbucket into your workflow

    Like much of science, programming benefits for a little sunlight. If you’re serious about improving your code, get someone else to look at it and give you feedback (in fact, for R users, I can probably be that person — shoot me an email)!

    1. Find a style guide you like, and use it

    Most programming languages (R, Python, C++, etc.) have a particular set of conventions dictating code appearance. These conventions are documented in style guides, like this one for R. The point of a style guide is to keep code readable, and there’s solid research sitting behind most of the advice. In my opinion, these are the two most important stylistic suggestions for R:

    • Spacing: put a space around all binary operators (=, +, <-, -), and after all commas
    • Line breaks: break lines at 80 characters (you can set RStudio to display a vertical reminder line under Tools -> Global Options -> select Code Editing on the left, and then set “Show margins” to 80).

    Following the suggested indentation specs is also a good idea, especially if you work (or plan to eventually work) in Python or other languages in which indentation and spacing are interpreted pieces of the code syntax.

    2. Use a consistent filing system for all projects

    Because of the ebbs and flows of data collection, teaching, and travel, it’s not unusual for scientists to juggle five to ten different projects simultaneously. One way to overcome the resulting chaos is to keep a consistent directory structure for all projects.

    I keep every project (for me, “project” is usually synonymous with “manuscript”) in a folder named Research.  The Research folder has subdirectories (a.k.a. subfolders) for each project, and the folders are named to reflect their topics. Inside each project folder, I have exactly the same set of folders. These are

    • Data —————— contains all datasets associated with this project
    • Code —————— contains all code files required for this project
    • Documentation — contains manuscript drafts, notes, presentations associated with this project
    • Figures ————— contains all project figures

    Collaborative projects (reviews, analyses with multiple analysts, or projects where I’m working as a consultant) have an additional “Communications” folder. I often use subdirectories within these folders, but their composition varies.

    3. Functionalize and annotate analyses

    Code for data analysis generally does one of the following: loads data, cleans data, generates functionality (reads in source functions), and runs analysis. Some programmers advocate having a separate script allocated specifically to each of these processes (I found these suggestions, and particularly this embedded link, very useful). I haven’t fully integrated this idea into my workflow yet, but I like it.

    Functions are like little machines that take a set of inputs (or “arguments”), do some stuff based on those inputs, and return a set of outputs (or “values”).

    There are at least two good reasons to functionalize. First, it facilitates error checking, and second, it improves code readability. My very basic rule of thumb is that if it takes me more than about five lines of code to get from inputs to outputs, it’s probably worth functionalizing.

    Here’s an example of a function in R:

    MyFunction <- function(, input.out) {
      # this function returns a vector of integers from 
      # "" to "input.out".
      # Args
      # = first integer in sequence
      # input.out = last integer in sequence
      # Returns
      # k = vector of integers from to input.out
      k <- seq(from =, to = input.out)

    I strongly recommend using a header structure like I’ve used here, that specifically lists function purpose, arguments, and returns. It’s a good policy to save each function in its own file (I give those files the same name as the function they contain, so the file containing this function would be named MyFunction.R). To load the function into a different file, use R’s source command.

    # head of new file.
    # source in all necessary functions (including MyFunction) first
    my.function.test <- MyFunction( = 2, input.out = 7)


    Good code designers plan their code structure ahead of time (e.g., I want this big output; to get it, I will need to work through these five subprocesses; each subprocess gets its own function, and a wrapper function integrates them all into a single entity that I will eventually call in one line).

    In my experience, this is often not how biologists write code. Instead, we often write our analyses (simulations or samplers or whatever) in giant, free-flowing scripts. To get from that programming style to functionalized code, I recommend breaking code into functions after-the-fact in a few existing projects. Doing this a few times helped me learn to identify relevant subroutines at the project’s outset and write in functions from the beginning. Here are a couple examples of relatively common disease ecology programming tasks, with off-the-cuff suggestions about reasonable subroutines.

    Example 1: Simulating a discrete-time, individual-based SIR process
    I know from the beginning that I’ll likely want “Births” and “Deaths” functions, a “GetInfected” function that moves individuals from S to I, and a “Recover” function that moves individuals from I to R (e.g., a function for each major demographic process). If each process gets its own function, I know exactly where to go to incorporate additional complexity (like density dependence, pulsed births, age-specific demographic and disease processes, etc.). I wrap all these functions in a single function that calls each subroutine in sequence.

    Example 2: Writing an MCMC sampler
    Usually I know from the beginning what parameters I’m estimating, and I should have a clear plan about how to step through the algorithm (e.g., which updates are Gibbs, which are Metropolis, which control a reversible jump, etc.). In this case, I’d use a separate function to update each element (or block of elements) in the parameter vector. This gives me the flexibility to change some aspect of one update without having to dig through the whole sampler and risk messing up some other piece. Again, I’d use a wrapper to link all the subroutines into one entity.

    My rule of thumb is to annotate everything that I can’t quickly regenerate from basic logic. One of the reasons I’ve pushed toward more functionalized code (and git/github) is because it tightens my annotation process: even if all I do is write an appropriate header for the function, my code is already easier to follow than it was in a single giant script.

    4. Use an integrated development environment like RStudio

    At our roots most of us are scientists, not programmers or developers, and as such we need to keep up with what’s going on in science, not software development. The Open Science movement has invested a lot of effort in helping scientists incorporage modern computational workflows into research. One example project that tries to do this is RStudio. RStudio is an integrated development environment (“IDE”) set up for scientists and analysts. It integrates an R language compiler with LaTeX (a document generating program commonly used in math, computer science, and physics) and git (one flavor of version control software). Because of these integrations, I highly recommend that scientists using R use it through RStudio (this from someone who used the R-GUI for two years and vim-r-plugin for another two). In my mind, the integration is what makes RStudio worthwhile, even for Mac users whose R-GUI isn’t quite so bad.

    5. Use version control software like git, SVN, or Hg and incorporate github or bitbucket into your workflow

    Version control software solves the problem of ending all your code files in “_today’s_date”. These tools keep track of changes you make, and allow you to annotate precisely what you’re doing. Importantly, they also let you dig discarded code chunks out of the trash.

    Several flavors of version control software are now integrated with online platforms. This allows for easy code sharing and cloud backup (and code publication). One platform, github (and regular git run locally), integrates directly with RStudio; another, bitbucket, has unlimited free repositories. Students also have access to five free repos on github — go to and request the student pack; in my experience, it helps to send them a reminder email a few weeks after your first request. An aside: women (or, users with female first names) are crazily under-represented on github. Growing the female online programming community is important for science, and good for your code to boot!

    Some of these steps are easier to implement than others. I recommend establishing some protocols for yourself, applying these protocols to new projects, and gradually moving old projects into compliance as needed.

    In my experience, adopting some parts of the style conventions (especially those pertaining to spacing and characters-per-line) were easy; others were harder. Start with the low-hanging fruit — any improvement is better than none!

    I don’t know many people (and especially not many scientists) who are particularly proud of how their code looks, but having people look at your code can be incredibly instructive. Find a buddy and work together, if you can.

    Finally, a few small changes can make a big difference, not only in the reproducibility of your science, but also in your confidence as a programmer. People do ask biologists and ecologists for code samples in the job application process, and a little finesse goes a long way!

    Posted in News | 4 Comments

    Creepy, crawly, crunchy: Can insects feed the future?

    As CIDD graduate students, we think about insects as vectors of disease, but we don’t always consider other important attributes of insects: like how tasty they might be. Many insects are edible and considering their use as a novel livestock may help combat problems in obtaining global food security.

    Why should we worry about food insecurity? We live on a hungry planet. The Food and Agriculture Organization of the United Nations (FAO) estimates that 805 million people are chronically undernourished. Projections of food requirements and population growth suggest that we would need to increase current global food production by 70 percent to keep up with demands for human food by 2050. We could also shift paradigms in food production to incorporate novel sources of food. Are insects the livestock of the future?

    On Tuesday, April 21 a panel discussion will be held to discuss the merits of using insects as nontraditional livestock to help feed our globe. Let’s eat more bugs. The discussion will be focused on using insects as a human food source, with particular focus on the barriers to insect-rearing, and insect-eating or “entomophagy”, in the developed and developing world.

    The panelists are Robert (Bob) Anderson, founder of Sustainable Strategies LLC and advisor to the U.S. Department of Agriculture, Dr. Florence Dunkel, an associate professor in the College of Agriculture at Montana State University, Dr. Dorothy Blair, a former assistant professor of Nutrition at Penn State, and Dr. Alyssa Chilton, a Penn State staff sensory scientist in the Department of Food Science. Florence has an interesting TEDx talk which can be found here.

    Tuesday, April 21, 2015

    12 – 1:30 p.m.

    Foster Auditorium

    Paterno Library

    Posted in News | Leave a comment

    Opportunity to meet with Florence Dunkel, April 20 @ 11:00 a.m.

    All graduate students (CIDD, biology, entomology, INTAD) are welcome to meet with Florence Dunkel on Monday, April 20 at 11:00 a.m. Location TBA. Please RSVP to Jo at if you would like to attend.


    Posted in News | Leave a comment

    Nita Bharti seminar

    Nita BhartiDon’t forget that CIDD’s Nita Bharti will being giving a talk tomorrow:

    • The role of movement in the spread and control of disease
    • March 17, 4-5pm
    • 8 Mueller Lab
    Posted in News | Leave a comment