-
Notifications
You must be signed in to change notification settings - Fork 0
/
week5.html
73 lines (50 loc) · 3.71 KB
/
week5.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
<h1>Progress</h1>
<h2>Lists</h2>
<p>The whole of the week has been rewriting the main function (and many others) so that the package can accept lists of modules. This is now done and I think the package works sensibly. Here is some examples</p>
<p>Get the package from github.</p>
<pre>[code, language=r]# install devtools
install.packages('devtools')
library('devtools')
# install and load zoon from github
install_github('zoonproject/zoon')
library('zoon')
[/code]</pre>
<p>Then to run an analysis for two species we might can use the module 'SpOcc'. This collects data from a number of ecological databases using the 'spooc' package by ROpenSci. By default it uses just GBIF which is fine for our purposes.</p>
<pre>[code, language=r]flow <- workflow(occurMod = list(
ModuleOptions('SpOcc',
species = 'Culex pipiens', extent = c(-20,20,45,65)),
ModuleOptions('SpOcc',
species = 'Anopheles plumbeus', extent = c(-20,20,45,65))
),
covarMod = 'UKAir',
procMod = 'OneHundredBackground',
modelMod = 'LogisticRegression',
outMod = 'SameTimePlaceMap')
[/code]</pre>
<p>This will give us two separate analysis, one for each species. The output modules are not particularly well set up for parallel output yet. But we can have a quick look at our output with</p>
<pre>[code, language=r]par(mfrow=c(1,2))
plot(flow$output[[1]])
points(flow$occurrence[[1]][,1:2])
plot(flow$output[[2]])
points(flow$occurrence[[2]][,1:2])
[/code]</pre>
<p><img src="parallelSp.png" alt="Plotted output" title="" /></p>
<p>So any of the modules can be given parallel modules in this fasion. But only one module can have multiple modules as it is unclear quite what would be wanted with multiple sets of modules and if it's all combinations then this will quickly get fairly ridiculous.</p>
<pre>[code, language=r]x <- workflow(occurMod = list('UKAnophelesPlumbeus',
'UKAnophelesPlumbeus'),
covarMod = list('UKAir', 'UKAir'),
procMod = 'OneHundredBackground',
modelMod = 'LogisticRegression',
outMod = 'SameTimePlaceMap')
Error in workflow(occurMod = list("UKAnophelesPlumbeus", "UKAnophelesPlumbeus"), :
[/code]</pre>
<h1>To do</h1>
<h2>Daisy chain</h2>
<p>Following on from the listable work above I really need to now write functions that 'daisy chain' modules together rather than running them in parallel. For example, as output we might want AUC and a map, but that shouldn't stop us running two species. Or we might want to use species data from two sources but want to combine them and run a number of models, rather comparing analyses done with the two datasets separately.</p>
<h2>Multicore</h2>
<p>Something that I won't be doing immediately but might be quite easy and useful to implement is to make these analyses run on parallel cores. As the code is written with *apply functions, this should be fairly quite straight forward.</p>
<h2>Cross validation</h2>
<p>This is probably what I will do next. The main functions need to be rewritten so that cross validation and external validation is an integral part of the workflow</p>
<h2>Documentation</h2>
<p>It's not quite clear how to do the documentation for modules. As the modules are held on repositories, the documentation isn't loaded automatically with the package. Furthermore, we want it to be easy for contributors to add well documented modules. This will probably be done by making the MakeModule() function ask for information.</p>
<p>As a first attempt I think the documentation will be just written manually and held on the online repo. A new function will call the documentation given the module name.</p>