(4) Methods

##Compute Resources

Ansible was used to control active virtual machines while Docker was used for software distribution. Data is stored on a single Chameleon instance: TeamArizona(TrentaXL), 160GB. The data is also stored off-site at the UA, in Pejmon Hodaee’s IT office, on an iMac.

Because the Mosquito Landscape Simulation program for predicting mosquito abundance was written in Matlab, we were limited to compute resources for that stage of the process that could support Matlab. Matlab runtime was utilized via Docker containers run within instances on Chameleon Cloud. Though initiating Chameleon instances via Ansible proved difficult, it was possible to launch a specified number of identical instances from a snapshot of a specifically configured instance (m1.medium, VCPUs 2, Root Disk 40 GB, RAM 4 GB), and then control the active instances with Ansible. No matter the amount of workers per instance, each instance processed one CSV file at an inconsistent rate of 0.8-1.4 per hour, this resulted even with system that even contained 44 vCPUs.

It is important to note for the collection phase, not to over-utilize workers in parallelizing data collection as too many requests on the data host could result in an unintentional Denial-of-service attack.

##Masking

The National Land Cover Database 2011 (NLCD 2011) identifies land cover areas at a scale of .003 degree difference (120 meter square). First, a grid of 4km x 4km was overlaid on top of the state of interest (Arizona) and clipped in QGIS using a shapefile of the state’s boundary (obtained from https://www.census.gov/geo/maps-data/data/tiger-cart-boundary.html). This ensured that the grid was bounded by the state’s boundary. The center of each 4km x 4km square was taken and added to a list of latitude and longitude pairs for the state. Lists of these coordinates are provided for every state on the team’s github (DataCollection/IDs/).

The masking process is highly malleable, as the masking values can be changed as well as the heuristic associated with the process. Over each coordinate of interest, a small region was queried of ~1000ft by ~1000ft. This query area can be expanded to fit the full 4km x 4km grid that the climate data has, or scaled to meet the gridsize of any weather dataset. Within this query range, the number of spots matching the mask values of interest were counted, and if it exceeded a threshold, which was chosen to be 30%, the 4km x 4km section would then be considered to represent a developed area.

Our goal was to mask out areas that are considered “non-developed” areas of the state, as Aedes aegypti (the mosquito species of interest) is not likely to be found in such regions. Latitude and longitude pairs that fall in developed areas were selected using the NLCD data. Coordinates that were classified as being 30% “developed” were identified (land cover areas 21, 22, 23, and 24: Developed, Open Space; Developed, Low Intensity; Developed, Medium Intensity; and Developed, High Intensity as defined by MRLC.gov - http://www.mrlc.gov/nlcd11_leg.php). The 21-24 series of land cover areas possess a combination of factors, namely a concentration of humans, contributing to mosquito-human disease spread (particularly for Ae. aegypti). The program /DataCollection/maskData.py produced a series of coordinate points that were input into /DataCollection/createMakeflow.py and then passed to /DataCollection/MakeRequests.py to collect only the data within these masked areas. For Arizona, this was approximately 3% of the state.

##Data Collection

After evaluating environmental data sources, data from Northwest Knowledge Network: Multivariate Adaptive Constructed Analog (MACA) Method data (http://climate.nkn.uidaho.edu/MACA/data_csv.php ) was selected because it provided an accessible data format for data processing as well as the fastest download speed of the methods we encountered; an important factor given the expected volume and our time constraints.

There were three desired dataset types to download: historical climate data (01/01/1950 - 12/31/2005), and two different future prediction datasets (01/01/2006 - 12/31/2099). The future prediction data can predict data for different possible scenarios or Representative Concentration Pathways (RCPs). RCP 4.5 is a moderate climate change scenario (Clarke et al 2007, Smith & Wigley 2006, Wise et al 2009) while RCP 8.5 is a “worst-case scenario” (Riahi 2007). Data collection was accomplished using a python script (/DataCollection/MakeRequests.py) to download 3 CSV files (historical data, future RCP 4.5 data, and future RCP 8.5 data) for each developed latitude and longitude point.

Collection was parallelized using makeflow and workqueue on a single instance of Chameleon. A makeflow file was generated using the script /DataCollection/createMakeflow.py. The worker makes a request for the csv, checks to see if it is a csv format and the correct length, and then calls another script (/DataCollection/DataProcessing.py) to properly format the csv for input into the mosquito abundance model. When all workers successfully downloaded all the data for the points of interest, the script /DataCollection/mergeCsvs.py was used to create a csv with a complete time series from 1950 to 2099 to run through the mosquito abundance model.

##Data Processing

Mosquito abundance for mosquito species Ae. aegypti was calculated using Mosquito Landscape Simulation (MoLS - https://github.com/JocelineLega/MoLS) provided by Joceline Lega. MoLS, a Matlab program accessed via Python, calculates Ae. aegypti abundance in a given location, using inputs of time, temperature, precipitation, and relative humidity. Data from RCP 4.5, RCP 8.5, and the historical climate data were to be processed through MoLS and then reformatted for visualization.

Our method was to distribute the task with Makeflow, with workers running from inside of containers to provide a consistent computational environment. The most challenging part of this method is making sure that running containers are distinct from each other. Given the resources we had available on Chameleon and Jetstream combined, we should have had several hundred vCPUs to run computations on. If each vCPU represented a running worker, the computations would have scaled nicely and the points would all have been complete. However there seemed to be a large issue with simultaneous runs of the model on a single instance, meaning that we saw very similar performance from drastically different vCPU configurations, with respect to tasks completed per hour per instance.

This meant that our limitation appeared to be running instances, and not the number of virtual cores available for running. With Chameleon’s limit of 50 instances and Jetstream’s limit of 25, this was not enough to be able to run through the several thousand hours of computation.

##Data Visualization

The clients’ original “ideal” was an interactive interface in which they could select state, land coverage types, manipulate variables for future predictive climate data and mosquito abundance, and vary between daily, weekly, or monthly time scales, alongside time-series animations. We accomplished making videos to illustrate mosquito abundance over time for a given state (AZ and FL in this case), and provided tools to make this possible in other states. We were also successful in illustrating two future climate model-based mosquito predictions, using RCP 4.5 and 8.5 situations. The final product displays monthly averages as a “proof of concept” of the capabilities of the system and can be modified to display other timescales.

We assessed the following visualization tools: QGIS and its plugins for Time Manager, web2GIS, QGIS Cloud, geonode.org and using gdal.org and postgis.net as an interoperative technology stack with OpenLayers. We took the CSV files from the data collection step, processed them with Python scripts, and imported the data as a delimited text layer in QGIS. To optimize the final product given our resources (including time restraints), we decided to stick with the QGIS Time Manager plugin to produce .png files for each month and render images that were stitched together to create a video.

We approached the client with our concerns and first received a ranked list of features and later a description of a minimum viable product: "In my view, if your team can provide a nice-looking animation of historical mosquito abundance and future predictions for a couple of climate models, you will have a product that is ready to be posted on a web page and that can be used to illustrate the effects of climate change. I think the goal of having something to show, even if as (technologically) simple as a video, is a very good first step." (Heidi Brown, personal communication 12/9/2016).

Based on this communication from the client, the final visualization method was using the QGIS Time Manager plugin to render animations of mosquito abundance for both RCP 4.5 and RCP 8.5 scenarios. Monthly averages of mosquito abundance for the 150 years was calculated and added as a delimited text layer in QGIS desktop. The Time Manager plugin exported monthly PNG images and these frames were stitched together using ffmpeg to make a video visualizing mosquito abundance in Arizona.

With the prioritized list of requirements we received from our clients in mind, we researched different methods using QGIS Cloud, QGIS Desktop plug-ins and Geonode to create a web-based interactive interface. We found that with each method we researched, there were issues with the flexibility. For flexibility purposes, writing our own graphical user interface with HTML and JavaScript would be ideal for the user. Using OpenLayers to provide a basemap and adding our layers on top of it would allow the user to interact with the map, display other data types, and potentially visualize the change of a data type over time using a time lapse.