zoonproject / zoon Goto Github PK

tmpZoonWork <- ErrorAndSave(...)
return(tmpZoonWork)

instead of global assignment i.e. assign('tmpZoonWork', w, env = 'GlobalEnv()) or whatever it is.

Need to think about what information the output module might potentially need. I think process.output and model.output may contain everything (covariate and occurrence data are all in process). So need to rewrite sametimeplacemap module to match that.

We want to be able to view lists of each module type. This seems the easiest way to do it.

Calling NCEP or some other online environmental dataset is quite slow and therefore not ideal for examples (and annoying when rebuilding package/vignettes.)

Easiest is probably to download a dataset and bundle with package if that's allowed.

It would be good to (after the workshop) set up continuous integration for both zoon and modules.

See e.g.
http://yihui.name/en/2013/04/travis-ci-general-purpose/
https://github.com/craigcitro/r-travis
http://www.rdocumentation.org/packages/devtools/functions/add_travis

This would be particularly helpful for the modules package as I'm assuming it would autobuild the docs as soon as a new module is added.

Firstly add the code from the bottom of the gist as an example for the workflow function.

It may be worth adding minimal examples for the other modules too, though we still haven't decided on the right type of repository for those, so that's not urgent at all.

look in zoon/R and you'll see what I mean.

I think the command you want is something like: git rm --cached zoon/R/*.R~

In fixing #40 we have prevented execution of functions given to arguments.

The easiest way to tell between list(mod1, mod2), Chain(mod1, mod2) and mod1 is to simply see if the first element of the substituted argument is 'list', 'Chain' or something else.

I think there's probably some reason why this is bad coding style.

Furthermore it means Chain is not a function that is ever actually called. It need documentation though. So perhaps I need to make a phantom function or something.

It makes more sense to list the output modules rather then Chain them to do what they currently do. Chains could be used to pass one output to another output

We need to choose a licence (two 'c's is a noun, with an s is a verb apparently.)

Both of these appear in the manual, but neither function is visible when I install & load the latest version on my linux machine. GetModuleList works fine.

As well as having examples in the documentation, having a constantly updated vignette seems a good way to keep everyone up to date on how the package works.

It works well as the vignette is recompiles with each new package build, and is automatically (I think) downloaded when the package is downloaded.

Adding the full code to the output of the workflow function for reproducibility, recording the package versions and session info.

GetModuleList should either by default or as an option give a one liner description of each module.

Pick a style guide and state it somewhere (on the blog/readme/wiki?), reformat the current code to it, then follow it, ruthlessly.

Google R style guide or a variant might be a good option.

Need to set.seeds() within each module so that parallel modules are comparing some thing. e.g. if we compare two data sets, we want the same pseudorandom background points. Need to check I'm doing it sensibly and reproducibly all the way through though.

I still can't get this to work for my new modules, I get:

> ModuleHelp('UKBiomod')

Warning: /tmp/RtmpkaxY78/UKBiomod.Rd:1: All text must be in a section
Error: /tmp/RtmpkaxY78/UKBiomod.Rd: Sections \title, and \name must exist and be unique in Rd files

for UKBiomod, OneThousandBackground, OptGRaF and QuickGRaF

works for yours though, e.g.:

> ModuleHelp('LogisticRegression')

Model module: LogisticRegression

Description:

     Model module to fit a simple logistic regression model

Usage:

     LogisticRegression(df)

See Also:

     ‘glm’

The progress so far should be accessible in case of a crash.

Once the package is ina reasonable state need to spend some time writing a test suite.

Someone at the zoon workshop was experiencing this error.
Looks like it should a) throw and error and b) be fixed.

Warning messages:
1: In names(df)[6:ncol(df)] <- names(ras) :
number of items to replace is not a multiple of replacement length

Add a tag (probably an attribute) that says whether a workflow was run entirely from the online repo and is therefore reproducible (given that the data is bundled with it.)

The way the workflow is currently written, you get multiple copies of the wholw environmental rasters. I think this is probably a bad idea but would need to think about how best to fix it.

We're going to have to work out a user friendly way of installing this sort of awkward software.

Chris Clements tweeted a helpful suggestion for rgdal and rgeos:

Want to install the "rgdal" and "rgeos" #R packages? try this:

install.packages(c('rgdal','rgeos'),repos="http://www.stats.ox.ac.uk/pub/RWin ")
(https://twitter.com/CClements88/status/509958777303736320)

though I haven't explored that

Perhaps for maxent we could link to the page to accept the licence (http://www.cs.princeton.edu/~schapire/maxent) and get the jar then try and handle putting it in the right place for the user?

Hi,

Looks like you have done a terrific work! Looking forward to trying it.

Now I just wanted to comment that I'm also getting an error when running the Biomod workflow in https://github.com/zoonproject/zoon/blob/master/zoonQuickStart.R.

After a quick look I suspect it might be related to your chosen 'modeling.id' argument in 'BIOMOD_Modeling' function (https://github.com/zoonproject/modules/blob/master/R/BiomodModel.R).

With the current specification:
modeling.id = paste('zoon',Sys.time(),sep=" ")
the resulting file path ('Species/.BIOMOD_DATA/zoon 2014-09-17 00:12:33/formated.input.data') is probably not valid, at least in Windows, due to the colons. That causes an error in gzfile:
In gzfile(file, "wb") :
cannot open compressed file 'Species/.BIOMOD_DATA/zoon 2014-09-17 00:12:33/formated.input.data', probable reason 'Invalid argument'.

I'd suggest a quick check using the standard 'modeling.id' in Biomod, i.e. modeling.id = as.character(format(Sys.time(), '%s')), to see if that sorts out the problem.

Thanks and see you soon,

Paco

Hi,

When I try to install the package I get this error. Any guesses at what it could be? It gets messed up when it tries to deal with the vignette.... do I need to have latex installed? Or perhaps you have omitted a file needed to build the vignette?

Hope we can get the sorted tomorrow!

Tom

install_github("zoonproject/zoon")
Installing github repo zoon/master from zoonproject
Downloading master.zip from https://github.com/zoonproject/zoon/archive/master.zip
Installing package from C:\Users\Tom\AppData\Local\Temp\RtmpQlt7PR/master.zip
Installing zoon
"C:/PROGRA1/R/R-301.2/bin/x64/R" --vanilla CMD build
"C:\Users\Tom\AppData\Local\Temp\RtmpQlt7PR\devtools193828231c4d\zoon-master"
--no-manual --no-resave-data

• checking for file 'C:\Users\Tom\AppData\Local\Temp\RtmpQlt7PR\devtools193828231c4d\zoon-master/DESCRIPTION' ... OK
• preparing 'zoon':
• checking DESCRIPTION meta-information ... OK
• installing the package to build vignettes
• creating vignettes ...Error in find_vignette_product(name, by = "weave", dir = dirname(file), :
  Failed to locate the 'weave' output file (by engine 'utils::Sweave') for vignette with name 'vignette'. The following files exists in directory 'C:/Users/Tom/AppData/Local/Temp/RtmpkNqD9L/Rbuildac443ac7f1f/zoon/inst/doc': 'basic-zoon-usage.R', 'basic-zoon-usage.Rmd', 'basic-zoon-usage.html', 'vignette.Rnw'
  Execution halted
  Error: Command failed (1)

Currently some tests require packages. The tests pass if the packages are installed and fail if not. Long term, this means they will fail. Not sure how best to fix it and how other people deal with this.

Overview

Nick and I have been discussing some of the problems with syntax here. #42

I have made the package so that it can accept modules like this

workflow(UKAnopheles, UKAir, Crossvalidate(k=2), LogReg, PrintMap)

as discussed at the workshop.

A tweak that I will make but haven't yet is to make GetModules search for module names in the global namespace first and in the github repo second.

URL/Paths syntax

The bit we're stuck on is what the syntax for a module being defined by a path or url, but with extra arguments should be. I've put the types we've thought of below. They are all possible. If you could opinions or simply votes, that would be great.

a) String as function

This is already downvoted by Nick, but adding for completeness.

workflow('/pathto/myModule.R'(arg = 1, para = 'something'),
         'www.github.com/name/repo/moduleName.R'(options = 2),
         ...)

b) Get function with params after

workflow(get('/pathto/myModule.R')(arg = 1, para = 'something'),
         get('www.github.com/name/repo/moduleName.R')(options = 2),
         ...)

c) A function like ModuleOptions

workflow(ModuleOptions('/pathto/myModule.R', arg = 1, para = 'something'),
         ModuleOptions('www.github.com/name/repo/moduleName.R', options = 2),
         ...)

d) Separately define repo location

workflow(myModule(arg = 1, para = 'something'),
         moduleName(options = 2),
         occurrence_repo = '/pathto', 
         covariate_repo = 'www.github.com/name/repo/',
         ...)

e) Separately define repo location as arg

workflow(myModule(arg = 1, para = 'something', repo = '/pathto'),
         moduleName(options = 2, repo = 'www.github.com/name/repo/'),
         ...)

f) Disallow directly calling from a custom path

Instead make users load the function into the global environment for development

source('/pathto/myModule.R')
source('www.github.com/name/repo/moduleName.R')

workflow(myModule(arg = 1, para = 'something'),
     moduleName(options = 2),
     ...)

ModuleHelp should convert it's argument to a string

ModuleHelp(NCEP) and ModuleHelp('NCEP') should be the same. This matches help() as well.

‘Output.output’ - perhaps nice to denote the output from the last step in the workflow as ‘Report’.

The substitute stuff to make the syntax nicer has broken the ability to give a module path as an object e.g.
path <- '~/MyMod.R'
w <- workflow(path, ....)

now doesn't work because substitute reads this as 'path' not '~\MyMod.R'.

Send out workshop emails!

Just opening this so that I can close it.

As discussed at the workshop we want to move from
workflow(occurMod = ModuleOptions('SpOcc', species= 'Milvus milvus', ...

to

workflow(occurrence = SpOcc(species = 'Milvus milvus'), ...

A visual representation of the workflow should basically be everywhere.

We want to be able to run examples of presence-absence as well as presence only models. It would be good to find either an online PA dataset we can easily link to (figshare etc.) or else bundle one with the package.

I don't know how to do this but I think we need to add metadata to the roxygen comments and sort by that.

First thoughts are that we don't want to read the text of every module just to print a list of modules. So I'm not sure how to fix this.

Once continuous integration is sorted, it might be easiest to do a nightly run of reading each file, reading the meta data and making a separate file with the module list. GetModuleList() then simply needs to read that file. This also fixes the requirement for a github password to use GetModuleList.

Not sure, but think it's in the worng place. Should be passed down to GetModule

This was a quick hack to get stuff working for the workshop.

Now I want to move RunModels outside of the workflow function. But there was environment issues last time.

In moving the modules to another repo I have made it so that the outputted script no longer works (i.e. the workflow = workflow element of the output list from function workflow. Quite confusing there. Line 327 in the zoon_sketch.). Before fixing it I thought I would check what the aims for this part of the package is.

I'm still a little confused between the difference between this outputted script, which is reproducible, and the original handwritten script, which is also in theory reproducible.

I suppose the idea of the output script is that no matter what happens to the rest of the code, if the workflow function is runeable, there will be a reproducible script.

How much detail should go in there? Now that the modules have been moved online, they are similarly as stable as all the code in the packages that are loaded during the analysis.

Process modules must have the argument data. This shouldn't be documented (i.e. in the usage section) because then people will start trying to set that argument, when it is set by the internals of workflow.

In the workflow function all the arguments are suffixed with Mod, this seems redundant.

Currently gives:
$call
function (name, ...) .Primitive("call")

need to fix.

Currently assigns to global. Should be one up.

Currently this:

# run a workflow, using the logistic regression model
ans1 <- workflow(occurMod = 'UKAnophelesPlumbeus',
                covarMod = 'ThisShitIsBananasB-A-N-A-N-A-S',
                procMod = 'OneHundredBackground',
                modelMod = 'RandomForest',
                outMod = 'SameTimePlaceMap')

only returns this:

Error in GetModule(x$module, type) : 
  Cannot find the module. Check the URL or check that the module is at github.com/zoonproject

It would be useful to know which model doesn't exist, and at some point in the future some sort of fuzzy matching with suggestions?

Rename to avoid confusion between GetModule and GetModules.

Just for future refernce.
I tried to clean up the code for workflow
4434ccf
However it is harder than it looks. Moving code out of workflow means that any call to module functions (eg LogisticRegression()) fails because these functions are only in the workflow environment. I guess you'd have to pass down the environment name like I did with RunModels. But that's a pain.

I'm thinking we should probably set up a separate zoon organisation github account and have the main zoon repo in there, that way we can keep going on it when Tim finishes his internship.

Are you happy to do that Tim?

Adding authors to the modules.

Having install_github in GetPackages gives a warning on R CMD check which will annoy CRAN.

However, I'm not sure it's great to have devtools in imports. I don't know if suggests devtools gets round this?

Given #45, we might need to make an argument that forces workflow to get modules from the repo, even if they exist locally in order to confirm that the workflow is reproducible.